<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Nov 5, 2013, at 11:26 AM, Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
</blockquote><div><br></div><div>Ditto. :-)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Comments inline.<div class="im"><br>
<br>
On 11/04/2013 06:58 PM, Doug Hellmann wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a><br></div><div class="im">
<mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">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.<br>
This is the<br>
one for this decision which was made in our 2013-10-18<br>
public meeting.<br>
Jay's submission is consistent with the direction indicated<br>
by the team.<br>
<br></div>
<a href="https://blueprints.launchpad." target="_blank">https://blueprints.launchpad.</a>_<u></u>_net/solum/+spec/rest-api-base<br>
<<a href="https://blueprints.launchpad.net/solum/+spec/rest-api-base" target="_blank">https://blueprints.launchpad.<u></u>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/_<u></u>_solum.2013-10-08-16.01.log.__<u></u>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/<u></u>solum.2013-10-08-16.01.log.<u></u>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/<u></u>__solum.2013-10-08-16.01.log._<u></u>_html</a><div class="im"><br>
<<a href="http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html" target="_blank">http://irclogs.solum.io/2013/<u></u>solum.2013-10-08-16.01.log.<u></u>html</a>>><br>
<br>
<br>
Heh, not much discussion there. :-)<br>
<br>
<br>
Agreed. I actually didn't know anything about the discussion -- I<br>
wasn't at the meeting. I just figured I would throw some example<br>
code up to Gerrit that shows how Falcon can be used for the API<br>
plumbing. Like I mentioned in a previous email, I believe it's much<br>
easier to discuss things when there 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<br>
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<br>
its simplicity and specifically because of the following things:<br>
<br>
* It's lack of integration with WSME, which I don't care for. I<br>
don't care for WSME because I believe it tries to put the model at<br>
the view layer, 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>
</div></blockquote>
<br>
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.</blockquote>
<div><br></div><div>That approach binds your API tightly to the database representation, which we were trying to avoid.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.</blockquote>
<div><br></div><div>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.<br></div></div></div></div></div></blockquote><div><br></div><div>+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.</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The benefits of declaring WSME classes include automatic serialization<br>
in JSON and XML, generating WADL files to be included in the API docs<br>
(work is already happening to make this available for everyone), and<br>
consistent input and output types for API endpoints (making it easier<br>
for consumers of the API to use it and for implementers to validate<br>
inputs and assume consistent defaults).<br>
</blockquote>
<br></div>
I can't stand XML. I believe it should be retired to the dustbin of coding history, like Basic.<br></blockquote><div><br></div><div>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*.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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. <br></blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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...</blockquote>
<div><br></div><div>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). <br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And, to be clear, Pecan and WSME are integrated by Pecan can definitely<br>
be used without WSME. I included WSME in the proposal to replace the<br>
home-grown WSGI framework because I thought it added significant<br>
benefits, but it is not going to be appropriate for all situations<br>
(streaming large image files is one example).<br>
<br>
* It doesn't need a configuration file, specifically a configuration<br>
file that is a Python file as opposed to an .ini file.<br>
<br>
Pecan does not require a configuration file. It can use one, but we set<br>
up the WSGI app factory in ceilometer to not use one and I expect the<br>
other projects to work the same way.<br>
</blockquote>
<br></div>
OK, that's good to know.<br>
<br>
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.</blockquote>
<div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<u></u>sched.org/event/<u></u>b2680d411aa7f5d432438a435ac21f<u></u>ee</a>)<br>
to discuss tips and pain points with Pecan & WSME.<br>
</blockquote>
<br></div>
Unfortunately, I won't be at the summit. :(</blockquote><div><br></div><div>OK, we'll be updating the etherpad and obviously we can continue this via email.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
>I didn't intend to<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
revisit the decision to start adopting either (we've spent an hour at<br>
each of the last summits going over that, as well as many email<br>
threads),<br>
</blockquote>
<br></div>
Yeah, you know the argument that a couple dozen folks have discussed something at one or two of the past summits and therefore it should be considered settled fact is a bit annoying to me.<br></blockquote><div><br></div>
<div>"as well as many email threads".<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Partly it is annoying because the summit has a vast number of sessions, with many tracks going simultaneously, making it impossible to get to all the sessions that people feel strongly about. I wish I could have been at several design summit discussions, especially around database issues, at the last couple summits, but I was in the QA track most of the summit, for good or bad.<br>
</blockquote><div><br></div><div>Yep. There is not a single time slot this week where I don't want to be in fewer than 3 places at one time.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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 reasons that I'm saying "let's give Falcon a chance".<br>
</blockquote><div><br></div><div>My main arguments were "do not build something new from scratch when there are working tools" and "the existing library is too hard to use". We can argue about whether Falcon or Pecan solves the second issue better, but Pecan was used in production deployments far earlier than Falcon even existed.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I believe we discussed why Bazaar and Launchpad merge proposals were the code contribution platform at length for the Austin, Bexar and Cactus summits, with GitHub fans at every one of those discussions, and lo and behold, the community switched to Git and GitHub and Gerrit during the Diablo timeframe. So, long story short, stuff changes, opinions change, and that's totally fine...</blockquote>
<div><br></div><div>Agreed.<br><br>Doug<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
> but I do want to clear up any other misconceptions and discuss<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
issues with either tool so that feedback can be incorporated upstream.<br>
Now that both Pecan and WSME are on stackforge, we have already had a<br>
few patches from OpenStack developers intended to improve and adjust<br>
them to meet our needs better.<br>
</blockquote>
<br></div>
I think that is a fine thing to continue, and I don't believe this particular debate by the Solum project should affect that at all.<br>
<br>
Best,<br>
-jay<br>
<br>
[1] <a href="https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/models.py" target="_blank">https://github.com/openstack/<u></u>ceilometer/blob/master/<u></u>ceilometer/storage/models.py</a><br>
[2] <a href="https://github.com/openstack/ceilometer/blob/master/ceilometer/api/controllers/v2.py" target="_blank">https://github.com/openstack/<u></u>ceilometer/blob/master/<u></u>ceilometer/api/controllers/v2.<u></u>py</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Doug<br>
<br>
<br>
<br>
I care less about the particular choice and more about<br>
consistency. It<br>
brings a lot of value, such as making it a lot easier for<br>
developers to<br>
jump around between the OpenStack projects. Can we first at<br>
least agree<br>
that there is value in standardizing on *something* for most<br>
OpenStack APIs?<br>
<br>
<br>
I completely understand the need for consistency. I pushed my patch<br>
as an example of how to do things the Falcon way. While I would<br>
prefer Falcon over Pecan (and certainly over Pecan+WSME), I will<br>
respect the push towards consistency if that's what is most important.<br>
<br>
That said, I also believe that the projects in Stackforge should be<br>
the "laboratories of experiment", and these projects may serve as a<br>
good playground for various implementations of things. I remind the<br>
reader that over time, the development community has standardized on<br>
various things, only to find a better implementation in an incubated<br>
project. Pecan+WSME is actually an example of that experimentation<br>
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<br>
justify<br>
being different. Marconi being more of a data-plane API vs<br>
control-plane means that performance concerns are much higher,<br>
for example.<br>
<br>
If we agree that consistency is good, does Solum have needs that<br>
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<br>
[3],<br>
but with Pecan+WSME, to help facilitate the discussion?<br>
<br>
[1]<br></div></div>
<a href="http://icehousedesignsummit." target="_blank">http://icehousedesignsummit.</a>__<a href="http://sched.org/event/__b2680d411aa7f5d432438a435ac21f__ee" target="_blank"><u></u>sched.org/event/__<u></u>b2680d411aa7f5d432438a435ac21f<u></u>__ee</a><br>
<<a href="http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee" target="_blank">http://icehousedesignsummit.<u></u>sched.org/event/<u></u>b2680d411aa7f5d432438a435ac21f<u></u>ee</a>><br>
[2]<br>
<a href="http://icehousedesignsummit." target="_blank">http://icehousedesignsummit.</a>__<a href="http://sched.org/event/__4a7316a4f5c6f783e362cbba2644ba__e2" target="_blank"><u></u>sched.org/event/__<u></u>4a7316a4f5c6f783e362cbba2644ba<u></u>__e2</a><br>
<<a href="http://icehousedesignsummit.sched.org/event/4a7316a4f5c6f783e362cbba2644bae2" target="_blank">http://icehousedesignsummit.<u></u>sched.org/event/<u></u>4a7316a4f5c6f783e362cbba2644ba<u></u>e2</a>><br>
[3] <a href="https://review.openstack.org/#__/c/55040/" target="_blank">https://review.openstack.org/#<u></u>__/c/55040/</a><br>
<<a href="https://review.openstack.org/#/c/55040/" target="_blank">https://review.openstack.org/<u></u>#/c/55040/</a>><br>
<br>
<br>
<br>
______________________________<u></u>___________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack">OpenStack-dev@lists.openstack</a>.<u></u>__org<br>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
<a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-dev</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a>><div class="im">
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OpenStack-dev mailing list</span><br><span><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></body></html>