[Spacewalk-list] Managing Channels/Repositories - Patching Workflow

[Jérôme Meyer]

Hi Phil,

Thank you for sharing your information about your test...
"Spacewalk-manage-channel-lifecycle" sounds very interesting. I'll also do some tests and give you feedback.
I'm very interested in the results of the re-sync because that is actually the most important thing.

Best regards,
Jérôme



From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of P.Cookson at bham.ac.uk
Sent: Mittwoch, 16. Januar 2019 14:38
To: spacewalk-list at redhat.com
Subject: Re: [Spacewalk-list] Managing Channels/Repositories - Patching Workflow

Hi Jérôme

Thanks for your feedback. I've read that "spacewalk-clone-by-date" gives some unexpected results, really doesn't sound very reliable or therefore, of much interest to me!

I've started some testing of "spacewalk-manage-channel-lifecycle" and, initially, that seems to be giving more consistent results. As the name suggests, maybe it's more likely to manage a dev/test/prod lifecycle/workflow better? It seems to just capture the state of the source channel as opposed to copying every package, from the related repo, in to new repo's each time. This makes me think that you'd have to ensure the source repo's were retained while dev/test/prod clones were still referencing it but far less disk space is required. I'm waiting to see what happens when the source is re-synced and more packages are added to it, as I wouldn't want the clone repo's to get any updated packages as well!

Regards
Phil


From: spacewalk-list-bounces at redhat.com<mailto:spacewalk-list-bounces at redhat.com> <spacewalk-list-bounces at redhat.com<mailto:spacewalk-list-bounces at redhat.com>> On Behalf Of Jerome.Meyer at lcsystems.ch<mailto:Jerome.Meyer at lcsystems.ch>
Sent: 16 January 2019 12:13
To: 'spacewalk-list at redhat.com' <spacewalk-list at redhat.com<mailto:spacewalk-list at redhat.com>>
Subject: Re: [Spacewalk-list] Managing Channels/Repositories - Patching Workflow

Hi Phil,

I'm using the spacewalk-clone-by-date command and there's my point of view and experience.
I've created three channels: dev,test and prod with spacewalk-clone-by-date. Each month in a specific date I resync these three channels with the same commands. In this process errata will be synchronized with their dependencies.
All was perfect until I notice that not all packages will be added. By example new package version but not an errata will not be updated. At the end, the channels hasn't the same packages number has it's parents.
I'll perhaps make some test with other commands but if you do any more tests on your side, I'll be interested in your results.
Unfortunately I didn't any more informations on web regarding this problematic.

Regards,
Jérôme

From: spacewalk-list-bounces at redhat.com<mailto:spacewalk-list-bounces at redhat.com> [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of P.Cookson at bham.ac.uk<mailto:P.Cookson at bham.ac.uk>
Sent: Dienstag, 15. Januar 2019 14:01
To: spacewalk-list at redhat.com<mailto:spacewalk-list at redhat.com>
Subject: [Spacewalk-list] Managing Channels/Repositories - Patching Workflow

Hi all

I've recently built a SW 2.8 environment, added Channels/Repositories for RHEL/Oracle Linux 6/7 and successfully patched relevant client systems. I now want to know how people are managing their patching workflow - at this point in time I just want to ensure the same group of patches are applied to Dev, Test and Production after sufficient testing has been performed. If I never re-sync these repositories obviously they'll remain static and could be used for the whole workflow. However, other service areas may want their environments patched at different times with additional patches. I guess I could just create similar Channels/Repositories, at a later time, but that would be time consuming and need more disk space. I've seen references to cloning using WebUI, spacecmd -- softwarechannel_clone, spacewalk-clone-by-date or spacewalk-manage-channel-lifecycle and can research these further but just wondering what people have found to be the easiest and most reliable solution really?

Regards
Phil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20190117/41c3b104/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5165 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20190117/41c3b104/attachment.p7s>