[Spacewalk-list] Best practices for channel management and updates

Tue May 22 01:37:10 UTC 2012

You missed the point

It applies to both tiers for different reasons.
I just explained the two reasons.
 On May 21, 2012 8:15 PM, "Musayev, Ilya" <imusayev at webmd.net> wrote:

> For the most part, financials usually can afford Sattelite and many are
> strong believer of enterprise -everything, Web shops are being creative and
> trying to skim the cost wherever possible – hence most will opt for
> spacewalk.****
>
> ** **
>
> I do find pricing model for satellite a bit outrageous – which in turn
> forces many to use spacewalk – including myself. I was basicly asked, would
> like an additional head count if you use spacewalk or no headcount and go
> with satellite. The choice is clear for me.****
>
> ** **
>
> ** **
>
> *From:* spacewalk-list-bounces at redhat.com [mailto:
> spacewalk-list-bounces at redhat.com] *On Behalf Of *Paul Robert Marino
> *Sent:* Monday, May 21, 2012 7:47 PM
> *To:* spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] Best practices for channel management and
> updates****
>
> ** **
>
> By the way you're biggest two markets that need this functionality are web
> and large finacial or other mission critical environments.
> Web needs it because many web programers have issues with things like PHP
> updates (usually due to sloppy code practices like purposly utilizing bugs
> in their code) .
> Large Financial and other mission crittical environments need it because
> they need to throughly test all changes before they go into production and
> this includes large financial companies I've worked for in the past who
> have implemented RHN sattelite and been bitten by updates that introduced
> unexpected bugs with new features. And if a security update happens after a
> new feature patch the sec gives finacial institution no choice but to
> update or at least test the update within a "timely manner".****
>
> On May 21, 2012 7:36 PM, "Paul Robert Marino" <prmarino1 at gmail.com> wrote:
> ****
>
> In short answer to your question there is no best practice currently.
> All the methods you mentioned are adhoc solutions.
> No doubt there are senarios where this would be handy but its
> counterintuitive to the RHN sattelite business model.
> The best way to handle this would be to write a RFE to justify the
> addition of the functionality.
> I would suggest is to use traditional redhat terminoligy eg. Rawhide,
> testing, stable. This is a more complexe thing to implement than it
> initialy sounds.
> This would requier
> 1) an additional tag be put on the package in the database
> 2) cobbler handelling changes to produce multiple repomd.xml, etc. Files
> for each channel based on which level of stability you want.
> 3) interface changes to handle the individual versions of the channel.
> 4) api changes to allow the setting and promotion of packages from one
> version to the next version of the channel.
> 5) changes to sattelite sync, rhnpush, etc. To handle spacification of the
> current status of new packages.
> 6) Additional modifications to how erratas work.
> 7) possibly client changes to handle the different presented versions of
> the channels.****
>
> On May 21, 2012 5:45 PM, "Musayev, Ilya" <imusayev at webmd.net> wrote:****
>
> This is the second or third time I'm asking this question, I figure no one
> has the answer.. :(
>
> -----Original Message-----
> From: spacewalk-list-bounces at redhat.com [mailto:
> spacewalk-list-bounces at redhat.com] On Behalf Of Musayev, Ilya
> Sent: Monday, May 21, 2012 2:54 PM
> To: spacewalk-list at redhat.com
> Subject: [Spacewalk-list] Best practices for channel management and updates
>
> I was actually searching for additional documentation (month+) on RHN
> Satellite/Spacewalk and specifically best practices on how to maintain
> channels for updates. As of now, as hard as I tried, I could not find a
> best practices guides. Would you be able to suggest on how to properly
> maintain channels for dev/qa/prod hosts?
>
> For example, I currently have a clone of entire rhel- x86_64-server-5 as
> rhel- x86_64-server-5-latest (which is updated daily with packages and
> erratas). I was thinking of cloning this base channel as rhel-
> x86_64-server-5-testing and rhel- x86_64-server-5-prod (all clones as base
> channels) and assign test and prod hosts respectively.
>
> -------------------------------------
> Example 1 (all channels are base channels):
>
> rhel- x86_64-server-5-latest (daily updates of packages/errata)
> rhel-x86_64-server-5-testing (clone of latest at point in time)
> rhel- x86_64-server-5-prod (clone of testing, once certified)
> -------------------------------------
>
> Example 2
>
> I also had an original design where I would create a base channel, with
> several child channels for testing and updates
>
> rhel-x86_64-server-5 (constantly updated)
>   rhel-x86_64-server-5-testing (clone of the base as point in time)
>   rhel-x86_64-server-5-prod (clone of testing channel once approved)
> -------------------------------------
>
> Example 3
>
> rhel-x86_64-server-5 (blank - no packages or errata)
>  rhel-x86_64-server-5-updates (daily updates and errata)
>  rhel-x86_64-server-5-testing (clone of the updates as point in time)
>  rhel-x86_64-server-5-prod (clone of testing channel once approved)
> -------------------------------------
>
> As you can see, each design has a flaw and it gets complicated.
>
> The channel assign will happen based on activation keys.
>
> Would you clone the channels or copy packages to channels?
> What setup do you have and  what   issues do you foresee (or have seen)
> for any of these setups?
>
> If there are any suggestion you can help with I would truly appreciate it.
>
> Thank you
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list****
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20120521/d2e7031e/attachment.htm>