On Thu, Mar 6, 2014 at 10:24 PM, John Garbutt <[email protected]> wrote:
> On 5 March 2014 03:44, Christopher Yeoh <[email protected]> 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
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
