Re: [EPEL-devel] Re: Ansible in EL7

[Nico Kadel-Garcia]

On Sat, Apr 14, 2018 at 2:36 PM, Neal Gompa  wrote:
> On Sat, Apr 14, 2018 at 2:28 PM, Nico Kadel-Garcia  wrote:
>> On Sat, Apr 14, 2018 at 2:04 PM, Kevin Fenzi  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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Neal Gompa]

On Sat, Apr 14, 2018 at 2:28 PM, Nico Kadel-Garcia  wrote:
> On Sat, Apr 14, 2018 at 2:04 PM, Kevin Fenzi  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Nico Kadel-Garcia]

On Sat, Apr 14, 2018 at 2:04 PM, Kevin Fenzi  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Kevin Fenzi]

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



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Terry Bowling]

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  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 
> wrote:
>
>> On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen 
>> wrote:
>> > On 11 April 2018 at 10:02, Nico Kadel-Garcia  wrote:
>> >> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy <
>> aboko...@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@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Terry Bowling]

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  wrote:

> On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen 
> wrote:
> > On 11 April 2018 at 10:02, Nico Kadel-Garcia  wrote:
> >> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy 
> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Nico Kadel-Garcia]

On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen  wrote:
> On 11 April 2018 at 10:02, Nico Kadel-Garcia  wrote:
>> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy  
>> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Stephen John Smoogen]

On 11 April 2018 at 10:02, Nico Kadel-Garcia  wrote:
> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy  
> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[James Hogarth]

On 11 April 2018 at 15:02, Nico Kadel-Garcia  wrote:
> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy  
> 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_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Nico Kadel-Garcia]

On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Kevin Fenzi]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[James Hogarth]

On Wed, 11 Apr 2018, 10:05 Peter Robinson,  wrote:

> On Wed, Apr 11, 2018 at 12:58 AM, Todd Zullinger  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

> 
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Alexander Bokovoy]

On ti, 10 huhti 2018, Todd Zullinger wrote:

James Hogarth wrote:

On Wed, 11 Apr 2018, 00:59 Todd Zullinger,  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[James Hogarth]

On Wed, 11 Apr 2018, 01:26 Todd Zullinger,  wrote:

> James Hogarth wrote:
> > On Wed, 11 Apr 2018, 00:59 Todd Zullinger,  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 mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Todd Zullinger]

James Hogarth wrote:
> On Wed, 11 Apr 2018, 00:59 Todd Zullinger,  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.



signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org