Open Stack

On 22/01/14 07:32 -0500, Sean Dague wrote:
>On 01/22/2014 05:19 AM, Julien Danjou wrote:
>> On Tue, Jan 21 2014, Joe Gordon wrote:
>>
>>> 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.
>>
>> I don't think that would be possible as a voting job, since the point of
>> oslo-incubator is to be able to break the API compatibility.
>
>I'm starting to feel like we need to revisit that point. Because what
>happens now is a chunk of code gets worked off in a corner, possibly
>randomly changing interfaces, not running unit tests in a way that we
>know it's multi process safe.

This is not true. If there have been abrupt changes on the interfaces
then we failed at keeping backwards compatibility. However, that
doesn't mean the API is not considered when reviewing nor that it
doesn't matter because the library is incubated.

This kind of changes usually get filed on all projects using a
specific functionality. For example, https://bugs.launchpad.net/oslo/+bug/1266962

Again, if there have been cases where an API has been changed without
even notifying others - either with a good commit message, m-l thread
or bug report - then there's definitely something wrong in the process
and it should be fixed. Also, I'd expect these errors to be raised as
soon as they're noted because they may also affect other projects as
well.

The above is very different than just saying oslo-incubator is not
trustworthy because things get copied around and changes to the
libraries are made randomly.

>So there ends up being a ton of blind trust in the sync right now. Which
>is why the syncs are coming slower, and you'll have nova 4 - 6 months
>behind on many modules, missing a critical bug fix that's buried some
>where inside a bunch of other interface changes that are expensive. (Not
>theoretical, I just tripped over this in Dec).

I'm sorry but this is not an excuse to avoid syncing from
oslo-incubator. Actually, if things like this can happen, the bigger
the gap is the harder it'll be to sync from oslo. My suggestion has
always been to do periodic syncs from oslo and keep up to day.
Interface changes that *just* break other projects without a good way
forward have to be raised here.

I know we're talking about incubated libraries that are suppose to
change but as mentioned above, we always consider backwards
compatibility even on incubated libs because they're on its way to
stability and breaking other projects is not fun.

>I think we need to graduate things to stable interfaces a lot faster.
>Realizing that stable just means "have to deprecate to change it". So
>the interface is still changeable, just requires standard deprecation
>techniques. Which we are trying to get more python libraries to do
>anyway, so it would be good if we built up a bunch of best practices here.

Agreed. This is something that we've been working on during Icehouse.
We should probably define more clear what's the incubation path of
modules that land in oslo-incubator. For example, determine where
would they fit, how long should they be around based on their
functionality and/or complexity etc.

We talked about having a meeting on this matter after I-2. Not sure
when it'll happen but it'll be a perfect time to discuss this further.

Cheers,
FF

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140122/01482769/attachment.pgp>