Open Stack

On Wed, Feb 19, 2014 at 9:52 PM, Joe Gordon <joe.gordon0 at 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
> <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.
>

+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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> 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/1e644369/attachment.html>