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: [email protected] [mailto:[email protected]] On Behalf Of Paul Robert Marino Sent: Monday, May 21, 2012 7:47 PM To: [email protected] 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" <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[email protected]>> wrote: This is the second or third time I'm asking this question, I figure no one has the answer.. :( -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Musayev, Ilya Sent: Monday, May 21, 2012 2:54 PM To: [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list [email protected]<mailto:[email protected]> https://www.redhat.com/mailman/listinfo/spacewalk-list
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
