> On Nov 3, 2013, at 9:02 AM, Jay Pipes <jaypi...@gmail.com> wrote:
>> On 11/02/2013 11:26 PM, Russell Bryant wrote:
>>> 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.  :-)
> Agreed. I actually didn't know anything about the discussion -- I wasn't at 
> the meeting. I just figured I would throw some example code up to Gerrit that 
> shows how Falcon can be used for the API plumbing. Like I mentioned in a 
> previous email, I believe it's much easier to discuss things when there is 
> sample code...
>> 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've used both actually, and I've come to prefer Falcon because of its 
> simplicity and specifically because of the following things:
> * It's lack of integration with WSME, which I don't care for. I don't care 
> for WSME because I believe it tries to put the model at the view layer, 
> instead of where it belongs, at the model layer.

Well, there are domain models, and API models.  Being able to map the domain 
model to a slightly different representation (although wsme isn't necessarily 
the best example of this), or to introduce virtual fields that exist solely for 
the benefit of a client, has been useful for us in practice over the years. 

The biggest benefit of the API model from my perspective is separating the 
concern of validating fields and reporting those validations consistently and 
correctly to a client, from the underlying persistence translations.  Tying 
json serialization too closely to a domain model will cause other coupling 
problems later on.

If I understand correctly from looking at the nova code this mapping (and of 
other domain model actions) is a goal of the 'objects' work, so if we end up 
versioning our domain model, not just the API, there's less of a need to for 
anything more that a light API translation.

All my 2 cents - I generally prefer having a light API model on top of my 
domain model for anything more complicated than a simple crud resource.

> * It doesn't need a configuration file, specifically a configuration file 
> that is a Python file as opposed to an .ini file.
>> 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 completely understand the need for consistency. I pushed my patch as an 
> example of how to do things the Falcon way. While I would prefer Falcon over 
> Pecan (and certainly over Pecan+WSME), I will respect the push towards 
> consistency if that's what is most important.
> That said, I also believe that the projects in Stackforge should be the 
> "laboratories of experiment", and these projects may serve as a good 
> playground for various implementations of things. I remind the reader that 
> over time, the development community has standardized on various things, only 
> to find a better implementation in an incubated project. Pecan+WSME is 
> actually an example of that experimentation turned accepted standard.
> Best,
> -jay
>> 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/
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to