-
Notifications
You must be signed in to change notification settings - Fork 106
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
Discussion: How paused state for a managed resource should be reported? #363
Comments
Quoting my message from Slack. This was a long discussion when we first discussed how to do observe-only resources, i.e. whether it should be an annotation/policy field or a separate kind. Where we sort of landed was a separate kind with There is a conceptual race there about whether the desire is spec or the annotation when both exist. I’d personally approach from another angle as well which is the fact that we set |
Intuitively
Could you state explicitly what the concerns are? |
I'm not sure how much we can really change at this point - I would consider status conditions as part of a resource's API and thus changing the status conditions (with perhaps the exception of the human readable message) to be a breaking API change. That said, I think
|
Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as |
What problem are you facing?
In a recent discussion with @luebken and @muvaf and me, there were some concerns around how the paused state of a managed resource is communicated. The current behavior is to put the resource into a
Synced=False
state with the reasonReconcilePaused
as follows:So for example, if the managed resource is
Ready=True, Synced=True
state, pausing it will transition it into theReady=True, Synced=False/ReconcilePaused
state omitting apaused
event on the managed resource. A subsequentkubectl get
on the managed resource will also reportSYNCED=False
:> k get vpc NAME READY SYNCED ID CIDR IPV6CIDR AGE my-resource-7q8tk-v4hjw True False vpc-077f9c262d8241fe7 192.168.0.0/16 19h
and then a
kubectl describe
or akubectl get -o yaml
can be used the check if theSynced=False
is due to aReconcileError
or aReconcilePaused
.And if the
crossplane.io/paused
annotation is removed, or its value is changed to something other than"true"
, then the managed resource will transition into theSynced=True
(if there are no reconcile errors), or theSynced=False/ReconcileError
state.We should also keep in mind that once all the events associated with a paused managed resource are drained from the controller's workerqueue, no further events are queued for the paused managed resource and we will not observe any more
paused
events for the resource unless an external entity (client) modifies/deletes the managed resource, causing new reconciliations.With this issue, we would like to discuss:
Synced=False
status condition only toReconcileError
s and remove theReconcilePaused
reason associated with theSynced=False
condition.Synched=False
condition, whether we want to report this state as part of the resource'sstatus
somewhere (like with a new status condition or elsewhere likeReady=False
, etc.)How could Crossplane help solve your problem?
I'm opening this issue for collecting feedback and ideas and also to increase awareness for the new feature.
The text was updated successfully, but these errors were encountered: