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