[Spacewalk-list] Action Chains?

Matt Moldvan matt at moldvan.com
Fri Apr 15 13:55:52 UTC 2016 

Nice, thanks for the pointers.  We have a similar set up, with some
guidelines I followed from the Satellite lifecycle article at
https://access.redhat.com/articles/469173 and associated PDF
https://access.redhat.com/sites/default/files/attachments/red_hat_satellite-5.6-satellite_errata_management-en-us.pdf
.

Basically, our bootstrap determines the "environment" (prod or non prod)
for the systems that are registering, and uses an activation key to
register against centos6-x86_64-{nonprod,prod} channels.  A top level
channel for each release is also set up, named centos6-x86_64-all for
example, that has the latest packages from the official repos.  At the
beginning of every month, the spacewalk-clone-by-date command runs and
"promotes" last months errata to the non prod channels, and two month's
priors errata to the prod channels.

What I'm thinking is having something two scripts similar to yours, one
basically to loop through each system in the non prod channels and assign
them to a patch group for that week.  Because of previous issues doing all
400 or so systems at once, I've had to break them up into groups of 100 at
a time, so a group like patching-week1 with ~400 systems had to be broken
up into patching-week1-set{1,2,3,4}.  I will also have to implement a
method to determine if systems still "exist", as we decommission and
provision new systems on a regular basis.

Anyway, just thinking out loud.  The snapshots are a good idea, and one I
hadn't thought of, but with multiple hypervisors and the goal to expand
into public cloud environments, this might be too much for our use case,
having to support 2 hypervisors (RHEV and VMware), with the understanding
we may branch out into third party hypervisors later.

So I guess to the original post, action chains are good for one time use
but it will take some effort to do exactly what you want with the API.
Glad the API is relatively well documented and available.

Merci!

Matt.

On Fri, Apr 15, 2016 at 3:03 AM Maxime VEROONE <maxime.veroone at nordnet.fr>
wrote:

