On jueves, 14 de marzo de 2019 11:22:50 (CET) Steve Moring wrote:
Julio,
On Thu, 2019-03-14 at 09:19 +0100, Julio González Gil wrote:
Are you talking about migrating a client?
Yes, sorry. I have some clients that are os423, some are os150. I have keys defined for both. I have bootstraps for both. All are salt.
Understood :-)
As far as I know we don't have an official procedure.
I totally understand. It's not enterprise (SUMA).
Well, what I mean is that I am not aware of anybody testing that so far, so I can't provide instructions that will work for sure (that's why I mentioned there is no "official procedure" :-)
I'm wondering how I would move an os423 client to be subscribed to the channels defined with the os150 keys. Or, if I can unsubscribe the os423 clients, clean up the bootstrapped components, then re-subscribe to the os150 key/channels and upgrade. I get to play, so this is all blue sky.
Well, first of all I am not sure about your channel structure. But assuming that you have one base channel for Leap 42.3 and another base c channel for 15.0: a) If you are not worried about changing the activation key used for the current 42.3 clients, you could change the channels assigned to that key, and then create an action change as described. I am not sure if changing an activation key propagates the changes to the clients. b) If that doesn't work, then the other way to do it is to change the base channel for all 42.3 clients from the 42.3 base channel to the 15.0 base channel. That could be done with the API, to find all 42.3 clients and then change the base channel, And then, again, an action change to update all clients and reboot. In theory maybe you can also use spacecmd instead of raw calls to the API. I am not sure how easy will be filtering 42.3 clients with spacecmd as "system_list" does not seem to allow filters.
But since Uyuni manages the repositories for the clients, and assuming your
current Leap 42.3 are NOT traditional clients you could:
1. Adjust the channels assigned to the activation key to change them from Leap
42.3 to 15.0
2. Create an action change to:
- Apply the highstate (so the Leap 15.0 repositories become available for the
client(s)
- Update all packages
- Reboot.
Unfortunately, for this particular scenario, I'd have to move all the clients at once.
You can do that. The action change can be defined for several clients. I think you can achieve this with SSM (System Set Manager) I suggest you try with only one client first so you can fix the issues before applying the change to all of them.
O course, this assumes the clients will not have any kind of dependency
conflicts when switching from Leap 42.3 to Leap 15.0.
Agreed, should be fun :-)
If you are using the official repositories from Leap, and nothing else, then you should not have problems. In this case I was thinking when I migrated my laptop from Leap 42.3 to Leap 15.0. That was a problem because I use A LOT of extra repositories from OBS, and zypper complained about vendor changes and that sort of things :-) Anyway, if the clients are similar, remember: try first with one and fix as needed, before doing the massive change. If there are groups that are similar, then try first with one system for each group. Good luck!
Thanks for the cycles.
-Steve
--
Julio González Gil