Open Stack

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?

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?

Thanks,

Adrian

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.
> 
> Mark.
> 
>> Anyways, just a thought.
>> 
>> -Josh
>> 
>> On 12/3/13 2:39 PM, "Mark McLoughlin" <markmc at redhat.com> wrote:
>> 
>>> On Tue, 2013-12-03 at 22:31 +0000, Joshua Harlow wrote:
>>>> Sure, no one has said it. But it seems to be implied, otherwise these
>>>> types of discussions wouldn't occur. Right?
>>> 
>>> You're assuming the Nova objects API is at a point where the maintainers
>>> of it feel ready to commit to API stability.
>>> 
>>> Mark.
>>> 
>>>> On 12/3/13 2:25 PM, "Mark McLoughlin" <markmc at redhat.com> wrote:
>>>> 
>>>>> On Tue, 2013-12-03 at 22:07 +0000, Joshua Harlow wrote:
>>>>> 
>>>>>> Process for process sake imho has been a problem for oslo.
>>>>> 
>>>>> It's been reiterated many times, but again - the only purpose of
>>>>> oslo-incubator is as a place to evolve an API until we're ready to make
>>>>> a commitment to API stability.
>>>>> 
>>>>> It's often easier to start a new API completely standalone, push it to
>>>>> PyPI and plan for API backwards compatibility from the start. No-one
>>>> has
>>>>> ever said that such APIs need to go through oslo-incubator "for process
>>>>> sake".
>>>>> 
>>>>> Mark.
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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