> Hi,
>
>
>
> I am unfortunately now allowed to post the code, but I can explain the
> architecture.
>
> First of all, we have setup groups : development servers, pre-production,
> production
>
> We have also one channel per OS type, from CentOS5-32b to CentOS7-64b
>
> Each month, we start a first script that clones each channel to another
> named “frozen-OS-arch” which stays the same for the whole month
>
>
>
> I have written a second script that lists systems in a group,  looks for
> them via the vmware API to snapshot them, and create a snapshot deletion
> script. (for later)
>
> Then a third script schedules the updates this way :
>
> -          Lists all systems in the selected group(s)
>
> -          Move them to their respective “frozen” channel
>
> -          Order the list depending on a custom value “priority” (allow
> us to distribute members of a cluster among the same group)
>
> -          Then loop over the list and do this :
>
> o   Verify that the VM has a correct snapshot,
>
> o   Verify that the system has updates to apply
> (system.listLatestUpgradablePackages)
>
> o   Log the packages to be updated
>
> o   Schedule this remote command(system.scheduleScriptRun) :
>
>
>
> #!/bin/bash
>
> #avoid stacking dozens of kernels
>
> perl -pi -e \'s/installonly_limit=.*$/installonly_limit=3/\' /etc/yum.conf
>
> grep -q -v installonly_limit /etc/yum.conf && perl -pi -e
> \'s/\[main\]/[main]\ninstallonly_limit=3/\' /etc/yum.conf
>
> echo "Started : $(date)"
>
> yum update -y || exit -1
>
> echo "Finished : $(date)”
>
> #Avoid boot loops
>
> [ $(cut -d'.' -f 1 /proc/uptime) -gt 900 ] && shutdown -r -t 30 now
>
>
>
> o   Rename the scheduled action to something more meaningful (can’t be
> done with API, need to modify the database : public.rhnaction set name=’’
> where id=’’)
>
> o   Wait 30 seconds, then move to next system
>
> -          Once all actions are scheduled, we wait for them to finish
> (schedule.listInProgressActions) for 30 minutes
>
> -          And finally, we move back all systems to their normal channels
>
>
>
> Hope this gives you ideas. It is important to think first about your
> update process and the way you want to organize each cycle, and then go
> ahead with the code.
>
> We have choosen the perl API because of your skills here being way higher
> in this language, but python works even better, i’ve been told.
>
>
>
> Good luck.
>
> Maxime
>
>
>
> *De :* spacewalk-list-bounces at redhat.com [mailto:
> spacewalk-list-bounces at redhat.com] *De la part de* Matt Moldvan
> *Envoyé :* jeudi 14 avril 2016 22:03
>
>
> *À :* spacewalk-list at redhat.com
> *Objet :* Re: [Spacewalk-list] Action Chains?
>
>
>
> We opted for Spacewalk last year over Katello/Foreman/Pulp/Candlepin
> because of the (somewhat) simplified install process.  Overall it's still
> been a big learning curve.  For us, we were thinking of setting up
> Spacewalk as a platform for our Operations personnel to log in and schedule
> patching for the many thousands of systems we manage.
>
>
>
> For that reason, having a set of action chains that is abstract enough to
> be reusable (e.g. schedule all security errata for group X during patch
> window at timestamp blah, back end code figures out the rest) isn't
> necessarily something that doesn't make sense; on the contrary it would
> make a lot of sense and save a lot of time.  For smaller environments, or
> if we're thinking stricly in specifics (e.g. schedule errata CESA-2016:0519
> to be applied on host xyz then reboot), I agree it doesn't make sense.
>
>
>
> With that said, the next step for us is like Maxime, to automate the
> update process using the API.  Unfortunately I haven't found any examples
> in the wild yet... Maxime would you be able to share any of the code or how
> you implemented it?
>
>
>
> On Thu, Apr 14, 2016 at 3:50 AM Maxime VEROONE <maxime.veroone at nordnet.fr>
> wrote:
>
> Hi,
>
>
>
> We, here, at first sought for action chain templates or something similar.
>
> We have then moved to automating the update process with an extensive use
> of the API.
>
>
>
> Just FYI, Satellite 6 is built around Katello, (http://www.katello.org/)
> and not Spacewalk.
>
> Katello is using puppet as a core component. I hope that answers your
> question.
>
>
>
> Maxime
>
>
>
> *De :* spacewalk-list-bounces at redhat.com [mailto:
> spacewalk-list-bounces at redhat.com] *De la part de* Lachlan Musicman
> *Envoyé :* jeudi 14 avril 2016 08:19
> *À :* spacewalk-list at redhat.com
> *Objet :* Re: [Spacewalk-list] Action Chains?
>
>
>
> Daniel,
>
> Yes, so long as you don't schedule or action them. Once you do that, they
> disappear.
>
> That section seems to be a holding zone for action chains that are "being
> built" - once the chain is run, it disappears. Would be nice to have some
> permanence - especially if pushing a new conf file from Configuration and
> you want to restart a service - on >3 machines, would be nice to automate.
>
> I guess at that point I should be using Ansible or fabric. Would just be
> nice to have everything in the same space.
>
> Does anyone know if the move to Satellite 6 will be more
> Ansible/Chef/Puppet like?
>
>
>
> cheers
>
> L.
>
>
> ------
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
>
>
> On 14 April 2016 at 15:36, Daniel Eather <daniel.eather at cranegroup.com.au>
> wrote:
>
> Can you see your saved action chains in *Schedule > Action Chains* ? I
> can’t confirm as I don’t use them (yet) but the description of this page
> states “Below is a list of all Action Chains available to the current user.
> Click on a label to view or edit it.” Seems legit.
>
>
>
> *From:* spacewalk-list-bounces at redhat.com [mailto:
> spacewalk-list-bounces at redhat.com] *On Behalf Of *Matt Moldvan
> *Sent:* Wednesday, 13 April 2016 12:35 PM
> *To:* spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] Action Chains?
>
>
>
> I don't think so, unfortunately.  If I'm wrong I'd love to hear
> otherwise... would be nice if they could be saved, shared among other
> users, etc.  But seems like they are one time use and they fly away...
>
>
>
> On Tue, Apr 12, 2016 at 9:20 PM Lachlan Musicman <datakid at gmail.com>
> wrote:
>
> I just set up an action chain, and was quite chuffed with myself.
>
> After I scheduled it, it executed, and now I can't find it any more?
>
> Surely actions chains are saved for repeated use?
>
> cheers
>
> L.
>
> ------
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
> ______________________________________________________________________
> Any views expressed in this message are those of the individual sender,
> except where the sender specifically states them to be the views of
> Fletcher Building or any related subsidiaries.
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20160415/3060cbe3/attachment.htm>

More information about the Spacewalk-list mailing list