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

Noorul Islam K M noorul at noorul.com
Sun Nov 3 07:07:12 UTC 2013

Russell Bryant <rbryant at redhat.com> writes:

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

I will work on this and submit one.


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

More information about the OpenStack-dev mailing list