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

Resume/suspend/terminate/stop will result in invalid state #2942

Open
alexec opened this issue May 4, 2020 · 3 comments
Open

Resume/suspend/terminate/stop will result in invalid state #2942

alexec opened this issue May 4, 2020 · 3 comments
Labels
area/controller Controller issues, panics type/tech-debt

Comments

@alexec
Copy link
Contributor

alexec commented May 4, 2020

Summary

Only the workflow controller should be able to change a workflow.

Motivation

All these operations can result in invalid state one large workflows because they update the workflow out of the main loop.

Proposal

The controller currently reacts to pod and workflow changes, but it can already be reacting when a third-party changes - resulting in conflict and invalid state.

We could have a new operation queue that takes operations to workflows and ensures they are applied sequentially.


Message from the maintainers:

If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

@alexec alexec added the type/feature Feature request label May 4, 2020
@alexec
Copy link
Contributor Author

alexec commented May 4, 2020

See #2367

@alexec alexec changed the title Resume/suspend/terminate/stop can result in invalid state Resume/suspend/terminate/stop will result in invalid state May 4, 2020
@alexec alexec added area/controller Controller issues, panics type/tech-debt and removed type/feature Feature request labels Feb 7, 2022
@stale

This comment was marked as resolved.

@stale stale bot added the problem/stale This has not had a response in some time label Mar 2, 2022
@alexec alexec removed the problem/stale This has not had a response in some time label Mar 2, 2022
@agilgur5
Copy link
Member

agilgur5 commented May 15, 2024

I think this is no longer an issue? We have several checks in the codebase where the ShutdownStrategy is handled currently.

If they require changes to the Workflow (via spec or annotation or label), then they are more-or-less queued up as resourceVersion changes.

Only the workflow controller should be able to change a workflow.

Related is #12538 for the manual Retry operation

We could have a new operation queue that takes operations to workflows and ensures they are applied sequentially.

Also *Request CRDs as I mentioned in #6490 (comment) would very explicitly delegate to the Controller and would be queued (as the entire Controller is queued).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/controller Controller issues, panics type/tech-debt
Projects
None yet
Development

No branches or pull requests

2 participants