There is a configuration management SIG in CentOS, right ? Given that they already are packaging Ansible (maybe? Didn't check..) they might be inclined to carry shade since it's a core plugin dependency.

David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Aug 25, 2016 8:11 AM, "Haïkel" <hguemar(a)fedoraproject.org&gt; wrote: 2016-08-25 11:17 GMT+02:00 Michael Scherer <mscherer(a)redhat.com&gt;: > Le jeudi 25 août 2016 à 13:53 +1000, Graeme Gillies a écrit : >> Hi, >> >> A while ago there was a discussion around python-shade library and >> getting it into RDO. [1] >> >> It's been a few months since then, and shade is now successfully >> packaged and shipped as part of Fedora [2] which is great, but now I >> wanted to restart the conversation about how to make it available to >> users of CentOS/RDO. >> >> While it was suggested to get it into EPEL, I don't feel that is the >> best course of action simply because of the restrictive update policies >> of EPEL not allowing us to update it as frequently as needed, and also >> because python-shade depends on the python openstack clients, which are >> not a part of EPEL (as my understanding). >> >> The best place for us to make this package available is in RDO itself, >> as shade is an official Openstack big tent project, and RDOs aims to be >> a distribution providing packages for Openstack projects. >> >> So I just wanted to confirm with everyone and get some feedback, but >> unless there is any major objections, I was going to start looking at >> the process to get a new package into RDO, which I assume means putting >> a review request in to the project https://github.com/rdo-packages >> (though I assume a new repo needs to be created for it first). > > As shade is used by ansible for orchestration, having to hunt various > repositories around the centos ecosystem, all being uncoordinated and > upgrading at different time is gonna be likely annoying. > > That's kinda the exact things people complained years ago in the rpm > ecosystem, and we are just doing it again with SIGs. > > As a smooth ops, I would prefer to have EPEL as a option for shade[1]. > > [1] yes, this pun is awful, no, I am not sending that email for the sake > of making that reference > -- > Michael Scherer > Sysadmin, Community Infrastructure and Platform, OSAS > > As long as EPEL doesn't fix its broken policy, it's unlikely to happen. 1. EPEL doesn't respect any EL7 packaging standard 2. Updates policy is used to block major version update even when it makes sense -> Impossible to maintain OpenStack clients in that context. 3. While some maintainers don't even respect the said updates policy to push broken updates I'd rather not speak about EPEL anymore. H. > > _______________________________________________ > rdo-list mailing list > rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com _______________________________________________ rdo-list mailing list rdo-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com

2016-08-25 15:02 GMT+02:00 David Moreau Simard <dms(a)redhat.com&gt;: > > There is a configuration management SIG in CentOS, right ? > > > > Given that they already are packaging Ansible (maybe? Didn't check..) they > > might be inclined to carry shade since it's a core plugin dependency. > > Shade is useless without OpenStack clients ...