[Spacewalk-list] metadata_expire and Spacewalk updates

[Brian Long]

"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/