On Wed, Apr 25, 2018 at 9:09 AM, Matthias Runge mrunge@matthias-runge.de wrote:

On Wed, Apr 25, 2018 at 08:32:53AM +0200, Thomas Oulevey wrote:

...

My proposal would to initiate a rebuild of the new Ansible channel[2](within the Config Management SIG) and follow a better release cycle.

What do you think ? Would it be a solution from all SIG, or should we continue to ship Ansible within each SIG ?

I would really like to see Ansible built and shipped from a single SIG instead of each SIG consuming ansible building their own.

It would probably make sense for the Configuration Management SIG to handle it, as it fits neatly within the purview of that SIG. Same goes for Salt, Chef, Puppet, etc. if they're done by anyone in CentOS in another SIG.

2018-04-27 16:53 GMT+02:00 Sandro Bonazzola sbonazzo@redhat.com:

2018-04-25 8:32 GMT+02:00 Thomas Oulevey thomas.oulevey@cern.ch:

...

Hello Folks,

Starting with CentOS 7.5, ansible package will no be available in CentOS -extras anymore as Red Hat decided to ship Ansible on a separate channel.

Looking at ansible package in CBS [1] I see that Troy, Fabian, Sandro and Alan are rebuilding it. Can we get better at that task ?

My proposal would to initiate a rebuild of the new Ansible channel[2](within the Config Management SIG) and follow a better release cycle.

What do you think ? Would it be a solution from all SIG, or should we continue to ship Ansible within each SIG ?

I would be more than happy to hand over ansible rebuilds to Config Management SIG. I'm rebuilding ansible in Virt SIG just because there wasn't any other SIG keeping the pace with ansible releases. While creating repos, please consider having an ansible-2 repo having always latest ansible 2 along with ansible-2.5, ansible-2.6 and so on. In oVirt we'd like to consume latest ansible 2 always.

Ansible 2.5.3 has been released. What's the status of this? Do I need to build this release in Virt SIG or is this being done from Config Management SIG? Thanks,

...

I would be happy to contribute the rebuild/debranding of existing source rpms (all available versions) if we all agree.

Please note that EPEL is shipping again Ansible 2.5 as it was removed from Extras [3]

-- Thomas Oulevey

en/Ansible/SRPMS/

---

CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

--

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D

Red Hat EMEA https://www.redhat.com/

sbonazzo@redhat.com https://red.ht/sig https://redhat.com/summit

On 23/05/18 08:09, Sandro Bonazzola wrote:

2018-05-18 11:41 GMT+02:00 Sandro Bonazzola <sbonazzo@redhat.com mailto:sbonazzo@redhat.com>:

2018-04-27 16:53 GMT+02:00 Sandro Bonazzola <sbonazzo@redhat.com
<mailto:sbonazzo@redhat.com>>:



    2018-04-25 8:32 GMT+02:00 Thomas Oulevey <thomas.oulevey@cern.ch
    <mailto:thomas.oulevey@cern.ch>>:

        Hello Folks,

        Starting with CentOS 7.5, ansible package will no be
        available in CentOS
        -extras anymore as Red Hat decided to ship Ansible on a
        separate channel.

        Looking at ansible package in CBS [1] I see that Troy,
        Fabian, Sandro
        and Alan are rebuilding it.
        Can we get better at that task ?

        My proposal would to initiate a rebuild of the new Ansible
        channel[2](within the Config Management SIG) and follow a
        better release
        cycle.

        What do you think ? Would it be a solution from all SIG, or
        should we
        continue to ship Ansible within each SIG ?


    I would be more than happy to hand over ansible rebuilds
    to Config Management SIG.
    I'm rebuilding ansible in Virt SIG just because there wasn't any
    other SIG keeping the pace with ansible releases.
    While creating repos, please consider having an ansible-2 repo
    having always latest ansible 2 along with ansible-2.5,
    ansible-2.6 and so on.
    In oVirt we'd like to consume latest ansible 2 always.


Ansible 2.5.3 has been released. What's the status of this?
Do I need to build this release in Virt SIG or is this being done
from Config Management SIG?

Rebuilt within Virt SIG due to lack of response. Build is tagged for release: http://cbs.centos.org/koji/buildinfo?buildID=22809

That's your best option so far, as there is *no* Cfgmgmt SIG (that should be killed if there was really a process for that) as there is nobody involved, no SIG chair, no pkg even built ... the only exception is yum4/dnf (and to be honnest I don't even know why it landed there, as to me it was a wrong target, but not my call)

