Open Stack

In line (at the bottom)

From: Devananda van der Veen [mailto:devananda.vdv at gmail.com]
Sent: Friday, June 19, 2015 12:40
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header


On Wed, Jun 17, 2015 at 7:31 AM Jay Pipes <jaypipes at gmail.com<mailto:jaypipes at gmail.com>> wrote:
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.

Nope - not a problem. Actually it's been really helpful. We've found this to be a better way to implement driver extensions -- it's clearly *not* part of Ironic's API, and it's communicated as such in the API itself.

Any standard part of Ironic's functionality is exposed in the standard API, and hardware-specific extensions, which are not supported by enough vendors to be standardized yet, are only exposed through the vendor-specific API endpoint. It's very clear in the REST API what this is -- the end points are, for example,

  GET /v1/nodes/NNNN/vendor_passthru/methods
  POST /v1/nodes/NNNN/vendor_passthru?method=foo&param=bar

  GET /v1/drivers/DDDD/methods

... and so on. This provides a mechanism to discover what resources and methods said hardware vendor exposes in their hardware driver. We have always supported out of tree drivers, and it is possible to upgrade Ironic without upgrading the driver (or vice versa).

Also to note, our client library doesn't support any of the vendor-specific methods, and never will. It only supports Ironic's API's ability to *discover* what vendor-specific methods that driver exposes, and then to transparently call to them. And none of that is relevant to other OpenStack projects.

So if an operator wants to write a custom app that uses foo-vendor's advanced-foo-making capabilities because they only buy Foo hardware -- that's great. They can do that. Presumably, they have a support contract with Foo vendor. Ironic is merely providing the transport between them.



> * 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.

yes, this is leaky in the purest sense, but remember that ironic doesn't expose a *public* API. Only operators and other services should be talking directly to it -- and this field was requested by operators who find it helpful to know which service has locked a resource.


> 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.

Sure.

Unless the API-WG is going to actually define the API for every project (or the TC wants to do that), I don't think we can remove the project name from the header.

If another *project team* wanted to implement a Baremetal Service, and they were required to use the "OpenStack-Baremetal-API-Version" -- or the "OpenStack-API-Version" -- headers, and assuming they don't want to be sitting second fiddle to the incumbent project's API changes (I mean, if they wanted that, why go make a new project?) it would be difficult for any user to tell the two apart. Imagine a new service returning a lower version number for the same version header, but the REST API behaves completely differently from any API that Ironic has ever had.

In other words, requiring projects to use the service name in the API header is going to put OpenStack back in the place of not allowing any competition between projects to provide similar functionality.

[Rockyg] +1000  I’ve been wondering how humans would be able to tell the various codebases in operation apart if the header is simply “OpenStack” or “OpenStack-Service” but thought I must be missing something.  At least with service, you can tell the *type* of API set and guess the project.  Until we get competing projects or services.  Hmmm, messaging?  With simply “OpenStack, humans and/or computers would have to devine the service and project.  Not something you’d want to do on the fly when you have a million users down and the first clue of why is an “Openstack-API-2.1.36” and an error message.  Not error recovery friendly.  Please think about how these things play out in the *not* happy path before making decisions that are hard to change.
<flame off>

--Rocky

-Deva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150620/2faacead/attachment.html>