[openstack-dev] [nova][oslo] Changes to oslo-incubator sync workflow

Doug Hellmann doug.hellmann at dreamhost.com
Thu Feb 20 02:36:10 UTC 2014


On Wed, Feb 19, 2014 at 9:20 PM, Matt Riedemann
<mriedem at 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 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.
>

Another con is that if we do find a critical bug in an incubator module,
and a project that uses that module is far out of date, applying the fix
may be more difficult. (This is also another motivation for moving code
out of the incubator entirely, but as Joe pointed out earlier today, that's
not really a short-term solution.)


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

There has been some recent work on the db code to make it more suitable for
use in some of the other projects that don't have a single global session
pool. There's a compatibility shim, which should make the update painless,
but it's not just a simple file copy.


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

After a module graduates to a library, we treat the incubator copy as the
"stable branch" until all of the integrated projects that consume the
module have migrated to the new library. That way if bugs are found, the
fixes can be applied to a project without having to also migrate to the
library.

So, the best action is to port to the library. As a fall back, at least
update to the most current version from in the incubator now. I believe all
projects are already updated to use oslo.rootwrap.

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

There's a notifier middleware that uses the RPC code from the incubator
still. I believe work on moving that module into oslo.messaging has
started, although that's based on conversations from earlier today so it
might not be very far along yet. :-)


> 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, and FWIW, Russell and Mark are also Oslo cores.

Doug



>
> [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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140219/0bda30c6/attachment.html>


More information about the OpenStack-dev mailing list