Open Chrysostomus opened 1 month ago
did you have a look on the recurrent actions fracture? https://www.uyuni-project.org/uyuni-docs/en/uyuni/reference/systems/system-details/sd-recurring-actions.html
I did, thank you for asking!
The reasons why I think it doesn't fulfill the same use case are as follows:
1) it is attached to a recurring schedule and our contractually obligated update schedule (Monday of each months third full week) is such that it would be difficult to implement with them. Hence manual triggering works better for some use cases.
2) Recurring actions seem to be tied to individual servers. Action chains on the other hand allow putting different servers actions in sequence, which is desirable for things like high availability. For example, update server group a -> reboot server group a -> update server group b -> reboot server group b.
We could probably just use ansible or salt states for this, but there are reasons why it would be desirable to do updates via Uyuni. As it stands, I'm not sure what purpose the chained actions serve, as there doesn't seem to any inherent advantage in it compared to just running the actions in sequence. Being able to reuse the chains would greatly elevate their usefulness imho.
ok your use case makes sense. However, action channels are tied to a certain version of packages and action sequence for installing it. I doesn't make sense to run it more than once. What we are evaluating is give more functionality to recurrent action and improve them, to make it more flexible.
Short description
Make action chains more robust by allowing them to be reused. Some actions like updating servers (often the primary use case of Uyuni) are recurring in nature, and rebuilding action chain every time you update servers defeats the purpose of the action chains.
Details
Doing just number 1 would help immensely, but 2 and 3 would also be great.