-
Notifications
You must be signed in to change notification settings - Fork 28
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
Proposal of handling of module status #1630
base: main
Are you sure you want to change the base?
Conversation
I think ADR should be focused around one solution that is already the one that we want to implement, rather than presenting possible solutions. That creates open questions which are in contradiction with Architecture Decision Record, because the architecture decision is yet to be made. I think we should analyse each of the solutions, present results, decide which solution to accept, and then prepare a decision record. Moreover, I think we should really think again how our operator handles resources. Maybe it'd be better to just reduce the dependency in APIGateway CR controller to actually handle the lifecycle of application controllers, and maybe move some of the logic to separate controller... Moving back to the topic - usually the status keeps the finite state of a resource and changes if the said state changes. That means setting a status rather should be a final step in resource reconciliation. Keeping Ideally this should look like that:
|
Let's rework the document a little bit, so the proposed solution is described in details in the main section (like 'Decision') and put other ones in 'considered alternative solutions'. |
Description
Changes proposed in this pull request:
Pre-Merge Checklist
Related issues