package handling for offline minions

[daniel-duchon]

Hi,

I'm trying to handle package, config and state management on our client devices.
As these are more offline than online (8 hours online, 16 Hours offline), I'd like to premark any change handling and let the client pickup these changes on the next connect.

What I got working so far is a highstate update via reactor by adding a custom config in /etc/venv-salt-minion/minion.d/ on the clients with value startup_states: highstate.

What I can't get to work is the package management.

Every time I trigger an upgrade, package install or uninstall, it fails due to the minion not being reachable.

What is the best way to solve this with uyuni?

[rjmateus]

Do you have a time window when you know the minions are up and reachable? You could schedule a recurrent action to just run hight state, of just install all available updates for that time window. We don't have a feature to install updates when the minion is reachable. You schedule it to a certain time, and it will try to do it at that time. Then it can fail or succeed

[daniel-duchon]

I had hoped to be able to release the package updates manually one by one.

Unfortunately, there is no real time window in which they are all available. So I would have to run the job 3-4 times a day. That would work, but then I still wouldn't be able to release each package individually

[sbluhm]

@daniel-duchon , thank you for bringing this up. I thought I was the only one having this issue. I had different priorities so never started looking whether this was a user error or by design.

I have opened an enhancement request here: #9421

[rjmateus]

Thank you for the feedback, and this is a good inside and user story.

[admd]

Ok use cases are getting more & more interesting but I definitely see the value in it. We recently fixed a similar issue around channel assignment #8943.

On a related note, there is another interesting request where user would actually like to mark the system as offline so Uyuni doesn't even try to reach them as that cost time. That would keep the system onboarded in the Uyuni and once user decide to make the changes again, he just move those systems back to active state.

[sbluhm]

@admd If I remember correctly, there used to be Spacewalk features that allowed to lock systems. But I think the main purpose was to protect them from rolling out changes to them. I couldn't find it anymore.

Is this maybe something you want? It sounds like it might do what you describe (on System --> Details --> Properties).

[admd]

Thank you Stefan. I totally forgot about this checkbox 🤦‍♂️ . Yeah, that would certainly help that user, at least partially as user don't want to see such servers in Uyuni altogether :)

[sbluhm]

@admd Just thinking of workarounds: System Set Manager (Overview) might help to make things look nicer. Or duplicate the channel names adding a Z as a prefix for offline systems. Then they can sort by name.