On 6 March 2014 13:18, Christopher Yeoh <cbky...@gmail.com> wrote: > On Thu, Mar 6, 2014 at 10:24 PM, John Garbutt <j...@johngarbutt.com> wrote: >> >> On 5 March 2014 03:44, Christopher Yeoh <cbky...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
