[Spacewalk-list] metadata_expire and Spacewalk updates

[Steven Miano]

We're on the opposite side of this lean, and have approximately 22,000
clients that are on very limited circuits (as many as 6,000 clients on a
30mbps link).

In the past we were running Salt Stack to ensure packages were in place,
and checking for a latest version of said packages (Salt Stack will auto
expire and refresh the meta data when it does that).

In order to alleviate some of the pain of having 6,000 machines attempt to
download a 20MB metadata file, we're now no longer forcing the latest
packages with each highstate, and have opened/releaxed the metadata
refreshes out to 96 hours (4 days).

If you were to want to be so aggressive, I could/can recommend a frequent
high state schedule through salt stack demanding the latest packages within
certain states.

Good luck!

On Wed, Mar 4, 2020 at 7:40 AM Brian Long <briandlong at gmail.com> wrote:

> "I cannot push updates to a channel and then immediately tell a client
> to update itself and reboot.  Depending on where it is in that
> metadata_expire window, it won't see the newest changes.   Another way
> to say this is that I have
> to update my channels and wait six hours before telling Spacewalk to
> push the updates out; otherwise a lot of my clients will not get the
> latest updates.  rhn_check checks in, sees no updates and the task is
> done."
>
> Has anyone else found a solution to this?  Am I overlooking something
> really simple I can enable in Spacewalk to force a client metadata
> update before trying to update?
>
> /Brian/
>
> On Mon, Feb 24, 2020 at 9:10 AM Brian Long <briandlong at gmail.com> wrote:
> >
> > Dennis, thanks for your response, but I'm not concerned with the
> > Spacewalk side of the metadata.  I'm interesting in getting my clients
> > updating their metadata as soon as a Spacewalk channel is updated.
> > With default configuration, it could take six hours before they see
> > the channel has been updated since yum's default metadata_expire
> > setting is six hours.  I'm wondering if other users of Spacewalk are
> > somehow forcing client-side metadata updates before telling Spacewalk
> > to update their clients?  Or are people configuring each of their
> > client yum.conf files to specify a smaller metadata_expire setting to
> > fix this behavior?
> >
> > When yum-based Linux installs are Internet-connected and trying to
> > download updates from upstream mirrors like Fedora, CentOS, etc. I
> > understand metadata_expire being set to six hours out-of-the-box.  The
> > problem is operationalizing Spacewalk, I cannot push updates to a
> > channel and then immediately tell a client to update itself and
> > reboot.  Depending on where it is in that metadata_expire window, it
> > won't see the newest changes.   Another way to say this is that I have
> > to update my channels and wait six hours before telling Spacewalk to
> > push the updates out; otherwise a lot of my clients will not get the
> > latest updates.  rhn_check checks in, sees no updates and the task is
> > done.  Does that make more sense?
> >
> > /Brian/
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>

-- 
Steven M. Miano
(727)244-9990
http://stevenmiano.com
1811 C2CB 8219 4F52
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20200304/36824d1c/attachment.htm>