Open Stack

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. 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.

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.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140306/681cf5cf/attachment.html>