Open Stack

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

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.

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

iQEcBAEBCgAGBQJUkCi0AAoJEC5aWaUY1u57lBoH/3sSr2yF4PfrMjTS4dyplgQ7
ZW+tSewctNf1JRYfh4l9+eYnv+R9YB4xWT7AvfBVO28WP2BuK5CmZ5ja49M8fzmO
jeRsgTInnZ7Hm3RkyAxpHdsiLuVRKN0syuEPN81BVJI0gLBd3kVf/0Anc6raC/Op
RBlYOL9pUoCiSki+a6Pg4j2Zn/yKUAcOmGWblCoB7zpFNgeWNAoXCH06/6bKtDFg
u0DHArKyOC/ZgmNs5BD/i2EFr71dqR5kitryuRbV02nVkm6U2iO6QfCgQx6PG61q
vQHN3bLJ2JLuA2weisZL+20yDeSb9kAuXTwdstG/rhNTWH89CZy1nsuWdbXcsqE=
=NE/f
-----END PGP SIGNATURE-----