Open Stack

On Tue, Jan 21, 2014 at 11:14 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
> On Jan 17, 2014 12:24 AM, "Flavio Percoco" <flavio at redhat.com> wrote:
>>
>> On 16/01/14 17:32 -0500, Doug Hellmann wrote:
>>>
>>> On Thu, Jan 16, 2014 at 3:19 PM, Ben Nemec <openstack at nemebean.com>
>>> wrote:
>>>
>>>    On 2014-01-16 13:48, John Griffith wrote:
>>>
>>>        Hey Everyone,
>>>
>>>        A review came up today that cherry-picked a specific commit to
>>> OSLO
>>>        Incubator, without updating the rest of the files in the module.
>>> I
>>>        rejected that patch, because my philosophy has been that when you
>>>        update/pull from oslo-incubator it should be done as a full sync
>>> of
>>>        the entire module, not a cherry pick of the bits and pieces that
>>> you
>>>        may or may not be interested in.
>>>
>>>        As it turns out I've received a bit of push back on this, so it
>>> seems
>>>        maybe I'm being unreasonable, or that I'm mistaken in my
>>> understanding
>>>        of the process here.  To me it seems like a complete and total
>>> waste
>>>        to have an oslo-incubator and common libs if you're going to turn
>>>        around and just cherry pick changes, but maybe I'm completely out
>>> of
>>>        line.
>>>
>>>        Thoughts??
>>>
>>>
>>>    I suppose there might be exceptions, but in general I'm with you.  For
>>> one
>>>    thing, if someone tries to pull out a specific change in the Oslo
>>> code,
>>>    there's no guarantee that code even works.  Depending on how the sync
>>> was
>>>    done it's possible the code they're syncing never passed the Oslo unit
>>>    tests in the form being synced, and since unit tests aren't synced to
>>> the
>>>    target projects it's conceivable that completely broken code could get
>>>    through Jenkins.
>>>
>>>    Obviously it's possible to do a successful partial sync, but for the
>>> sake
>>>    of reviewer sanity I'm -1 on partial syncs without a _very_ good
>>> reason
>>>    (like it's blocking the gate and there's some reason the full module
>>> can't
>>>    be synced).
>>>
>>>
>>> I agree. Cherry picking a single (or even partial) commit really should
>>> be
>>> avoided.
>>>
>>> The update tool does allow syncing just a single module, but that should
>>> be
>>> used very VERY carefully, especially because some of the changes we're
>>> making
>>> as we work on graduating some more libraries will include cross-dependent
>>> changes between oslo modules.
>>
>>
>> Agrred. Syncing on master should be complete synchornization from Oslo
>> incubator. IMHO, the only case where cherry-picking from oslo should
>> be allowed is when backporting patches to stable branches. Master
>> branches should try to keep up-to-date with Oslo and sync everything
>> every time.
>
> When we started Oslo incubator, we treated that code as trusted. But since
> then there have been occasional issues when syncing the code. So Oslo
> incubator code has lost *my* trust. Therefore I am always a hesitant to do a
> full Oslo sync because I am not an expert on the Oslo code and I risk
> breaking something when doing it (the issue may not appear 100% of the time
> too). Syncing code in becomes the first time that code is run against
> tempest, which scares me.
>
Understood and agreed, but frankly this defeats the intended purpose
IMO.  If we're going to go this route and never make them true libs
commonly shared/used then we're not gaining anything at all.

We might as well go back to maintaining our own versions in each
project and copying/pasting fixes around.  In essence that's exactly
what you end up with in this situation.

> I would like to propose having a integration test job in Oslo incubator that
> syncs in the code, similar to how we do global requirements.
>
> Additionally, what about a periodic jenkins job that does the Oslo syncs and
> is managed by the Oslo team itself?

Sure, that's a cool idea... once we get through an initial sync I
think it's doable.  As you've pointed out however there's some
challenges with projects that have been doing cherry picks or just
ignoring updates for any length of time.

>
>>
>> With that in mind, I'd like to request project's members to do
>> periodic syncs from Oslo incubator. Yes, it is tedious, painful and
>> sometimes requires more than just syncing, but we should all try to
>> keep up-to-date with Oslo. The main reason why I'm asking this is
>> precisely "stable branches". If the project stays way behind the
>> oslo-incubator, it'll be really painful to backport patches to stable
>> branches in case of failures.

I'd agree with this for sure

>>
>> Unfortunately, there are projects that are quite behind from
>> oslo-incubator master.
>>
>> One last comment. FWIW, backwards compatibility is always considered
>> in all Oslo reviews and if there's a crazy-breaking change, it's
>> always notified.

I agree there are challenges here, some due to being too far out of
date etc.  I also agree that a lot goes in to backward compat,
however, I think the emphasis on this and what drives a significant
number of the changes is Nova specific.  I also think that's where
most people's focus stops, I don't think there's significant checking
or testing across other projects.  To be fair we've grown to a size
where this isn't necessarily feasible without automation which goes
back to your earlier point.

At the risk of coming across the wrong way, it seems that
oslo-incubator has become something that really isn't that different
or far way from the days when we all just copy/pasted code from nova.
I know that's completely unfair in terms of items that have made it
out and are actual libraries but I think there's some validity to the
perspective.

>>
>> Thankfully, this all will be alleviated with the libs that are being
>> pulled out from the incubator. The syncs will contain fewer modules
>> and will be smaller.
>>
>>
>> I'm happy you brought this up now. I was meaning to do it.
>>
>> Cheers,
>> FF
>>
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>> _______________________________________________
>> 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
>