-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatically add and remove dedicated masters. #814
Conversation
93b0677
to
f8f7fb2
Compare
If no master tier is configured, it is automatically added/removed: - Added if the number of nodes is >= the dedicated master threshold - Removed if the number of nodes is < the dedicated master threshold If the TF config already contains a master tier, the plan-modifier is skipped.
ed50d36
to
10861ec
Compare
d4ad4cc
to
bb68f78
Compare
ec/ecresource/deploymentresource/planmodifiers/topology_dedicated_masters.go
Outdated
Show resolved
Hide resolved
ec/ecresource/deploymentresource/planmodifiers/topology_dedicated_masters.go
Outdated
Show resolved
Hide resolved
ec/ecresource/deploymentresource/planmodifiers/topology_dedicated_masters.go
Outdated
Show resolved
Hide resolved
ec/ecresource/deploymentresource/planmodifiers/topology_dedicated_masters.go
Outdated
Show resolved
Hide resolved
ec/ecresource/deploymentresource/planmodifiers/topology_dedicated_masters.go
Outdated
Show resolved
Hide resolved
This happens if a tier requests more memory than the largest size available. In this case multiple nodes are provisioned.
@tobio thank you for the feedback. I implemented your feedback in the last two commits. |
ec/ecresource/deploymentresource/planmodifiers/topology_dedicated_masters.go
Outdated
Show resolved
Hide resolved
ec/ecresource/deploymentresource/planmodifiers/topology_dedicated_masters.go
Outdated
Show resolved
Hide resolved
ec/ecresource/deploymentresource/planmodifiers/topology_dedicated_masters.go
Outdated
Show resolved
Hide resolved
It is important to use UseTopologyStateForUnknown here, as UseStateForUnknown will also set a state for all children of the topology. However the children should stay unknown and their plan modifiers don't run. This leads to problems when migrating templates, as the master tier should then not use the state and instead get the new values from the new template.
- The IC should only be updated if 'migrate_to_latest_hardware' is set - When this is set -> Take the latest values from deployment-template - The master tier should only be updated in the plan if it actually is being enabled or disabled - When the master tier has a ic-id and ic-version, those should be used to decide the default size and zone-count - However the deployment-template will always contain the latest version, which may not be the one used in the tier currently - So now the plan-modifier will load the correct IC via API and then use that
- Use template if migrateToLatestHw==true - Try using IC from private state - Fall back to template if no IC in private state (for example during create)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work 👍
@dimuon thank you very much for taking the time to review this 🥇 |
Hello @gigerdo , any timeline to when this will be released ? |
@hnajib-sym we do have plans to release a version 0.11 soon, though we don't have an exact timeline. |
We also have run into this same issue and would love to see a release soon! |
We have now release 0.11.0 which contains this feature: |
Description
If the terraform config defines no master, the provider will add/remove it as needed:
Regarding the implementation:
ModifyPlan
modifier to first calculate the number of nodes, then adds or removes the master tierRelated Issues
#635
(Most of the problems described in that issue have already been solved, this PR just adds automatically adding/removing master tier)
Motivation and Context
How Has This Been Tested?
Types of Changes
Readiness Checklist