It's been several years since OpenStack has been part of the Fedora
distribution. Since then, a number of things have changed.
Some of the major ones:
* Python packaging has gotten better and easier in Fedora (the changes are
* RDO now has Software Factory and full-range CI capabilities
* Fedora has CI hook support for packaging (with the transition to Pagure
* OpenStack and Fedora schedules line up again:
In my view, it's a huge shame that we don't offer OpenStack for people to
use on Fedora, integrated with the latest software. OpenStack distribution
on other distros are able to pull this off, and I feel like we should be
able to as well.
So what I want to know is the following:
* What are the (real or perceived) difficulties in packaging OpenStack for
* How difficult would it be to adapt RDO CI tooling to plug into Fedora
* How many of the underlying dependencies exist in Fedora today that were
forked into CentOS for RDO and which ones?
* What dependencies are in RDO that don't exist in Fedora?
I'm willing to help with a lot of the packaging stuff, including adapting
packages for Fedora, and helping with reviews to bring stuff back in. I
firmly believe that maintenance of OpenStack in Fedora should be far easier
than it was three years ago, when it was ripped out.
So help me... Help you!
真実はいつも一つ！/ Always, there's only one truth!
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:
ansible noarch 126.96.36.199-1.el7.ans /ansible-188.8.131.52-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
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
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
I am Sampath Priyankara and NEW to RDO. I work for NTT and the current PTL
for OpenStack Masakari project .
Recently, some of Masakari users asked me for RPM packages. It seems to me
that, adding them to RDO is the correct way to proceed. I did a quick
how to add masakari components  to RDO, but couldn't find any doc or
information on how to do that.
Any link or information regarding to this would be highly appreciated.
Within the RDO Community and Red Hat, of course your privacy is important
and we will continue to be transparent about what information we collect,
how we use it and about your rights in managing that information. However,
because of the high demands made by the General Data Projection Regulation
(GDPR), a law passed in the European Union, we have made some explicit
changes in our privacy statement. 
If there are any questions, concerns, or requests to see your data or
opt-out, please email privacy(a)rdoproject.org.
Thanks so much,
K Rain Leander
OpenStack Community Liaison
Open Source and Standards Team