Skip to content
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

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

barchw
Copy link
Contributor

@barchw barchw commented Jan 22, 2025

Description

Changes proposed in this pull request:

  • Proposal of handling of module status

Pre-Merge Checklist

  • As a PR reviewer, verify code coverage and evaluate if it is acceptable.

Related issues

@kyma-bot kyma-bot added do-not-merge/work-in-progress cla: yes Indicates the PR's author has signed the CLA. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jan 22, 2025
@barchw barchw marked this pull request as ready for review January 22, 2025 08:17
@barchw barchw requested a review from a team as a code owner January 22, 2025 08:17
@Ressetkk
Copy link
Contributor

Ressetkk commented Jan 24, 2025

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 Processing as transient state will make a problem with resource conflicts, if you for example set this state at the beginning of reconciliation, then you have to Get() resource again to fetch its updated state.

Ideally this should look like that:

  1. User applies a CR
  2. Controller schedules bunch of stuff
  3. Controller sets up Processing status, finishes reconciliation and queues the next run in seconds
  4. In the next run controller checks the state of each of the stuff we scheduled
  5. If they are working/done, controller sets state to Ready and finishes work
  6. If they failed, controller sets state to Error/Warning and finishes work - user attention is needed
  7. If they still run, controller leaves Processing status and queues next run.

@kasiakepka kasiakepka requested a review from strekm January 29, 2025 08:55
strekm
strekm previously approved these changes Jan 29, 2025
@kyma-bot kyma-bot added the lgtm Looks good to me! label Jan 29, 2025
@kyma-bot kyma-bot removed the lgtm Looks good to me! label Jan 29, 2025
@mluk-sap
Copy link
Contributor

mluk-sap commented Jan 30, 2025

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'.

@mluk-sap mluk-sap self-requested a review January 30, 2025 12:43
@kyma-bot kyma-bot added the lgtm Looks good to me! label Feb 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes Indicates the PR's author has signed the CLA. lgtm Looks good to me! size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants