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).

Regards, Graeme [1] https://www.redhat.com/archives/rdo-list/2015-November/thread.html [2] http://koji.fedoraproject.org/koji/packageinfo?packageID=21707 -- Graeme Gillies Principal Systems Administrator Openstack Infrastructure Red Hat Australia _______________________________________________ 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

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

_______________________________________________ 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

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

Sorry I'm a bit confused here, are you actually saying that shade can't be in RDO because it lives in a slightly different git repo location, a location by which, is still referenced as perfectly valid for openstack projects in Big tent

I'm also confused why you think the clients should also be moved out of rdo into another repo as well. This is just splitting the repos up needlessly isn't it? Shade, like oslo and other Openstack libraries, should be part of RDO.

On 26/08/16 16:31, Alan Pevec wrote: > > On Aug 26, 2016 07:09, "Graeme Gillies" <ggillies(a)redhat.com > <mailto:ggillies@redhat.com>> wrote: > >> Sorry I'm a bit confused here, are you actually saying that shade can't >> be in RDO because it lives in a slightly different git repo location, a >> location by which, is still referenced as perfectly valid for openstack >> projects in Big tent >> >> > https://github.com/openstack/governance/blob/master/reference/projects.yaml >> >> I'm also confused why you think the clients should also be moved out of >> rdo into another repo as well. This is just splitting the repos up >> needlessly isn't it? Shade, like oslo and other Openstack libraries, >> should be part of RDO. > > Problem with Shade is that it'd branchless so putting it into one RDO > release repo won't work. That's why separate repo is suggested, which > would also solve the other issue Haikel mentioned: upstream infra > enables RDO repo only to get openvswitch which is not in EL7 base, so we > would put that in rdo-extras. > > Cheers, > Alan > Sorry just so I am 100% clear here, in order for python-shade to just go into RDO it would need to have stable release branches, which I would assume match the standard Openstack release naming (liberty, mitaka, etc). Pulling back a bit, can we talk about the charter regarding RDO and packaging Openstack projects (which fall under big tent)? Under big tent, projects are not beholden to the explicit 6 month release cycle that has been mandated in the past. Most projects choose to stick with it, but there are a couple which don't. The official governance documentation [1] references projects can have the following release management release:cycle-with-milestones release:cycle-with-intermediary release:cycle-trailing release:independent The ones that are probably most interesting to this discussion are release:cycle-trailing and release:independent (of which shade uses). Can we get the packaging documentation modified to include an official policy on how the projects with the different release cycles are to be treated? I don't believe that projects with release:independent should be excluded from RDO, in fact, they definitely aren't because we package and ship rally as part of RDO and that uses release:independent.

Regards, Graeme [1] https://governance.openstack.org/reference/tags/ -- Graeme Gillies Principal Systems Administrator Openstack Infrastructure Red Hat Australia

2016-08-29 1:19 GMT+02:00 Graeme Gillies <ggillies(a)redhat.com&gt;: > On 26/08/16 16:31, Alan Pevec wrote: >> >> On Aug 26, 2016 07:09, "Graeme Gillies" <ggillies(a)redhat.com >> <mailto:ggillies@redhat.com>> wrote: >> >>> Sorry I'm a bit confused here, are you actually saying that shade can't >>> be in RDO because it lives in a slightly different git repo location, a >>> location by which, is still referenced as perfectly valid for openstack >>> projects in Big tent >>> >>> >> https://github.com/openstack/governance/blob/master/reference/projects.yaml >>> >>> I'm also confused why you think the clients should also be moved out of >>> rdo into another repo as well. This is just splitting the repos up >>> needlessly isn't it? Shade, like oslo and other Openstack libraries, >>> should be part of RDO. >> >> Problem with Shade is that it'd branchless so putting it into one RDO >> release repo won't work. That's why separate repo is suggested, which >> would also solve the other issue Haikel mentioned: upstream infra >> enables RDO repo only to get openvswitch which is not in EL7 base, so we >> would put that in rdo-extras. >> >> Cheers, >> Alan >> > > Sorry just so I am 100% clear here, in order for python-shade to just go > into RDO it would need to have stable release branches, which I would > assume match the standard Openstack release naming (liberty, mitaka, etc). > > Pulling back a bit, can we talk about the charter regarding RDO and > packaging Openstack projects (which fall under big tent)? > > Under big tent, projects are not beholden to the explicit 6 month > release cycle that has been mandated in the past. Most projects choose > to stick with it, but there are a couple which don't. > > The official governance documentation [1] references projects can have > the following release management > > release:cycle-with-milestones > release:cycle-with-intermediary > release:cycle-trailing > release:independent > > The ones that are probably most interesting to this discussion are > release:cycle-trailing and release:independent (of which shade uses). > > Can we get the packaging documentation modified to include an official > policy on how the projects with the different release cycles are to be > treated? I don't believe that projects with release:independent should > be excluded from RDO, in fact, they definitely aren't because we package > and ship rally as part of RDO and that uses release:independent. > (CC'ing Paul, as I would like to hear openstack-infra feedback on that point) Yes, we will discuss that item during our next meeting. If there's agreement to create a rdo-extras repository, projects tagged release:independent are candidate to be shipped in that repository. What we need to figure out is what *exactly* it should contains, provisionnally, it is: * shade + latest clients from stable branches * projects tagged release:independent * minor utilities only available through EPEL and useful for openstack-infra (should it be a separate repo?) Regards, H.

> Regards, > > Graeme > > [1] https://governance.openstack.org/reference/tags/ > > -- > Graeme Gillies > Principal Systems Administrator > Openstack Infrastructure > Red Hat Australia

