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

[Noorul Islam K M]

Ryan Petrello  writes:

> Sorry for the late reply to this thread - I was having email access fits for 
> most of the summit this past week.  I also intend to look at the gate 
> failures for py33 and pypy for Noorul's patch.  I need to dig a bit and 
> figure out what's *actually* going on there, as pecan should work just fine 
> for both.
>

Here is a patch [1] to make them non-voting for the time being and once
it starts working this can be reverted.

Regards,
Noorul

[1] https://review.openstack.org/#/c/55109/


> ---
> Ryan Petrello
> Senior Developer, DreamHost
> ryan.petre...@dreamhost.com
>
> On Nov 7, 2013, at 7:02 PM, Jay Pipes  wrote:
>
>> On 11/07/2013 06:41 PM, Adrian Otto wrote:
>>> Solum Team,
>>> 
>>> First of all I wanted to say that I have been thinking a lot about this 
>>> thread, and have been seeking input from a number of you who attended the 
>>> Summit this week. I do *not* see this decision as a critical one, because 
>>> if something really mattered a ton we could rip our one framework and put 
>>> another in.
>>> 
>>> What I love about this discussion is that we are having a healthy debate 
>>> about different points of view, which was very thought provoking. I have 
>>> heard input from skeptics who think that engineering decisions have to be 
>>> made in a small group in order to be efficient. I know that thinking is 
>>> wrong, and it's examples like these that convince me further that 
>>> discussions like these help us make better choices, and make development 
>>> more efficient over the long run.
>>> 
>>> We should give the most weight to the preferences of the engineers who will 
>>> write and maintain the code. If there are team members who are volunteering 
>>> to write and maintain the bulk of our API code over a period of time who 
>>> really want Falcon over Pecan, then we should give that fair consideration. 
>>> The API is exceedingly important to Solum, and all of us will be working on 
>>> it, so we need a choice that all of us can live with.
>>> 
>>> I suggest that we settle on Pecan+WSME, for the following reasons:
>>> 
>>> 1) It is a known quantity, and is likely to work well for Solum's needs, 
>>> considering that Solum is primarily a control plane API system, and that 
>>> performance is not a primary motivator.
>>> 
>>> 2) Pecan+WSME allows us to offer data serializations in both JSON and XML 
>>> to help satisfy the preferences of the API consumers.
>>> 
>>> 3) It allows us to have multiple models that are loosely coupled, which can 
>>> aid in data validation.
>>> 
>>> 4) At this point in time, other OpenStack core/integrated/ecosystem 
>>> projects are using Pecan+WSME, and several Solum contributors will be 
>>> switching between projects. There is an advantage to a higher level of 
>>> consistency among various projects.
>>> 
>>> I accept that Webob may be problematic for us, that performance may be less 
>>> than ideal, and that some Solum developers may dislike working with WSME, 
>>> and that Falcon may actually be more pleasant to work with. We have team 
>>> members with a deep understanding of Falcon, and could definitely make it 
>>> work. We can proceed with Pecan+WSME accepting these (and  other) 
>>> trade-offs.
>>> 
>>> Are there any other critically important considerations that we should 
>>> consider before converging on this choice? I'd like to hear that input 
>>> prior to our next IRC meeting.
>> 
>> None that I can think of. I'll get behind the decision, then, and if all are 
>> in consensus, I'll abandon the Falcon API patch.
>> 
>> We do need to get the Pecan/WSME patch to pass the gates though :) Doug, I'm 
>> hoping you might give Noorul a hand with that next week upon your return 
>> from Hong Kong?
>> 
>> All the best,
>> -jay
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ryan Petrello]

Sorry for the late reply to this thread - I was having email access fits for 
most of the summit this past week.  I also intend to look at the gate failures 
for py33 and pypy for Noorul's patch.  I need to dig a bit and figure out 
what's *actually* going on there, as pecan should work just fine for both.

---
Ryan Petrello
Senior Developer, DreamHost
ryan.petre...@dreamhost.com

On Nov 7, 2013, at 7:02 PM, Jay Pipes  wrote:

