[openstack-dev] [api][nova][ironic] Microversion API HTTP header

Salvatore Orlando sorlando at nicira.com
Tue Jun 16 13:09:55 UTC 2015


On 16 June 2015 at 14:38, Lucas Alvares Gomes <lucasagomes at gmail.com> wrote:

> Hi
>
> >> So if our min_version is 2.1 and the max_version is 2.50. That means
> >> alternative implementations need implement all the 50 versions
> >> api...that sounds pain...
> >
> >
> > Yes, it's pain, but it's no different than someone who is following the
> > Amazon EC2 API, which cuts releases at a regular (sometimes every 2-3
> weeks)
> > clip.
> >
> > In Amazon-land, the releases are date-based, instead of
> > microversion/incrementing version-based, but the idea is essentially the
> > same.
> >
>
> 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.

So, even I understand where Jay is coming from, and ideally I'd love to
have APIs associated with app catalog elements rather than projects, I
think there is not yet a model that would allow to achieve this when
multiple API implementations are present. So I also understand why the
headers have been implemented in the current way.



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


>
> > There is GREAT value to having an API mean ONE thing and ONE thing only.
> It
> > means that developers can code against something that isn't like
> quicksand
> > -- constantly changing meanings.
>
> +1, sure.
>
> Cheers,
> Lucas
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150616/31ca8b4f/attachment.html>


More information about the OpenStack-dev mailing list