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" <[email protected]> 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:* [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]> 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]> 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]] On Behalf Of Musayev, Ilya > Sent: Monday, May 21, 2012 2:54 PM > To: [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] > https://www.redhat.com/mailman/listinfo/spacewalk-list > > > > _______________________________________________ > Spacewalk-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/spacewalk-list**** > > _______________________________________________ > Spacewalk-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/spacewalk-list >
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