> On 11/07/2013 06:41 PM, Adrian Otto wrote:
>> Solum Team,
>> 
>> First of all I wanted to say that I have been thinking a lot about this 
>> thread, and have been seeking input from a number of you who attended the 
>> Summit this week. I do *not* see this decision as a critical one, because if 
>> something really mattered a ton we could rip our one framework and put 
>> another in.
>> 
>> What I love about this discussion is that we are having a healthy debate 
>> about different points of view, which was very thought provoking. I have 
>> heard input from skeptics who think that engineering decisions have to be 
>> made in a small group in order to be efficient. I know that thinking is 
>> wrong, and it's examples like these that convince me further that 
>> discussions like these help us make better choices, and make development 
>> more efficient over the long run.
>> 
>> We should give the most weight to the preferences of the engineers who will 
>> write and maintain the code. If there are team members who are volunteering 
>> to write and maintain the bulk of our API code over a period of time who 
>> really want Falcon over Pecan, then we should give that fair consideration. 
>> The API is exceedingly important to Solum, and all of us will be working on 
>> it, so we need a choice that all of us can live with.
>> 
>> I suggest that we settle on Pecan+WSME, for the following reasons:
>> 
>> 1) It is a known quantity, and is likely to work well for Solum's needs, 
>> considering that Solum is primarily a control plane API system, and that 
>> performance is not a primary motivator.
>> 
>> 2) Pecan+WSME allows us to offer data serializations in both JSON and XML to 
>> help satisfy the preferences of the API consumers.
>> 
>> 3) It allows us to have multiple models that are loosely coupled, which can 
>> aid in data validation.
>> 
>> 4) At this point in time, other OpenStack core/integrated/ecosystem projects 
>> are using Pecan+WSME, and several Solum contributors will be switching 
>> between projects. There is an advantage to a higher level of consistency 
>> among various projects.
>> 
>> I accept that Webob may be problematic for us, that performance may be less 
>> than ideal, and that some Solum developers may dislike working with WSME, 
>> and that Falcon may actually be more pleasant to work with. We have team 
>> members with a deep understanding of Falcon, and could definitely make it 
>> work. We can proceed with Pecan+WSME accepting these (and  other) trade-offs.
>> 
>> Are there any other critically important considerations that we should 
>> consider before converging on this choice? I'd like to hear that input prior 
>> to our next IRC meeting.
> 
> None that I can think of. I'll get behind the decision, then, and if all are 
> in consensus, I'll abandon the Falcon API patch.
> 
> We do need to get the Pecan/WSME patch to pass the gates though :) Doug, I'm 
> hoping you might give Noorul a hand with that next week upon your return from 
> Hong Kong?
> 
> All the best,
> -jay
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

On Fri, Nov 8, 2013 at 8:02 AM, Jay Pipes  wrote:

> On 11/07/2013 06:41 PM, Adrian Otto wrote:
>
>> Solum Team,
>>
>> First of all I wanted to say that I have been thinking a lot about this
>> thread, and have been seeking input from a number of you who attended the
>> Summit this week. I do *not* see this decision as a critical one, because
>> if something really mattered a ton we could rip our one framework and put
>> another in.
>>
>> What I love about this discussion is that we are having a healthy debate
>> about different points of view, which was very thought provoking. I have
>> heard input from skeptics who think that engineering decisions have to be
>> made in a small group in order to be efficient. I know that thinking is
>> wrong, and it's examples like these that convince me further that
>> discussions like these help us make better choices, and make development
>> more efficient over the long run.
>>
>> We should give the most weight to the preferences of the engineers who
>> will write and maintain the code. If there are team members who are
>> volunteering to write and maintain the bulk of our API code over a period
>> of time who really want Falcon over Pecan, then we should give that fair
>> consideration. The API is exceedingly important to Solum, and all of us
>> will be working on it, so we need a choice that all of us can live with.
>>
>> I suggest that we settle on Pecan+WSME, for the following reasons:
>>
>> 1) It is a known quantity, and is likely to work well for Solum's needs,
>> considering that Solum is primarily a control plane API system, and that
>> performance is not a primary motivator.
>>
>> 2) Pecan+WSME allows us to offer data serializations in both JSON and XML
>> to help satisfy the preferences of the API consumers.
>>
>> 3) It allows us to have multiple models that are loosely coupled, which
>> can aid in data validation.
>>
>> 4) At this point in time, other OpenStack core/integrated/ecosystem
>> projects are using Pecan+WSME, and several Solum contributors will be
>> switching between projects. There is an advantage to a higher level of
>> consistency among various projects.
>>
>> I accept that Webob may be problematic for us, that performance may be
>> less than ideal, and that some Solum developers may dislike working with
>> WSME, and that Falcon may actually be more pleasant to work with. We have
>> team members with a deep understanding of Falcon, and could definitely make
>> it work. We can proceed with Pecan+WSME accepting these (and  other)
>> trade-offs.
>>
>> Are there any other critically important considerations that we should
>> consider before converging on this choice? I'd like to hear that input
>> prior to our next IRC meeting.
>>
>
> None that I can think of. I'll get behind the decision, then, and if all
> are in consensus, I'll abandon the Falcon API patch.
>
> We do need to get the Pecan/WSME patch to pass the gates though :) Doug,
> I'm hoping you might give Noorul a hand with that next week upon your
> return from Hong Kong?
>

I'd be happy to help. Please add me as a reviewer on the patch set if I'm
not already listed.

Doug


>
> All the best,
>
> -jay
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Pipes]

On 11/07/2013 06:41 PM, Adrian Otto wrote:

Solum Team,

