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

Overridable subroutines for composite builtin workflow actions #2914

Open
albinsuresh opened this issue Jun 3, 2024 · 0 comments
Open

Overridable subroutines for composite builtin workflow actions #2914

albinsuresh opened this issue Jun 3, 2024 · 0 comments
Labels
idea ideas/opportunities/feature requests which need to be further investigated before implementation

Comments

@albinsuresh
Copy link
Contributor

Is your feature request related to a problem? Please describe.

The inbuilt workflow actions like the executing action of software update or configuration update are composite actions that involve multiple subroutines. For example, the software update execution action involves the following three steps: a prepare, update-list and finalize. Similarly, a configuration update execution involves downloading the config file, validating it when needed, applying the update and then performing any finalization step like restarting the relevant software or even the device itself. It would have been nice if some of these subroutines could be overridden individually without having to override the entire executing action, so that the rest of the reusable subroutines like downloading the file can be reused.

Describe the solution you'd like

Introduce overridable abstractions for complex/composite builtin actions so that those individual subroutines can be overridden separately. Ideally, the user should be able to separately override a step for each type of software or configuration. For example, in a configuration update workflow, one should be able to provide separate overridden logic for how a configuration is updated for different config types. For e.g: config update for certain types might just involve replacing the existing configuration with the new one on the disk, but certain other types might involve executing some commands (e.g: kubectl apply -f /path/to/new/config) to apply the updated configuration.

Describe alternatives you've considered

Breakup the single executing step of these operations into multiple steps like prepare, validate, apply, finalize etc so that the existing workflow overriding mechanism itself can be used to override those individual steps.

@albinsuresh albinsuresh added the idea ideas/opportunities/feature requests which need to be further investigated before implementation label Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idea ideas/opportunities/feature requests which need to be further investigated before implementation
Projects
None yet
Development

No branches or pull requests

1 participant