Open Stack

On Wednesday, December 4, 2013, Flavio Percoco wrote:

> On 04/12/13 01:13 +0000, Adrian Otto wrote:
>
>> Jay is right. What we have is probably close enough to what's in Nova to
>> qualify for oslo-incubator. The simplifications seem to me to have general
>> appeal so this code would be more attractive to other projects. One worry I
>> have is that there is still a good deal of magic behavior in this code, as
>> reviewers have made clear notes about in the code review. I'd like to try
>> it and see if there are further simplifications we could entertain to make
>> this code easier to debug and maintain. It would be great if such
>> iterations happened in a place where other projects could easily leverage
>> them.
>>
>> I will remind us that Solum is not currently an incubated project. Should
>> we address this concern now, or during an incubation phase?
>>
>
> This is not just a Solum issue but a general issue throughout
> OpenStack. The sooner we sort this out, the better.
>
>
>> Some approaches for us to consider:
>>
>> 1) Merge this code in Solum, open a bug against it to move it back into
>> oslo-incubation, open a stub project in oslo-incubation with a read me that
>> references the bug, and continue iterate on it in Solum until we are
>> reasonably happy with it. Then during an incubation phase, we can resolve
>> that bug by putting the code into oslo-incubation, and achieve the goal of
>> making more reusable work between projects.
>>
>> We could also address that bug at such time as any other ecosystem
>> project is looking for a similar solution, and finds the stub project in
>> oslo-incubation.
>>
>> 2) Just plunk all of this code into oslo-incubation as-is and do all
>> iterating there. That might cause a bit more copying around of code during
>> the simplification process, but would potentially achieve the reusability
>> goal sooner, possibly by a couple of months.
>>
>> 3) Use pypi. In all honesty we have enough new developers (about half the
>> engineers on this project) coming up to speed with how things work in the
>> OpenStack ecosystem that I'm reluctant to throw that into the mix too.
>>
>> What do you all prefer?
>>
>
>
> I'd personally prefer number 2. Besides the reasons already raised in
> this thread we should also add the fact that having it in
> oslo-incubator will make it easier for people from other projects to
> contribute, review and improve that code.


>
Exactly. This sounds like a feature we want to live in a common library,
but without a currently stable API. That's exactly what the incubator is
for.

Doug


>
>
>> On Dec 3, 2013, at 2:58 PM, Mark McLoughlin <markmc at redhat.com>
>> wrote:
>>
>>  On Tue, 2013-12-03 at 22:44 +0000, Joshua Harlow wrote:
>>>
>>>> Sure sure, let me not make that assumption (can't speak for them), but
>>>> even libraries on pypi have to deal with API instability.
>>>>
>>>
>>> Yes, they do ... either by my maintaining stability, bumping their major
>>> version number to reflect an incompatible change ... or annoying the
>>> hell out of their users!
>>>
>>>  Just more of suggesting, might as well bite the bullet (if objects folks
>>>> feel ok with this) and just learn to deal with the pypi method for
>>>> dealing
>>>> with API instability (versions, deprecation...). Since code copying
>>>> around
>>>> is just creating a miniature version of the same 'learning experience'
>>>> except u lose the other parts (versioning, deprecation, ...) which comes
>>>> along with pypi and libraries.
>>>>
>>>
>>> Yes, if the maintainers of the API are prepared to deal with the demands
>>> of API stability, publishing the API as a standalone library would be
>>> far more preferable.
>>>
>>> Failing that, oslo-incubator offers a halfway house which sucks, but not
>>> as as much as the alternative - projects copying and pasting each
>>> other's code and evolving their copies independently.
>>>
>>
> Agreed. Also, as mentioned above, keeping the code in oslo will bring
> more eyeballs to the review, which helps a lot when designing APIs and
> seeking for stability.
>
> Projects throughout OpenStack look for re-usable code in Oslo first -
> or at least I think they should - and then elsewhere. Putting things
> in oslo-incubator has also a community impact, not just technical
> benefits. IMHO.
>
> FF
>
> --
> @flaper87
> Flavio Percoco
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131204/2e8b8f9f/attachment-0001.html>