search

uyuni-project / uyuni

Source code for Uyuni
https://www.uyuni-project.org/
GNU General Public License v2.0
428 stars 177 forks source link

Allow reusing action chains #9107

Open Chrysostomus opened 1 month ago

Chrysostomus commented 1 month ago

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

  1. Allow saving action chains for later use. This saves a lot of work by not having to rebuild the action chain every time. When scheduling an action chain, add a checkbox for "Delete the action chain afterwards". If it is not checked, just leave action chain in the Action chains tab of the UI.
  2. Allow adding more systems to actions in action chains instead of only removing systems from steps. This saves work by not needing to rebuild the action chain every time there is a new server. At the top of the list of systems in that action add a hyperlink "Add systems" that would lead to an UI similar to system set manager
  3. Allow having more than 1 action chain at the same time. Currently it seems that you can only add systems to 1 action chain and I haven't found a way to have more than 1 action chain at a time.

Doing just number 1 would help immensely, but 2 and 3 would also be great.

rjmateus commented 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

Chrysostomus commented 1 month ago

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.

rjmateus commented 1 month ago

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.