schedule for CLM projects

[AxHuGH]

Dear Uyuni team,

Is it feasible to incorporate a scheduler that updates content lifecycle projects on a regular basis?

We use a script (XMLRPC API) to update our projects every day.

Thanks in advance

[rjmateus]

Hey, We have looked at that and is something that have been asked a few times. It's uner our radar but I don't know when we would be able to implement.

[ppanon2022]

The way I've been doing it is by running a systemd timer and service on the host running the container. The service runs mgrctl exec to run the script in the context of the container. It's not ideal but it will work until the Uyuni team can support it within the application as a task.

myuyuny-server:/etc/systemd/system # cat uyuni-server-promote-lcm-prod.timer
[Unit]
Description="Run Uyuni LCM promotions every blabla"

[Timer]
OnCalendar=DoW *-*-* 06:00:00
Unit=uyuni-server-promote-lcm-prod.service

[Install]
WantedBy=multi-user.target
myuyuny-server:/etc/systemd/system # cat uyuni-server-promote-lcm-prod.service
[Unit]
Description="Uyuni promote devtest LCM versions to prod"

[Service]
ExecStart=mgrctl exec "/usr/bin/bash /root/bin/promote_LCM_vers_to_prod"

[AxHuGH]

Thanks for the information,
Could you also show the contents of the script "/root/bin/promote_LCM_vers_to_prod"?

[ppanon2022]

That's very specific to our configuration and our patching approaches which involve staging of patch sets through test environments before deployment to production (think SAP-type change control), also specifying certain project exclusions. In fact, promote_LCM_vers_to_prod (we also have another similar script for creating new LCM versions to be used for baseline and staging/testing of patch sets) just calls a python script which does most of the work through the XMLRPC API, based on command line parameters. It also pulls credentials for the API calls from ~/.spacecmd/config if you have that set up. That python script is nearly 24K, so I can't just paste it in, and I don't see any way to add attachments to this discussion the way we would with an issue/ bug report.

I suppose if you want to open it as an "enhancement request" issue, I could attach it as a starting point if someone wants to run with it to make it fit better within the Uyuni framework/style. I'm not sure if/how you could take a python script and turn it into a taskomatic task though. It would probably make more sense to rewrite it in Java and call the appropriate Java modules directly. And you also would probably configure it through new PG tables populated by new admin web pages rather than use some clumsy command parameters or config file. At best my script would be a talking point for discussing some possible use cases and scenarios to develop a more generalized design.