Open Stack

2015-06-20 4:40 GMT+09:00 Devananda van der Veen <devananda.vdv at gmail.com>:
>>
>> > * 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.

If renaming "Ironic" to the other, is it still necessary to keep the
name in the header?
There are some projects which are already renamed like Neutron, Zaqar
and the others.
So "OpenStack-API-Version" which doesn't contain project name seems
reasonable for me.

Thanks
Ken Ohmichi