[openstack-dev] [Solum] Choice of API infrastructure

Russell Bryant rbryant at redhat.com
Sun Nov 3 03:26:11 UTC 2013


On 11/02/2013 11:54 AM, Adrian Otto wrote:
> Noorul,
> 
> I agree that key decisions should be tracked in blueprints. This is the
> one for this decision which was made in our 2013-10-18 public meeting.
> Jay's submission is consistent with the direction indicated by the team.
> 
> https://blueprints.launchpad.net/solum/+spec/rest-api-base
> 
> Transcript log:
> http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html
> <http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html>

Heh, not much discussion there.  :-)

Here's my take ... Pecan+WSME has been pushed as the thing to
standardize on across most OpenStack APIs.  Ceilometer (and maybe
others?) are already using it.  Others, such as Nova, are planning to
use it this cycle. [1][2]

I care less about the particular choice and more about consistency.  It
brings a lot of value, such as making it a lot easier for developers to
jump around between the OpenStack projects.  Can we first at least agree
that there is value in standardizing on *something* for most OpenStack APIs?

I understand that there may be cases where the needs for an API justify
being different.  Marconi being more of a data-plane API vs
control-plane means that performance concerns are much higher, for example.

If we agree that consistency is good, does Solum have needs that make it
different than the majority of OpenStack APIs?  IMO, it does not.

Can someone lay out a case for why all OpenStack projects should be
using Falcon, if that's what you think Solum should use?

Also, is anyone willing to put up the equivalent of Jay's review [3],
but with Pecan+WSME, to help facilitate the discussion?

[1]
http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee
[2]
http://icehousedesignsummit.sched.org/event/4a7316a4f5c6f783e362cbba2644bae2
[3] https://review.openstack.org/#/c/55040/

-- 
Russell Bryant



More information about the OpenStack-dev mailing list