Open Stack

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

> Signed PGP part
> On 16/12/14 12:52, Doug Hellmann wrote:
> >
> > 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.
> 
> Hm. Does it leave us with option 3 only? In that case, should we care
> about incompatibilities between different versions of incubator
> modules running in the same process (one for core code, and another
> one for a service)? That sounds more like we're not left with safe
> options.

I think you only want to have one copy of the Oslo modules active in a process at any given point. That probably means having the *aas projects use whatever incubated Oslo modules are in the main neutron repository instead of their own copy, but as you point out that will break those projects when neutron adopts a new library. You might end up having to build shims in neutron to hide the Oslo change during the transition.

OTOH, it may not be a big deal. We don’t go out of our way to break compatibility, so you might find that it works fine in a lot of cases. I think context won’t, because it holds global state, but some of the others should be fine.

FWIW, usually when we hit a dependency problem like this, the solution is to split one of the projects up so there is a library that can be used by all of the consumers. It sounds like neutron is trying to be both an application and a library.

> 
> >
> >>
> >>>
> >>> 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
> >
> >>
> >
> > _______________________________________________ OpenStack-dev
> > mailing list OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev