-
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
✨ Make sure IPAddressClaim has a cluster name label. #9883
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Who's responsible for adding this label? If users, I'd say this should be a field, like
spec.Cluster
like in other objectsThere 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.
Are we sure we want to enforce that an IPAddressClaim has to belong to a cluster?
Today it's perfectly fine to use this CRD independent of a Cluster, which I could imagine can be quite useful in some cases.
(One rare use case that we have in CAPV e2e tests is that we basically have a separate cluster running once that we can use for IPAM purposes. This is entirely separate of mgmt clusters and the "reserved" IP addresses are then used in e2e mgmt clusters)
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.
Agreed, it seems this should have been discussed in the related issue. I was more commenting on the implementation of this constraint rather than looking at the semantics of the CRD; I haven't used these CRDs much, so I'll leave it to the folks responsible for them.
cc @rvanderp3
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.
Yup got it. Sorry just thought my point somewhat fits to yours :)
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.
Maybe @fabriziopandini can add more thoughts in this regards
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.
I agree with Stefan, I don't think we should enforce this. Providers should set the label when creating claims that are part of a cluster, but we shouldn't make it mandatory for every actor.
We (I) still need to create a proper IPAM contract description, which should include this as a requirement.
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.
If a label is required to link the claim to a cluster, the label should be a field, can be optional in this case; but we shouldn't rely on labels as a good API to expose to users in this context
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.
if this is not needed, feel free to close it.
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.
I agree, and so do the k8s api guidelines I think, that labels (and annotations) shouldn't be used if a property can be used instead.
Since the label is set on a lot of resources, which makes sense for querying them with clusterctl, the immediate thought is to use the label instead of a property to avoid duplicating data.
#10182