First of all I wanted to say that I have been thinking a lot about this thread, 
and have been seeking input from a number of you who attended the Summit this 
week. I do *not* see this decision as a critical one, because if something 
really mattered a ton we could rip our one framework and put another in.

What I love about this discussion is that we are having a healthy debate about 
different points of view, which was very thought provoking. I have heard input 
from skeptics who think that engineering decisions have to be made in a small 
group in order to be efficient. I know that thinking is wrong, and it's 
examples like these that convince me further that discussions like these help 
us make better choices, and make development more efficient over the long run.

We should give the most weight to the preferences of the engineers who will 
write and maintain the code. If there are team members who are volunteering to 
write and maintain the bulk of our API code over a period of time who really 
want Falcon over Pecan, then we should give that fair consideration. The API is 
exceedingly important to Solum, and all of us will be working on it, so we need 
a choice that all of us can live with.

I suggest that we settle on Pecan+WSME, for the following reasons:

1) It is a known quantity, and is likely to work well for Solum's needs, 
considering that Solum is primarily a control plane API system, and that 
performance is not a primary motivator.

2) Pecan+WSME allows us to offer data serializations in both JSON and XML to 
help satisfy the preferences of the API consumers.

3) It allows us to have multiple models that are loosely coupled, which can aid 
in data validation.

4) At this point in time, other OpenStack core/integrated/ecosystem projects 
are using Pecan+WSME, and several Solum contributors will be switching between 
projects. There is an advantage to a higher level of consistency among various 
projects.

I accept that Webob may be problematic for us, that performance may be less 
than ideal, and that some Solum developers may dislike working with WSME, and 
that Falcon may actually be more pleasant to work with. We have team members 
with a deep understanding of Falcon, and could definitely make it work. We can 
proceed with Pecan+WSME accepting these (and  other) trade-offs.

Are there any other critically important considerations that we should consider 
before converging on this choice? I'd like to hear that input prior to our next 
IRC meeting.


None that I can think of. I'll get behind the decision, then, and if all 
are in consensus, I'll abandon the Falcon API patch.


We do need to get the Pecan/WSME patch to pass the gates though :) Doug, 
I'm hoping you might give Noorul a hand with that next week upon your 
return from Hong Kong?


All the best,
-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Adrian Otto]

Solum Team,

First of all I wanted to say that I have been thinking a lot about this thread, 
and have been seeking input from a number of you who attended the Summit this 
week. I do *not* see this decision as a critical one, because if something 
really mattered a ton we could rip our one framework and put another in. 

What I love about this discussion is that we are having a healthy debate about 
different points of view, which was very thought provoking. I have heard input 
from skeptics who think that engineering decisions have to be made in a small 
group in order to be efficient. I know that thinking is wrong, and it's 
examples like these that convince me further that discussions like these help 
us make better choices, and make development more efficient over the long run.

We should give the most weight to the preferences of the engineers who will 
write and maintain the code. If there are team members who are volunteering to 
write and maintain the bulk of our API code over a period of time who really 
want Falcon over Pecan, then we should give that fair consideration. The API is 
exceedingly important to Solum, and all of us will be working on it, so we need 
a choice that all of us can live with.

I suggest that we settle on Pecan+WSME, for the following reasons:

1) It is a known quantity, and is likely to work well for Solum's needs, 
considering that Solum is primarily a control plane API system, and that 
performance is not a primary motivator.

2) Pecan+WSME allows us to offer data serializations in both JSON and XML to 
help satisfy the preferences of the API consumers. 

3) It allows us to have multiple models that are loosely coupled, which can aid 
in data validation.

4) At this point in time, other OpenStack core/integrated/ecosystem projects 
are using Pecan+WSME, and several Solum contributors will be switching between 
projects. There is an advantage to a higher level of consistency among various 
projects.

I accept that Webob may be problematic for us, that performance may be less 
than ideal, and that some Solum developers may dislike working with WSME, and 
that Falcon may actually be more pleasant to work with. We have team members 
with a deep understanding of Falcon, and could definitely make it work. We can 
proceed with Pecan+WSME accepting these (and  other) trade-offs.

Are there any other critically important considerations that we should consider 
before converging on this choice? I'd like to hear that input prior to our next 
IRC meeting.

Thanks,

Adrian


On Nov 8, 2013, at 5:59 AM, Steven Dake  wrote:

