-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Consistent metadata propagation behaviour #5240
Comments
/milestone Next Is this a bug? |
/priority important-soon |
@vincepri Depends on what we want to behavior to be. I'm not sure what we want but the current behaviour seems to be a bit inconsistent. I'm not sure if the expected behavior is specified somewhere. |
We're relying on the In my opinion it would also be good to extend cc @MaxRink @sbueringer I think |
My opinion on the situation: KCP => lgtm
I think it's strange to propagate top-level MD.annotations to MS.annotations
It think we should also propagate (I would rather propagate
Seems more consistent to me to also propagate |
I think we should always either propagate both, annotations and labels, or neither. It's not very intuitive (nor logical) if only one is propagated. |
100% agree. Basically my comment comes down to: "let's always propagate both and let's stop propagating top-level MD annotations" |
I agree with sorting this out. Me and @sedefsavas were looking at this the other day and were pretty confused about what gets propagated and doesn't. |
+1 for consistency |
Discussing with @schrej , @vincepri and @sbueringer in Slack, the conclusions we've reached is that: MDs should behave like appsv1/Deployment In which case, the behaviour is, where d = appsv1/deployment and r = replicaset d.annotations => r.annotations This is in https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/deployment/sync.go#L146-L150 and https://github.com/kubernetes/kubernetes/blob/38746752af6d0ec955f4511a727da37347da3b92/pkg/controller/deployment/util/deployment_util.go#L232 with a comment here: kubernetes/kubernetes#92896 (comment) From this, it would appear the outstanding task is to propagate MS.spec.template.metadata.annotations to KubeadmConfig.meta.annotations if we want to be consistent. |
/milestone v1.0 |
There is an outstanding question about InfraMachineTemplate.Spec.Template.Meta and KubeadmConfigTemplate.Spec.Template.Meta . Should all providers implement this, what is the merge behaviour, and who should when there's conflict? |
/reopen The current implementation just takes everything in cluster-api/controllers/external/util.go Line 144 in 9fdf087
Neither KubeadmConfigTemplate nor DockerMachineTemplate have .Spec.Template.Meta fields |
@sbueringer: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
The same is true for the other infra providers, so we should add something to the v1beta1 docs? |
In wonder if/where we have guidance how the templates should be implemented. |
I'll have a look and knock something up. |
/assign I'll take a look at closing out the last couple of issues related to this. |
v1alpha4 <-> v1beta1 conversions were failing and never tested. As part of the PR - Add a missing gcpclustertemplate_conversion.go file - Add conversion test to make sure conversions work - Add ObjectMeta to GCPClusterTemplateResource and GCPMachineTemplateResource. See kubernetes-sigs/cluster-api#5240
v1alpha4 <-> v1beta1 conversions were failing and never tested. As part of the PR - Add a missing gcpclustertemplate_conversion.go file - Add conversion test to make sure conversions work - Add ObjectMeta to GCPClusterTemplateResource and GCPMachineTemplateResource. See kubernetes-sigs/cluster-api#5240
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen |
@sbueringer: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle-state |
/reopen |
@schrej: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@schrej Is there something specific outstanding on this issue we should tackle? |
Oh sorry, just saw your misspelled lifecycle command and missed the PR. /close |
@schrej: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
I didn't even notice that until now 😆 |
I'm not entirely sure how it should be, but let's discuss in this issue how we want metadata to propagate and then adjust the implementation accordingly.
Right now the metadata is propagated as follows: ( from => to)
KubeadmControlPlane
.labels =>
.annotations =>
.spec.machineTemplate.metadata.labels => Machine.labels, InfraMachine.labels, KubeadmConfig.labels
.spec.machineTemplate.metadata.annotations => Machine.annotations, InfraMachine.annotations, KubeadmConfig.annotations
MachineDeployment
.labels =>
.annotations => MS.annotations
.spec.template.metadata.labels => MS.labels, MS.spec.template.metadata.labels
.spec.template.metadata.annotations => MS.spec.template.metadata.annotations
MachineSet
.labels =>
.annotations =>
.spec.template.metadata.labels => Machine.labels, InfraMachine.labels, KubeadmConfig.labels
.spec.template.metadata.annotations => Machine.annotations, InfraMachine.annotations
/kind bug
The text was updated successfully, but these errors were encountered: