11:05 a.m.
On Fri, Mar 30, 2018 at 4:31 AM, Sam Doran <sdoran(a)redhat.com> wrote:
> Ansible RPMs are already there
> http://releases.ansible.com/ansible/rpm/release/epel-7-x86_64/ but they
> depend on EPEL for additional deps.
Ansible RPMs have always been there. I don't believe they depend on anything
in EPEL.
You are correct, I had some stale info or mixed it up with something else.
Here is yum install output on an empty CentOS7 machine:
Installing:
ansible noarch 2.4.3.0-1.el7.ans /ansible-2.4.3.0-1.el7.ans.noarch
Installing for dependencies:
PyYAML x86_64 3.10-11.el7 base
libyaml x86_64 0.1.4-11.el7_0 base
python-babel noarch 0.9.6-8.el7 base
python-cffi x86_64 1.6.0-5.el7 base
python-enum34 noarch 1.0.4-1.el7 base
python-idna noarch 2.4-1.el7 base
python-ipaddress noarch 1.0.16-2.el7 base
python-jinja2 noarch 2.7.2-2.el7 base
python-markupsafe x86_64 0.11-10.el7 base
python-paramiko noarch 2.1.1-4.el7 extras
python-ply noarch 3.4-11.el7 base
python-pycparser noarch 2.14-1.el7 base
python-setuptools noarch 0.9.8-7.el7 base
python2-cryptography x86_64 1.7.2-1.el7_4.1 updates
python2-pyasn1 noarch 0.1.9-7.el7 base
sshpass x86_64 1.06-2.el7 extras
sshpass and paramiko come from Extras, python2-cryptography comes
from
updates.
My concern is that if those were included in Extras for Ansible, they
would be removed from Extras together with ansible.
I'm not sure if any of that is helpful since you mentioned it
would need to
be built by the appropriate SIG anyway.
Yes, ideally we would be able to get ConfigMgmt SIG going, in the
meantime other SIGs are rebuilding on their own e.g. Virt SIG/oVirt
did 2.4.3 http://cbs.centos.org/koji/buildinfo?buildID=21591
As a quickfix, we could also temporarily push this to RDO deps repo,
until we have rest of the plan ready.
> BTW ideal approach would be to insert OpenStack use-cases into
Ansible
> upstream CI and make it voting, this could become reality with cross-project
> CI efforts lead by openstack-infra. With that, Ansible master would never
> break us!
I don't entirely follow this, but I think it sounds like what I proposed
above: having OpenStack test the devel branch of Ansible so Ansible
Engineering can get feedback quickly if things are broken prior to a
release. I know some of the OpenStack infra folks, and the networking team
within Ansible has been doing a lot of work with them with Zuul for
distributed CI. Myself and Ricardo Cruz on the Ansible side are very
interested in hooking up more testing of Ansible as it relates to OpenStack
using Zuul run by OpenStack Infra. Ricki and I talked about this a bunch at
the PTG but have been working on other things since we got back.
Yes, above was forward-looking CD world where, given infinite CI
resources, everything is tested pre-commit across collaborating
projects.
Definitely trunk RPMs from devel branch are the step in that
direction, progression scale is:
no testing, push the latest release, hope for the best -> CI with
latest release -> CI with devel branch -> CI pre-commit
Cheers,
Alan
9:39 p.m.
New subject: Strategy on packaging external dependencies in RDO + include Ansible in RDO
I see good progress on this thread.
Once thing that I want to bring up, related to
https://review.rdoproject.org/r/#/c/13254/ is that in the future we want to
automate bumps for Ansible (every time there is a new tag); and also make
rdoinfo-tripleo-master-testing-centos-7-multinode-1ctlr-featureset010
<https://review.rdoproject.org/jenkins/job/rdoinfo-tripleo-master-testing-...
job
voting at some point, because it's too easy to merge this patch now while
in fact, new Ansible wasn't properly tested.
On Tue, Apr 3, 2018 at 9:05 AM, Alan Pevec <apevec(a)redhat.com> wrote:
On Fri, Mar 30, 2018 at 4:31 AM, Sam Doran <sdoran(a)redhat.com>
wrote:
>> Ansible RPMs are already there
>> http://releases.ansible.com/ansible/rpm/release/epel-7-x86_64/ but they
>> depend on EPEL for additional deps.
>
> Ansible RPMs have always been there. I don't believe they depend on
anything
> in EPEL.
You are correct, I had some stale info or mixed it up with something else.
Here is yum install output on an empty CentOS7 machine:
Installing:
ansible noarch 2.4.3.0-1.el7.ans /ansible-2.4.3.0-1.el7.ans.
noarch
Installing for dependencies:
PyYAML x86_64 3.10-11.el7 base
libyaml x86_64 0.1.4-11.el7_0 base
python-babel noarch 0.9.6-8.el7 base
python-cffi x86_64 1.6.0-5.el7 base
python-enum34 noarch 1.0.4-1.el7 base
python-idna noarch 2.4-1.el7 base
python-ipaddress noarch 1.0.16-2.el7 base
python-jinja2 noarch 2.7.2-2.el7 base
python-markupsafe x86_64 0.11-10.el7 base
python-paramiko noarch 2.1.1-4.el7 extras
python-ply noarch 3.4-11.el7 base
python-pycparser noarch 2.14-1.el7 base
python-setuptools noarch 0.9.8-7.el7 base
python2-cryptography x86_64 1.7.2-1.el7_4.1 updates
python2-pyasn1 noarch 0.1.9-7.el7 base
sshpass x86_64 1.06-2.el7 extras
> sshpass and paramiko come from Extras, python2-cryptography comes from
> updates.
My concern is that if those were included in Extras for Ansible, they
would be removed from Extras together with ansible.
> I'm not sure if any of that is helpful since you mentioned it would need
to
> be built by the appropriate SIG anyway.
Yes, ideally we would be able to get ConfigMgmt SIG going, in the
meantime other SIGs are rebuilding on their own e.g. Virt SIG/oVirt
did 2.4.3 http://cbs.centos.org/koji/buildinfo?buildID=21591
As a quickfix, we could also temporarily push this to RDO deps repo,
until we have rest of the plan ready.
>> BTW ideal approach would be to insert OpenStack use-cases into Ansible
>> upstream CI and make it voting, this could become reality with
cross-project
>> CI efforts lead by openstack-infra. With that, Ansible master would
never
>> break us!
>
> I don't entirely follow this, but I think it sounds like what I proposed
> above: having OpenStack test the devel branch of Ansible so Ansible
> Engineering can get feedback quickly if things are broken prior to a
> release. I know some of the OpenStack infra folks, and the networking
team
> within Ansible has been doing a lot of work with them with Zuul for
> distributed CI. Myself and Ricardo Cruz on the Ansible side are very
> interested in hooking up more testing of Ansible as it relates to
OpenStack
> using Zuul run by OpenStack Infra. Ricki and I talked about this a bunch
at
> the PTG but have been working on other things since we got back.
Yes, above was forward-looking CD world where, given infinite CI
resources, everything is tested pre-commit across collaborating
projects.
Definitely trunk RPMs from devel branch are the step in that
direction, progression scale is:
no testing, push the latest release, hope for the best -> CI with
latest release -> CI with devel branch -> CI pre-commit
Cheers,
Alan
--
Emilien Macchi
3:50 p.m.
New subject: Strategy on packaging external dependencies in RDO + include Ansible in RDO
This is coming back up. We're making module changes that will release
with ansible 2.7 and will be needed in tripleo. What do we need to do
to move forward with a long term plan for ensuring ansible releases find
their way into rdo?
- JillOn Tue, 2018-04-03 at 18:05 +0200, Alan Pevec wrote:
On Fri, Mar 30, 2018 at 4:31 AM, Sam Doran <sdoran(a)redhat.com>
wrote:
>
> >
> > Ansible RPMs are already there
> > http://releases.ansible.com/ansible/rpm/release/epel-7-x86_64/ but
> > they
> > depend on EPEL for additional deps.
> Ansible RPMs have always been there. I don't believe they depend on
> anything
> in EPEL.
You are correct, I had some stale info or mixed it up with something
else.
Here is yum install output on an empty CentOS7 machine:
Installing:
ansible noarch 2.4.3.0-1.el7.ans /ansible-2.4.3.0-
1.el7.ans.noarch
Installing for dependencies:
PyYAML x86_64 3.10-11.el7 base
libyaml x86_64 0.1.4-11.el7_0 base
python-babel noarch 0.9.6-8.el7 base
python-cffi x86_64 1.6.0-5.el7 base
python-enum34 noarch 1.0.4-1.el7 base
python-idna noarch 2.4-1.el7 base
python-ipaddress noarch 1.0.16-2.el7 base
python-jinja2 noarch 2.7.2-2.el7 base
python-markupsafe x86_64 0.11-10.el7 base
python-paramiko noarch 2.1.1-4.el7 extras
python-ply noarch 3.4-11.el7 base
python-pycparser noarch 2.14-1.el7 base
python-setuptools noarch 0.9.8-7.el7 base
python2-cryptography x86_64 1.7.2-1.el7_4.1 updates
python2-pyasn1 noarch 0.1.9-7.el7 base
sshpass x86_64 1.06-2.el7 extras
>
> sshpass and paramiko come from Extras, python2-cryptography comes
> from
> updates.
My concern is that if those were included in Extras for Ansible, they
would be removed from Extras together with ansible.
>
> I'm not sure if any of that is helpful since you mentioned it would
> need to
> be built by the appropriate SIG anyway.
Yes, ideally we would be able to get ConfigMgmt SIG going, in the
meantime other SIGs are rebuilding on their own e.g. Virt SIG/oVirt
did 2.4.3 http://cbs.centos.org/koji/buildinfo?buildID=21591
As a quickfix, we could also temporarily push this to RDO deps repo,
until we have rest of the plan ready.
>
> >
> > BTW ideal approach would be to insert OpenStack use-cases into
> > Ansible
> > upstream CI and make it voting, this could become reality with
> > cross-project
> > CI efforts lead by openstack-infra. With that, Ansible master
> > would never
> > break us!
> I don't entirely follow this, but I think it sounds like what I
> proposed
> above: having OpenStack test the devel branch of Ansible so Ansible
> Engineering can get feedback quickly if things are broken prior to a
> release. I know some of the OpenStack infra folks, and the
> networking team
> within Ansible has been doing a lot of work with them with Zuul for
> distributed CI. Myself and Ricardo Cruz on the Ansible side are very
> interested in hooking up more testing of Ansible as it relates to
> OpenStack
> using Zuul run by OpenStack Infra. Ricki and I talked about this a
> bunch at
> the PTG but have been working on other things since we got back.
Yes, above was forward-looking CD world where, given infinite CI
resources, everything is tested pre-commit across collaborating
projects.
Definitely trunk RPMs from devel branch are the step in that
direction, progression scale is:
no testing, push the latest release, hope for the best -> CI with
latest release -> CI with devel branch -> CI pre-commit
Cheers,
Alan
_______________________________________________
dev mailing list
dev(a)lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev
To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org
2142
days inactive
2239
days old
2 comments
3 participants
participants (3)
-
Alan Pevec -
Emilien Macchi -
Jill Rouleau