5:30 p.m.
Hi all,
I was under the impression that as of 2.4.0 in EL7 we removed ansible
from EPEL7 since Red Hat included it in their extras repo, and EPEL
policy is not to conflict.
I was surprised just now to see ansible 2.5.0 on a test centos system,
when it wasn't in extras, and on a little bit of a search found:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b
Of course this is a bit of an issue for CentOS/RHEL users that have
need for the Red Hat ansible as they have been upgraded, and RH will
need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then)
to ensure they get it from the right repo.
With a branch retirement shouldn't this have been blocked in koji?
Cheers,
James
6:58 p.m.
New subject: [EPEL-devel] Ansible in EL7
James Hogarth wrote:
I was under the impression that as of 2.4.0 in EL7 we removed
ansible
from EPEL7 since Red Hat included it in their extras repo, and EPEL
policy is not to conflict.
I was surprised just now to see ansible 2.5.0 on a test centos system,
when it wasn't in extras, and on a little bit of a search found:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b
Of course this is a bit of an issue for CentOS/RHEL users that have
need for the Red Hat ansible as they have been upgraded, and RH will
need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then)
to ensure they get it from the right repo.
With a branch retirement shouldn't this have been blocked in koji?
Red Hat announced today that Ansible was being deprecated
from the extras channel. Their advice is that those who
have "previously installed Ansible and its dependencies from
the Extras channel are advised to enable and update from the
Ansible Engine channel, or uninstall the packages as future
errata will not be provided from the Extras channel."
https://access.redhat.com/errata/RHSA-2018:1075
Given that, I believe it is reasonable to see ansible return
to EPEL. This was discussed in previous EPEL meetings a
bit, so I'm sure it was known to at least some of the folks
involved.
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Time may be a great healer, but it's a lousy beautician.
7:13 p.m.
New subject: [EPEL-devel] Ansible in EL7
On Wed, 11 Apr 2018, 00:59 Todd Zullinger, <tmz(a)pobox.com> wrote:
James Hogarth wrote:
> I was under the impression that as of 2.4.0 in EL7 we removed ansible
> from EPEL7 since Red Hat included it in their extras repo, and EPEL
> policy is not to conflict.
>
> I was surprised just now to see ansible 2.5.0 on a test centos system,
> when it wasn't in extras, and on a little bit of a search found:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b
>
> Of course this is a bit of an issue for CentOS/RHEL users that have
> need for the Red Hat ansible as they have been upgraded, and RH will
> need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then)
> to ensure they get it from the right repo.
>
> With a branch retirement shouldn't this have been blocked in koji?
Red Hat announced today that Ansible was being deprecated
from the extras channel. Their advice is that those who
have "previously installed Ansible and its dependencies from
the Extras channel are advised to enable and update from the
Ansible Engine channel, or uninstall the packages as future
errata will not be provided from the Extras channel."
https://access.redhat.com/errata/RHSA-2018:1075
Given that, I believe it is reasonable to see ansible return
to EPEL. This was discussed in previous EPEL meetings a
bit, so I'm sure it was known to at least some of the folks
involved.
Cheers for the info.
It wasn't mentioned on the devel list, I didn't see it in the 7.5 release
notes and it was still in extras when I checked a short while ago.
In that case yes I agree it makes total sense to return to epel7
I wonder why they dropped it when the whole point of them bringing it in to
begin with was for Satellite and Tower to have it in the standard RHEL
repos.
Seems so pointless to have only had one release there!
7:16 p.m.
New subject: [EPEL-devel] Ansible in EL7
On Wed, 11 Apr 2018, 01:13 James Hogarth, <james.hogarth(a)gmail.com> wrote:
On Wed, 11 Apr 2018, 00:59 Todd Zullinger, <tmz(a)pobox.com> wrote:
> James Hogarth wrote:
> > I was under the impression that as of 2.4.0 in EL7 we removed ansible
> > from EPEL7 since Red Hat included it in their extras repo, and EPEL
> > policy is not to conflict.
> > > I was surprised just now to see ansible 2.5.0 on a
test centos system,
> > when it wasn't in extras, and on a little bit of a search found:
> > >
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b
> > > Of course this is a bit of an issue for CentOS/RHEL
users that have
> > need for the Red Hat ansible as they have been upgraded, and RH will
> > need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then)
> > to ensure they get it from the right repo.
> > > With a branch retirement shouldn't this have been
blocked in koji?
> Red Hat announced today that Ansible was being deprecated
> from the extras channel. Their advice is that those who
> have "previously installed Ansible and its dependencies from
> the Extras channel are advised to enable and update from the
> Ansible Engine channel, or uninstall the packages as future
> errata will not be provided from the Extras channel."
> https://access.redhat.com/errata/RHSA-2018:1075
> Given that, I believe it is reasonable to see ansible
return
> to EPEL. This was discussed in previous EPEL meetings a
> bit, so I'm sure it was known to at least some of the folks
> involved.
Cheers for the info.
It wasn't mentioned on the devel list, I didn't see it in the 7.5 release
notes and it was still in extras when I checked a short while ago.
In that case yes I agree it makes total sense to return to epel7
I wonder why they dropped it when the whole point of them bringing it in
to begin with was for Satellite and Tower to have it in the standard RHEL
repos.
Seems so pointless to have only had one release there!
And having read the bugzilla entry now... they moved it to its own product
channel that all RHEL subscribers have access to...
Again this feels so very pointless.
7:25 p.m.
New subject: [EPEL-devel] Re: Ansible in EL7
James Hogarth wrote:
On Wed, 11 Apr 2018, 00:59 Todd Zullinger, <tmz(a)pobox.com>
wrote:
> Red Hat announced today that Ansible was being deprecated
> from the extras channel. Their advice is that those who
> have "previously installed Ansible and its dependencies from
> the Extras channel are advised to enable and update from the
> Ansible Engine channel, or uninstall the packages as future
> errata will not be provided from the Extras channel."
>
> https://access.redhat.com/errata/RHSA-2018:1075
>
> Given that, I believe it is reasonable to see ansible return
> to EPEL. This was discussed in previous EPEL meetings a
> bit, so I'm sure it was known to at least some of the folks
> involved.
Cheers for the info.
It wasn't mentioned on the devel list, I didn't see it in the 7.5 release
notes and it was still in extras when I checked a short while ago.
In that case yes I agree it makes total sense to return to epel7
I wonder why they dropped it when the whole point of them bringing it in to
begin with was for Satellite and Tower to have it in the standard RHEL
repos.
Seems so pointless to have only had one release there!
Indeed, it was a bit strange. Perhaps someone with more
insight into the rationale can comment. I have no
particular knowledge of things, but maybe keeping a fast
moving project like ansible in even the RHEL extras channel
was a problem.
Maybe the plan with the move to the "Ansible Engine" channel
is to work closer with subscribers on migrating from version
to version. And non-subscribers can just follow it in EPEL.
I'd be interested in hearing more about the change, though I
suspect those who know more either aren't on these lists or
can't say more than Red Hat's advisory has already.
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I'm not fat. I am a nutritional overachiever.
1:05 a.m.
New subject: [EPEL-devel] Re: Ansible in EL7
On Wed, 11 Apr 2018, 01:26 Todd Zullinger, <tmz(a)pobox.com> wrote:
James Hogarth wrote:
> On Wed, 11 Apr 2018, 00:59 Todd Zullinger, <tmz(a)pobox.com> wrote:
>> Red Hat announced today that Ansible was being deprecated
>> from the extras channel. Their advice is that those who
>> have "previously installed Ansible and its dependencies from
>> the Extras channel are advised to enable and update from the
>> Ansible Engine channel, or uninstall the packages as future
>> errata will not be provided from the Extras channel."
> >> https://access.redhat.com/errata/RHSA-2018:1075
> >> Given that, I believe it is reasonable to see ansible
return
>> to EPEL. This was discussed in previous EPEL meetings a
>> bit, so I'm sure it was known to at least some of the folks
>> involved.
> Cheers for the info.
> It wasn't mentioned on the devel list, I didn't
see it in the 7.5 release
> notes and it was still in extras when I checked a short while ago.
> In that case yes I agree it makes total sense to return
to epel7
> I wonder why they dropped it when the whole point of them
bringing it in
to
> begin with was for Satellite and Tower to have it in the standard RHEL
> repos.
> Seems so pointless to have only had one release there!
Indeed, it was a bit strange. Perhaps someone with more
insight into the rationale can comment. I have no
particular knowledge of things, but maybe keeping a fast
moving project like ansible in even the RHEL extras channel
was a problem.
Maybe the plan with the move to the "Ansible Engine" channel
is to work closer with subscribers on migrating from version
to version. And non-subscribers can just follow it in EPEL.
I'd be interested in hearing more about the change, though I
suspect those who know more either aren't on these lists or
can't say more than Red Hat's advisory has already.
At this point, no offense to Nirik and the maintenance he does on the
package, I'm actually tempted to just grab it from upstream directly at
https://releases.ansible.com/ansible/rpm/
At least then I can get consistency with selection of stable, preview or
nightly ...
<devel-leave(a)lists.fedoraproject.org
8:26 a.m.
New subject: [EPEL-devel] Re: Ansible in EL7
On 04/10/2018 11:05 PM, James Hogarth wrote:
At this point, no offense to Nirik and the maintenance he does on
the
package, I'm actually tempted to just grab it from upstream directly at
https://releases.ansible.com/ansible/rpm/
Feel free. Do whatever you feel is best for you.
At least then I can get consistency with selection of stable, preview or
nightly ...
I don't really understand what you mean here... EPEL is going to pushing
stable releases... with 2 weeks in testing.
With 2.5.x upstream is going to try and do minor releases every 2-3weeks
with all bugfixes that are landed then. EPEL will package those.
kevin
3:43 a.m.
New subject: [EPEL-devel] Re: Ansible in EL7
On ti, 10 huhti 2018, Todd Zullinger wrote:
James Hogarth wrote:
> On Wed, 11 Apr 2018, 00:59 Todd Zullinger, <tmz(a)pobox.com> wrote:
>> Red Hat announced today that Ansible was being deprecated
>> from the extras channel. Their advice is that those who
>> have "previously installed Ansible and its dependencies from
>> the Extras channel are advised to enable and update from the
>> Ansible Engine channel, or uninstall the packages as future
>> errata will not be provided from the Extras channel."
>>
>> https://access.redhat.com/errata/RHSA-2018:1075
>>
>> Given that, I believe it is reasonable to see ansible return
>> to EPEL. This was discussed in previous EPEL meetings a
>> bit, so I'm sure it was known to at least some of the folks
>> involved.
>
> Cheers for the info.
>
> It wasn't mentioned on the devel list, I didn't see it in the 7.5 release
> notes and it was still in extras when I checked a short while ago.
>
> In that case yes I agree it makes total sense to return to epel7
>
> I wonder why they dropped it when the whole point of them bringing it in to
> begin with was for Satellite and Tower to have it in the standard RHEL
> repos.
>
> Seems so pointless to have only had one release there!
Indeed, it was a bit strange. Perhaps someone with more
insight into the rationale can comment. I have no
particular knowledge of things, but maybe keeping a fast
moving project like ansible in even the RHEL extras channel
was a problem.
Maybe the plan with the move to the "Ansible Engine" channel
is to work closer with subscribers on migrating from version
to version. And non-subscribers can just follow it in EPEL.
I'd be interested in hearing more about the change, though I
suspect those who know more either aren't on these lists or
can't say more than Red Hat's advisory has already.
I'm not in Ansible
engineering or product management so take this with a
grain of salt. My understanding is that cadence of Ansible releases and
its aggressiveness in API changes makes it a bit less suitable to follow
a traditional RHEL 7 release cadence. A separate product channel allows
them to update packages at own cadence.
I wonder how re-packaging for CentOS targets could happen with this
approach and probably moving it back to EPEL7 is indeed something that
makes more sense.
--
/ Alexander Bokovoy
9:02 a.m.
New subject: [EPEL-devel] Re: Ansible in EL7
On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy <abokovoy(a)redhat.com> wrote:
I'm not in Ansible engineering or product management so take this
with a
grain of salt. My understanding is that cadence of Ansible releases and
its aggressiveness in API changes makes it a bit less suitable to follow
a traditional RHEL 7 release cadence. A separate product channel allows
them to update packages at own cadence.
I wonder how re-packaging for CentOS targets could happen with this
approach and probably moving it back to EPEL7 is indeed something that
makes more sense.
Wouldn't a separate RHEL channel for a separate product, such as
ansible, mean a separate channel for CentOS to avoid precisely this
confusion? Mixing it into EPEL and having it on a separate RHEL
channel would be *bad* for anyone who activates that separate channel.
They'd have to filter it out of EPEL to ensure that the streams don't
get crossed on any updates from Red Hat. I understand that this is one
of the main reasons EPEL never carries packages that overlap with RHEL
published software.
10:01 a.m.
New subject: [EPEL-devel] Re: Ansible in EL7
On 11 April 2018 at 15:02, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy
<abokovoy(a)redhat.com> wrote:
> I'm not in Ansible engineering or product management so take this with a
> grain of salt. My understanding is that cadence of Ansible releases and
> its aggressiveness in API changes makes it a bit less suitable to follow
> a traditional RHEL 7 release cadence. A separate product channel allows
> them to update packages at own cadence.
>
> I wonder how re-packaging for CentOS targets could happen with this
> approach and probably moving it back to EPEL7 is indeed something that
> makes more sense.
Wouldn't a separate RHEL channel for a separate product, such as
ansible, mean a separate channel for CentOS to avoid precisely this
confusion? Mixing it into EPEL and having it on a separate RHEL
channel would be *bad* for anyone who activates that separate channel.
They'd have to filter it out of EPEL to ensure that the streams don't
get crossed on any updates from Red Hat. I understand that this is one
of the main reasons EPEL never carries packages that overlap with RHEL
published software.
The official EPEL policy with regards to conflicts is here:
https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provid...
So technically, we aren't against policy here... it is a confusing
situation that will require careful config to get the "correct"
ansible for RHEL users though.
10:07 a.m.
New subject: [EPEL-devel] Re: Ansible in EL7
On 11 April 2018 at 10:02, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy
<abokovoy(a)redhat.com> wrote:
> I'm not in Ansible engineering or product management so take this with a
> grain of salt. My understanding is that cadence of Ansible releases and
> its aggressiveness in API changes makes it a bit less suitable to follow
> a traditional RHEL 7 release cadence. A separate product channel allows
> them to update packages at own cadence.
>
> I wonder how re-packaging for CentOS targets could happen with this
> approach and probably moving it back to EPEL7 is indeed something that
> makes more sense.
Wouldn't a separate RHEL channel for a separate product, such as
ansible, mean a separate channel for CentOS to avoid precisely this
confusion? Mixing it into EPEL and having it on a separate RHEL
channel would be *bad* for anyone who activates that separate channel.
They'd have to filter it out of EPEL to ensure that the streams don't
get crossed on any updates from Red Hat. I understand that this is one
of the main reasons EPEL never carries packages that overlap with RHEL
published software.
It is a lot more nuanced than that. EPEL builds packages that do not
overlap with the following channels:
rhel-7-server-extras-rpms/
rhel-7-server-optional-rpms/
rhel-7-server-rpms/
rhel-ha-for-rhel-7-server-rpms/
rhel-server-rhscl-7-rpms/
These are chosen because they were the base set originally and other
channels which might be available can have items which conflict with
each other. This means that EPEL can conflict with somethings inside
of "RHEL" but so can things are in "RHEL".
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
5:13 p.m.
New subject: [EPEL-devel] Re: Ansible in EL7
On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On 11 April 2018 at 10:02, Nico Kadel-Garcia <nkadel(a)gmail.com>
wrote:
> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy <abokovoy(a)redhat.com>
wrote:
>
>> I'm not in Ansible engineering or product management so take this with a
>> grain of salt. My understanding is that cadence of Ansible releases and
>> its aggressiveness in API changes makes it a bit less suitable to follow
>> a traditional RHEL 7 release cadence. A separate product channel allows
>> them to update packages at own cadence.
>>
>> I wonder how re-packaging for CentOS targets could happen with this
>> approach and probably moving it back to EPEL7 is indeed something that
>> makes more sense.
>
> Wouldn't a separate RHEL channel for a separate product, such as
> ansible, mean a separate channel for CentOS to avoid precisely this
> confusion? Mixing it into EPEL and having it on a separate RHEL
> channel would be *bad* for anyone who activates that separate channel.
> They'd have to filter it out of EPEL to ensure that the streams don't
> get crossed on any updates from Red Hat. I understand that this is one
> of the main reasons EPEL never carries packages that overlap with RHEL
> published software.
It is a lot more nuanced than that. EPEL builds packages that do not
overlap with the following channels:
rhel-7-server-extras-rpms/
rhel-7-server-optional-rpms/
rhel-7-server-rpms/
rhel-ha-for-rhel-7-server-rpms/
rhel-server-rhscl-7-rpms/
These are chosen because they were the base set originally and other
channels which might be available can have items which conflict with
each other. This means that EPEL can conflict with somethings inside
of "RHEL" but so can things are in "RHEL".
EPEL is a default, critical requirement for many tools, including Chef
and mock. Many environments running RHEL or CentOS 6 could not be used
without EPEL's plethora of useful tools. RHEL channels can conflict
with each other because they are enabled on an individual host, case
by case basis. I think, from old experiences, that having *anything*
in EPEL that overlaps with any RHEL published channel is begging for
pain.
It may cause pain to current RHEL ansible users, but I think that the
EPEL package needs to be renamed to something like "ansible25" to
avoid conflicts with the RHEL channel.
5:58 a.m.
New subject: [EPEL-devel] Re: Ansible in EL7
Hopefully I can help provide some clarity on this topic, though there is no
easy answer to all aspects. We worked with the Ansible product team to
bundle the Ansible Engine product with the RHEL Subscription. This wording
is important to address the following which we have learned over the past
year are critically important.
- Ansible Engine is a distinct and separate product, with *separate
channel / repo*, lifecycle, release cadence, and support policies.
- Make AE ubiquitous and easily accessible - full support comes with a
subscription
- As a separate product bundled with RHEL, it is *not* RHEL official
content and can go back into EPEL (which was very important).
- The version of Ansible previously provided in RHEL Extras is now
officially deprecated
Changing the package name in one channel does not make all of the problems
go away. There are still Require and Provides metadata tags that would
inevitably cause future conflicts. And probably other issues that I cannot
think of at the moment.
So if a user decides to enable the AE & EPEL channels, then I guess they
could use repo priorities to decide which version is more important to
them. If we decide for them, we will be wrong 50% of the time.
If they are comfortable with EPEL content, I would assume they would simply
not enable the AE channel and problem is solved. At least we are not
making them choose between Extras and EPEL now. With that said, is this
still a problem?
Thank you,
Terry Bowling
Sr. Technical Product Manager - RHEL Systems Mgmt
Red Hat, Inc.
On Wed, Apr 11, 2018 at 6:13 PM, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen
<smooge(a)gmail.com>
wrote:
> On 11 April 2018 at 10:02, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
>> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy <abokovoy(a)redhat.com>
wrote:
>>
>>> I'm not in Ansible engineering or product management so take this with
a
>>> grain of salt. My understanding is that cadence of Ansible releases and
>>> its aggressiveness in API changes makes it a bit less suitable to
follow
>>> a traditional RHEL 7 release cadence. A separate product channel allows
>>> them to update packages at own cadence.
>>>
>>> I wonder how re-packaging for CentOS targets could happen with this
>>> approach and probably moving it back to EPEL7 is indeed something that
>>> makes more sense.
>>
>> Wouldn't a separate RHEL channel for a separate product, such as
>> ansible, mean a separate channel for CentOS to avoid precisely this
>> confusion? Mixing it into EPEL and having it on a separate RHEL
>> channel would be *bad* for anyone who activates that separate channel.
>> They'd have to filter it out of EPEL to ensure that the streams don't
>> get crossed on any updates from Red Hat. I understand that this is one
>> of the main reasons EPEL never carries packages that overlap with RHEL
>> published software.
>
> It is a lot more nuanced than that. EPEL builds packages that do not
> overlap with the following channels:
>
>
> rhel-7-server-extras-rpms/
> rhel-7-server-optional-rpms/
> rhel-7-server-rpms/
> rhel-ha-for-rhel-7-server-rpms/
> rhel-server-rhscl-7-rpms/
>
> These are chosen because they were the base set originally and other
> channels which might be available can have items which conflict with
> each other. This means that EPEL can conflict with somethings inside
> of "RHEL" but so can things are in "RHEL".
EPEL is a default, critical requirement for many tools, including Chef
and mock. Many environments running RHEL or CentOS 6 could not be used
without EPEL's plethora of useful tools. RHEL channels can conflict
with each other because they are enabled on an individual host, case
by case basis. I think, from old experiences, that having *anything*
in EPEL that overlaps with any RHEL published channel is begging for
pain.
It may cause pain to current RHEL ansible users, but I think that the
EPEL package needs to be renamed to something like "ansible25" to
avoid conflicts with the RHEL channel.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
6:28 a.m.
New subject: [EPEL-devel] Re: Ansible in EL7
Re-adding epel-devel as I was previously not a member and received a
rejection notice.
Thank you,
Terry Bowling
Sr. Technical Product Manager - RHEL Systems Mgmt
Red Hat, Inc.
On Sat, Apr 14, 2018 at 6:58 AM, Terry Bowling <tbowling(a)redhat.com> wrote:
Hopefully I can help provide some clarity on this topic, though there
is
no easy answer to all aspects. We worked with the Ansible product team to
bundle the Ansible Engine product with the RHEL Subscription. This wording
is important to address the following which we have learned over the past
year are critically important.
- Ansible Engine is a distinct and separate product, with *separate
channel / repo*, lifecycle, release cadence, and support policies.
- Make AE ubiquitous and easily accessible - full support comes with a
subscription
- As a separate product bundled with RHEL, it is *not* RHEL official
content and can go back into EPEL (which was very important).
- The version of Ansible previously provided in RHEL Extras is now
officially deprecated
Changing the package name in one channel does not make all of the problems
go away. There are still Require and Provides metadata tags that would
inevitably cause future conflicts. And probably other issues that I cannot
think of at the moment.
So if a user decides to enable the AE & EPEL channels, then I guess they
could use repo priorities to decide which version is more important to
them. If we decide for them, we will be wrong 50% of the time.
If they are comfortable with EPEL content, I would assume they would
simply not enable the AE channel and problem is solved. At least we are
not making them choose between Extras and EPEL now. With that said, is
this still a problem?
Thank you,
Terry Bowling
Sr. Technical Product Manager - RHEL Systems Mgmt
Red Hat, Inc.
On Wed, Apr 11, 2018 at 6:13 PM, Nico Kadel-Garcia <nkadel(a)gmail.com>
wrote:
> On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen <smooge(a)gmail.com>
> wrote:
> > On 11 April 2018 at 10:02, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
> >> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy <
> abokovoy(a)redhat.com> wrote:
> >>
> >>> I'm not in Ansible engineering or product management so take this
> with a
> >>> grain of salt. My understanding is that cadence of Ansible releases
> and
> >>> its aggressiveness in API changes makes it a bit less suitable to
> follow
> >>> a traditional RHEL 7 release cadence. A separate product channel
> allows
> >>> them to update packages at own cadence.
> >>>
> >>> I wonder how re-packaging for CentOS targets could happen with this
> >>> approach and probably moving it back to EPEL7 is indeed something that
> >>> makes more sense.
> >>
> >> Wouldn't a separate RHEL channel for a separate product, such as
> >> ansible, mean a separate channel for CentOS to avoid precisely this
> >> confusion? Mixing it into EPEL and having it on a separate RHEL
> >> channel would be *bad* for anyone who activates that separate channel.
> >> They'd have to filter it out of EPEL to ensure that the streams
don't
> >> get crossed on any updates from Red Hat. I understand that this is one
> >> of the main reasons EPEL never carries packages that overlap with RHEL
> >> published software.
> >
> > It is a lot more nuanced than that. EPEL builds packages that do not
> > overlap with the following channels:
> >
> >
> > rhel-7-server-extras-rpms/
> > rhel-7-server-optional-rpms/
> > rhel-7-server-rpms/
> > rhel-ha-for-rhel-7-server-rpms/
> > rhel-server-rhscl-7-rpms/
> >
> > These are chosen because they were the base set originally and other
> > channels which might be available can have items which conflict with
> > each other. This means that EPEL can conflict with somethings inside
> > of "RHEL" but so can things are in "RHEL".
>
> EPEL is a default, critical requirement for many tools, including Chef
> and mock. Many environments running RHEL or CentOS 6 could not be used
> without EPEL's plethora of useful tools. RHEL channels can conflict
> with each other because they are enabled on an individual host, case
> by case basis. I think, from old experiences, that having *anything*
> in EPEL that overlaps with any RHEL published channel is begging for
> pain.
>
> It may cause pain to current RHEL ansible users, but I think that the
> EPEL package needs to be renamed to something like "ansible25" to
> avoid conflicts with the RHEL channel.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
1:04 p.m.
New subject: [EPEL-devel] Re: Ansible in EL7
On 04/11/2018 03:13 PM, Nico Kadel-Garcia wrote:
EPEL is a default, critical requirement for many tools, including
Chef
and mock. Many environments running RHEL or CentOS 6 could not be used
without EPEL's plethora of useful tools. RHEL channels can conflict
with each other because they are enabled on an individual host, case
by case basis. I think, from old experiences, that having *anything*
in EPEL that overlaps with any RHEL published channel is begging for
pain.
There's a number of problems with EPEL saying they won't conflict with
any channel RHEL "publishes". For one, I don't know of any such list of
channels and all the rpms they contain. Additionally, that would mean
likely removing things like Chef and mock, because I suspect there's
some channels out there with those.
It may cause pain to current RHEL ansible users, but I think that the
EPEL package needs to be renamed to something like "ansible25" to
avoid conflicts with the RHEL channel.
I don't think thats practical / desirable.
kevin
1:28 p.m.
New subject: [EPEL-devel] Re: Ansible in EL7
On Sat, Apr 14, 2018 at 2:04 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On 04/11/2018 03:13 PM, Nico Kadel-Garcia wrote:
> EPEL is a default, critical requirement for many tools, including Chef
> and mock. Many environments running RHEL or CentOS 6 could not be used
> without EPEL's plethora of useful tools. RHEL channels can conflict
> with each other because they are enabled on an individual host, case
> by case basis. I think, from old experiences, that having *anything*
> in EPEL that overlaps with any RHEL published channel is begging for
> pain.
There's a number of problems with EPEL saying they won't conflict with
any channel RHEL "publishes". For one, I don't know of any such list of
channels and all the rpms they contain. Additionally, that would mean
likely removing things like Chef and mock, because I suspect there's
some channels out there with those.
That's why I was very careful to say "RHEL published channel". If you
build your own private yum repository, well, it's your responsibility
to set your policies with it. To the best of my ability to discover,
chef is not in *any* published yum repository. The installation
procedures for it on RHEL and CentOS are "run this script to get the
right RPM" based. For mock, it's published in EPEL, not in the base
RHEL channels. So it's completely consistent for it to rely on EPEL
itself.
> It may cause pain to current RHEL ansible users, but I think that
the
> EPEL package needs to be renamed to something like "ansible25" to
> avoid conflicts with the RHEL channel.
I don't think thats practical / desirable.
kevin
I'd agree that it would have been easier to do up front. On further
thought, say call it "ansible-rhel" to resemble the way mysql and java
are published as distiinctly named sets of tools for different
published releases from different authors.
1:36 p.m.
New subject: [EPEL-devel] Re: Ansible in EL7
On Sat, Apr 14, 2018 at 2:28 PM, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Sat, Apr 14, 2018 at 2:04 PM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> On 04/11/2018 03:13 PM, Nico Kadel-Garcia wrote:
>> It may cause pain to current RHEL ansible users, but I think that the
>> EPEL package needs to be renamed to something like "ansible25" to
>> avoid conflicts with the RHEL channel.
>
> I don't think thats practical / desirable.
>
> kevin
I'd agree that it would have been easier to do up front. On further
thought, say call it "ansible-rhel" to resemble the way mysql and java
are published as distiinctly named sets of tools for different
published releases from different authors.
This really doesn't matter. At the end of it, the Ansible guys are
willing support Ansible on EL7 from either source, so it's a moot
point. I would be shocked if we wouldn't be keeping it relatively in
sync between the two channels anyway, since the reason for Ansible
being moved out of Extras is so it can move faster.
Leave it as "ansible" and call it good.
--
真実はいつも一つ！/ Always, there's only one truth!
8:41 p.m.
New subject: [EPEL-devel] Re: Ansible in EL7
On Sat, Apr 14, 2018 at 2:36 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, Apr 14, 2018 at 2:28 PM, Nico Kadel-Garcia
<nkadel(a)gmail.com> wrote:
> On Sat, Apr 14, 2018 at 2:04 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
>> On 04/11/2018 03:13 PM, Nico Kadel-Garcia wrote:
>>> It may cause pain to current RHEL ansible users, but I think that the
>>> EPEL package needs to be renamed to something like "ansible25" to
>>> avoid conflicts with the RHEL channel.
>>
>> I don't think thats practical / desirable.
>>
>> kevin
>
> I'd agree that it would have been easier to do up front. On further
> thought, say call it "ansible-rhel" to resemble the way mysql and java
> are published as distiinctly named sets of tools for different
> published releases from different authors.
This really doesn't matter. At the end of it, the Ansible guys are
willing support Ansible on EL7 from either source, so it's a moot
point. I would be shocked if we wouldn't be keeping it relatively in
sync between the two channels anyway, since the reason for Ansible
being moved out of Extras is so it can move faster.
So what? It only takes an individual consistency in one configuration
to cause configurations for one feature to break ansible entirely for
configurations in the even infinitesimally distinct version of ansible
from the other channel. Maintaining compatibility between different
channels for something with the same package only works well until a
single newly named config file or library is a critical part of the
software, and testing for breakages requires switching back and forth
between the channels to enforce upgrades from the other channel. It
requires regression testing from components from another respository
you're not even using.
Setting "Priorities" is useful to avoid mixing the streams, but in
that case it only takes one added RPM with a name that doesn't exist
in the other repository to mess up the dependencies. We saw that with
"mysql-libs", in particular, and various "openssl" libraries. It was
a
*pain*. If you want it to move faster, and not interfere with an
existing package of the identical name, it's cleaner for the sysadmins
in the field to give it a different name.
> Leave it as "ansible" and call it good.
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
4:04 a.m.
New subject: [EPEL-devel] Ansible in EL7
On Wed, Apr 11, 2018 at 12:58 AM, Todd Zullinger <tmz(a)pobox.com> wrote:
James Hogarth wrote:
> I was under the impression that as of 2.4.0 in EL7 we removed ansible
> from EPEL7 since Red Hat included it in their extras repo, and EPEL
> policy is not to conflict.
>
> I was surprised just now to see ansible 2.5.0 on a test centos system,
> when it wasn't in extras, and on a little bit of a search found:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b
>
> Of course this is a bit of an issue for CentOS/RHEL users that have
> need for the Red Hat ansible as they have been upgraded, and RH will
> need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then)
> to ensure they get it from the right repo.
>
> With a branch retirement shouldn't this have been blocked in koji?
Red Hat announced today that Ansible was being deprecated
from the extras channel. Their advice is that those who
have "previously installed Ansible and its dependencies from
the Extras channel are advised to enable and update from the
Ansible Engine channel, or uninstall the packages as future
errata will not be provided from the Extras channel."
https://access.redhat.com/errata/RHSA-2018:1075
Given that, I believe it is reasonable to see ansible return
to EPEL. This was discussed in previous EPEL meetings a
bit, so I'm sure it was known to at least some of the folks
involved.
There probably should be an announcement sent to the epel announce
list then it gets to a wider audience so more people know this.
6:52 a.m.
New subject: [EPEL-devel] Re: Ansible in EL7
On Wed, 11 Apr 2018, 10:05 Peter Robinson, <pbrobinson(a)gmail.com> wrote:
On Wed, Apr 11, 2018 at 12:58 AM, Todd Zullinger
<tmz(a)pobox.com> wrote:
> James Hogarth wrote:
>> I was under the impression that as of 2.4.0 in EL7 we removed ansible
>> from EPEL7 since Red Hat included it in their extras repo, and EPEL
>> policy is not to conflict.
>>
>> I was surprised just now to see ansible 2.5.0 on a test centos system,
>> when it wasn't in extras, and on a little bit of a search found:
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b
>>
>> Of course this is a bit of an issue for CentOS/RHEL users that have
>> need for the Red Hat ansible as they have been upgraded, and RH will
>> need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then)
>> to ensure they get it from the right repo.
>>
>> With a branch retirement shouldn't this have been blocked in koji?
>
> Red Hat announced today that Ansible was being deprecated
> from the extras channel. Their advice is that those who
> have "previously installed Ansible and its dependencies from
> the Extras channel are advised to enable and update from the
> Ansible Engine channel, or uninstall the packages as future
> errata will not be provided from the Extras channel."
>
> https://access.redhat.com/errata/RHSA-2018:1075
>
> Given that, I believe it is reasonable to see ansible return
> to EPEL. This was discussed in previous EPEL meetings a
> bit, so I'm sure it was known to at least some of the folks
> involved.
There probably should be an announcement sent to the epel announce
list then it gets to a wider audience so more people know this.
Especially if EPEL7 now has a clash with an optional repo that is available
to all subscribers...
There are priority or exclude filters people will need to add to their yum
repository configurations that they may not be otherwise aware of if they
want the "official Red Hat" build of it etc etc
<epel-devel-leave(a)lists.fedoraproject.org>
2209
days inactive
2214
days old
19 comments
9 participants
participants (9)
-
Alexander Bokovoy -
James Hogarth -
Kevin Fenzi -
Neal Gompa -
Nico Kadel-Garcia -
Peter Robinson -
Stephen John Smoogen -
Terry Bowling -
Todd Zullinger