Hi all, I'm ready to help with syncing of DB code. But we'll need reviewers attention in both oslo-incubator in nova :)
Thanks, Roman On Thu, Feb 20, 2014 at 5:37 AM, Lance D Bragstad <ldbra...@us.ibm.com> wrote: > Shed a little bit of light on Matt's comment about Keystone removing > oslo-incubator code and the issues we hit. Comments below. > > > Best Regards, > > Lance Bragstad > ldbra...@us.ibm.com > > Doug Hellmann <doug.hellm...@dreamhost.com> wrote on 02/19/2014 09:00:29 PM: > >> From: Doug Hellmann <doug.hellm...@dreamhost.com> >> To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org>, >> Date: 02/19/2014 09:12 PM >> Subject: Re: [openstack-dev] [nova][oslo] Changes to oslo-incubator >> sync workflow > > >> >> > >> On Wed, Feb 19, 2014 at 9:52 PM, Joe Gordon <joe.gord...@gmail.com> wrote: >> As a side to this, as an exercise I tried a oslo sync in cinder to see >> what kind of issues would arise and here are my findings so far: >> https://review.openstack.org/#/c/74786/ >> >> On Wed, Feb 19, 2014 at 6:20 PM, Matt Riedemann >> <mrie...@linux.vnet.ibm.com> wrote: >> > >> > >> > On 2/19/2014 7:13 PM, Joe Gordon wrote: >> >> >> >> Hi All, >> >> >> >> As many of you know most oslo-incubator code is wildly out of sync. >> >> Assuming we consider it a good idea to sync up oslo-incubator code >> >> before cutting Icehouse, then we have a problem. >> >> >> >> Today oslo-incubator code is synced in ad-hoc manor, resulting in >> >> duplicated efforts and wildly out of date code. Part of the challenges >> >> today are backwards incompatible changes and new oslo bugs. I expect >> >> that once we get a single project to have an up to date oslo-incubator >> >> copy it will make syncing a second project significantly easier. So >> >> because I (hopefully) have some karma built up in nova, I would like >> >> to volunteer nova to be the guinea pig. >> >> >> >> >> >> To fix this I would like to propose starting an oslo-incubator/nova >> >> sync team. They would be responsible for getting nova's oslo code up >> >> to date. I expect this work to involve: >> >> * Reviewing lots of oslo sync patches >> >> * Tracking the current sync patches >> >> * Syncing over the low hanging fruit, modules that work without >> >> changing >> >> nova. >> >> * Reporting bugs to oslo team >> >> * Working with oslo team to figure out how to deal with backwards >> >> incompatible changes >> >> * Update nova code or make oslo module backwards compatible >> >> * Track all this >> >> * Create a roadmap for other projects to follow (re: documentation) >> >> >> >> I am looking for volunteers to help with this effort, any takers? >> >> >> >> >> >> best, >> >> Joe Gordon >> >> >> >> _______________________________________________ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> > >> > Well I'll get the ball rolling... >> > >> > In the past when this has come up there is always a debate over should >> > be >> > just sync to sync because we should always be up to date, or is that >> > dangerous and we should only sync when there is a need (which is what >> > the >> > review guidelines say now [1]). There are pros and cons: >> > >> > pros: >> > >> > - we get bug fixes that we didn't know existed >> > - it should be less painful to sync if we do it more often >> > >> > cons: >> > >> > - it's more review overhead and some crazy guy thinks we need a special >> > team >> > dedicated to reviewing those changes :) >> > - there are some changes in o-i that would break nova; I'm specifically >> > thinking of the oslo RequestContext which has domain support now (or >> > some >> > other keystone thingy) and nova has it's own RequestContext - so if we >> > did >> > sync that from o-i it would change nova's logging context and break on >> > us >> > since we didn't use oslo context. >> > >> > For that last con, I'd argue that we should move to the oslo >> > RequestContext, >> > I'm not sure why we aren't. Would that module then not fall under >> > low-hanging-fruit? > >> I am classifying low hanging fruit as anything that doesn't require >> any nova changes to work. >> >> +1 >> > I think the DB API modules have been a concern for auto-syncing before >> > too >> > but I can't remember why now...something about possibly changing the >> > behavior of how the nova migrations would work? But if they are already >> > using the common code, I don't see the issue. > >> AFAIK there is already a team working on db api syncing, so I was >> thinking of let them deal with it. >> >> +1 >> >> Doug >> >> > >> > This is kind of an aside, but I'm kind of confused now about how the >> > syncs >> > work with things that fall under oslo.rootwrap or oslo.messaging, like >> > this >> > patch [2]. It doesn't completely match the o-i patch, i.e. it's not >> > syncing >> > over openstack/common/rootwrap/wrapper.py, and I'm assuming because >> > that's >> > in oslo.rootwrap now? But then why does the code still exist in >> > oslo-incubator? >> > >> > I think the keystone guys are running into a similar issue where they >> > want >> > to remove a bunch of now-dead messaging code from keystone but can't >> > because >> > there are still some things in oslo-incubator using oslo.messaging code, >> > or >> > something weird like that. So maybe those modules are considered out of >> > scope for this effort until the o-r/o-m code is completely out of o-i? >> > > > For the Keystone work specifically, we were looking to remove the > openstack.common.notifier > and openstack.common.rpc modules from Keystone common because we recently > switched to > oslo.messaging (since between those two modules it ends up being around > 5,500 lines of dead code). > We hit issues trying to remove notifier and rpc from Keystone because > openstack.common.log_handler > still imported notifier [1], and our docs failed to build [2][3]. We are > trying to fix this > by submitting a change to oslo.messaging that will graduate log_handler to > oslo.messaging [4]. The > patch is here [5] thanks to some help from Ben Nemec strengthening the test > cases. > > > [1] > http://git.openstack.org/cgit/openstack/oslo-incubator/tree/openstack/common/log_handler.py#n19 > [2] https://review.openstack.org/#/c/73900/ > [3] https://review.openstack.org/#/c/73895/4 > [4] https://wiki.openstack.org/wiki/Oslo/GraduationStatus#oslo.messaging > [5] https://review.openstack.org/#/c/74804/ > > >> > Finally, just like we'd like to have cores for each virt driver in nova >> > and >> > the neutron API in nova, I think this kind of thing, at least initially, >> > would benefit from having some oslo cores involved in a team that are >> > also >> > familiar to a degree with nova, e.g. bnemec or dims. >> > >> > [1] >> > https://wiki.openstack.org/wiki/ReviewChecklist#Oslo_Syncing_Checklist >> > [2] https://review.openstack.org/#/c/73340/ >> > >> > -- >> > >> > Thanks, >> > >> > Matt Riedemann >> > >> > >> > _______________________________________________ >> > 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 >> _______________________________________________ >> 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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