> On 11/07/2013 07:28 AM, Jay Pipes wrote:
>> Hey Doug, following up, but realize you are likely very busy at the summit :)
>> 
>> On 11/04/2013 10:20 PM, Doug Hellmann wrote:
>>> On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes >> 
>>>The "models" defined in WSME are completely different from the
>>>database
>>>models, and should not be used outside of the API code. Think of
>>>them as
>>>declaring the models for the consumer of the API, rather than the
>>>implementer of the API.
>>> 
>>> 
>>>I don't really see the point of the distinction. At the end of the
>>>day, the consumer of the API is using the API to manipulate and
>>>retrieve data. That data is really the model, with some syntactic
>>>sugar like Atom links, etc. Even in a control API -- as opposed to a
>>>data API like Glance, Ceilometer or Swift -- the benefits of a heavy
>>>API layer like Pecan and WSME are pretty small, IMO.
>>> 
>>> 
>>> That approach binds your API tightly to the database representation,
>>> which we were trying to avoid.
>> 
>> I wasn't referring to the database representation, actually. I was referring 
>> to the data model, which is different in that it abstracts away any 
>> underlying schema or storage engine...
>> 
>>>I would much rather see the Ceilometer models [1] actually be models
>>>that can validate the data that is used to construct the model
>>>object instead of having duplicated WSME "models" repeated in the
>>>WSGI controller code [2]. The reason is because if/when I decide to
>>>make a Ceilometer API that uses a different protocol, say AMQP,
>>>instead of HTTP, now I need to duplicate all of the validation code
>>>that WSME is providing on the data model layer... however if the
>>>validation was in the models themselves, I could easily create an
>>>API on a different protocol using just the models for validation.
>>> 
>>> We do that in some cases. However, there is also a difference in some
>>> cases between the validation at the API layer (a value must be a number,
>>> or a UUID, etc.) and the validation in the database layer (a number must
>>> fall within a range or a UUID must refer to an existing object). So
>>> there is a place for both, and the validation done in the WSME classes
>>> is not meant to be the only validation performed.
>> 
>> OK, understood.
>

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

[Steven Dake]

On 11/07/2013 07:28 AM, Jay Pipes wrote:
Hey Doug, following up, but realize you are likely very busy at the 
summit :)


On 11/04/2013 10:20 PM, Doug Hellmann wrote:

On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes declaring the models for the consumer of the API, rather than 
the

implementer of the API.


I don't really see the point of the distinction. At the end of the
day, the consumer of the API is using the API to manipulate and
retrieve data. That data is really the model, with some syntactic
sugar like Atom links, etc. Even in a control API -- as opposed to a
data API like Glance, Ceilometer or Swift -- the benefits of a heavy
API layer like Pecan and WSME are pretty small, IMO.


That approach binds your API tightly to the database representation,
which we were trying to avoid.


I wasn't referring to the database representation, actually. I was 
referring to the data model, which is different in that it abstracts 
away any underlying schema or storage engine...



I would much rather see the Ceilometer models [1] actually be models
that can validate the data that is used to construct the model
object instead of having duplicated WSME "models" repeated in the
WSGI controller code [2]. The reason is because if/when I decide to
make a Ceilometer API that uses a different protocol, say AMQP,
instead of HTTP, now I need to duplicate all of the validation code
that WSME is providing on the data model layer... however if the
validation was in the models themselves, I could easily create an
API on a different protocol using just the models for validation.

We do that in some cases. However, there is also a difference in some
cases between the validation at the API layer (a value must be a number,
or a UUID, etc.) and the validation in the database layer (a number must
fall within a range or a UUID must refer to an existing object). So
there is a place for both, and the validation done in the WSME classes
is not meant to be the only validation performed.


OK, understood.


The benefits of declaring WSME classes include automatic
serialization
in JSON and XML, generating WADL files to be included in the API
docs
(work is already happening to make this available for 
everyone), and

consistent input and output types for API endpoints (making it
easier
for consumers of the API to use it and for implementers to 
validate

inputs and assume consistent defaults).


I can't stand XML. I believe it should be retired to the dustbin of
coding history, like Basic.

You've made that clear in the past. :-) I agree, for what it's worth.
Some of our users do seem to want it, and with WSME *you don't have to
care*.


Also understood. :)


That said, consumers of a RESTful API don't care how the API is
implemented. They care that it's documented and consistent, and if
WSME makes API documentation easier, then that's A Good Thing, 
agreed.


It's true that WSME includes some stuff to make validating inputs
"easier", but it does so, IMHO, at the expense of readability
because everything is decorated and hidden away somewhere other than
the models themselves. See note above...

I'm not sure what that means. Hidden where? The validation is either
described in the attribute specifier for the model, or in the model's
class, or in the controller (depending on the scope of the rule being
applied).


Sorry, "hidden" wasn't the best word to describe that. I meant more 
"it's less obvious to folks who expect to find validation of the data 
model at the data model layer" :)



And, to be clear, Pecan and WSME are integrated by Pecan can
definitely
be used without WSME. I included WSME in the proposal to 
replace the

home-grown WSGI framework because I thought it added significant
benefits, but it is not going to be appropriate for all 
situations

(streaming large image files is one example).