The "Ansible" case is even more interesting, as when it landed in Extras, there was no even need to have it rebuilt through CBS, but it was removed again, so now it's in a strange situation where newer versions aren't built, so yes, only option is to rebuild those in CBS in your own target/tags and other people can then "tag-build" the same ENVR if they want to also provide it through their SIG repositories

2018-06-04 0:42 GMT+02:00 Alan Pevec apevec@redhat.com:

Hey Thomas,

On Wed, Apr 25, 2018 at 8:32 AM, Thomas Oulevey thomas.oulevey@cern.ch wrote:

...

My proposal would to initiate a rebuild of the new Ansible channel[2](within the Config Management SIG) and follow a better release cycle.

I would rebuild SRPMs published by upstream http://releases.ansible.com/ansible/rpm/release/epel-7-x86_64/ that's was the source for Ansible builds in RDO/Cloud SIG and it mirrors what Storage SIG is doing with Ceph (rebuilding upstream SRPMs from http://download.ceph.com/ )

Ok for me. Just to be sure, how does the spec file from upstream differ from the one in EPEL other than in %dist changed to el7.ans?

I've applied for sig-configmanagement to get this going.

Great.

Cheers, Alan _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

That means that either Brian or me would like to also rebuild (that's the easy part) ansible through CBS, but sticking to the ansible engine version, so rebuilding the src.rpm available here : ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/Ansible/SRPMS/

We could have separate tags and repos, one for .el7ae and the other for upstream .el7.ans rebuilds. Concern with .el7ae is that there will always be delay and it's up to Red Hat product management which versions are selected. For OpenStack master CI we'll need to track upstream closely, eventually doing per commit cross-project CI, see background inhttps://lists.rdoproject.org/pipermail/dev/2018-April/008652.html

Cheers, Alan

On Mon, Jun 4, 2018 at 6:52 AM Sandro Bonazzola sbonazzo@redhat.com wrote:

2018-06-04 12:47 GMT+02:00 Alan Pevec apevec@redhat.com:

...

...

That means that either Brian or me would like to also rebuild (that's the easy part) ansible through CBS, but sticking to the ansible engine version, so rebuilding the src.rpm available here : ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/Ansible/SRPMS/

We could have separate tags and repos, one for .el7ae and the other for upstream .el7.ans rebuilds. Concern with .el7ae is that there will always be delay and it's up to Red Hat product management which versions are selected. For OpenStack master CI we'll need to track upstream closely, eventually doing per commit cross-project CI, see background inhttps://lists.rdoproject.org/pipermail/dev/2018-April/008652.html

Agreed, for oVirt is important too having access to latest upstream.

For anyone not paying close attention: The "latest upstream" from RHEL in the "extras" channel is a 2.4 release, the "latest upstream" from EPEL is 2.5. This is going to continue to cause update confusion depending on which non-default channel is activated. If you want the "latest upstream" from ansible source for ovirt, you need the EPEL version, not the RHEL extras version.

I realize it's late, but would it make sense to start publishing "ansible24", "ansible25", etc. to avoid these conflicts? Similar work was done for RT, Berkeley DB, gcc, and openssl in the past.

On Thu, Jun 7, 2018 at 10:54 PM, Ken Dreyer kdreyer@redhat.com wrote:

On Wed, Jun 6, 2018 at 5:24 AM, Nico Kadel-Garcia nkadel@gmail.com wrote:

...

For anyone not paying close attention: The "latest upstream" from RHEL in the "extras" channel is a 2.4 release, the "latest upstream" from EPEL is 2.5. This is going to continue to cause update confusion depending on which non-default channel is activated. If you want the "latest upstream" from ansible source for ovirt, you need the EPEL version, not the RHEL extras version.

The RHEL 7 Extras version of the ansible package is dead and will not receive updates.

ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/Ansible/SRPMS/ has the "Ansible Engine" channel's RPMs ( not "RHEL Extras" ). Compared to what happened with RHEL 7 Extras in the past, I anticipate that the SRPM versions there will be rev'd more quickly.

• Ken

That channel now has a 2.5.4 release as of 5/4/2018, last Monday. *Good*. Is there a distinct channel now for CentOS, to harvest that package outside of EPEL or extras, distinct as the this channel is distinct? I don't see one in the current CentOS repos. Without that, and without getting out of EPEL, I suspect we're just going to see a recurrence.