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.
Sure.
Best,
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
