-
Notifications
You must be signed in to change notification settings - Fork 53
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
Approval controller improvements #398
Comments
cc @arora-sagar |
related: kptdev/kpt#4040 |
/retitle Approval controller improvements In the long run, we could design a more robust approval controller that has ApprovalPolicy resources that we can attach to packages. However, for now, we can make some iterative improvements. As a quick hack, we could make
See https://github.com/nephio-project/nephio/blob/main/controllers/pkg/reconcilers/approval/ for the code. This could be a nice, well contained piece of functionality for someone wanting to get a taste of controller development. Another little tweak would be to send an event when we approve. Right now, we only send events for failures or when we are "waiting". It would be a better UX to see an approval event as well. That would be here: https://github.com/nephio-project/nephio/blob/main/controllers/pkg/reconcilers/approval/reconciler.go#L202 cc @adetalhouet |
Oh - for 3) this will allow a cascading delete from PVS, because when you delete the PVS, it deletes the PV resources, which in turn results in the PackageRevision going to DeletionProposed. |
Triaged |
Looking at #797, I think we need another policy that just auto-approves everything. It should be really easy to implement. Basically, instead of "initial", we "always" or "ready" which approves any thing that has met the readiness gates. That will allow our controllers to make multiple revisions and avoid some of the race conditions inherent in the "initial" policy use. |
Continuing the conversation from the closed #797: If this is the case, wouldn't it help, if the PackageVariant controller would create the new v1 PackageRevision with a false readiness gate in the very first place, and only set the readiness gate to true after all the mutations are applied? This would help us avoid race conditions between the PackageVariant and Approval controllers. This seems to me as a better way of solving the problem than tweaking the timing. |
I think the PackageVariant is not marked ready until all mutations are done, and the approval controller checks that. Maybe there is a bug there? Note that package variant readiness is distinct from the package revision readiness gates. Both are supposed to be true for the approval controller to do its thing. |
So, based on the approval controller code, approval shouldn't kick in until mutations are done, because the approval requires both PackageVariant and PackageRevision to be ready, and PackageVariant readiness implies all mutations are done. However, maybe there is a bug where one (or both) of the PackageVariant/PackageRevision are showing "ready" briefly when they shouldn't be? |
Yes, according to my theory there is such a moment, when both PackageVariant and PackageRevision is "ready", but not all the mutations were applied to the PackageRevision. So using the "always" approval policy indeed solves this, and I agree we should implement that. |
Please note that I have no proof yet, that what I wrote above is actually happening, it is just a theory |
Sounds like a good idea! |
No description provided.
The text was updated successfully, but these errors were encountered: