SM3: Creating action chain

SUSE Manager
1

Has anyone created an action chain in SM3? I have read through 8.5, Action Chains, in the Reference Manual but can’t seem to figure out how to create an action chain. I would like to automatically reboot any server being patched with a patch requiring a reboot (such as a kernel update) and thought these two actions (patching and reboot) could be linked by action chains. I don’t see any button anywhere that would allow me to create an action chain when installing a patch or package.

2

achinayoung,

It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.

These forums are peer-to-peer, best effort, volunteer run and that if your issue
is urgent or not getting a response, you might try one of the following options:

Be sure to read the forum FAQ about what to expect in the way of responses:
http://forums.suse.com/faq.php

If this is a reply to a duplicate posting or otherwise posted in error, please
ignore and accept our apologies and rest assured we will issue a stern reprimand
to our posting bot…

Good luck!

Your SUSE Forums Team
http://forums.suse.com

3

Welcome to SUMA 3! There is no way to create an action chain anymore (at least not natively).

Why? Ask the nerds at SUSE. We are in the process of reconsidering to not renew a six-figure contract with SUSE and the missing action chain is one of several reasons. It is just beyond me why SUSE did not include actions chains in the WebGUI anymore.

So how do you do action chains? You have to use salt or a remote script. We do it by using a remote command like this:

zypper ref && zypper patch --updatestack-only -y && zypper patch --with-update -y && salt-call state.sls packages.profileupdate && shutdown -r now

This will work only with SLES 12 SP 2. Why? Well, they decided to deprecate several zypper arguments. Why? Don’t ask me! Ask SUSE! So in SLES version < SLES 12 SP 2 use something like this:

zypper ref && zypper patch -y && zypper patch -y && salt-call state.sls packages.profileupdate && shutdown -r now

This will imitate an action chain where the client (minion) gets only rebooted if and when the zypper commands were successful.

Wanna try something funny? Try to put several servers in the system set manager (SSM). You can also just work with a system group. And then try to issue a remote command to all of the servers in the SSM. They forgot to put it in the WebGUI. Not kidding here! There is no way to issue a remote command to more than one server using the WebGUI. It will be added in a future update though.

Here is a way around this:

system_runscript group:my_group_name_here -s 201506170130 -l "patching my_group" -t 60 -f /root/myscript

You’ll be using spacecmd here from the bash to run “myscript” on all servers in “my_group”. Argument -t stands for timeout. Argument -s is the time my_script will be run. Argument -l is just anything you want and will appear under “pending Actions” in the WebGUI. You can omit -l (label).

Of course you can do everything as well with salt commands. Good luck with that (preferably after an intensive advance training course in salt).

@SUSE: We are a customer paying you some six-figure price and we only get this bug ridden alpha-stage software. What were you thinking offering this software you paying customers? Really - what were you thinking?

4

Action chains are closely coupled to ‘traditional’ (non-salt) clients and not (yet!) available to Salt clients (minions). We will provide a similar functionality to minions at a later point in time.

If you stay with traditional clients, SUSE Manager 3 does not introduce any regressions.

In this case, you are eligible for support and the SUSE Manager engineering team will be happy to resolve any reasonable request you might have.

5

That is true. However

  1. Salt is the default way to add clients to SUMA in 3.1.
  2. I pay a six-figure amount of money for a software and I expect and demand that basic functions are working in the WebGUI. “This is not yet implemented in the GUI” is simply not acceptable! Period.

SUSE support WILL NOT help with features that have not been programmed into the WebGUI. Sure, I can (and have) opened an enhancement request. And yes, there are workarounds (few of which I have show in my above posting). But again, I might expect such a behavior from a free alpha-stage software but certainly not from a high priced enterprise software. Or to put it in more blunt words: This is ****! **** I’m expected to pay for.

6

[QUOTE=bucks;38940]Welcome to SUMA 3! There is no way to create an action chain anymore (at least not natively).

Why? Ask the nerds at SUSE. We are in the process of reconsidering to not renew a six-figure contract with SUSE and the missing action chain is one of several reasons. It is just beyond me why SUSE did not include actions chains in the WebGUI anymore.

So how do you do action chains? You have to use salt or a remote script. We do it by using a remote command like this:

zypper ref && zypper patch --updatestack-only -y && zypper patch --with-update -y && salt-call state.sls packages.profileupdate && shutdown -r now

This will work only with SLES 12 SP 2. Why? Well, they decided to deprecate several zypper arguments. Why? Don’t ask me! Ask SUSE! So in SLES version < SLES 12 SP 2 use something like this:

zypper ref && zypper patch -y && zypper patch -y && salt-call state.sls packages.profileupdate && shutdown -r now

This will imitate an action chain where the client (minion) gets only rebooted if and when the zypper commands were successful.

Wanna try something funny? Try to put several servers in the system set manager (SSM). You can also just work with a system group. And then try to issue a remote command to all of the servers in the SSM. They forgot to put it in the WebGUI. Not kidding here! There is no way to issue a remote command to more than one server using the WebGUI. It will be added in a future update though.

Here is a way around this:

system_runscript group:my_group_name_here -s 201506170130 -l "patching my_group" -t 60 -f /root/myscript

You’ll be using spacecmd here from the bash to run “myscript” on all servers in “my_group”. Argument -t stands for timeout. Argument -s is the time my_script will be run. Argument -l is just anything you want and will appear under “pending Actions” in the WebGUI. You can omit -l (label).

Of course you can do everything as well with salt commands. Good luck with that (preferably after an intensive advance training course in salt).

@SUSE: We are a customer paying you some six-figure price and we only get this bug ridden alpha-stage software. What were you thinking offering this software you paying customers? Really - what were you thinking?[/QUOTE]

Hi

Do you have any experiences doing a service pack update (e.g. SLES 12 SP 2 to SLES 12 SP3) using SUSE Manager 3.1 and salt-minions and automation?
SUSE told us to use the WEB GUI. However the Web GUI provides only a service pack update procedure for single server (!). It does not scale very well for 600+ servers.

Phonthip

7

[QUOTE=Phonthip;38964]Do you have any experiences doing a service pack update (e.g. SLES 12 SP 2 to SLES 12 SP3) using SUSE Manager 3.1 and salt-minions and automation?
SUSE told us to use the WEB GUI. However the Web GUI provides only a service pack update procedure for single server (!). It does not scale very well for 600+ servers.
[/QUOTE]

I’ve not yet tried a service pack upgrade but I already dread it. But even with SUMA 2.1 I’ve never used system groups or multiple clients in SSM for any upgrade action. I always went client by client. I see nowhere in the GUI any hint about how to upgrade more than one minion at a time. So if you want to use the WebGUI I guess you have to schedule upgrades minion after minion.

You could however use spacecmd (or salt if you like it more) to upgrade multiple server.