Open Stack

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

-Deva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150619/84e46531/attachment-0001.html>