Yes, in one way it's a bit unfortanate that we're now comparing Falcon 
with Pecan + WSME as opposed to just comparing Falcon with Pecan and 
then evaluating whether WSME should be used (on top of either one...). 
It's unfortunate because we've spent all this email thread actually 
talking about WSME and not much at all about Pecan ;)



Here's a third reason I don't care for Pecan/WSME: it uses Webob.
Other than eventlet, I don't know of a single library that OpenStack
projects have used over the years that we've had more issues with
than Webob.

Yes, I felt the pain of updating us to the latest WebOb. The project has
evolved since those days, and the current maintainers are committed to
not breaking the API. That new attitude, combined with the long history
of addressing edge cases from misbehaving web client libraries makes m e
less reluctant to use WebOb than in the past.


OK, that's good to hea

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

[Jay Pipes]

Hey Doug, following up, but realize you are likely very busy at the 
summit :)


On 11/04/2013 10:20 PM, Doug Hellmann wrote:

On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes 

I wasn't referring to the database representation, actually. I was 
referring to the data model, which is different in that it abstracts 
away any underlying schema or storage engine...



I would much rather see the Ceilometer models [1] actually be models
that can validate the data that is used to construct the model
object instead of having duplicated WSME "models" repeated in the
WSGI controller code [2]. The reason is because if/when I decide to
make a Ceilometer API that uses a different protocol, say AMQP,
instead of HTTP, now I need to duplicate all of the validation code
that WSME is providing on the data model layer... however if the
validation was in the models themselves, I could easily create an
API on a different protocol using just the models for validation.

We do that in some cases. However, there is also a difference in some
cases between the validation at the API layer (a value must be a number,
or a UUID, etc.) and the validation in the database layer (a number must
fall within a range or a UUID must refer to an existing object). So
there is a place for both, and the validation done in the WSME classes
is not meant to be the only validation performed.


OK, understood.


The benefits of declaring WSME classes include automatic
serialization
in JSON and XML, generating WADL files to be included in the API
docs
(work is already happening to make this available for everyone), and
consistent input and output types for API endpoints (making it
easier
for consumers of the API to use it and for implementers to validate
inputs and assume consistent defaults).


I can't stand XML. I believe it should be retired to the dustbin of
coding history, like Basic.

You've made that clear in the past. :-) I agree, for what it's worth.
Some of our users do seem to want it, and with WSME *you don't have to
care*.


Also understood. :)


That said, consumers of a RESTful API don't care how the API is
implemented. They care that it's documented and consistent, and if
WSME makes API documentation easier, then that's A Good Thing, agreed.

It's true that WSME includes some stuff to make validating inputs
"easier", but it does so, IMHO, at the expense of readability
because everything is decorated and hidden away somewhere other than
the models themselves. See note above...

I'm not sure what that means. Hidden where? The validation is either
described in the attribute specifier for the model, or in the model's
class, or in the controller (depending on the scope of the rule being
applied).


Sorry, "hidden" wasn't the best word to describe that. I meant more 
"it's less obvious to folks who expect to find validation of the data 
model at the data model layer" :)



And, to be clear, Pecan and WSME are integrated by Pecan can
definitely
be used without WSME. I included WSME in the proposal to replace the
home-grown WSGI framework because I thought it added significant
benefits, but it is not going to be appropriate for all situations
(streaming large image files is one example).


Yes, in one way it's a bit unfortanate that we're now comparing Falcon 
with Pecan + WSME as opposed to just comparing Falcon with Pecan and 
then evaluating whether WSME should be used (on top of either one...). 
It's unfortunate because we've spent all this email thread actually 
talking about WSME and not much at all about Pecan ;)



Here's a third reason I don't care for Pecan/WSME: it uses Webob.
Other than eventlet, I don't know of a single library that OpenStack
projects have used over the years that we've had more issues with
than Webob.

Yes, I felt the pain of updating us to the latest WebOb. The project has
evolved since those days, and the current maintainers are committed to
not breaking the API. That new attitude, combined with the long history
of addressing edge cases from misbehaving web client libraries makes m e
less reluctant to use WebOb than in the past.


OK, that's good to hear. However, I remain guarded and 
pessimistic...it's my nature I suppose :)



Secondly, it is the sign of strength that a contributor community
consider -- and continually consider -- alternative libraries or
implementations of various things. Change is good, and projects that
are just starting off are a good place to experiment with newer
libraries and see if something is better than what existed
previously. I seem to remember that was your position on Pecan when
the community was considering whether to standardize on some WSGI
pipeline. Why didn't you just use what was in other projects instead
of Pecan and WSME? Likely the same 

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

[Clayton Coleman]

