crd: add status sub resource #3
Merged
Conversation
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
|
/cc @qinqon |
qinqon
requested changes
Sep 18, 2023
There was a problem hiding this comment.
Also the fact that we can differenciate between resource and subresource at Roles is an important feature so for example a user that creates the CRD can read the status.IPs but not modify it.
From k8s docs
Types with both spec and status stanzas can (and usually should) have distinct authorization scopes for them. This allows users to be granted full write access to spec and read-only access to status, while relevant controllers are granted read-only access to spec but full write access to status.
Can you add this as a bullet at PR/commit description ?
qinqon
approved these changes
Sep 18, 2023
An approach with a status sub-resource would be interesting for scenarios where a separate `IPAMLease` controller operates as an IPAM controller; the client workload controllers (e.g. KubeVirt) would: - create an IPAMLease object - the IPAMLease controller would see this CR being created, generate an IP for it, and update its status - the client workload controller would see the IPAMLease update (i.e. the IP allocation) and be able to template the pod object requesting this static IP address. Thus, the workload controller - e.g. KubeVirt - would have write access to spec and read-only to status, while the IPAM CNI would have read-only access to the spec while having full write access to the status sub-resource. Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
maiqueb
force-pushed
the
add-status-subresource
branch
from
fb95e88
to
845b64a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
An approach with a status sub-resource would be interesting for scenarios where a separate
IPAMLeasecontroller operates as an IPAM controller; the client workload controllers (e.g. KubeVirt) would:Differentiating between resource and sub-resource at Roles allows having distinct authorization scopes; meaning users can be granted full write access to spec and read-only access to status, while relevant controllers are granted read-only access to spec but full write access to status.
Thus, assuming KubeVirt would be "the" reference client, we would have the KubeVirt controller as having write access to spec and read-only to status, while the IPAM CNI would have read-only access to the spec stanza, while having full write access to the status sub-resource.