Skip to content
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

JSON6902 patches should allow matching on group when version is not specified #1332

Open
BenTheElder opened this issue Feb 13, 2020 · 6 comments
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.

Comments

@BenTheElder
Copy link
Member

What would you like to be added:

the internal patch runtime should handle group / version matching so that GK can be specified without full GVK (Group, Version, Kind).

basically we want to allow not specfiying V (version) since versions are often largely the same but group and kind key totally different objects and we probably don't want patches applied to all objects.

Why is this needed:

To avoid surprising behavior when version is left unspecified in JSON6902 patches

/assign

@BenTheElder BenTheElder added the kind/feature Categorizes issue or PR as related to a new feature. label Feb 13, 2020
@BenTheElder BenTheElder added the priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Feb 18, 2020
@BenTheElder BenTheElder removed their assignment Feb 21, 2020
@BenTheElder BenTheElder added the help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. label Feb 21, 2020
@BenTheElder BenTheElder added this to the 2020 goals milestone Feb 27, 2020
@jiatongw
Copy link

Hi @BenTheElder, I have an idea.
Generally, a patch would be like this:

kubeadmConfigPatchesJson6902:
- group: kubeadm.k8s.io
  version: v1beta2
  kind: ClusterConfiguration

If the version field is empty, then we could get the kubeadm config file and read the version there. Then I could add the version field to the patch - I mean, programmatically. Then we could merge the patch to kubeadm config without any surprise. WDYT?

@jiatongw
Copy link

This is only for Kubeadm patch. For others, e.g. containerd patch, I have to dig more, or maybe this approach could also work

@BenTheElder
Copy link
Member Author

We should not take this approach, because we also need to patch other component configs (kube-proxy, kubelet...)

We should fix how the match considers the group / version to be matching, the merge patches already support this correctly.

@BenTheElder
Copy link
Member Author

"kubeadm config" is a bit of a misnomer and should probably get renamed, those patches patch the data that is supplied to kubeadm currently, which is more than just kubeadm's config object(s).

@jiatongw
Copy link

Your are right. I just focused on kubeadm configs. Let me do more research. Meanwhile, if you have better idea, please at me as well. I am happy to work on this

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 24, 2020
@BenTheElder BenTheElder added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jun 24, 2020
@kubernetes-sigs kubernetes-sigs deleted a comment from fejta-bot Jun 24, 2020
@BenTheElder BenTheElder modified the milestones: 2020 goals, 2021 goals Jan 25, 2021
@BenTheElder
Copy link
Member Author

re: renaming #2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Development

No branches or pull requests

3 participants