Open Stack

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 <jaypipes at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140114/2cdd3421/attachment.pgp>