> On Nov 5, 2013, at 11:26 AM, Doug Hellmann  
> wrote:
> 
> 
> 
> 
>> On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes  wrote:
>> Doug, I respect you very much as an engineer and as a community member, so I 
>> want to preface this with a very important dislaimer: don't take these 
>> opinions as anything more than what they are...a discussion of differing 
>> viewpoints.
> 
> Ditto. :-)
>  
>> 
>> Comments inline.
>> 
>> 
>>> On 11/04/2013 06:58 PM, Doug Hellmann wrote:
>>> On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes >> > 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
>>> 
>>> 
>>> >> 
>>> >
>>> 
>>> 
>>> 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.
>>> 
>>> 
>>> The "models" defined in WSME are completely different from the database
>>> models, and should not be used outside of the API code. Think of them as
>>> declaring the models for the consumer of the API, rather than the
>>> implementer of the API.
>> 
>> I don't really see the point of the distinction. At the end of the day, the 
>> consumer of the API is using the API to manipulate and retrieve data. That 
>> data is really the model, with some syntactic sugar like Atom links, etc. 
>> Even in a control API -- as opposed to a data API like Glance, Ceilometer or 
>> Swift -- the benefits of a heavy API layer like Pecan and WSME are pretty 
>> small, IMO.
> 
> That approach binds your API tightly to the database representation, which we 
> were trying to avoid.
>  
>> 
>> I would much rather see the Ceilometer models [1] actually be models that 
>> can validate the data that is used to construct the model object instead of 
>> having duplicated WSME "models" repeated in the WSGI controller code [2]. 
>> The reason is because if/when I decide to make a Ceilometer API that uses a 
>> different protocol, say AMQP, instead of HTTP, now I need to duplicate all 
>> of the validation code that WSME is providing on the data model layer... 
>> however if the validation was in the models themselves, I could easily 
>> create an API on a different protocol using just the models for validation.
> 
> We do that in some cases. However, there is also a difference in some cases 
> between the validation at the API layer (a value must be a number, or a UUID, 
> etc.) and the validation in the database layer (a number must fall within a 
> range or a UUID must refer to an existing object). So there is a place for 
> both, and the validation done in the WSME classes is not meant to be the only 
> validation performed.

+1 here - translation of a string to a uuid for use with a domain model is a 
good example of why a view model and a domain model exist.  This is a practical 
concern that almost always comes up during API evolution.

>  
>> 
>> 
>>> The benefits of declaring WSME classes include automatic serialization
>>> in JSON and XML, generating WADL files to be included in the API docs
>>> (work is already happening to make this available for everyone), and
>>> consistent input and output types for API en

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

[Doug Hellmann]

On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes  wrote:

> Doug, I respect you very much as an engineer and as a community member, so
> I want to preface this with a very important dislaimer: don't take these
> opinions as anything more than what they are...a discussion of differing
> viewpoints.
>

Ditto. :-)


>
> Comments inline.
>
>
> On 11/04/2013 06:58 PM, Doug Hellmann wrote:
>
>> On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes > > 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
>> > >
>> > _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.
>>
>>
>> The "models" defined in WSME are completely different from the database
>> models, and should not be used outside of the API code. Think of them as
>> declaring the models for the consumer of the API, rather than the
>> implementer of the API.
>>
>
> I don't really see the point of the distinction. At the end of the day,
> the consumer of the API is using the API to manipulate and retrieve data.
> That data is really the model, with some syntactic sugar like Atom links,
> etc. Even in a control API -- as opposed to a data API like Glance,
> Ceilometer or Swift -- the benefits of a heavy API layer like Pecan and
> WSME are pretty small, IMO.


That approach binds your API tightly to the database representation, which
we were trying to avoid.


>
> I would much rather see the Ceilometer models [1] actually be models that
> can validate the data that is used to construct the model object instead of
> having duplicated WSME "models" repeated in the WSGI controller code [2].
> The reason is because if/when I decide to make a Ceilometer API that uses a
> different protocol, say AMQP, instead of HTTP, now I need to duplicate all
> of the validation code that WSME is providing on the data model layer...
> however if the validation was in the models themselves, I could easily
> create an API on a different protocol using just the models for validation.


We do that in some cases. However, there is also a difference in some cases
between the validation at the API layer (a value must be a number, or a
UUID, etc.) and the validation in the database layer (a number must fall
within a range or a UUID must refer to an existing object). So there is a
place for both, and the validation done in the WSME classes is not meant to
be the only validation performed.


>
>
>  The benefits of declaring WSME classes include automatic serialization
>> in JSON and XML, generating WADL files to be included in the API docs
>> (work is already happening to make this available for everyone), and
>> consistent input and output types for API endpoints (making it easier
>> for consumers of the API to use it and for implementers to validate
>> inputs and assume consistent defaults).
>>
>
> I can't stand XML. I believe it should be retired to the dustbin of coding
> history, like Basic.
>

You've made that clear in the past. :-) I agree, for what it's worth. Some
of our users do seem to want it, and with WSME *you don't have to care*.


>
> That said, consumers of a RESTful

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

[Doug Hellmann]

On Tue, Nov 5, 2013 at 8:11 AM, Noorul Islam K M  wrote:

