feat: use go template for cluster resource names #552
feat: use go template for cluster resource names #552sylr wants to merge 5 commits intoAzure:masterfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: sylr If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
a109faf to
97cb720
Compare
0182c40 to
4e5ec7d
Compare
|
@jackfrancis @CecileRobertMichon @tariq1890 could you please review this. It is a fairly big change in terms of volume of code so I would appreciate if we could move along quickly so that it does not conflict with other PR. Thank you. |
4e5ec7d to
039c7ed
Compare
039c7ed to
92e6c89
Compare
|
@sylr could you |
|
Also FYI this is was rebased/force-pushed after master was changed to no longer require generated code. |
Signed-off-by: Sylvain Rabot <s.rabot@lectra.com>
Signed-off-by: Sylvain Rabot <s.rabot@lectra.com>
Signed-off-by: Sylvain Rabot <s.rabot@lectra.com>
92e6c89 to
efe2c6e
Compare
|
@mboersma Done. |
|
This change is not backwards compatible. See this upgrade operation on this branch against a cluster built w/ v0.31.1: The api model used to build the original cluster: |
|
We read the vm name suffix from the see : aks-engine/pkg/operations/kubernetesupgrade/upgradecluster.go Lines 166 to 172 in 707cf6a |
|
@serbrech I removed that https://github.com/Azure/aks-engine/pull/552/files#diff-95227b07e97ba7cbd04cfd8b2cdb6980L168 I think I'll remove the selection of the VM based on resource name and replace it with tag matching. |
Signed-off-by: Sylvain Rabot <s.rabot@lectra.com>
Signed-off-by: Sylvain Rabot <s.rabot@lectra.com>
|
I don't think we should add a dependency on VM tags in upgrade. VM tags are often changed by users and are not sticky. Removing them will cause a no-op upgrade. We ran into the same issue in the past which generated a large amount of support tickets for AKS because customers' VMs weren't getting upgraded when they had changed/removed the VM tags and we eventually worked to remove that dependency. @mboersma might be able to bring more context since he implemented the PR to fix it. See Azure/acs-engine#3663 for background. |
|
This is becoming too difficult for me to implement something that will comply with AKS needs which I'm completely unaware of. I'm currently happy with the PR as it for the needs of my company and I can hardly make the case internally to spend more time working on this as it will not directly benefit my company. It would have been nice to have this feature merged but I believe I will have to make it live in a soft fork and rebase it when needed. |
|
@sylr Totally understood. Do we have a comprehensive statement of functional requirements? We can file an issue and gather interest in terms of priority there. As you point out, it's difficult for you to have a full grasp of the back-compat ramifications as they relate to AKS Engine being a downstream dependency for AKS, and implementation of this work may have to be guided by AKS. |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
New attempt at #56
Follow up of #202