June 2018 - dev - Rdo List Archives

by Neal Gompa

Hey all, 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 numerous) * RDO now has Software Factory and full-range CI capabilities * Fedora has CI hook support for packaging (with the transition to Pagure dist-git) * OpenStack and Fedora schedules line up again: https://releases.openstack.org/ 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 Fedora? * How difficult would it be to adapt RDO CI tooling to plug into Fedora Dist-Git? * 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! Best regards, Neal -- 真実はいつも一つ！/ Always, there's only one truth!

6 years

3
2
0 / 0

Re: [rdo-dev] Strategy on packaging external dependencies in RDO + include Ansible in RDO

by Alan Pevec

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

6 years

3
2
0 / 0

zuulv3 migration update

by Paul Belanger

Greetings, Wanted to give an update to the zuulv3 migration process. As it stands right now, all projects specific to the rdoproject.org have been fully migrated from jenkins to zuulv3. Hopefully this process was transparent to you, for the most part we were able to fully test everything before flipping the switch on a project. However we did have a few issues with jobs, but thanks to jpena, amoralej and number80, to name a few, we managed to land fixes quickly. At this point, we are still waiting to complete the migration of tripleo-ci jobs, this include OVB and various 3rd party CI jobs. We've been blocked by a nodepool migration of upstream-centos-7 nodes, but I'm told that will be finished today. Meaning, we are aiming for Monday morning to flip the switch on the rest of the tripleo-ci specific projects. Due to this, we are still converting JJB changes into ansible playbooks using the zuul-migrate command, so I please hold of on moving forward with changes to the new rdo-jobs project. If everything goes well on Monday, we'll remove the freeze on config / rdo-jobs for people to start contributing to again. Thanks for your patience during these last 3 weeks, and hopefully we'll be wrapped up Monday. If you have any questions or problems, please reply here or #rdo on freenode. - Paul

6 years

3
7
0 / 0

[meeting] RDO meeting (2018-06-27) minutes

by Javier Pena

============================ #rdo: RDO meeting 2018-06-27 ============================ Meeting started by jpena at 15:00:59 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/rdo_meeting_2018_06_27/2018/rdo_m... . Meeting summary --------------- * roll call (jpena, 15:01:06) * p-o-i failures in RDO master (jpena, 15:03:06) * LINK: https://centos.logs.rdoproject.org/weirdo-generic-puppet-openstack-scenar... (amoralej, 15:06:09) * anything for the july newsletter? (jpena, 15:13:42) * next week's chair (jpena, 15:20:01) * ACTION: amoralej to chair the next meeting (jpena, 15:21:28) * open floor (jpena, 15:21:36) Meeting ended at 15:33:05 UTC. Action items, by person ----------------------- * amoralej * amoralej to chair the next meeting People present (lines said) --------------------------- * jpena (25) * leanderthal (17) * tosky (10) * pabelanger (9) * amoralej (9) * mwhahaha (7) * openstack (4) * dmsimard (2) * sshnaidm (1) Generated by `MeetBot`_ 0.1.4

6 years, 1 month

1
0
0 / 0

Managing executables in python2/python3 packages

by Alfredo Moralejo Alonso

Hi, As part of the python3 PoC we are working on in rocky cycle i think we need to reconsider how we are managing executables in packages with python2/python3 subpackages. Currently, we are following Fedora best practices creating <executable>-<python version> in python{2|3}-<package> packages and making <executable> a symlink for python2 version and shipping it only in python2 subpackages. I think this is not a convenient way to manage it for python3 installations as it requires users (and tools) to use <executable>-3 commands. IMO, moving from python2 to python3 should be more transparent from a user PoV. I see some ways we could manage this: 1. Don't build python2 in el7 builds and stop creating <executable>-<python version>, just <executable>. 2. Keep building both and change <executable> symlink to point to <executable>-3 when python3 subpackages are enabled in spec file. 3. Keep building both and use alternatives mechanism to manage <executable> symlink to point to <executable>-2 or <executable>-3 depending on what is installed (-3 if both are enabled). My main doubt is related to how to handle this from a Fedora perspective keeping in mind that we are using the same specs to build packages in Fedora repos. I guess the best way to keep both python2 and 3 installations working is to use option 3. What do you think?, any feedback? Best regards, Alfredo

6 years, 1 month

2
2
0 / 0

[infra][maintenance] Routine patch update to logs.rdoproject.org and afs-mirror.rdoproject.org On Jun 26, 9:00 UTC

by Javier Pena

Dear all, We will run a routine patch update procedure on logs.rdoproject.org and afs-mirror.rdoproject.org tomorrow, June 26th, at 9:00 UTC. During this maintenance, expected to last for 1h, there might be short interruptions to jobs using those resources (any job running on review.rdoproject.org) due to the reboot. If you have any doubt, please do not hesitate to contact me. Regards, Javier Peña

6 years, 1 month

2
3
0 / 0

[Fedocal] Reminder meeting : RDO meeting

by hguemar＠fedoraproject.org

Dear all, You are kindly invited to the meeting: RDO meeting on 2018-06-27 from 15:00:00 to 16:00:00 UTC At rdo(a)irc.freenode.net The meeting will be about: RDO IRC meeting [Agenda at https://etherpad.openstack.org/p/RDO-Meeting ](https://etherpad.openstack.org/p/RDO-Meeting) Every Wednesday on #rdo on Freenode IRC Source: https://apps.fedoraproject.org/calendar/meeting/8759/

6 years, 1 month

1
0
0 / 0

[Fedocal] Reminder meeting : RDO meeting

by hguemar＠fedoraproject.org

Dear all, You are kindly invited to the meeting: RDO meeting on 2018-06-27 from 15:00:00 to 16:00:00 UTC At rdo(a)irc.freenode.net The meeting will be about: RDO IRC meeting [Agenda at https://etherpad.openstack.org/p/RDO-Meeting ](https://etherpad.openstack.org/p/RDO-Meeting) Every Wednesday on #rdo on Freenode IRC Source: https://apps.fedoraproject.org/calendar/meeting/2017/

6 years, 1 month

1
0
0 / 0

[Fedocal] Reminder meeting : RDO Office Hours

by chkumar246＠gmail.com

Dear all, You are kindly invited to the meeting: RDO Office Hours on 2018-06-26 from 13:30:00 to 14:30:00 UTC The meeting will be about: The meeting will be about RDO Office Hour. Aim: To keep up with increasing participation, we'll host office hours to add more easy fixes and provide mentoring to newcomers. [Agenda at RDO Office Hour easyfixes](https://review.rdoproject.org/etherpad/p/rdo-office-hour-easyf... Source: https://apps.fedoraproject.org/calendar/meeting/6374/

6 years, 1 month

1
0
0 / 0

CentOS Dojo at DevConf.US CFP is OPEN!

by Rain Leander

The CentOS and Fedora communities will be holding a Dojo on August 16th, 2018 - the day before DevConf.US begins - at Boston University, in Terrace Lounge, on the 2nd floor of the Fitness and Recreation Center. If you're in the area and keen, we'd love it if you share your RDO experience on CentOS - the CFP is open until 25 June. As always, please let me know if I can help you with your CFP, demonstrations and / or talks. -- K Rain Leander OpenStack Community Liaison Open Source and Standards Team https://www.rdoproject.org/ http://community.redhat.com

6 years, 1 month

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

dev June 2018