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 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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
