Open Stack

On 6 March 2014 13:18, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> On Thu, Mar 6, 2014 at 10:24 PM, John Garbutt <john at johngarbutt.com> wrote:
>>
>> On 5 March 2014 03:44, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
>> > But this plan is certainly something I'm happy to support.
>>
>> One extra thing we need to consider, how to deal with new APIs while
>> we go through this transition?
>>
>> I don't really have any answers to hand, but I want v3 to get released
>> ASAP, and I want people to easily add API features to Nova. If the
>> proxy is ready early, maybe we could have people implement only v3
>> extensions, then optionally add v2 extension that just uses wraps the
>> v2 proxy + v3 extensions.
>>
>
> So pretty much any extension which is added now (or those that have gone in
> during Icehouse) should
> offer an API which is exactly the same. There's no excuse for divergence so
> what you suggest is most likely
> quite doable. We might not even need a proxy in some cases to make it
> available in the v2 namespace.
>
>
>>
>> > - I'm not sure how this affects how we approach the tasks work. Will
>> >   need to think about that more.
>>
>> +1
>>
>> Its a thread of its own, but I think improving instance-actions, still
>> leaving tasks for v3, might be the way forward.
>>
>> While we need to avoid feature creep, I still think if we add tasks
>> into v3 in the right way, it could be what makes people move to v3.
>>
>
> Yea we really need to flesh out what we want from tasks long term.
>
>>
>> One more thing... I wonder if all new extensions should be considered
>> "experimental" (or version 0) for at least one cycle. In theory, that
>> should help us avoid some of the worst mistakes when adding new APIs.
>>
>
> Yes, so this I think is a similar suggestion to being able to have
> extensions first drop
> into a holding area outside of Nova. Because the whole freeze deadline rush
> is a recipe for making
> compromises around the API that we don't want to live with for the long term
> but do so
> because we want a feature to merge soon.

I don't like the idea of encouraging these to be out of tree.
I prefer the idea of getting better at controlled in-tree innovation.

> But I think whatever approach we
> take it needs
> to come with the possibility that if its not fixed up in a reasonable time,
> it may get removed.
> So we don't end up with a large pool of experimental things.

+1
I totally forgot about that, but I agree.

Remove things that were experimental at the last major release at
Feature Freeze, or something like that, could work.

> As an aside, I think we need to improve the process we use for API related
> features. Because a lot of the
> problems that get picked up during code review could have been avoided if we
> had a better review
> earlier on that just focussed on the API design independent of
> implementation and Nova internals.

+1

We have more detailed blueprint reviews now, but I agree we need to
get much better at this.

I think the ideas around moving to gerrit for blueprint reviews are a
good starting point.

Seeing each others reviews will help us collectively improve in the
same way as our code reviews today.

John