Open Stack

Hi,

I don't want to have to diverge much from the topic of this thread,
I've done this already as pointed out by Sean. But I feel like
replying to this.

>> Sorry I might be missing something. I don't think one thing justify
>> the other, plus the problem seems to be the source of truth. I thought
>> that the idea of big tent in OpenStack was to not having TC to "pick
>> winners". E.g, If someone wants to have an alternative implementation
>> of the Baremetal service they will always have to follow Ironic's API?
>> That's unfair, cause they will always be behind and mostly likely
>> won't weight much on the decisions of the API.
>
>
> I agree and at the same I disagree with this statement.
>
> A competing project in the Baremetal (or networking, or pop-corn as a
> service) areas, can move into two directions:
> 1) Providing a different implementation for the same API that the
> "incumbent" (Ironic in this case) provides.
> 2) Supply different paradigms, including a different user API, thus
> presenting itself as a "new way" of doing Baremetal (and this is exactly
> what Quantum did to nova-network).
>
> Both cases are valid, I believe.
> In the first case, the advantage is that operators could switch between the
> various implementations without affecting their users (this does not mean
> that the switch won't be painful for them of course). Also, users shouldn't
> have to worry about what's implementing the service, as they always interact
> with the same API.
> However, it creates a problem regarding control of said API... the team from
> the "incumbent" project, the new team, both teams, the API-WG, or no-one?
> The second case is super-painful for both operators and users (do you need a
> refresh on the nova-network vs neutron saga? We're at the 5th series now,
> and the end is not even in sight) However, it completely avoid the
> governance problem arising from having APIs which are implemented by
> multiple projects.
>

Right, I wasn't considering 2) because I thought it was out of the
table for this discussion.

>> As I mentioned in the other reply, I find it difficult to talk about
>> alternative implementations while we do not decouple the API
>> definition level from the implementation level. If we want alternative
>> implementations to be a real competitor we need to have a sorta of
>> program in OpenStack that will be responsible for delivering a
>> reference API for each type of project (Baremetal, Compute, Identity,
>> and so on...).
>
>
> Indeed. If I understood what you wrote correctly, this is in-line with what
> I stated in the previous paragraph.
> Nevertheless, since afaict we do not have any competing APIs at the moment
> (the nova-network API is part of the Nova API so we might be talking about
> 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)

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

* 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

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

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.

[1] http://docs.openstack.org/developer/ironic/webapi/v1.html#Node

Cheers,
Lucas