> Doug Hellmann  writes:
>
> > On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes  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
>  
> 
> >>>
> >>> 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.
> >>
> >
> > The "models" defined in WSME are completely different from the database
> > models, and should not be used outside of the API code. Think of them as
> > declaring the models for the consumer of the API, rather than the
> > implementer of the API.
> >
> > The benefits of declaring WSME classes include automatic serialization in
> > JSON and XML, generating WADL files to be included in the API docs (work
> is
> > already happening to make this available for everyone), and consistent
> > input and output types for API endpoints (making it easier for consumers
> of
> > the API to use it and for implementers to validate inputs and assume
> > consistent defaults).
> >
> > And, to be clear, Pecan and WSME are integrated by Pecan can definitely
> be
> > used without WSME. I included WSME in the proposal to replace the
> > home-grown WSGI framework because I thought it added significant
> benefits,
> > but it is not going to be appropriate for all situations (streaming large
> > image files is one example).
> >
> >
> >> * It doesn't need a configuration file, specifically a configuration
> file
> >> that is a Python file as opposed to an .ini file.
> >
> >
> > Pecan does not require a configuration file. It can use one, but we set
> up
> > the WSGI app factory in ceilometer to not use one and I expect the other
> > projects to work the same way.
> >
> >
>
> I see that in ceilometer project has both pypy and py33 gates switched
> off. Is this because of Pecan + WSME? From one of the conversations on
> IRC, it looks like Solum project would like to be py33 compatible from
> the beginning.
>

No, that is not because of Pecan and WSME. The rest of ceilometer is not
yet working on python 3 or pypy, as far as I know.


>
> Having said that, pecan fails to install on pypy and py33. See
> https://review.openstack.org/#/c/55083
>

Pecan tests run under python 3.3 and WSME runs under both python 3.3 and
pypy. It looks like the issue with that changeset is an upstream
dependency. In the past when we've seen that error it had to do with pbr
and versions of setuptools, but I don't know if that's what's going on in
this case.

Doug


>
> Thanks and Regards
> Noorul
>
> > Tuesday (today) at 2:00 there is a session in the Oslo track (
> >
> http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee
> )
> > to discuss tips and pain points with Pecan & WSME. I didn't intend to
> > revisit the decision to start adopting either (we've spent an hour at
> each
> > of the last summits going over that, as well as many email threads), but
> I
> > do want to clear up any other misconceptions and discuss issues with
> either
> > tool so that feedback can be incorporated upstream. Now that both Pecan
> and
> > WSME are on stackforge, we have already had a few patches from OpenStack
> > developers intended to improve and adjust them to meet our needs better.
> >
> > Doug
> >
> >
> >>
> >>
> >>  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 valu

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

[Jay Pipes]

Doug, I respect you very much as an engineer and as a community member, 
so I want to preface this with a very important dislaimer: don't take 
these opinions as anything more than what they are...a discussion of 
differing viewpoints.


Comments inline.

On 11/04/2013 06:58 PM, Doug Hellmann wrote:

On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes mailto: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

>


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.


The "models" defined in WSME are completely different from the database
models, and should not be used outside of the API code. Think of them as
declaring the models for the consumer of the API, rather than the
implementer of the API.


I don't really see the point of the distinction. At the end of the day, 
the consumer of the API is using the API to manipulate and retrieve 
data. That data is really the model, with some syntactic sugar like Atom 
links, etc. Even in a control API -- as opposed to a data API like 
Glance, Ceilometer or Swift -- the benefits of a heavy API layer like 
Pecan and WSME are pretty small, IMO.


I would much rather see the Ceilometer models [1] actually be models 
that can validate the data that is used to construct the model object 
instead of having duplicated WSME "models" repeated in the WSGI 
controller code [2]. The reason is because if/when I decide to make a 
Ceilometer API that uses a different protocol, say AMQP, instead of 
HTTP, now I need to duplicate all of the validation code that WSME is 
providing on the data model layer... however if the validation was in 
the models themselves, I could easily create an API on a different 
protocol using just the models for validation.



The benefits of declaring WSME classes include automatic serialization
in JSON and XML, generating WADL files to be included in the API docs
(work is already happening to make this available for everyone), and
consistent input and output types for API endpoints (making it easier
for consumers of the API to use it and for implementers to validate
inputs and assume consistent defaults).


I can't stand XML. I believe it should be retired to the dustbin of 
coding history, like Basic.


That said, consumers of a RESTful API don't care how the API is 
implemented. They care that it's documented and consistent, and if WSME 
makes API documentation easier, then that's A Good Thing, agreed.


It's true that WSME includes some stuff to make validating inputs 
"easier", but it does so, IMHO, at the expense of readability because 
everything is decorated and hidden away somewhere other than the models 
themselves. See note above...



