[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