-
Notifications
You must be signed in to change notification settings - Fork 592
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
Defaultcontroller #843
Defaultcontroller #843
Conversation
and update its status in case the channel is not being watched by any controller This could happen if the end user creates a channel but doesn't install the provisioner. Issue#779: knative#779
/assign @n3wscott |
/assign @grantr |
I'd actually update the Release Notes seciton, since it has user visible changes. Also, we should make sure to update documentation with this information and probably update the debugging also. Not as part of this PR, but we should probably create an issue to track or put out a PR to update those. |
…roller Merge from upstream/master and missing dependency
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 think there is a clarification that is required around our expectations of the Ready condition and the default provisioner controller. I would not expect it to set Ready
at all.
There is also a question of if this controller should update this status on the normal re-reconcile period if it finds there to be no provisioner. It would sure be interesting to get that set on the channel that worked and then the provisioner went away and now my stuff is broken? |
I don't agree with not setting the Ready condition. I think this is the correct user experience that is expected. Thoughts? |
…itialize() function from MarkProvisioned()
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 can live with this version 😄 I think there could be a todo added or issue created to follow-up on if we should fetch the provisioner and see if it is having a bad day or not and then propagate it's status up.
/lgtm
The following is the coverage report on pkg/.
|
/lgtm |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: akashrv, n3wscott, vaikas-google The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Matthias Wessendorf <mwessend@redhat.com>
Fixes #779
Proposed Changes
The API server Update API support optimistic concurrency based on resource version. When using controller client to update, if the object on server side changes after reading the object and before updating it in the controller, then the update api will fail with CONFLICT error. This is handled by re-queueing the request for reconcile.
I have verified this behavior with current code on a GKE cluster.
Release Note