stable/MAJOR.MINOR and ensure there's matching branch for OpenStack release[1]

2016-08-30 8:23 GMT+02:00 Graeme Gillies <ggillies(a)redhat.com&gt;: > > I would really implore you to think very carefully about splitting out > release:independant projects into a separate repo, especially one with > the name "extras". > Naming is easy to change, could be RDO clients and SDK, RDO Cloud users or whatever > Fracturing the repo setup only reduces usability, causes confusion, and > for those projects that choose an independent release model, it makes > them feel like second class citizens and less likely to want to care or > be part of the RDO community. > As Alan explained, we can't. Actually, forcing release-independent projects like shade in release-specific repositories would make them more of a second-class citizen. Let's say that shade requires a newer version of clients than we can ship in Mitaka, that would force us to pin shade to an older release and maybe fork it to backport security updates. A separate repository would give us the flexibility to ship the latest and greatest of those projects without worrying to break stuff that will be installed in our cloud nodes. > As I've already mentioned, we already ship a release:independant project > in the normal repo, and I fail to see from a technical level why others > can't do the same. Simply ship their latest stable release in the > current stable repo. > That's poor workaround because we didn't have the flexibility to do otherwise. As for shade, stable releases requirements don't match release-dependent projects requirements and we do have a precedent: gnocchi. Gnocchi follows its own branching model and because of requirements, we have to collaborate with upstream devs to map specific gnocchi branches to an OpenStack release, though if you install gnocchi nodes in separated nodes, it does not matter. > A lot of the projects that choose release:independant are smaller, > perhaps a bit newer, and still in a growth phase. If RDO is able to show > that those projects can be a part of RDO like everything else, it means > they are more likely to participate in the community, as it makes their > software more accessible. > We can provide flexibility like we did with gnocchi but here I'd rather think of how could we provide better fits to our community by adding a new repository to fit the needs of cloud user > Remember the goal here is to grow the community and have as many > projects participating in RDO as possible. Encouraging the smaller > projects to do so is a great way to help that. > > Regards, > > Graeme > *nods* Regards, H. >> >>> Regards, >>> >>> Graeme >>> >>> [1] https://governance.openstack.org/reference/tags/ >>> >>> -- >>> Graeme Gillies >>> Principal Systems Administrator >>> Openstack Infrastructure >>> Red Hat Australia > > > -- > Graeme Gillies > Principal Systems Administrator > Openstack Infrastructure > Red Hat Australia

Apologies for top posting, trying to resurrect this thread. So if I am understanding correctly, the outcome from this email thread was that a new repo in RDO was going to be setup for packages in Openstack big tent which do not follow the "stable branch" model. Was this ever done? If so, are we in a position to put python-shade inside it? I recently rebuilt it for centos 7 in COPR https://copr.fedorainfracloud.org/coprs/ggillies/rdo-newton-extras/packages/ And it works fine. If we haven't gotten to the point of creating this repo, what do we need to do to get this done? How do we move forward from here?

Regards, Graeme On 30/08/16 23:19, Haïkel wrote: > 2016-08-30 8:23 GMT+02:00 Graeme Gillies <ggillies(a)redhat.com&gt;: >> >> I would really implore you to think very carefully about splitting out >> release:independant projects into a separate repo, especially one with >> the name "extras". >> > > Naming is easy to change, could be RDO clients and SDK, RDO Cloud > users or whatever > >> Fracturing the repo setup only reduces usability, causes confusion, and >> for those projects that choose an independent release model, it makes >> them feel like second class citizens and less likely to want to care or >> be part of the RDO community. >> > > As Alan explained, we can't. > > Actually, forcing release-independent projects like shade in > release-specific repositories would make them more of a second-class > citizen. Let's say that shade requires a newer version of clients than > we can ship in Mitaka, that would force us to pin shade to an older > release and maybe fork it to backport security updates. > A separate repository would give us the flexibility to ship the latest > and greatest of those projects without worrying to break stuff that > will be installed in our cloud nodes. > >> As I've already mentioned, we already ship a release:independant project >> in the normal repo, and I fail to see from a technical level why others >> can't do the same. Simply ship their latest stable release in the >> current stable repo. >> > > That's poor workaround because we didn't have the flexibility to do otherwise. > As for shade, stable releases requirements don't match > release-dependent projects requirements and we do have a precedent: > gnocchi. > Gnocchi follows its own branching model and because of requirements, > we have to collaborate with upstream devs to map specific gnocchi > branches to an OpenStack release, though if you install gnocchi nodes > in separated nodes, it does not matter. > > >> A lot of the projects that choose release:independant are smaller, >> perhaps a bit newer, and still in a growth phase. If RDO is able to show >> that those projects can be a part of RDO like everything else, it means >> they are more likely to participate in the community, as it makes their >> software more accessible. >> > > We can provide flexibility like we did with gnocchi but here I'd > rather think of how could we provide better fits to our community by > adding a new repository to fit the needs of cloud user > >> Remember the goal here is to grow the community and have as many >> projects participating in RDO as possible. Encouraging the smaller >> projects to do so is a great way to help that. >> >> Regards, >> >> Graeme >> > > *nods* > > Regards, > H. > >>> >>>> Regards, >>>> >>>> Graeme >>>> >>>> [1] https://governance.openstack.org/reference/tags/ >>>> >>>> -- >>>> Graeme Gillies >>>> Principal Systems Administrator >>>> Openstack Infrastructure >>>> Red Hat Australia >> >> >> -- >> Graeme Gillies >> Principal Systems Administrator >> Openstack Infrastructure >> Red Hat Australia -- Graeme Gillies Principal Systems Administrator Openstack Infrastructure Red Hat Australia