And, to be clear, Pecan and WSME are integrated by Pecan can definitely
be used without WSME. I included WSME in the proposal to replace the
home-grown WSGI framework because I thought it added significant
benefits, but it is not going to be appropriate for all situations
(streaming large image files is one example).

* It doesn't need a configuration file, specifically a configuration
file that is a Python file as opposed to an .ini file.

Pecan does not require a configuration file. It can use one, but we set
up the WSGI app f

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

[Noorul Islam K M]

Doug Hellmann  writes:

> On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes  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
 

>>>
>>> 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.
>>
>
> The "models" defined in WSME are completely different from the database
> models, and should not be used outside of the API code. Think of them as
> declaring the models for the consumer of the API, rather than the
> implementer of the API.
>
> The benefits of declaring WSME classes include automatic serialization in
> JSON and XML, generating WADL files to be included in the API docs (work is
> already happening to make this available for everyone), and consistent
> input and output types for API endpoints (making it easier for consumers of
> the API to use it and for implementers to validate inputs and assume
> consistent defaults).
>
> And, to be clear, Pecan and WSME are integrated by Pecan can definitely be
> used without WSME. I included WSME in the proposal to replace the
> home-grown WSGI framework because I thought it added significant benefits,
> but it is not going to be appropriate for all situations (streaming large
> image files is one example).
>
>
>> * It doesn't need a configuration file, specifically a configuration file
>> that is a Python file as opposed to an .ini file.
>
>
> Pecan does not require a configuration file. It can use one, but we set up
> the WSGI app factory in ceilometer to not use one and I expect the other
> projects to work the same way.
>
>

I see that in ceilometer project has both pypy and py33 gates switched
off. Is this because of Pecan + WSME? From one of the conversations on
IRC, it looks like Solum project would like to be py33 compatible from
the beginning.

Having said that, pecan fails to install on pypy and py33. See
https://review.openstack.org/#/c/55083

Thanks and Regards
Noorul

> Tuesday (today) at 2:00 there is a session in the Oslo track (
> http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee)
> to discuss tips and pain points with Pecan & WSME. I didn't intend to
> revisit the decision to start adopting either (we've spent an hour at each
> of the last summits going over that, as well as many email threads), but I
> do want to clear up any other misconceptions and discuss issues with either
> tool so that feedback can be incorporated upstream. Now that both Pecan and
> WSME are on stackforge, we have already had a few patches from OpenStack
> developers intended to improve and adjust them to meet our needs better.
>
> Doug
>
>
>>
>>
>>  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
>> 

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

[Doug Hellmann]

On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes  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
>>> 
>>>
>>
>> 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.
>

The "models" defined in WSME are completely different from the database
models, and should not be used outside of the API code. Think of them as
declaring the models for the consumer of the API, rather than the
implementer of the API.

The benefits of declaring WSME classes include automatic serialization in
JSON and XML, generating WADL files to be included in the API docs (work is
already happening to make this available for everyone), and consistent
input and output types for API endpoints (making it easier for consumers of
the API to use it and for implementers to validate inputs and assume
consistent defaults).

And, to be clear, Pecan and WSME are integrated by Pecan can definitely be
used without WSME. I included WSME in the proposal to replace the
home-grown WSGI framework because I thought it added significant benefits,
but it is not going to be appropriate for all situations (streaming large
image files is one example).


> * It doesn't need a configuration file, specifically a configuration file
> that is a Python file as opposed to an .ini file.


Pecan does not require a configuration file. It can use one, but we set up
the WSGI app factory in ceilometer to not use one and I expect the other
projects to work the same way.


Tuesday (today) at 2:00 there is a session in the Oslo track (
http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee)
to discuss tips and pain points with Pecan & WSME. I didn't intend to
revisit the decision to start adopting either (we've spent an hour at each
of the last summits going over that, as well as many email threads), but I
do want to clear up any other misconceptions and discuss issues with either
tool so that feedback can be incorporated upstream. Now that both Pecan and
WSME are on stackforge, we have already had a few patches from OpenStack
developers intended to improve and adjust them to meet our needs better.

Doug


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

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

[Clayton Coleman]

> On Nov 3, 2013, at 9:02 AM, Jay Pipes  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
>>> 
>> 
>> 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
OpenStack-dev@lists.o

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

[Adrian Otto]

On Nov 3, 2013, at 6:54 AM, Jay Pipes  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
>>> 
>> 
>> 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.
> * 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/
>> 

I added this subject to our next meeting agenda: 
https://wiki.openstack.org/wiki/Meetings/Solum

Adrian
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Pipes]

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



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

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

[Angus Salkeld]

On 03/11/13 11:26 +0800, 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



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]


+1, for Pecan+WSME



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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Noorul Islam K M]

Russell Bryant  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
>> 
>
> 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.

Regards,
Noorul

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

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

[Russell Bryant]

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
> 

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev