[openstack-dev] [api][nova][ironic] Microversion API HTTP header

Jay Pipes jaypipes at gmail.com
Wed Jun 17 14:22:29 UTC 2015

On 06/17/2015 06:30 AM, Lucas Alvares Gomes wrote:
>> overlap there rather than competition), how crazy does it sound if we say
>> that for OpenStack Nova is the compute API and Ironic the Bare Metal API and
>> so on? Would that be an unacceptable power grab?
> It's not that it's unacceptable, but I think that things weren't
> projected that way. Jay started this thread with this sentence:
> "To be blunt, Nova is the *implementation* of the OpenStack Compute
> API. Ironic is the *implementation* of the OpenStack BareMetal API."
> Which I don't think is totally correct, at least for Ironic. The
> Ironic's API have evolved and shaped as we implemented Ironic, I think
> that some decisions we made in the API makes it clear, e.g:
> * Resources have JSON attributes. If you look at some attributes of
> the resources you will see that they are just a JSON blob. That's by
> design because we didn't know exactly how the API should look like and
> so by having these JSON fields it allows us to easily extend the
> resource without changing it's structure [1] (see driver_info,
> instance_info, extra)

OK. Nothing wrong with that.

> * We have a vendor endpoint. This endpoint allows vendor to extend our
> API to expose new hardware capabilities that aren't present in the
> core API. Once multiple vendors starts implementing the same feature
> on this endpoint we then decide whether to promote it to the core API.

This is a problem. The above means that there is no single OpenStack 
BareMetal API. This means developers that want to write against an 
OpenStack BareMetal API cannot rely on different deployments of Ironic 
exposing the same API. That is a recipe for a lack of interoperability 
and decreased developer ease of use.

> * There's a "reservation" attribute in the Node's resource [1] which
> valueis the hostname of the conductor that is currently holding an
> exclusive lock to act upon this node. This is because internally we
> use a distributed hashing algorithm to be able to route the requests
> from the API service to a conductor service that is able to manage
> that Node. And having this field in the API

That is just leaking implementation inappropriately out of the public 
REST API, and shouldn't be encouraged, IMHO. Nova has a number of these 
leaky parts of its API, too, of course. Just look at the os-guests API 
extension, which only works when you're using Xen under the hood, 
thereby leaking implementation details about the underlying 
infrastructure out through the public REST API.

> I don't think that any of those decisions were bad by the way, this
> have helped us a lot to understand how a service to manage Bare Metal
> machines should looks like, and we have made wrong decisions too (You
> can get the same information by GET'ing different endpoints in the
> API, the Chassis resources currently have no usage apart from
> logically grouping nodes, etc...)

Sure, all APIs have warts :) But the warts aren't an excuse to delay 
plugging up those leaks.

> So back to the topic. if we are removing the project name from the
> Header to facilitate another project to implement the these type of
> APIs I don't think it will help much. Perhaps the API-WG group should
> make say that for new API's the microversion Header should not have
> the projects name in it. Because then, I think we can think about an
> API definition that is decouple from the implementation.



More information about the OpenStack-dev mailing list