A while we discussed dropping the old drbd packages out of the repo. I have a two node cluster I rolled from the same ks file and built rpms from a supported version of drbd using their trivial and well documented method, so when I needed help, I could get it:)
During a `yum update` on only "one" node, it wants to replace drbd.x86_64 8.3.7-1 with drbd82? Uh, ok...
I don't have the genuine skill to manage packages for a repo of such importance like a CentOS repo, but an abandoned package is of equal harm. When a user installs those and then goes to the drbd list for help I suspect he would get the same reply if he installed CentOS 5.0 then encountered an issue and asked for help. Fair? The list of fixes from 8.2.x to current is long.
Given the package building is so well done for drbd, by Linbit, does it make sense to duplicate their effort and simply make work for the maintainers of this repo?
Thanks guys, jlc
On Mon, 31 May 2010, Joseph L. Casale wrote:
A while we discussed dropping the old drbd packages out of the repo. I have a two node cluster I rolled from the same ks file and built rpms from a supported version of drbd using their trivial and well documented method, so when I needed help, I could get it:)
During a `yum update` on only "one" node, it wants to replace drbd.x86_64 8.3.7-1 with drbd82? Uh, ok...
I don't have the genuine skill to manage packages for a repo of such importance like a CentOS repo, but an abandoned package is of equal harm. When a user installs those and then goes to the drbd list for help I suspect he would get the same reply if he installed CentOS 5.0 then encountered an issue and asked for help. Fair? The list of fixes from 8.2.x to current is long.
Given the package building is so well done for drbd, by Linbit, does it make sense to duplicate their effort and simply make work for the maintainers of this repo?
Hi Joseph,
We (ELRepo) are actually discussing to provide kmod-drbd and drbd packages from the ELRepo project (http://elrepo.org/). The goal of the ELRepo project is to provide additional kernel driver (modules) and additional features that the upstream RHEL kernel is lacking for use with both RHEL's and CentOS' kernel.
DRBD in fact fits nicely into this and, as it is now, a lot of people first look at ELRepo when looking for kernel modules anyway. However the importance of bringing out quality packages is very high (the risk of bad things happening too) so we can use all the help we can get to test them once they appear in the ELRepo testing repository.
I hope we can target both drbd80 as well as drbd83, while staying compatible with existing installations and keeping the releases current (testing will have the same or a newer release than production).
Any feedback is welcome.
Kind regards,
On 05/31/2010 05:05 PM, Joseph L. Casale wrote:
During a `yum update` on only "one" node, it wants to replace drbd.x86_64 8.3.7-1 with drbd82? Uh, ok...
yum will not do an update for drbd with drbd82 just based on the name, is there something in drbd82 that is doing an obsolete for drbd ?
Given the package building is so well done for drbd, by Linbit, does it make sense to duplicate their effort and simply make work for the maintainers of this repo?
are they doing any work directly to support centos/el ? If so, it might be worth asking them i they would like to work with Ralph in maintaining the packages in the centos repos.
- KB
yOn Tue, 1 Jun 2010, Karanbir Singh wrote:
On 05/31/2010 05:05 PM, Joseph L. Casale wrote:
Given the package building is so well done for drbd, by Linbit, does it make sense to duplicate their effort and simply make work for the maintainers of this repo?
are they doing any work directly to support centos/el ? If so, it might be worth asking them i they would like to work with Ralph in maintaining the packages in the centos repos.
You have to pay for those packages, so I doubt that is an option. It certainly can't hurt to ask.
However in any case I am interested to get a package-list from each of the listed Linbit packages so we can make the ELRepo packages similar. Or at least compatible.
What worries me is that Linbit doesn't offer repositories and therefore does not have a risk of offering multiple versions at the same time. It is up to the user to select what packages they integrate (which is always a good practice if you want to control your environment).
But our users expect more, spoiled brats :-)
On 06/01/2010 10:42 AM, Dag Wieers wrote:
You have to pay for those packages, so I doubt that is an option. It certainly can't hurt to ask.
I have done that now. I know they based their packages from the centos provided ones, at one point in the past. Since I dont use drbd have lost sync with what they are doing at the moment.
With the open part of the stack going into the mainline, there should be a fairly large pool of people looking to maintain the stable branch as well.
However in any case I am interested to get a package-list from each of the listed Linbit packages so we can make the ELRepo packages similar. Or at least compatible.
I am not interested in elrepo or the packages there, I'd like to fix this for the larger centos community and create a better homogenous user experience.
- KB
You have to pay for those packages, so I doubt that is an option. It certainly can't hurt to ask.
They provide a tarball which builds them automatically, its very well done. http://www.drbd.org/users-guide-emb/s-build-rpm.html
If you want them to run those few commands, you can pay...
I am not interested in elrepo or the packages there, I'd like to fix this for the larger centos community and create a better homogenous user experience.
I think it would be hard to satisfy all options here unless you intentionally made the packages non dependant and possibly made empty rpm's that pull in groups of packages:
I build as follows for my env: $ make rpm RPMOPT="--with rgmanager --without heartbeat --without pacemaker --without xen" $ make km-rpm
As you can see, I use RHCS, not one of the others, I also don't use xen etc...
Just looks like a crap pile of additional work that must then be maintained at every kernel update. I don't want to pull in a xen kernel etc on my HP physical clusters, there's no reason, especially for the sake of a generic "build everything" command applied to the rpm generation.
jlc
On Tue, 1 Jun 2010, Karanbir Singh wrote:
On 06/01/2010 10:42 AM, Dag Wieers wrote:
However in any case I am interested to get a package-list from each of the listed Linbit packages so we can make the ELRepo packages similar. Or at least compatible.
I am not interested in elrepo or the packages there, I'd like to fix this for the larger centos community and create a better homogenous user experience.
Karan,
Both RPMforge and ELRepo are fixing things for the even larger CentOS, Scientific Linux _and_ RHEL communities.
So what else fits into this homogenous user experience plan ?
On Tue, 1 Jun 2010, Karanbir Singh wrote:
On 06/01/2010 09:35 PM, Dag Wieers wrote:
So what else fits into this homogenous user experience plan ?
upstream, downstream and the platform. Take any one of the tree away and in this day and age - its mostly wasted effort.
Ok, let's be more specific. On what basis are packages from downstream accepted ? I can see a list of packages in CentOS Extras, but no clear relation. Let alone some "homogenous user experience plan".
Also during FOSDEM this year (wrt. additional packages) you clearly articulated that the CentOS project was going to return to its core business, and do that well. How does that match with a CentOS Extras repository ?
This is confusing me now, especially since kmod-drbd is out of sync with upstream and most of the packages in CentOS Extras have not been updated since 2007/2008.
On 6/1/2010 5:59 PM, Dag Wieers wrote:
On 06/01/2010 09:35 PM, Dag Wieers wrote:
So what else fits into this homogenous user experience plan ?
upstream, downstream and the platform. Take any one of the tree away and in this day and age - its mostly wasted effort.
Ok, let's be more specific. On what basis are packages from downstream accepted ? I can see a list of packages in CentOS Extras, but no clear relation. Let alone some "homogenous user experience plan".
Also during FOSDEM this year (wrt. additional packages) you clearly articulated that the CentOS project was going to return to its core business, and do that well. How does that match with a CentOS Extras repository ?
This is confusing me now, especially since kmod-drbd is out of sync with upstream and most of the packages in CentOS Extras have not been updated since 2007/2008.
I haven't looked through these specifically, but I think at least some have appeared in EPEL with the same names, and some with incompatible dependencies or builds. Having them continue to exist in both places is a bad thing.
On 01/06/2010 23:59, Dag Wieers wrote:
upstream, downstream and the platform. Take any one of the tree away and in this day and age - its mostly wasted effort.
Ok, let's be more specific. On what basis are packages from downstream accepted ? I can see a list of packages in CentOS Extras, but no clear relation. Let alone some "homogenous user experience plan".
The guys who produce DRBD put out their own packages, CentOS has packages and there are other places that people can get drbd from - most common deployed strategy I've seen is based on local builds(!). The idea of homogenous here would be that if CentOS and the upstream were to work together to make sure that user experience is relatively sane, irrespective of source they get their packages from - that would be a big win.
I have opened a dialog with linbit to see how we might be able to do this. There are quite a few options here that I want to pursue with other upstream vendors as well.
Also during FOSDEM this year (wrt. additional packages) you clearly articulated that the CentOS project was going to return to its core business, and do that well. How does that match with a CentOS Extras repository ?
You are twisting things a bit here. I dont think CentOS ever left its core business of the main distro. Things would have been a bit different had CentOS given up at anytime in the past. So the idea of returning to things is flawed.
From the CentOS Developers perspective its going to be a case of
focusing on whats core to the project and the userbase. If users want to step up and create a self-supported mechanism I dont see why we need to say no or to step away.
CentOS is in a fantastic place to try and unify some of these user experience issues that people run into so often and I would really like to see that change. But rather than just talk about stuff as we have been doing in the past, it worth actually doing things.
- KB
On Tue, 22 Jun 2010, Karanbir Singh wrote:
On 01/06/2010 23:59, Dag Wieers wrote:
Also during FOSDEM this year (wrt. additional packages) you clearly articulated that the CentOS project was going to return to its core business, and do that well. How does that match with a CentOS Extras repository ?
You are twisting things a bit here. I dont think CentOS ever left its core business of the main distro. Things would have been a bit different had CentOS given up at anytime in the past. So the idea of returning to things is flawed.
I obviously meant returning to 'only its core business', but obviously you know this as you said that at FOSDEM :-)
From the CentOS Developers perspective its going to be a case of focusing on whats core to the project and the userbase. If users want to step up and create a self-supported mechanism I dont see why we need to say no or to step away.
Sounds fabulous.
CentOS is in a fantastic place to try and unify some of these user experience issues that people run into so often and I would really like to see that change. But rather than just talk about stuff as we have been doing in the past, it worth actually doing things.
Great !
yum will not do an update for drbd with drbd82 just based on the name, is there something in drbd82 that is doing an obsolete for drbd ?
I'll look into it this afternoon, what's further odd is of the two identical machines whose drbd was installed via rpms built from the same dev box, only one exhibits this behavior?
jlc
On Tue, Jun 1, 2010 at 9:30 AM, Karanbir Singh mail-lists@karan.org wrote:
On 05/31/2010 05:05 PM, Joseph L. Casale wrote:
During a `yum update` on only "one" node, it wants to replace drbd.x86_64 8.3.7-1 with drbd82? Uh, ok...
yum will not do an update for drbd with drbd82 just based on the name, is there something in drbd82 that is doing an obsolete for drbd ?
Yes, there is, iirc. Because we shipped drbd80, drbd82 and drbd83. The drbd package up there is not from extreas.
Given the package building is so well done for drbd, by Linbit, does it make sense to duplicate their effort and simply make work for the maintainers of this repo?
I have no idea if their packaging is kernel agnostic, so that it survives the installation of a new kernel version without rebuilding or recompiling the kernel module.
are they doing any work directly to support centos/el ? If so, it might be worth asking them i they would like to work with Ralph in maintaining the packages in the centos repos.
There are packages for RHEL, which fall out of the SuSE build service, afaik. I've looked at their spec file, but find ours better suited to CentOS.
Ralph
-
Dag Wieers -
Joseph L. Casale -
Karanbir Singh -
Les Mikesell -
Ralph Angenendt