Open Stack

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
<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.
>
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev