Hi David, We have a lot of interest in the Juno for el6 packages at CERN. It would be great if you can share the patches and we can work together to build it in a central way. What is your approach in the current patchset ? rebuild python 2.7 or patch openstack to work with python 2.6 ? I am working as well with the CentOS team. I am part of the team that maintain the build system (http://wiki.centos.org/HowTos/CommunityBuildSystem). RDO started to rebuild their packages with this system for the cloud SIG effort (http://wiki.centos.org/SpecialInterestGroup/Cloud). I'll let Rich or someone more involved in the cloud sig to comment on this effort as I have not all latest details/plan. You can catch me on irc (alphacc on freenode) any time. cheers, -- Thomas. On 01/12/2015 06:11 AM, David Hill wrote:

On 01/13/2015 12:07 PM, Rich Bowen wrote: Hey, David, Thomas, et al, I wonder if you've had any chance to look at this, and whether you need anything to get started. As you may have seen, we're having a weekly Cloud SIG meeting on #centos-devel (on Freenode) every Thursday at 15:00 UTC, and there's also a bi-weekly RDO packaging meeting, every other Wednesday, also at 15:00 UTC, on #rdo. If there's anything we can do to help you, please let us know -- Rich Bowen - rbowen(a)redhat.com OpenStack Community Liaison http://openstack.redhat.com/

Hi All, I think it would be 2 different steps now : - Identify the patch that David already have. Contribute them to the list and review them. - In parallel I can assist to try to rebuild source RPMs, in cbs.centos.org. We have can test packages within a repo (unsigned) quickly to validate if something is wrong and then iterate. It would be nice for each contributor to open a bugs.centos.org ticket, to request access to the building system, a Cloud SIG member could validate the account. Then I can do basic training :) -- Thomas.

On 01/23/2015 07:05 PM, Haïkel wrote: Unfortunately, meetup time/space is something you sign up for on-site, which doesn't leave any time to work with peoples' schedules much. Hopefully there will be information about this Saturday morning, but I can't promise much in terms of how convenient the available times will be. -- Rich Bowen - rbowen(a)redhat.com OpenStack Community Liaison http://openstack.redhat.com/

Thanks for stepping up, I've created a trello card for this effort and added initial notes: https://trello.com/c/L0X5bU5s/25-el6-juno-packages Repeating here: * python27 is not there yet in EPEL6 (under review https://bugzilla.redhat.com/show_bug.cgi?id=829892 ) but it would also require to rebuild ALL python deps as python27-* so not an option * Juno is still python 2.6 compatible so single spec should work (see f21 branch for examples where single spec is used to build all of Fedora/el6/el7 builds of Icehouse There are also benefits (newer kernel/qemu-kvm/libvirt) on EL7 which you should consider also you'll have to make a switch at one point. python27 is still under review, but even if it gets into EPEL7 soon I wouldn't suggest that route (see above) Juno still works with python 2.6, >= Kilo requires python >= 2.7 Supporting py26 where upstream abandoned it would be a fork and RDO strives to be close to upstream. Way forward here would be to check Fedora Rawhide (f22 i.e. master branch) openstack-* specs and add support to build on el6. Also you might want to consider keeping only Compute nodes on EL6 and migrate Controllers to EL7. In that case we would need to maintain only openstack-nova Juno for EL6. Cheers, Alan

Hello Alan, I think dropping Centos6/RHEL6/OEL6 support at this time is premature (IMHO). I don't think we'll be updating to Centos7 this year and for this reason, I'll be maintaining packages on my side for internal use so... if I can give a little time home to get these packages done for the community while using community build system, it would be awesome and give me the opportunity to learn new stuff. I'm already familiar with build systems (spec files, rpms, signature, Jenkins, etc) so it wouldn't be that much of an effort (I guess). If we don't need python27 it's even better. Dave -----Original Message----- From: Alan Pevec [mailto:apevec@gmail.com] Sent: 12-Jan-15 5:02 AM To: David Hill Cc: rdo-list(a)redhat.com Subject: Re: [Rdo-list] Juno EPEL packages Thanks for stepping up, I've created a trello card for this effort and added initial notes: https://trello.com/c/L0X5bU5s/25-el6-juno-packages Repeating here: * python27 is not there yet in EPEL6 (under review https://bugzilla.redhat.com/show_bug.cgi?id=829892 ) but it would also require to rebuild ALL python deps as python27-* so not an option * Juno is still python 2.6 compatible so single spec should work (see f21 branch for examples where single spec is used to build all of Fedora/el6/el7 builds of Icehouse There are also benefits (newer kernel/qemu-kvm/libvirt) on EL7 which you should consider also you'll have to make a switch at one point. python27 is still under review, but even if it gets into EPEL7 soon I wouldn't suggest that route (see above) Juno still works with python 2.6, >= Kilo requires python >= 2.7 Supporting py26 where upstream abandoned it would be a fork and RDO strives to be close to upstream. Way forward here would be to check Fedora Rawhide (f22 i.e. master branch) openstack-* specs and add support to build on el6. Also you might want to consider keeping only Compute nodes on EL6 and migrate Controllers to EL7. In that case we would need to maintain only openstack-nova Juno for EL6. Cheers, Alan

On 1/12/2015 6:06 PM, Haïkel wrote: I'm not using RDO but our team has packaged Juno just fine on RHEL 6.5 with additional packages from epel 6, plus probably some updated source packages that aren't in the fedora repos to satisfy runtime dependencies, e.g. various oslo libraries. For Kilo we've moved to RHEL 7 mainly because of the support for python 2.7 being dropped in the community, nova has explicitly broken support for py27 for example, so unless you're going to maintain patches to revert those changes the code at runtime might have problems on py26. -- Thanks, Matt Riedemann