Open Stack

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

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