3:30 a.m.
Even though RDO is supposed to always being ahead of RHEL and EPEL, it
enforces a higher priority (lower priority=N) than the default. Why?
Enforcing priorities should really only ever happen if absolutely necessary
and will often cause pain to users.
For example I'm trying to manage my RDO installation with Puppet but EPEL
and RDO only have Puppet 2.6 which is EOL and it has been decided that
puppet-openstack will no longer support it effective immediately. But to
install puppet 3.2 from puppetlabs' repo, I first have to scrap the
priority from RDO's repo file manually.
As a (former) developer for Packstack I understand it requires a specific
Puppet version but I think we all agree most (non proof of concept)
installations are not using Packstack to set up or maintain their OpenStack
cloud.
-- Sandro
6:03 a.m.
On 06/20/2013 09:30 AM, Sandro "red" Mathys wrote:
Even though RDO is supposed to always being ahead of RHEL and EPEL,
it enforces a higher priority (lower priority=N) than the default. Why?
So yes this is debatable.
y-p-p is used with the RHOS product to give precedence over EPEL.
I.E. even though EPEL is not required there, con existence is supported.
Now RDO requires EPEL so again y-p-p gives us the flexibility for RDO to override EPEL.
Now whether this is actually required at present is not obvious.
We could retain the flexiblity while avoiding problems with y-p-p
by keeping the overlapping set as small as possible.
wrt puppet, I'm not sure why it's there TBH.
EPEL has 2.6.18-3 while puppet-2.6.18-2 is in the RDO repo.
I've asked around a little and will probably just remove
puppet from the RDO repo, which will fix your immediate problem.
I also see django14 in the RDO grizzly repos.
IIRC there were issues with the provides and requires in horizon and django
that required this package be present in RDO with y-p-p giving
precedence to it. Now there are recent changes in EPEL with Django14
being pushed there. Matthias could you remove Django14 from the
RDO repo if possible thus not having to worry about y-p-p for it at least?
Enforcing priorities should really only ever happen if absolutely
necessary and will often cause pain to users.
For example I'm trying to manage my RDO installation with Puppet but EPEL and RDO
only have Puppet 2.6 which is EOL and it has been decided that puppet-openstack will no
longer support it effective immediately. But to install puppet 3.2 from puppetlabs'
repo, I first have to scrap the priority from RDO's repo file manually.
As a (former) developer for Packstack I understand it requires a specific Puppet version
but I think we all agree most (non proof of concept) installations are not using Packstack
to set up or maintain their OpenStack cloud.
Looking at packstack, it installs y-p-p if epel-release is installed
(which it will be by default for RDO).
Again the intention here is to allow these "openstack" repos to override EPEL.
Maybe we should change that logic to only installing y-p-p if RHOS,
as opposed to RDO was being used? Also we'd have packstack setting the
priority in the repo files to actually enable y-p-p (which could already have been
installed).
Anyway given the package removals mentioned about,
I don't see an immediate need to adjust packstack.
thanks,
Pádraig.
6:35 a.m.
On 06/20/2013 12:03 PM, Pádraig Brady wrote:
On 06/20/2013 09:30 AM, Sandro "red" Mathys wrote:
> Even though RDO is supposed to always being ahead of RHEL and EPEL, it enforces a
higher priority (lower priority=N) than the default. Why?
So yes this is debatable.
y-p-p is used with the RHOS product to give precedence over EPEL.
I.E. even though EPEL is not required there, con existence is supported.
Now RDO requires EPEL so again y-p-p gives us the flexibility for RDO to override EPEL.
Now whether this is actually required at present is not obvious.
We could retain the flexiblity while avoiding problems with y-p-p
by keeping the overlapping set as small as possible.
wrt puppet, I'm not sure why it's there TBH.
EPEL has 2.6.18-3 while puppet-2.6.18-2 is in the RDO repo.
I've asked around a little and will probably just remove
puppet from the RDO repo, which will fix your immediate problem.
So I found the reason that puppet was in RDO from the following commit.
It was a temp workaround I made in the rush to get a working RDO out the door,
and completely forgot about. Now the update in epel should fix this issue,
so the plan above to remove puppet from RDO should work, and I've now done that.
thanks,
Pádraig.
commit 18a8667ad0ce3046b5a83edfb3df2f85c1ba2c3d
Author: Pádraig Brady <P(a)draigBrady.com>
Date: Tue Apr 9 16:34:17 2013 +0100
bump release to supersede problematic EPEL package
Avoid https://bugzilla.redhat.com/show_bug.cgi?id=949549
diff --git a/puppet.spec b/puppet.spec
index f7eb4cc..8468e7b 100644
--- a/puppet.spec
+++ b/puppet.spec
@@ -13,7 +13,7 @@
Name: puppet
Version: 2.6.18
-Release: 1%{?dist}
+Release: 2.1%{?dist}
Summary: A network tool for managing many disparate systems
License: GPLv2
URL: http://puppetlabs.com
@@ -290,7 +290,7 @@ fi
rm -rf %{buildroot}
%changelog
-* Mon Mar 11 2013 Michael Stahnke <stahnma(a)puppetlabs.com> - 2.6.18-1
+* Mon Mar 11 2013 Michael Stahnke <stahnma(a)puppetlabs.com> - 2.6.18-2.1
6:50 a.m.
Great, thanks for the quick reply and the quick fix. Still thinking yum
priorities are bad and should be removed completely from RDO (RHOS is a
different story) but if only directly openstack related packages remain in
the repo, it shouldn't matter anyway. -- Sandro
6:56 a.m.
On 20/06/13 13:50, Sandro "red" Mathys wrote:
Great, thanks for the quick reply and the quick fix. Still thinking
yum priorities are bad and should be removed completely from RDO
(RHOS is a different story) but if only directly openstack related
packages remain in the repo, it shouldn't matter anyway. -- Sandro
Why do you think priorities are bad?
They give us the freedom to
directly steer combinations of packages, thus as overriding packages
from elsewhere.
Please keep in mind, this won't happen that often, but still there might
be cases where this is desired.
Matthias
7:15 a.m.
On Thu, Jun 20, 2013 at 1:56 PM, Matthias Runge <mrunge(a)redhat.com> wrote:
On 20/06/13 13:50, Sandro "red" Mathys wrote:
> Great, thanks for the quick reply and the quick fix. Still thinking
> yum priorities are bad and should be removed completely from RDO
> (RHOS is a different story) but if only directly openstack related
> packages remain in the repo, it shouldn't matter anyway. -- Sandro
>
Why do you think priorities are bad?
Because they are patronizing the user, relatively hard to overcome and
situations where they seem necessary should be avoided in general.
They give us the freedom to
directly steer combinations of packages, thus as overriding packages
from elsewhere.
As written in the first post in this thread: since RDO strives to always be
(equal to or more likely) ahead of RHEL and EPEL, such an override should
never be necessary. And overriding "packages from _elsewhere_" should not
be considered necessary as no other repos are (nor should they be)
supported.
Please keep in mind, this won't happen that often, but still
there might
be cases where this is desired.
Like in what case? When will RDO ever want an older version of something
than what is in RHEL / EPEL?
The only thing I can possibly come up with right now are the kernel and
other tools where new networking stuff (netns, maybe more) was enabled
ahead of time but I sure hope those changes make it back into RHEL with the
next kernel update there. Or if not, that new RHEL kernels are again
re-built with those patches for RDO as well to avoid security holes.
-- Sandro
10:01 a.m.
On 20/06/13 14:15, Sandro "red" Mathys wrote:
On Thu, Jun 20, 2013 at 1:56 PM, Matthias Runge
<mrunge(a)redhat.com
<mailto:mrunge@redhat.com>> wrote:
On 20/06/13 13:50, Sandro "red" Mathys wrote:
> Great, thanks for the quick reply and the quick fix. Still thinking
> yum priorities are bad and should be removed completely from RDO
> (RHOS is a different story) but if only directly openstack related
> packages remain in the repo, it shouldn't matter anyway. -- Sandro
>
Why do you think priorities are bad?
Because they are patronizing the user, relatively hard to overcome and
situations where they seem necessary should be avoided in general.
Yum does not resolve dependencies very well, when it comes to ambiguities.
Simple example: we're using Django14 in RDO, whereas EPEL has both, and
the same versions.
yum prioritizes packages with shorter names, thus would install Django
instead of Django14. (version 1.3 vs. 1.4).
Other example: You could have a version of a software which is just a
plain "community" version, whereas you could have in RDO a more
"supported" version, e.g expressed by other logos etc, but still the
same package version.
Like in what case? When will RDO ever want an older version of something
than what is in RHEL / EPEL?
Good question: what will be priorized? Higher prio repo or higher
package version?
The only thing I can possibly come up with right now are the kernel and
other tools where new networking stuff (netns, maybe more) was enabled
ahead of time but I sure hope those changes make it back into RHEL with
the next kernel update there. Or if not, that new RHEL kernels are again
re-built with those patches for RDO as well to avoid security holes.
Good to see, you have found a use-case.
Matthias
10:06 a.m.
On 06/20/2013 04:01 PM, Matthias Runge wrote:
Simple example: we're using Django14 in RDO, whereas EPEL has
both, and
the same versions.
yum prioritizes packages with shorter names, thus would install Django
instead of Django14. (version 1.3 vs. 1.4).
This looks like a bad Requires: line in the RDO packaging. Yum wont
install Django 1.3 when your baseline Requires: >= 1.4 and Django14
should provide Django = 1.4
priorities are harsh in the way it handles and removes stuff from the
pkgsack, but dont blame it for bad packaging.
- KB
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
1:38 a.m.
On 20/06/13 17:06, Karanbir Singh wrote:
>
> yum prioritizes packages with shorter names, thus would install
> Django instead of Django14. (version 1.3 vs. 1.4).
>
This looks like a bad Requires: line in the RDO packaging. Yum wont
install Django 1.3 when your baseline Requires: >= 1.4 and Django14
should provide Django = 1.4
No.
Django14 provides:
Provides: Django = %{version}-%{release}
Horizon requires
%if 0%{?rhel}==6
Requires: Django14
So, it is like you requested.
The problem here is: Horizon requires e.g python-django-compressor,
which also works on Django 1.3. So you just can put there requires:
Django, when requiring there Django14 or Django >= 1.4, you'll break
other installations.
In this case, yum tries to install both, Django14 and Django, which
produces a conflict. Having both, does not make sense at all. So,
parallel installable versions don't help here.
Matthias
10:23 a.m.
On Thu, Jun 20, 2013 at 5:01 PM, Matthias Runge <mrunge(a)redhat.com> wrote:
On 20/06/13 14:15, Sandro "red" Mathys wrote:
> On Thu, Jun 20, 2013 at 1:56 PM, Matthias Runge <mrunge(a)redhat.com
> <mailto:mrunge@redhat.com>> wrote:
>
> On 20/06/13 13:50, Sandro "red" Mathys wrote:
> > Great, thanks for the quick reply and the quick fix. Still thinking
> > yum priorities are bad and should be removed completely from RDO
> > (RHOS is a different story) but if only directly openstack related
> > packages remain in the repo, it shouldn't matter anyway. -- Sandro
> >
> Why do you think priorities are bad?
>
>
> Because they are patronizing the user, relatively hard to overcome and
> situations where they seem necessary should be avoided in general.
>
Yum does not resolve dependencies very well, when it comes to ambiguities.
True. If there are ambiguities which is to be avoided (as said before).
Simple example: we're using Django14 in RDO, whereas EPEL has
both, and
the same versions.
yum prioritizes packages with shorter names, thus would install Django
instead of Django14. (version 1.3 vs. 1.4).
Yum itself does not prioritize anything based on package names. If you
install django, it will install django. If you install django14, it will
install django14. Doesn't matter to yum whether django is 1.3, 1.4 or 1.5
in either case.
...unless you Require django and hope django14 does Provide django and that
that's good enough. It isn't. Requiring something like django >= 1.4 should
be in that case, though.
Other example: You could have a version of a software which is just a
plain "community" version, whereas you could have in RDO a
more
"supported" version, e.g expressed by other logos etc, but still the
same package version.
You could do a lot of things, but lets stick to actual use cases. Even if
you change the logo, openstack-horizon in RDO should still be newer than
the one in EPEL.
>
> Like in what case? When will RDO ever want an older version of something
> than what is in RHEL / EPEL?
Good question: what will be priorized? Higher prio repo or higher
package version?
Well, that's the point of y-p-p: only the higher repo prio counts. Like the
case I mentioned before. RDO had Puppet 2.6 and puppetlabs Puppet 3.2.
Puppet from RDO, having a higher repo prio than default, would always win.
> The only thing I can possibly come up with right now are the
kernel and
> other tools where new networking stuff (netns, maybe more) was enabled
> ahead of time but I sure hope those changes make it back into RHEL with
> the next kernel update there. Or if not, that new RHEL kernels are again
> re-built with those patches for RDO as well to avoid security holes.
Good to see, you have found a use-case.
And I also explained why the use case must be discarded.
-- Sandro
7:53 a.m.
----- Original Message -----
From: "Pádraig Brady" <pbrady(a)redhat.com>
To: "Sandro \"red\" Mathys" <red(a)fedoraproject.org>
Cc: rdo-list(a)redhat.com
Sent: Thursday, June 20, 2013 7:35:09 AM
Subject: Re: [Rdo-list] Why use yum priority in rdo-release repo file?
On 06/20/2013 12:03 PM, Pádraig Brady wrote:
> On 06/20/2013 09:30 AM, Sandro "red" Mathys wrote:
>> Even though RDO is supposed to always being ahead of RHEL and EPEL, it
>> enforces a higher priority (lower priority=N) than the default. Why?
>
> So yes this is debatable.
> y-p-p is used with the RHOS product to give precedence over EPEL.
> I.E. even though EPEL is not required there, con existence is supported.
>
> Now RDO requires EPEL so again y-p-p gives us the flexibility for RDO to
> override EPEL.
> Now whether this is actually required at present is not obvious.
>
> We could retain the flexiblity while avoiding problems with y-p-p
> by keeping the overlapping set as small as possible.
>
> wrt puppet, I'm not sure why it's there TBH.
> EPEL has 2.6.18-3 while puppet-2.6.18-2 is in the RDO repo.
> I've asked around a little and will probably just remove
> puppet from the RDO repo, which will fix your immediate problem.
So I found the reason that puppet was in RDO from the following commit.
It was a temp workaround I made in the rush to get a working RDO out the
door,
and completely forgot about. Now the update in epel should fix this issue,
so the plan above to remove puppet from RDO should work, and I've now done
that.
thanks,
Pádraig.
If puppet is removed from the RDO repo will the Quick Start need to be updated to
explicitly state the EPEL requirement (it does not at the moment)? Currently my
understanding is users only need to explicitly enable/install the RDO repository, then
PackStack (as you say) enables EPEL if it detects that you are on an EL system...I'm
wondering if it is still able to do this without access to puppet from the RDO repository
(chicken and egg situation)?
If not then removing it would necessitate some updates to the instructions (not that this
is necessarily a bad thing in and of itself, there are other issues with the Quick Start
thanks to the introduction of Quantum support in PackStack but the page is locked to
edits).
Thanks,
Steve
8:14 a.m.
On Thu, Jun 20, 2013 at 2:53 PM, Steve Gordon <sgordon(a)redhat.com> wrote:
If puppet is removed from the RDO repo will the Quick Start need to be
updated to explicitly state the EPEL requirement (it does not at the
moment)? Currently my understanding is users only need to explicitly
enable/install the RDO repository, then PackStack (as you say) enables EPEL
if it detects that you are on an EL system...I'm wondering if it is still
able to do this without access to puppet from the RDO repository (chicken
and egg situation)?
Packstack uses pure Python code to enable EPEL.
See packstack/plugins/serverprep_901.py:418
-- Sandro
8:25 a.m.
On 06/20/2013 01:53 PM, Steve Gordon wrote:
----- Original Message -----
> From: "Pádraig Brady" <pbrady(a)redhat.com>
> To: "Sandro \"red\" Mathys" <red(a)fedoraproject.org>
> Cc: rdo-list(a)redhat.com
> Sent: Thursday, June 20, 2013 7:35:09 AM
> Subject: Re: [Rdo-list] Why use yum priority in rdo-release repo file?
>
> On 06/20/2013 12:03 PM, Pádraig Brady wrote:
>> On 06/20/2013 09:30 AM, Sandro "red" Mathys wrote:
>>> Even though RDO is supposed to always being ahead of RHEL and EPEL, it
>>> enforces a higher priority (lower priority=N) than the default. Why?
>>
>> So yes this is debatable.
>> y-p-p is used with the RHOS product to give precedence over EPEL.
>> I.E. even though EPEL is not required there, con existence is supported.
>>
>> Now RDO requires EPEL so again y-p-p gives us the flexibility for RDO to
>> override EPEL.
>> Now whether this is actually required at present is not obvious.
>>
>> We could retain the flexiblity while avoiding problems with y-p-p
>> by keeping the overlapping set as small as possible.
>>
>> wrt puppet, I'm not sure why it's there TBH.
>> EPEL has 2.6.18-3 while puppet-2.6.18-2 is in the RDO repo.
>> I've asked around a little and will probably just remove
>> puppet from the RDO repo, which will fix your immediate problem.
>
> So I found the reason that puppet was in RDO from the following commit.
> It was a temp workaround I made in the rush to get a working RDO out the
> door,
> and completely forgot about. Now the update in epel should fix this issue,
> so the plan above to remove puppet from RDO should work, and I've now done
> that.
>
> thanks,
> Pádraig.
If puppet is removed from the RDO repo will the Quick Start need to be updated to
explicitly state the EPEL requirement (it does not at the moment)? Currently my
understanding is users only need to explicitly enable/install the RDO repository, then
PackStack (as you say) enables EPEL if it detects that you are on an EL system...I'm
wondering if it is still able to do this without access to puppet from the RDO repository
(chicken and egg situation)?
If not then removing it would necessitate some updates to the instructions (not that this
is necessarily a bad thing in and of itself, there are other issues with the Quick Start
thanks to the introduction of Quantum support in PackStack but the page is locked to
edits).
Very good point.
But the packstack package doesn't depend on puppet,
and instead explicitly installs puppet after the
appropriate repos are enabled.
If it didn't do that, then rather than updating the docs,
it would probably best to add the epel-release rpm to the RDO repo
and have rdo-release depend on it. That would obviate the need
for docs and packstack logic. Caveat with that is we'd then
need separate rdo-release rpms for RHEL (derivatives) and Fedora.
So I'm leaving as is until the need arises to change this.
cheers,
Pádraig.
3984
days inactive
3985
days old
12 comments
5 participants
participants (5)
-
Karanbir Singh -
Matthias Runge -
Pádraig Brady -
Sandro "red" Mathys -
Steve Gordon