Open Stack

On Dec 16, 2014, at 5:22 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> Signed PGP part
> On 15/12/14 17:22, Doug Wiegley wrote:
> > Hi Ihar,
> >
> > I’m actually in favor of option 2, but it implies a few things
> > about your time, and I wanted to chat with you before presuming.
> 
> I think split didn't mean moving project trees under separate
> governance, so I assume oslo (doc, qa, ...) liaisons should not be
> split either.
> 
> >
> > Maintenance can not involve breaking changes. At this point, the
> > co-gate will block it.  Also, oslo graduation changes will have to
> > be made in the services repos first, and then Neutron.
> 
> Do you mean that a change to oslo-incubator modules is co-gated (not
> just co-checked with no vote) with each of advanced services?
> 
> As I pointed in my previous email, sometimes breakages are inescapable.
> 
> Consider a change to neutron oslo-incubator module used commonly in
> all repos that breaks API (they are quite rare, but still have a
> chance of happening once in a while). If we would co-gate main neutron
> repo changes with services, it will mean that we won't be able to
> merge the change.
> 
> That would probably suggest that we go forward with option 3 and
> manage all incubator files separately in each of the trees, though,
> again, breakages are still possible in that scenario via introducing
> incompatibility between versions of incubator modules in separate repos.
> 
> So we should be realistic about it and plan forward how we deal
> potential breakages that *may* occur.
> 
> As for oslo library graduations, the order is not really significant.
> What is significant is that we drop oslo-incubator module from main
> neutron repo only after all other neutron-*aas repos migrate to
> appropriate oslo.* library. The neutron migration itself may occur in
> parallel (by postponing module drop later).

Don’t assume that it’s safe to combine the incubated version and library version of a module. We’ve had some examples where the APIs change or global state changes in a way that make the two incompatible. We definitely don’t take any care to ensure that the two copies can be run together.

> 
> >
> > Thanks, doug
> >
> >
> > On 12/15/14, 6:15 AM, "Ihar Hrachyshka" <ihrachys at redhat.com>
> > wrote:
> >
> > Hi all,
> >
> > the question arose recently in one of reviews for neutron-*aas
> > repos to remove all oslo-incubator code from those repos since
> > it's duplicated in neutron main repo. (You can find the link to the
> > review at the end of the email.)
> >
> > Brief hostory: neutron repo was recently split into 4 pieces
> > (main, neutron-fwaas, neutron-lbaas, and neutron-vpnaas). The split
> > resulted in each repository keeping their own copy of
> > neutron/openstack/common/... tree (currently unused in all
> > neutron-*aas repos that are still bound to modules from main
> > repo).
> >
> > As a oslo liaison for the project, I wonder what's the best way to
> > manage oslo-incubator files. We have several options:
> >
> > 1. just kill all the neutron/openstack/common/ trees from
> > neutron-*aas repositories and continue using modules from main
> > repo.
> >
> > 2. kill all duplicate modules from neutron-*aas repos and leave
> > only those that are used in those repos but not in main repo.
> >
> > 3. fully duplicate all those modules in each of four repos that use
> > them.
> >
> > I think option 1. is a straw man, since we should be able to
> > introduce new oslo-incubator modules into neutron-*aas repos even
> > if they are not used in main repo.
> >
> > Option 2. is good when it comes to synching non-breaking bug fixes
> > (or security fixes) from oslo-incubator, in that it will require
> > only one sync patch instead of e.g. four. At the same time there
> > may be potential issues when synchronizing updates from
> > oslo-incubator that would break API and hence require changes to
> > each of the modules that use it. Since we don't support atomic
> > merges for multiple projects in gate, we will need to be cautious
> > about those updates, and we will still need to leave neutron-*aas
> > repos broken for some time (though the time may be mitigated with
> > care).
> >
> > Option 3. is vice versa - in theory, you get total decoupling,
> > meaning no oslo-incubator updates in main repo are expected to
> > break neutron-*aas repos, but bug fixing becomes a huge PITA.
> >
> > I would vote for option 2., for two reasons: - most oslo-incubator
> > syncs are non-breaking, and we may effectively apply care to
> > updates that may result in potential breakage (f.e. being able to
> > trigger an integrated run for each of neutron-*aas repos with the
> > main sync patch, if there are any concerns). - it will make oslo
> > liaison life a lot easier. OK, I'm probably too selfish on that.
> > ;) - it will make stable maintainers life a lot easier. The main
> > reason why stable maintainers and distributions like recent oslo
> > graduation movement is that we don't need to track each bug fix we
> > need in every project, and waste lots of cycles on it. Being able
> > to fix a bug in one place only is *highly* anticipated. [OK, I'm
> > quite selfish on that one too.] - it's a delusion that there will
> > be no neutron-main syncs that will break neutron-*aas repos ever.
> > There can still be problems due to incompatibility between neutron
> > main and neutron-*aas code resulted EXACTLY because multiple parts
> > of the same process use different versions of the same module.
> >
> > That said, Doug Wiegley (lbaas core) seems to be in favour of
> > option 3. due to lower coupling that is achieved in that way. I
> > know that lbaas team had a bad experience due to tight coupling to
> > neutron project in the past, so I appreciate their concerns.
> >
> > All in all, we should come up with some standard solution for both
> > advanced services that are already split out, *and* upcoming
> > vendor plugin shrinking initiative.
> >
> > The initial discussion is captured at:
> > https://review.openstack.org/#/c/141427/
> >
> > Thanks, /Ihar
> >
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev