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