[rdo-list] Python-shade in RDO

[Paul Belanger]

On Tue, Nov 08, 2016 at 10:30:31AM +1000, Graeme Gillies wrote:
> 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?
> 
I believe we have some upcoming changes to shade that is going to make packaging
a little easier. I seen a patch from Monty recently to replace python-*client
dependencies.

With that in mind, it should make landing shade into EPEL a little easier.

> Regards,
> 
> Graeme
> 
> On 30/08/16 23:19, Haïkel wrote:
> > 2016-08-30 8:23 GMT+02:00 Graeme Gillies <ggillies at redhat.com>:
> >>
> >> 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