On 01/14/2014 12:12 AM, Jay Pipes wrote: > On Tue, 2014-01-14 at 11:45 +0800, Christopher Yeoh wrote: >> On Tue, Jan 14, 2014 at 10:59 AM, Jay Pipes <jaypi...@gmail.com> >> wrote: >> >> We don't need API extensions and they make our Compute API >> laughably complex and cumbersome. We should ditch entirely the >> concept of API extensions in our next Compute API major >> release. >> >> I think it way too late in the cycle to make this sort of change for >> the V3 API. > > Completely agreed. I never said anything about v3. Specifically, in the > tl;dr section I said "in the next major API version" we should get rid > of API extensions.
+1 This is the direction I'd really like to see us head. I think it would be far more friendly to consumers of OpenStack clouds, and immediately go long strides towards making OS Clouds more compatible. > >> >> admin_actions -- seriously...why wouldn't pause/unpause, etc >> be part of >> the API? if some hypervisor doesn't support the action, then >> raise >> NotImplemented and return an HTTP 501 Not Implemented -- after >> all, >> that's what a 501 was designed for, and client tooling for >> HTTP APIs >> should understand that. Minor nit, it's not what 501 is designed for. Method means something *very* specific in HTTP, which we bastardized. That being said, we can come up with a way to signal not implemented to the user, so leave this to be fixed in v4. >> >> >> So interestingly the feedback we got at the HK design summit session >> around admin_actions >> is that we should split it up into multiple smaller extensions (and >> this is going through >> now). So deployers could more selectively deploy what they want to and >> not include what >> they don't want. > > If it wasn't clear, I was not proposing changing anything to do with the > existing v3 API or any of the extensions. I am saying we should get rid > of them for the next major version, which would be v4. > > BTW, I challenge you to find deployers that are clamouring for the > ability to "selectively deploy" some parts of the API and not > others...I'd be happy to have conversations with these people and figure > out what the real use cases are and what they're really after -- because > I can almost guarantee it's not yet more API extensions. > >>> And although we don't really have an official policy around it, I >>> think the API extension functionality has been used as a way of >>> allowing new functionality into Nova and evaluating it in place >> before >>> deciding whether or not it becomes a core part of Nova. >> >> >> I do understand this. But, I just think that it's mainly >> laziness that >> drives this. Instead of doing the hard work of determining a >> useful API >> structure ahead of time -- and validating that the new >> features actually >> fit the API audience -- it's just one more way of pushing >> immature or >> ill-fitting code into a codebase. >> >> Sorry for ranting. >> >> >> Ranting is fine with me :-) But if its something we wanted to do for >> the V3 API we really should >> >> have had this sort of discussion at the *Havana* design summit. > > I've brought up the problems before with API extensions numerous times, > but unfortunately, I haven't voiced enough concern over the last 18 > months or so, being lost a bit in ops-land. That said, I plan to > vigorously argue for scrapping all API extensions in v4 at the Juno > summit. This practice has just gone on way too long... Here here! > >> FWIW I think we're getting a lot better at doing quality control on >> APIs which are added. > > No disagreement. > > Best, > -jay > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
