[Spacewalk-list] avoiding the thundering herd

Guy Matz guymatz at gmail.com
Wed Apr 10 15:25:12 UTC 2019


I think the correct answer is RTFM  :-)  Thanks, Robert, your suggestion is
what I'm looking for.  yum also has a "--randomwait" option:

--randomwait=[time in minutes]
              Sets the maximum amount of time yum will wait before
performing a command  -  it  randomizes
              over the time.

so "--downloadonly --randomwait" was what I was looking for!  Thanks!!

On Wed, Apr 10, 2019 at 3:24 AM Robert Paschedag <robert.paschedag at web.de>
wrote:

> Am 9. April 2019 23:40:35 MESZ schrieb Guy Matz <guymatz at gmail.com>:
> >Hello!  I am going to be upgrading a number of servers and don't want
> >them
> >all banging on my spacewalk server at the same time to download
> >packages .
> >. .  I was hoping to be able to "stage" the updates on the servers
> >before-hand, then trigger the update via spacewalk.  I was hoping this
> >might result in a faster upgrade process on the day of upgrades, making
> >the
> >upgrade a bit easier to deal with . . .
> >
> >Any thoughts on how to go about this?  Any suggestions otherwise?
> >
>
> Hmm..I think I would run a remote command on all clients to do an
> "upgrade" with "download only" option.
>
> That prefixed with a sleep $RANDOM for example so the packages get staged
> on the clients and all not running at the same time.
>
> Then schedule upgrade of all hosts via spacewalk or - again - run remote
> command to upgrade now.
>
> If no new packages have been added to the channels, the clients might only
> refresh the channel metadata and the rest should run "offline"
>
> Robert
>
> >Thanks a lot,
> >Guy
>
>
> --
> sent from my mobile device
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20190410/758fb7b6/attachment.htm>


More information about the Spacewalk-list mailing list