Hi, severals users of Spacewalk [1] reported that Spacewalk client tools are removed [2] from CentOS (they are present in RHEL).
It's about packages: rhn-check rhn-client-tools rhnlib rhnsd rhn-setup rhn-setup-gnome yum-rhn-plugin
I dig up in history [3] and find that the reason was probably reference to rhn.redhat.com. Since current Spacewalk (default) configuration should not hit rhn.redhat.com I'm curious if those packages can be put back to CentOS? Or is some other reason behind removal of those packages?
1: https://fedorahosted.org/spacewalk/ 2: http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.4#head-6dfcd9ddca9da9913... 3: https://www.redhat.com/archives/spacewalk-devel/2008-July/msg00042.html
Hi Miroslav,
severals users of Spacewalk [1] reported that Spacewalk client tools are removed [2] from CentOS (they are present in RHEL).
It's about packages: rhn-check rhn-client-tools rhnlib rhnsd rhn-setup rhn-setup-gnome yum-rhn-plugin
I dig up in history [3] and find that the reason was probably reference to rhn.redhat.com. Since current Spacewalk (default) configuration should not hit rhn.redhat.com I'm curious if those packages can be put back to CentOS? Or is some other reason behind removal of those packages?
I guess the only good reason was because they where not necessary (nor useful) on CentOS in the past. Karan, could we put them in?
If needed, I could do build and QA on that.
Best Regards Marcus
Hi,
On 01/20/2010 03:59 PM, Miroslav Suchý wrote:
severals users of Spacewalk [1] reported that Spacewalk client tools are removed [2] from CentOS (they are present in RHEL).
I am not sure about that - these are not really 'spacewalk' client tools but are more along the lines of 'rhn tools'.
Or is some other reason behind removal of those packages?
They are removed since they have no real use in the CentOS environment - and we not be a reason for people hitting rhn.r.c when they dont need to or even should be doing so.
I think in the spacewalk context its easier to look at it from the point of view that adding these packages does nothing for the spacewalk user, since they are not the only things needed to make spacewalk environment. So the user haseto already go and enable another repo somewhere, these tools can come from there as well.
However, if there is a real reason to add these back in I dont see why that could not happen. I just dont see the reason at this time.
- KB
Karanbir Singh wrote:
Hi,
On 01/20/2010 03:59 PM, Miroslav Suchý wrote:
severals users of Spacewalk [1] reported that Spacewalk client tools are removed [2] from CentOS (they are present in RHEL).
I am not sure about that - these are not really 'spacewalk' client tools but are more along the lines of 'rhn tools'.
Yes, they carry the heritage of rhn in their name and their original purpose was to connect to rhn.redhat.com (and RHN Satellite), but since open sourcing this product as Spacewalk project at 2008, these tools can be used to connect to Spacewalk.
They are removed since they have no real use in the CentOS environment - and we not be a reason for people hitting rhn.r.c when they dont need to or even should be doing so.
They can be used to connect to Spacewalk, which is free upstream project of RHN Satellite, which is standalone version of rhn.redhat.com. Large part (if not majority) of Spacewalk users use CentOS and I'm pretty sure they will appreciate, if these tools will be present directly in CentoOS.
I think in the spacewalk context its easier to look at it from the point of view that adding these packages does nothing for the spacewalk user, since they are not the only things needed to make spacewalk environment. So the user haseto already go and enable another repo somewhere, these tools can come from there as well.
I disagree. Majority of people will install only these packages. Yes - we have client repo which contains several other tools. But with these packages you can do most of the management (install/upgrade/remove package, do rollback, compare profiles, run scripts, reboot machines, reprovision them...). In fact even as developer of Spacewalk I rarely use other then those mentioned client packages.
However, if there is a real reason to add these back in I dont see why that could not happen. I just dont see the reason at this time.
I'm not sure if I convinced you, I'm just asking because Spacewalk users asks us-developers.
That said however... the tools required are in the spacewalk repos and if you are going to be using spacewalk you will want to use those repos due to the heavy development and updates going on in them.... The spacewalk client repo was missing the python-ethtool package until recently but that has been rectified. If you are building centos systems it would be much better to use the spacewalk-client repo for these (or a local mirror of it) to ease troubleshooting the spacewalk systems whilst they are developed (not to mention you will probably want the spacewalk client repo anyway for things like spacewalk-koan, osad, etc).
James
2010/1/21 Miroslav Suchý msuchy@redhat.com
Karanbir Singh wrote:
Hi,
On 01/20/2010 03:59 PM, Miroslav Suchý wrote:
severals users of Spacewalk [1] reported that Spacewalk client tools are removed [2] from CentOS (they are present in RHEL).
I am not sure about that - these are not really 'spacewalk' client tools but are more along the lines of 'rhn tools'.
Yes, they carry the heritage of rhn in their name and their original purpose was to connect to rhn.redhat.com (and RHN Satellite), but since open sourcing this product as Spacewalk project at 2008, these tools can be used to connect to Spacewalk.
They are removed since they have no real use in the CentOS environment - and we not be a reason for people hitting rhn.r.c when they dont need to or even should be doing so.
They can be used to connect to Spacewalk, which is free upstream project of RHN Satellite, which is standalone version of rhn.redhat.com. Large part (if not majority) of Spacewalk users use CentOS and I'm pretty sure they will appreciate, if these tools will be present directly in CentoOS.
I think in the spacewalk context its easier to look at it from the point of view that adding these packages does nothing for the spacewalk user, since they are not the only things needed to make spacewalk environment. So the user haseto already go and enable another repo somewhere, these tools can come from there as well.
I disagree. Majority of people will install only these packages. Yes - we have client repo which contains several other tools. But with these packages you can do most of the management (install/upgrade/remove package, do rollback, compare profiles, run scripts, reboot machines, reprovision them...). In fact even as developer of Spacewalk I rarely use other then those mentioned client packages.
However, if there is a real reason to add these back in I dont see why that could not happen. I just dont see the reason at this time.
I'm not sure if I convinced you, I'm just asking because Spacewalk users asks us-developers.
-- Miroslav Suchy Red Hat Satellite Engineering Cloud Computing and Integrated Solution Dept. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Hi James,
Dont top post, its silly. And now there is no way to co-relate what you said to what Miroslav has.
On 21/01/10 09:16, James Hogarth wrote:
Yes, they carry the heritage of rhn in their name and their original purpose was to connect to rhn.redhat.com <http://rhn.redhat.com> (and RHN Satellite), but since open sourcing this product as Spacewalk project at 2008, these tools can be used to connect to Spacewalk.
I dont think the ability of these packages to connect with spacewalk is on the conversation block here really. Its the fact that we dont want to enable a set of tools that is in turn going to hit rhn or potentially cause AUP issues for people who dont know what they are doing or are unaware of the tools doing this sort of a thing.
Large part (if not majority) of Spacewalk users use CentOS and I'm pretty sure they will appreciate, if these tools will be present directly in CentoOS.
Just for the sake of having another options - would it be possible to perhaps get a few people together to manage and run a centos-spacewalk repo, we find project hosting and repo hosting within the centos infra and perhaps do something to make it easily visible ( perhaps a centos-spacewalk-release rpm which contains a .repo file pointing to this repository ).
Secondly, what is the release timeline for these client tools into RHEL 4/5 compared with whats in the spacewalk client tools repo at the moment ? are they mostly in sync ? I could go and just look, but I expect you guys to have a better idea on the state of things.
I disagree. Majority of people will install only these packages.
Ok, that clears up one part of the things for me.
Yes - we have client repo which contains several other tools. But with these packages you can do most of the management (install/upgrade/remove package, do rollback, compare profiles, run scripts, reboot machines, reprovision them...). In fact even as developer of Spacewalk I rarely use other then those mentioned client packages.
Justin Sherrill had started working down the road of making a 'snapshot' of the spacewalk client tools repo, updating that to sync with the release schedules of CentOS-4.X and 5.X; Is that still an option ?
I dont deny the fact that adding these packages in would make things easier for people who use spacewalk, but lets not do that if it makes things a bit harder or obscure for people who dont use spacewalk. So lets talk about it and see how we can make and keep both sides happy.
Am Donnerstag, den 21.01.2010, 10:32 +0100 schrieb Karanbir Singh:
Just for the sake of having another options - would it be possible to perhaps get a few people together to manage and run a centos-spacewalk repo, we find project hosting and repo hosting within the centos infra and perhaps do something to make it easily visible ( perhaps a centos-spacewalk-release rpm which contains a .repo file pointing to this repository ).
Isn't that exactly what the spacewalk-client-repo does? At least for C5.
Chris
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
On 21/01/10 09:46, Christoph Maser wrote:
Just for the sake of having another options - would it be possible to perhaps get a few people together to manage and run a centos-spacewalk repo, we find project hosting and repo hosting within the centos infra
Isn't that exactly what the spacewalk-client-repo does? At least for C5.
I dont know, you tell me :)
Dear Karan,
...
Justin Sherrill had started working down the road of making a 'snapshot' of the spacewalk client tools repo, updating that to sync with the release schedules of CentOS-4.X and 5.X; Is that still an option ?
I dont deny the fact that adding these packages in would make things easier for people who use spacewalk, but lets not do that if it makes things a bit harder or obscure for people who dont use spacewalk. So lets talk about it and see how we can make and keep both sides happy.
An option would be to include all packages from the newly created Spacewalk $ver-client repo, e.g.:
http://spacewalk.redhat.com/yum/0.7-client/RHEL/5/i386/
in the plus repo as it would make client registration/management a bit easier.
For Fedora, the plan is to bring these packages to the main tree, and most of them are already there.
As Miroslav already stated that these packages won't hit rhn.redhat.com I do not thing that should be a big problem.
Setting up an own repo for the 'server' part of Spacewalk within the CentOS Space does not make much sense imho and would cause overhead.
Best Regards Marcus
Marcus Moeller wrote:
An option would be to include all packages from the newly created Spacewalk $ver-client repo, e.g.:
Not in CentOS5 since recent this version require python-dmidecode which is not in RHEL and therefore probably in CentOS.
For Fedora, the plan is to bring these packages to the main tree, and most of them are already there.
Yes, I'm preparing them. Ale mentioned packages are already there. Bunch of others are on the way.
As Miroslav already stated that these packages won't hit rhn.redhat.com I do not thing that should be a big problem.
Partialy true. Recent upstream version will not hit accidentaly rhn.redhat.com That version included in RHEL will do that by default. But these change: https://fedorahosted.org/spacewalk/changeset/cd925d940357d145c7106c1c3ed6ed1... is only one which are required to prevent from accidental check of rhn.redhat.com
So my recomendation is: take this patch and apply it on current rhel5 package and include all of them in CentOS.
Setting up an own repo for the 'server' part of Spacewalk within the CentOS Space does not make much sense imho and would cause overhead.
+1
Dear Miroslav,
An option would be to include all packages from the newly created Spacewalk $ver-client repo, e.g.:
Not in CentOS5 since recent this version require python-dmidecode which is not in RHEL and therefore probably in CentOS.
Ah, I forgot about that.
Partialy true. Recent upstream version will not hit accidentaly rhn.redhat.com That version included in RHEL will do that by default. But these change: https://fedorahosted.org/spacewalk/changeset/cd925d940357d145c7106c1c3ed6ed1... is only one which are required to prevent from accidental check of rhn.redhat.com
So my recomendation is: take this patch and apply it on current rhel5 package and include all of them in CentOS.
I would personally do not include the rhns client packages to use them with Spacewalk.
Spacewalk development is much faster which may lead into missing features as they are not yet implemented in the version that is meant to be used with rhn.
The only option I see is to keep the rhns and spacewalk-client packages in sync, which may be the case in the near future (e.g. on RHEL 6)
Best Regards Marcus
Marcus Moeller wrote:
Spacewalk development is much faster which may lead into missing features as they are not yet implemented in the version that is meant to be used with rhn.
If you have environment when you want to centraly manage your machines and installing from is only way, you want to have yum-rhn-plugin available just after kickstart. Just to be able to install package. You do not care about recent features. But I have to admit, that I do not know how many such users and environment exists.
The only option I see is to keep the rhns and spacewalk-client packages in sync, which may be the case in the near future (e.g. on RHEL 6)
Yes, keep status que and do not remove it from CentOS 6 is definitely valid option.
Karanbir Singh wrote:
Secondly, what is the release timeline for these client tools into RHEL 4/5 compared with whats in the spacewalk client tools repo at the moment
Spacewalk is released every 2-3 months. Minor release of RHEL has been released aprox. every 8 months.
? are they mostly in sync ? I could go and just look, but I expect you guys to have a better idea on the state of things.
They are compatible. I.e you can use both to Spacewalk and it will work. But spacewalk client usually contains some features which rhel client do not have.
Justin Sherrill had started working down the road of making a 'snapshot' of the spacewalk client tools repo, updating that to sync with the release schedules of CentOS-4.X and 5.X; Is that still an option ?
Making another repo is IMO not option, if you have to add it, than you can add Spacewalk client repo directly.
I dont deny the fact that adding these packages in would make things easier for people who use spacewalk, but lets not do that if it makes things a bit harder or obscure for people who dont use spacewalk. So lets talk about it and see how we can make and keep both sides happy.
How can these packages make life "harder or obscure" for people who dont use spacewalk? Especially if these packages will not talk to rhn.redhat.com by default.
Hi,
On 21/01/10 14:02, Miroslav Suchý wrote:
Secondly, what is the release timeline for these client tools into RHEL 4/5 compared with whats in the spacewalk client tools repo at the moment
They are compatible. I.e you can use both to Spacewalk and it will work.
ok, that basically means that most people dont *need* to use the spacewalk client, and can stick with whats in the EL codebase for most of their work. ( ~ my understanding )
How can these packages make life "harder or obscure" for people who dont use spacewalk? Especially if these packages will not talk to rhn.redhat.com by default.
A very large number of pople who use centos, do so with little or no previous understand of linux or even the basics of systems management - we need to keep those people in mind as well. The problem that we have had, in the past, is that installing yum-rhn-plugin brought in loads of rhn* packages as well, which in turn would cause traffic to rhn.r.c. Also, given that rhn itself is a rhel connected service, the view we took was that there is no need for that functionality in the distro at all.
Traditionally, the approach has been to remove all rhn references and packages ( as much as can be done without maiming any significant functionality ). This is how it worked for CentOS-3/4/5. Having said that, there is no reason why we cant change things if there is a real benefit in doing so.
Let me import the sources into a shared setup, and we can workout a patchset that is needed. We can then target this for 5.5 inclusion if its considered worth doing and does not cause any issues.
Hi again,
Let me import the sources into a shared setup, and we can workout a patchset that is needed. We can then target this for 5.5 inclusion if its considered worth doing and does not cause any issues.
I still ask myself why one would use the 'old' rhn tools from rhel to connect against Spacewalk instead of the current ones.
Until these are not in sync, inclusion of the rhel packages does not make much sense imho.
Best Regards Marcus
PS: To be paranoid: maybe RH is planning a migration path to 'upgrade' from CentOS to RHEL, which is the only reason I see atm why the tools should be integrated :)
2010/1/26 Marcus Moeller mail@marcus-moeller.de:
Hi again,
Let me import the sources into a shared setup, and we can workout a patchset that is needed. We can then target this for 5.5 inclusion if its considered worth doing and does not cause any issues.
I still ask myself why one would use the 'old' rhn tools from rhel to connect against Spacewalk instead of the current ones.
Until these are not in sync, inclusion of the rhel packages does not make much sense imho.
Best Regards Marcus
PS: To be paranoid: maybe RH is planning a migration path to 'upgrade' from CentOS to RHEL, which is the only reason I see atm why the tools should be integrated :) _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
I have a growing spacewalk install for my centos systems to assist in management of them. Currently around 30 machines and when done should hit around 100-120... not a huge number but it helps significantly.
Given that to setup spacewalk in the first instance a user would need to make use of the non-client repo (possibly replicating it locally) and then create channels that sync from other upstream repos (or push own packages to them) to get proper functionality - ie the ability to view updated packages and push them out as required.... I honestly can't see much point in having the old RHEL5.X packages in Centos 5.X by default. Anyone that is implementing at this stage should have the competence to create a local yum repo from the client-tools spacewalk repo that they can use to install the client tools and register a system against their server - and if there were any bugs between spacewalk and the client tools they would likely be fixed faster in the client repo as used by the spacewalk team... doubly so in light of the time it takes for the redhat SRPMS to be cleaned up and generated for teh centos repositories.
As far as an 'upgrade path' from centos to RHEL upon recently asking this of our account manager (for a sizeable enterprise account) we were told quite clearly that such an action wouldn't be supported and RHEL systems they would provide support on going forwards would need to be built from scratch.
On 01/26/2010 09:04 AM, James Hogarth wrote:
Given that to setup spacewalk in the first instance a user would need to make use of the non-client repo (possibly replicating it locally) and then create channels that sync from other upstream repos (or push own packages to them) to get proper functionality - ie the ability to view updated packages and push them out as required.... I honestly can't see much point in having the old RHEL5.X packages in Centos 5.X by default.
Miroslav made a good point in that much of this work is only needed 'spacewalk master' side and that including these packages on the client distro would make things easier for new users to get onto the ladder. Is that really not the case ?
At the moment, there are two arguments - however, the main issue at hand is that does including these packages have any impact on the usability of spacewalk as a management environment, to manage centos installed machines.
- KB
Dear Karan.
...
Miroslav made a good point in that much of this work is only needed 'spacewalk master' side and that including these packages on the client distro would make things easier for new users to get onto the ladder. Is that really not the case ?
At the moment, there are two arguments - however, the main issue at hand is that does including these packages have any impact on the usability of spacewalk as a management environment, to manage centos installed machines.
As stated before, inclusion of the RHEL packages does not make much sence, as they are soon out of sync.
Adding the packages from the Spacewalk client repo could be an alternative, but I do not see that great benefits as you can add these as a child channel which is accessible during installation.
Best Regards Marcus
On 04/02/10 21:43, Marcus Moeller wrote:
As stated before, inclusion of the RHEL packages does not make much sence, as they are soon out of sync.
This conversation has gone past 2 full loops now. The only issue, as far as I can tell, not cleared up is that can packages in the stock EL4 and EL5 srpm tree be used against spacewalk 0.6 and 0.7 ?
They might be 'outdated' in that perhaps all features may not be present, but is there an issue of these packages not being usable at all due to an api incompatibility ?
Dear Karan.
...
This conversation has gone past 2 full loops now. The only issue, as far as I can tell, not cleared up is that can packages in the stock EL4 and EL5 srpm tree be used against spacewalk 0.6 and 0.7 ?
They might be 'outdated' in that perhaps all features may not be present, but is there an issue of these packages not being usable at all due to an api incompatibility ?
Not now, but maybe in upcoming releases of Spacewalk.
Spacewalk is meant to be used with the Spacewalk client tools, not the RHE ones.
Best Regards Marcus
On Tue, 9 Feb 2010, Marcus Moeller wrote:
This conversation has gone past 2 full loops now. The only issue, as far as I can tell, not cleared up is that can packages in the stock EL4 and EL5 srpm tree be used against spacewalk 0.6 and 0.7 ?
They might be 'outdated' in that perhaps all features may not be present, but is there an issue of these packages not being usable at all due to an api incompatibility ?
Not now, but maybe in upcoming releases of Spacewalk.
Spacewalk is meant to be used with the Spacewalk client tools, not the RHE ones.
Marcus,
Could we please wait to hear this confirmed by someone from the Spacewalk development community ? You may or may not know that what Red Hat ships and is called Red Hat Network Satellite, is in fact using spacewalk packages, and a seperate RHN package that rebrands Spacewalk.
So I would seriously doubt that Red Hat would break compatibility with Spacewalk in their own product. What's more, even if up2date/yum-rhn would break in a future product release, it would still allow people to choose whether to use a compatible Spacewalk release or not.
In my opinion, if CentOS wants to be compatible with RHEL, it needs to be compatible even in the parts that may or may not be useful to its users. Let the users decide whether it is useful to them or not, even if the majority will never use Spacewalk.
Hi,
On 10/02/10 21:55, Dag Wieers wrote:
Could we please wait to hear this confirmed by someone from the Spacewalk development community ? You may or may not know that what Red Hat ships and is called Red Hat Network Satellite, is in fact using spacewalk packages, and a seperate RHN package that rebrands Spacewalk.
This is sort of my concern as well. But then I dont use spacewalk and would really like to hear from Miroslav once on the issue.
In my opinion, if CentOS wants to be compatible with RHEL, it needs to be compatible even in the parts that may or may not be useful to its users.
sure, but then the reason why rhn tools were taken out of the distro in CentOS-3, 4 and 5 is not because its not useful to the users, its because it can and did cause real issues to the users and to Red Hat. There were instances were anecdotal evidence suggested hundreds of thousands of people hitting rhn who didnt even have a rhel install.
However, given that those issues can be addressed and the rhn tools in centos can be patched against the 'concerns' I'm quite happy to consider putting them back in if it helps people with spacewalk ( and potentially other tools )
On Wed, 10 Feb 2010, Karanbir Singh wrote:
On 10/02/10 21:55, Dag Wieers wrote:
Could we please wait to hear this confirmed by someone from the Spacewalk development community ? You may or may not know that what Red Hat ships and is called Red Hat Network Satellite, is in fact using spacewalk packages, and a seperate RHN package that rebrands Spacewalk.
This is sort of my concern as well. But then I dont use spacewalk and would really like to hear from Miroslav once on the issue.
Identical to what I said to Marcus. We know everyone's viewpoint now.
In my opinion, if CentOS wants to be compatible with RHEL, it needs to be compatible even in the parts that may or may not be useful to its users.
sure, but then the reason why rhn tools were taken out of the distro in CentOS-3, 4 and 5 is not because its not useful to the users, its because it can and did cause real issues to the users and to Red Hat. There were instances were anecdotal evidence suggested hundreds of thousands of people hitting rhn who didnt even have a rhel install.
Karanbir, that has been explained now at least three times. There was a reason why shipping the RHN stuff was useless. The situation is now different, and we are re-evaluating.
However, given that those issues can be addressed and the rhn tools in centos can be patched against the 'concerns' I'm quite happy to consider putting them back in if it helps people with spacewalk ( and potentially other tools )
I know. I thought we weren't looping anymore, guess I was wrong :-)
On 10/02/10 23:56, Dag Wieers wrote:
In my opinion, if CentOS wants to be compatible with RHEL, it needs to be compatible even in the parts that may or may not be useful to its users.
sure, but then the reason why rhn tools were taken out of the distro in CentOS-3, 4 and 5 is not because its not useful to the users, its because it can and did cause real issues to the users and to Red Hat.
Karanbir, that has been explained now at least three times. There was a reason why shipping the RHN stuff was useless. The situation is now different, and we are re-evaluating.
right, but I just want to make sure that people dont take your comments in the wrong sense because you seemed to imply that the rhn tools were and are removed from the centos distro due to the fact that they were not useful to the users - which is not the case.
Dear Dag,
Could we please wait to hear this confirmed by someone from the Spacewalk development community ? You may or may not know that what Red Hat ships and is called Red Hat Network Satellite, is in fact using spacewalk packages, and a seperate RHN package that rebrands Spacewalk.
I am an active member of the Spacewalk Community for quite a long time (not seen you there btw.). At work we are using both, Satellite or Spacewalk, so please go ahead and fool someone else.
Spacewalk is the UPSTREAM for Satellite, so development is quite faster. Packages that are concerned to be used with Satellite could as well work with Spacewalk but may lack of features (as stated before).
In my opinion, if CentOS wants to be compatible with RHEL, it needs to be compatible even in the parts that may or may not be useful to its users. Let the users decide whether it is useful to them or not, even if the majority will never use Spacewalk.
This has really nothing to do with RHEL compability, or do you want to manage your CentOS clients with Satellite?
Best Regards Marcus
On Thu, 11 Feb 2010, Marcus Moeller wrote:
Dear Dag,
Could we please wait to hear this confirmed by someone from the Spacewalk development community ? You may or may not know that what Red Hat ships and is called Red Hat Network Satellite, is in fact using spacewalk packages, and a seperate RHN package that rebrands Spacewalk.
I am an active member of the Spacewalk Community for quite a long time (not seen you there btw.). At work we are using both, Satellite or Spacewalk, so please go ahead and fool someone else.
I am not fooling anyone here. I never said I was a Spacewalk developer, and I never said you were _not_ part of the Spacewalk community. I am also not taking a position into the outcome.
But we had at least one Red Hat developer here going against your advice. So I'd like to hear their opinion, rather than 3 times your opinion.
Spacewalk is the UPSTREAM for Satellite, so development is quite faster. Packages that are concerned to be used with Satellite could as well work with Spacewalk but may lack of features (as stated before).
Sure, but even if Spacewalk would move on, people are not forced to use a newer Spacewalk. And even in the case that they would need a newer client, they will have to install that one anyway. So the gain is zero in case the client would not work with the latest Spacewalk, but positive if it is used against a compatible Spacewalk or even RHN.
In my opinion, if CentOS wants to be compatible with RHEL, it needs to be compatible even in the parts that may or may not be useful to its users. Let the users decide whether it is useful to them or not, even if the majority will never use Spacewalk.
This has really nothing to do with RHEL compability, or do you want to manage your CentOS clients with Satellite?
Marcus, if we look at the wider picture and CentOS would ship the RHEL RHN code. In that case what CentOS ships might have an impact to the reasoning and decisions the Spacewalk developers are taking.
Furthermore, at some point RHN will have to support CentOS clients as well (not sure if they are doing that now), but if RHN Satellite is competing with Spacewalk on functionality and Spacewalk would allow RHEL, CentOS, SciLinux and Solaris, but RHN Satellite would not, it seems only natural that Red Hat would be forced to change. Which means that even if not now, future RHEL releases might again be compatible. So leaving it out doesn't give any benefits.
Now I can give you another reason why having the RHN libraries (at least) available on CentOS would be useful. mrepo used the RHN libraries for download packages from RHN. My way of supporting CentOS, was to ship a copy of those libraries with mrepo. So for me it doesn't matter anymore.
But it can impact people outside of the Spacewalk community if RHEL and CentOS are different.
Hi Dag, ...
But we had at least one Red Hat developer here going against your advice. So I'd like to hear their opinion, rather than 3 times your opinion.
As far as I understood Miroslav, he agrees with me in general.
Spacewalk is the UPSTREAM for Satellite, so development is quite faster. Packages that are concerned to be used with Satellite could as well work with Spacewalk but may lack of features (as stated before).
Sure, but even if Spacewalk would move on, people are not forced to use a newer Spacewalk. And even in the case that they would need a newer client, they will have to install that one anyway. So the gain is zero in case the client would not work with the latest Spacewalk, but positive if it is used against a compatible Spacewalk or even RHN.
You should always use the client version that fits to your Spacewalk server. Since 0.7 client tools has been split and could be installed separately.
And as mentioned before, if you work with Spacewalk you can easily deploy system which will be automatically subscribed to the tools channel.
The only advantage would be to include rhn-setup, rhnsd and rhn-client-tools would be to allow systems which are not yet managed by Spacewalk to be registered to it.
Furthermore, at some point RHN will have to support CentOS clients as well (not sure if they are doing that now), but if RHN Satellite is competing with Spacewalk on functionality and Spacewalk would allow RHEL, CentOS, SciLinux and Solaris, but RHN Satellite would not, it seems only natural that Red Hat would be forced to change. Which means that even if not now, future RHEL releases might again be compatible. So leaving it out doesn't give any benefits.
You could already manage CentOS with Satellite if you really want to (but I guess you dont't).
As mentioned, if you really want to include them, I would 'mirror' the ones from the Spacewalk repos and put them into the CentOS-Plus repo.
Best Regards Marcus
On Thu, 11 Feb 2010, Marcus Moeller wrote:
But we had at least one Red Hat developer here going against your advice. So I'd like to hear their opinion, rather than 3 times your opinion.
As far as I understood Miroslav, he agrees with me in general.
Marcus, I have a different recollection from this thread:
http://lists.centos.org/pipermail/centos-devel/2010-January/005307.html
And from the rest of Miroslav's responses it seems he would prefer to patch the original RHEL packages so that they don't hit rhn.redhat.com by default. In fact he provided the patch and specifically mentioned that most people would be using the original client with Spacewalk and not the newer Spacewalk tools from a secondary repository.
You can find all this in the thread above.
It seems the people that would install the (newer) spacewalk client anyway are the first to object the inclusion of the original RHEL RHN code, and they are the least affected by this change.
I am trying to understand why that is.
Dear Dag,
But we had at least one Red Hat developer here going against your advice. So I'd like to hear their opinion, rather than 3 times your opinion.
As far as I understood Miroslav, he agrees with me in general.
Marcus, I have a different recollection from this thread:
http://lists.centos.org/pipermail/centos-devel/2010-January/005307.html
...
The only option I see is to keep the rhns and spacewalk-client packages in sync, which may be the case in the near future (e.g. on RHEL 6)
Yes, keep status que and do not remove it from CentOS 6 is definitely valid option. ...
is what I have read.
It seems the people that would install the (newer) spacewalk client anyway are the first to object the inclusion of the original RHEL RHN code, and they are the least affected by this change.
I am trying to understand why that is.
I know that you are a fan of multiple repos having different versions of packages (and may use priorities plugin). Me not.
An inclusion would also lead to such an situation, and there are no real benifits.
Best Regards Marcus
On Sat, 13 Feb 2010, Marcus Moeller wrote:
It seems the people that would install the (newer) spacewalk client anyway are the first to object the inclusion of the original RHEL RHN code, and they are the least affected by this change.
I am trying to understand why that is.
I know that you are a fan of multiple repos having different versions of packages (and may use priorities plugin). Me not.
I don't see what this has to do with anything. I am not a fan of multiple repositories, but unfortunately we can't push stuff in RHEL or CentOS.
An inclusion would also lead to such an situation, and there are no real benifits.
I don't understand. Without the (upstream) RHEL RHN client in CentOS people are forced to use another repository, even when the RHN client would be sufficient.
Sure there are benefits, if you'd be interested to use CentOS with the corporate RHN Satellite (to keep RHEL+CentOS infrastructure identical). Or simply to bootstrap from RHN/Spacewalk to download/install the updated spacewalk client ?
Why not ?
Dear Dag.
I don't understand. Without the (upstream) RHEL RHN client in CentOS people are forced to use another repository, even when the RHN client would be sufficient.
One disadvantage of using RHN(S) to manage CentOS machines is that you cannot really manage EPEL with it as it contains some 'duplicate' packages which are already in the Red Hat Tools channel.
Sure there are benefits, if you'd be interested to use CentOS with the corporate RHN Satellite (to keep RHEL+CentOS infrastructure identical). Or simply to bootstrap from RHN/Spacewalk to download/install the updated spacewalk client ?
Why not ?
If the packages are going to be incompatible one time, you cannot even register your system to Spacewalk.
Best Regards Marcus
On Mon, 15 Feb 2010, Marcus Moeller wrote:
Dear Dag.
I don't understand. Without the (upstream) RHEL RHN client in CentOS people are forced to use another repository, even when the RHN client would be sufficient.
One disadvantage of using RHN(S) to manage CentOS machines is that you cannot really manage EPEL with it as it contains some 'duplicate' packages which are already in the Red Hat Tools channel.
You can disable a channel when using activation keys, much as with Spacewalk I would assume. You can also populate channels in an automated fashion. Both with RHN and Spacewalk.
Sure there are benefits, if you'd be interested to use CentOS with the corporate RHN Satellite (to keep RHEL+CentOS infrastructure identical). Or simply to bootstrap from RHN/Spacewalk to download/install the updated spacewalk client ?
Why not ?
If the packages are going to be incompatible one time, you cannot even register your system to Spacewalk.
With an emphasis on *if*.
And the same will be true for RHEL. So when we make CentOS different from RHEL, the documentation for both may become different in that area. Is that what we really want ?
Also if CentOS would become identical to RHEL, it may change the dynamics and reasoning for (preventing) incompatibility changes. So I think there's a good reason for keeping things compatible. Whether people want to use RHEL/CentOS with RHN Satellite or using RHEL/CentOS with Spacewalk.
We can not base decisions on things that may or may not happen in the future. In fact, keeping things identical to RHEL protects us from changes that will happen in the future. Nobody can blame us for being identical to RHEL.
People may blame us for deviating from RHEL, which is what we will keep on doing if we leave the RHN libraries/client out.
Although I don't think I will be changing your mind, Marcus, because for your use-case there is no benefit.
Kind regards,
Hi.
I don't understand. Without the (upstream) RHEL RHN client in CentOS people are forced to use another repository, even when the RHN client would be sufficient.
One disadvantage of using RHN(S) to manage CentOS machines is that you cannot really manage EPEL with it as it contains some 'duplicate' packages which are already in the Red Hat Tools channel.
You can disable a channel when using activation keys, much as with Spacewalk I would assume. You can also populate channels in an automated fashion. Both with RHN and Spacewalk.
So what? ...
And the same will be true for RHEL. So when we make CentOS different from RHEL, the documentation for both may become different in that area. Is that what we really want ?
I think CentOS differs from RHEL in some cases. Management with Spacewalk is one. Spacewalk is intend to manage CentOS and Fedora systems, RHN(S) to manage RHEL. Of course it is technically possible to manage CentOS with RHN it is not supported by Red Hat in any form and won't be in the future imho.
People may blame us for deviating from RHEL, which is what we will keep on doing if we leave the RHN libraries/client out.
Although I don't think I will be changing your mind, Marcus, because for your use-case there is no benefit.
And I personally see no benifits in including them and loosing flexibility without any real benefits (besides for mrepo users).
Best Regards Marcus
On Tue, 16 Feb 2010, Marcus Moeller wrote:
People may blame us for deviating from RHEL, which is what we will keep on doing if we leave the RHN libraries/client out.
Although I don't think I will be changing your mind, Marcus, because for your use-case there is no benefit.
And I personally see no benifits in including them and loosing flexibility without any real benefits (besides for mrepo users).
So let's end this thread (before we reiterate for the 7th time) with words from Miroslav Suchÿ, one of the Red Hat Spacewalk developers who stays out of this thread, likely intimidated by it :-)
About including RHEL5 RHN tools in CentOS 5:
"So my recomendation is: take this patch and apply it on current rhel5 package and include all of them in CentOS."
http://lists.centos.org/pipermail/centos-devel/2010-January/005319.html
"Large part (if not majority) of Spacewalk users use CentOS and I'm pretty sure they will appreciate, if these tools will be present directly in CentoOS."
http://lists.centos.org/pipermail/centos-devel/2010-January/005312.html
In response that the user will need other tools anway to use it with Spacewalk:
"I disagree. Majority of people will install only these packages. Yes - we have client repo which contains several other tools. But with these packages you can do most of the management (install/upgrade/remove package, do rollback, compare profiles, run scripts, reboot machines, reprovision them...). In fact even as developer of Spacewalk I rarely use other then those mentioned client packages."
http://lists.centos.org/pipermail/centos-devel/2010-January/005312.html
Kind regards,
Dear Dag.
People may blame us for deviating from RHEL, which is what we will keep on doing if we leave the RHN libraries/client out.
Although I don't think I will be changing your mind, Marcus, because for your use-case there is no benefit.
And I personally see no benifits in including them and loosing flexibility without any real benefits (besides for mrepo users).
So let's end this thread (before we reiterate for the 7th time) with words from Miroslav Suchÿ, one of the Red Hat Spacewalk developers who stays out of this thread, likely intimidated by it :-)
Wasn't it Miroslav who also wanted to include these in EPEL, making it completly useless for managed RHEL systems? But anyhow, I have said what needs to be said.
Best Regards Marcus
But it can impact people outside of the Spacewalk community if RHEL and CentOS are different.
Dag is right, but a _possible_ solution for this would be creating SpaceWalk packages suitable for CentOS and keep it in a different repository so that people who really want/need to use SpaceWalk on CentOS can do it.
Though SpaceWald wouldn't be part of the main project because the compatibility issues mentioned by Dag. Warning people about this problems is important as well, and this could done somewhere in projects page.
By the way, there's a long thread in Centos-Docs list about SpaceWalk installation and configuration process. Maybe the points mentioned by Dag and all the arguments should be included in that document (if it's already not).
Regards,
Hi,
But it can impact people outside of the Spacewalk community if RHEL and CentOS are different.
Dag is right, but a _possible_ solution for this would be creating SpaceWalk packages suitable for CentOS and keep it in a different repository so that people who really want/need to use SpaceWalk on CentOS can do it.
These packages are already available in a 'different repository' as they are part of the Spacewalk repo. If you need to register a system to Spacewalk you can easily create a simple scripts that adds the necessary repo, downloads the packages, registers the system and disables all yum repos but the rhn-plugin.
From CentOS perspective, leaving these packages out is not the worst choice.
Best Regards Marcus
On Tue, 26 Jan 2010, Marcus Moeller wrote:
PS: To be paranoid: maybe RH is planning a migration path to 'upgrade' from CentOS to RHEL, which is the only reason I see atm why the tools should be integrated :)
Why should CentOS care in the least if prople migrate from the community product to the paid support with the upstream, or vice versa?
This is a win as I see it.
-- Russ herrold
-
Christoph Maser -
Dag Wieers -
James Hogarth -
Karanbir Singh -
Leonardo Menezes Vaz -
Marcus Moeller -
Miroslav Suchý -
R P Herrold