<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 5, 2013 at 8:11 AM, Noorul Islam K M <span dir="ltr"><<a href="mailto:noorul@noorul.com" target="_blank">noorul@noorul.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>> writes:<br>

<br>
> On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
><br>
>> On 11/02/2013 11:26 PM, Russell Bryant wrote:<br>
>><br>
>>> On 11/02/2013 11:54 AM, Adrian Otto wrote:<br>
>>><br>
>>>> Noorul,<br>
>>>><br>
>>>> I agree that key decisions should be tracked in blueprints. This is the<br>
>>>> one for this decision which was made in our 2013-10-18 public meeting.<br>
>>>> Jay's submission is consistent with the direction indicated by the team.<br>
>>>><br>
>>>> <a href="https://blueprints.launchpad.net/solum/+spec/rest-api-base" target="_blank">https://blueprints.launchpad.net/solum/+spec/rest-api-base</a><br>
>>>><br>
>>>> Transcript log:<br>
>>>> <a href="http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html" target="_blank">http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html</a><br>
>>>> <<a href="http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html" target="_blank">http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html</a>><br>
>>>><br>
>>><br>
>>> Heh, not much discussion there.  :-)<br>
>>><br>
>><br>
>> Agreed. I actually didn't know anything about the discussion -- I wasn't<br>
>> at the meeting. I just figured I would throw some example code up to Gerrit<br>
>> that shows how Falcon can be used for the API plumbing. Like I mentioned in<br>
>> a previous email, I believe it's much easier to discuss things when there<br>
>> is sample code...<br>
>><br>
>><br>
>>  Here's my take ... Pecan+WSME has been pushed as the thing to<br>
>>> standardize on across most OpenStack APIs.  Ceilometer (and maybe<br>
>>> others?) are already using it.  Others, such as Nova, are planning to<br>
>>> use it this cycle. [1][2]<br>
>>><br>
>><br>
>> I've used both actually, and I've come to prefer Falcon because of its<br>
>> simplicity and specifically because of the following things:<br>
>><br>
>> * It's lack of integration with WSME, which I don't care for. I don't care<br>
>> for WSME because I believe it tries to put the model at the view layer,<br>
>> instead of where it belongs, at the model layer.<br>
>><br>
><br>
> The "models" defined in WSME are completely different from the database<br>
> models, and should not be used outside of the API code. Think of them as<br>
> declaring the models for the consumer of the API, rather than the<br>
> implementer of the API.<br>
><br>
> The benefits of declaring WSME classes include automatic serialization in<br>
> JSON and XML, generating WADL files to be included in the API docs (work is<br>
> already happening to make this available for everyone), and consistent<br>
> input and output types for API endpoints (making it easier for consumers of<br>
> the API to use it and for implementers to validate inputs and assume<br>
> consistent defaults).<br>
><br>
> And, to be clear, Pecan and WSME are integrated by Pecan can definitely be<br>
> used without WSME. I included WSME in the proposal to replace the<br>
> home-grown WSGI framework because I thought it added significant benefits,<br>
> but it is not going to be appropriate for all situations (streaming large<br>
> image files is one example).<br>
><br>
><br>
>> * It doesn't need a configuration file, specifically a configuration file<br>
>> that is a Python file as opposed to an .ini file.<br>
><br>
><br>
> Pecan does not require a configuration file. It can use one, but we set up<br>
> the WSGI app factory in ceilometer to not use one and I expect the other<br>
> projects to work the same way.<br>
><br>
><br>
<br>
</div></div>I see that in ceilometer project has both pypy and py33 gates switched<br>
off. Is this because of Pecan + WSME? From one of the conversations on<br>
IRC, it looks like Solum project would like to be py33 compatible from<br>
the beginning.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
Having said that, pecan fails to install on pypy and py33. See<br>
<a href="https://review.openstack.org/#/c/55083" target="_blank">https://review.openstack.org/#/c/55083</a><br></blockquote><div><br></div><div>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.<br>
<br></div><div>Doug<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks and Regards<br>
<span class=""><font color="#888888">Noorul<br>
</font></span><div class=""><div class="h5"><br>
> Tuesday (today) at 2:00 there is a session in the Oslo track (<br>
> <a href="http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee" target="_blank">http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee</a>)<br>
> to discuss tips and pain points with Pecan & WSME. I didn't intend to<br>
> revisit the decision to start adopting either (we've spent an hour at each<br>
> of the last summits going over that, as well as many email threads), but I<br>
> do want to clear up any other misconceptions and discuss issues with either<br>
> tool so that feedback can be incorporated upstream. Now that both Pecan and<br>
> WSME are on stackforge, we have already had a few patches from OpenStack<br>
> developers intended to improve and adjust them to meet our needs better.<br>
><br>
> Doug<br>
><br>
><br>
>><br>
>><br>
>>  I care less about the particular choice and more about consistency.  It<br>
>>> brings a lot of value, such as making it a lot easier for developers to<br>
>>> jump around between the OpenStack projects.  Can we first at least agree<br>
>>> that there is value in standardizing on *something* for most OpenStack<br>
>>> APIs?<br>
>>><br>
>><br>
>> I completely understand the need for consistency. I pushed my patch as an<br>
>> example of how to do things the Falcon way. While I would prefer Falcon<br>
>> over Pecan (and certainly over Pecan+WSME), I will respect the push towards<br>
>> consistency if that's what is most important.<br>
>><br>
>> That said, I also believe that the projects in Stackforge should be the<br>
>> "laboratories of experiment", and these projects may serve as a good<br>
>> playground for various implementations of things. I remind the reader that<br>
>> over time, the development community has standardized on various things,<br>
>> only to find a better implementation in an incubated project. Pecan+WSME is<br>
>> actually an example of that experimentation turned accepted standard.<br>
>><br>
><br>
>> Best,<br>
>> -jay<br>
>><br>
>><br>
>>  I understand that there may be cases where the needs for an API justify<br>
>>> being different.  Marconi being more of a data-plane API vs<br>
>>> control-plane means that performance concerns are much higher, for<br>
>>> example.<br>
>>><br>
>>> If we agree that consistency is good, does Solum have needs that make it<br>
>>> different than the majority of OpenStack APIs?  IMO, it does not.<br>
>>><br>
>>> Can someone lay out a case for why all OpenStack projects should be<br>
>>> using Falcon, if that's what you think Solum should use?<br>
>>><br>
>>> Also, is anyone willing to put up the equivalent of Jay's review [3],<br>
>>> but with Pecan+WSME, to help facilitate the discussion?<br>
>>><br>
>>> [1]<br>
>>> <a href="http://icehousedesignsummit.sched.org/event/" target="_blank">http://icehousedesignsummit.sched.org/event/</a><br>
>>> b2680d411aa7f5d432438a435ac21fee<br>
>>> [2]<br>
>>> <a href="http://icehousedesignsummit.sched.org/event/" target="_blank">http://icehousedesignsummit.sched.org/event/</a><br>
>>> 4a7316a4f5c6f783e362cbba2644bae2<br>
>>> [3] <a href="https://review.openstack.org/#/c/55040/" target="_blank">https://review.openstack.org/#/c/55040/</a><br>
>>><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>