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