<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style></style></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1>I do see it being counterproductive for RHN Satellite business model – hence the silence. I doubt the RFE you are proposing would make it into spacewalk – it would probably make it into satellite – for the same business reason.<o:p></o:p><o:p> </o:p>Thank you for your input,<o:p></o:p><o:p> </o:p>Regards<o:p></o:p>ilya<o:p></o:p><o:p> </o:p><o:p> </o:p>From: spacewalk-list-bounces@redhat.com [mailto:spacewalk-list-bounces@redhat.com] On Behalf Of Paul Robert Marino Sent: Monday, May 21, 2012 7:37 PM To: spacewalk-list@redhat.com Subject: Re: [Spacewalk-list] Best practices for channel management and updates<o:p></o:p><o:p> </o:p>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.<o:p></o:p><div>On May 21, 2012 5:45 PM, "Musayev, Ilya" <<a href="mailto:imusayev@webmd.net">imusayev@webmd.net</a>> wrote:<o:p></o:p>This is the second or third time I'm asking this question, I figure no one has the answer.. :( -----Original Message----- From: <a href="mailto:spacewalk-list-bounces@redhat.com">spacewalk-list-bounces@redhat.com</a> [mailto:<a href="mailto:spacewalk-list-bounces@redhat.com">spacewalk-list-bounces@redhat.com</a>] On Behalf Of Musayev, Ilya Sent: Monday, May 21, 2012 2:54 PM To: <a href="mailto:spacewalk-list@redhat.com">spacewalk-list@redhat.com</a> 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 <a href="mailto:Spacewalk-list@redhat.com">Spacewalk-list@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/spacewalk-list" target="_blank">https://www.redhat.com/mailman/listinfo/spacewalk-list</a> _______________________________________________ Spacewalk-list mailing list <a href="mailto:Spacewalk-list@redhat.com">Spacewalk-list@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/spacewalk-list" target="_blank">https://www.redhat.com/mailman/listinfo/spacewalk-list</a><o:p></o:p></div></div></body></html>