Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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

> 
> 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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUkAfuAAoJEC5aWaUY1u57HnwH/3FtSQ+ul/zVqj21OVsy/3H2
7QHKp8BuszSRn0bRg7lkzGaV7OZnonXLWcmC/2k7LNrrSRy79mO20Zl4yMVx2TEz
WYXUo3RI7MMCQRJcZk/BqNdB3zcfST70l4s1i0wHAJQ972kidVku3CqNECg11+KH
RjMLskcT3sdmwiD5BwmXIqJtNrK02mjjrcQhkm/R8Mcc0hNk/oGbVy9s++Koplnw
iod21WV7ndlMXsAwKaCLfpjwsS4DxTK/UPPdXobmaM8EKaSB7xesldmxwp4HwO0c
P7NNgH+kSJXvrMeaSnfDjc5zM6bFlcc16+/hXPCKTKOz5sdgUjfsQbNMiO7TlEI=
=qtHJ
-----END PGP SIGNATURE-----