<div dir="ltr">Brandon,<br><div class="gmail_extra"><br><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="direction:ltr;font-size:10pt;font-family:Tahoma">
<div>Towards the bottom of that document it does mention content switching and how it would work with this. I know its a huge text document and hard to navigate but it is there. </div></div></div></blockquote><div>Yeah, i should have been more specific. My concern is that 'single-call API' is not powerfull enough right now to account for every case.</div>
<div>Which means that complex cases should still go through a regular process. </div><div>I think that creates inconsitent workflow where some objects should be created with one approach while others with another.</div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="direction:ltr;font-size:10pt;font-family:Tahoma"><div>The point of the one pool on a load balancer is because other than content switching
there aren't any other use cases for multiple pools. There's a question/answer about that. As we say in that document, it is not perfect but it is viable. If that is something most people do not like then another solution can be discussed.</div>
<div><br>
</div>
<div>As for referencing objects within the same request body, it probably wasn't explained well but if you need to reference a pool that is being created within that POST body then referencing by the name attribute should be fine. That name should only be
unique within that request body and references to that name should only be contained within the scope of the request body. After that, names don't have to be unique.</div>
<div><br>
</div>
<div>Even if that wasn't a viable solution, I don't think a single call API should be quickly dismissed because of this. </div></div></div></blockquote><div>Generally speaking, single-call API is not the way Neutron API is designed.</div>
<div>Personally I'm not dismissing this option, but there are two constraints that I would apply to this approach:</div><div>1) single-call API should reflect all capabilities of API </div><div>2) single-call API should be developed side-by side with per-object API (after initiall implementation reflects per-object API)</div>
<div>Even this approach of having two API styles could be questioned by some folks, but at least each of the approaches should be consistent, e.g. should cover every possible use case that is available with other counterpart.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="direction:ltr;font-size:10pt;font-family:Tahoma">
<div><br>
</div>
<div>Again, I understand its a huge document and some things are probably not detailed well. If they are not just ask me to give more details.</div></div></div></blockquote><div>The thing is that I've actually was through the single-call API discussion with some folks and I know the pits of it for our roadmap.</div>
<div>The general issue with a single-call API is that you end up creating Heat-like template language to address the use cases that we're planning, and yet you'll have to have per-object operations...</div><div><br>
</div><div>Thanks,</div><div>Eugene.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="direction:ltr;font-size:10pt;font-family:Tahoma">
<div>
<div style="font-size:16px;font-family:Times New Roman">
<hr>
<div style="direction:ltr"><font face="Tahoma" color="#000000"><b>From:</b> Eugene Nikanorov [<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>]<br>
<b>Sent:</b> Wednesday, April 16, 2014 4:31 PM<div><div class="h5"><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress<br>
</div></div></font><br>
</div><div><div class="h5">
<div></div>
<div>
<div dir="ltr">Hi folks,
<div><br>
</div>
<div>I've briefly looked over the doc.</div>
<div><br>
</div>
<div>I think whole idea to base the API on Atlas misses the content switching use case, which is very important:</div>
<div>We need multiple pools within loadbalancer, and API doesn't seem to allow that.</div>
<div>If it would, then you'll face another problem: you need to reference those pools somehow inside the json you use in POST.</div>
<div>There are two options here: use names or IDs, both are putting constraints and create complexity for both user of such API and for the implementation.</div>
<div><br>
</div>
<div>That particular problem becomes worse when it comes to objects which might not have names while it's better to not provide ID in POST and rely on their random generation. E.g. when you need to create references between objects in json input - you'll need
to create artificial attributes just for the parser to understand that such input means.</div>
<div><br>
</div>
<div>So that makes me think that right now a 'single-call API' is not flexible enough to comply with our requirements.</div>
<div>While I understand that it might be simpler to use such API for some cases, it makes complex configurations fall back to our existing approach which is creating configuration on per object basis.</div>
<div>While the problem with complex configurations is not sorted out, I'd prefer if we focus on existing 'object-oriented' approach.</div>
<div><br>
</div>
<div>On the other hand, without single-call API the rest of proposal seems to be similar to approaches discussed in <a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion" target="_blank">https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion</a></div>
<div><br>
</div>
<div>Thanks,</div>
<div>Eugene.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Apr 17, 2014 at 12:59 AM, Brandon Logan <span dir="ltr">
<<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-size:10pt;font-family:Tahoma">Sorry about that. It should be readable now.<br>
<div style="font-size:16px;font-family:Times New Roman">
<hr>
<div style="direction:ltr"><font face="Tahoma" color="#000000"><b>From:</b> Eugene Nikanorov [<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>]<br>
<b>Sent:</b> Wednesday, April 16, 2014 3:51 PM
<div><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
</div>
<div>
<div><b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress<br>
</div>
</div>
</font><br>
</div>
<div>
<div>
<div></div>
<div>
<div dir="ltr">Hi Brandon,
<div><br>
</div>
<div>Seems that doc has not been made public, so please share.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Eugene.</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Apr 17, 2014 at 12:39 AM, Brandon Logan <span dir="ltr">
<<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>Here is Jorge and team’s API proposal based on Atlas. The document has some questions and answers about why decisions were made. Feel free to open up a discussion about these questions and answers and really about anything. This can be changed up to
fit any flaws or use cases we missed that this would not support.</div>
<div><br>
</div>
<div>There is a CLI example at the bottom along with a possible L7 switching API model.</div>
<div><br>
</div>
<div><a href="https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWyXe-zo/edit" target="_blank">https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWyXe-zo/edit</a></div>
<div><br>
</div>
<div>Thanks,</div>
<div>Brandon Logan</div>
<div><br>
</div>
<span>
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">
<span style="font-weight:bold">From: </span>Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, April 15, 2014 at 7:00 AM<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>
<div><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress<br>
</div>
</div>
<div>
<div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">Hi Stephen,
<div><br>
</div>
<div>Thanks for a good summary. Some comments inline.</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Apr 15, 2014 at 5:20 AM, Stephen Balukoff <span dir="ltr">
<<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>></span> wrote:
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>So! On this front:</div>
<div><br>
</div>
<div>1. Does is make sense to keep filling out use cases in Samuel's document above? I can think of several more use cases that our customers actually use on our current deployments which aren't considered in the 8 cases in Samuel's document thus far. Plus
nobody has create any use cases from the cloud operator perspective yet.</div>
</div>
</blockquote>
<div><br>
</div>
<div>I treat Sam's doc as a source of use cases to triage API proposals. If you think you have use cases that don't fit into existing API or into proposed API, they should certainly be brought to attention.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>2. It looks like we've started to get real-world data on Load Balancer features in use in the real world. If you've not added your organization's data, please be sure to do so soon so we can make informed decisions about product direction. On this front,
when will we be making these decisions?</div>
</div>
</blockquote>
<div>I'd say we have two kinds of features - one kind is features that affect or even define the object model and API.</div>
<div>Other kind are features that are implementable within existing/proposed API or require slight changes/evolution.</div>
<div>First kind is the priority: while some of such features may or may not be implemented in some particular release, we need to implement proper infrastructure for them (API, obj model)</div>
<div><br>
</div>
<div>Oleg Bondarev (he's neutron core) and me are planning and mostly interested to work on implementing generic stuff like API/obj model and adopt haproxy driver to it. So our goal is to make implementation of particular features simpler for contributors and
also make sure that proposed design fits in general lbaas architecture. I believe that everyone who wants to see certain feature may start working on it - propose design, participate in discussions and start actually writing the code.</div>
<div> </div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>3. Jorge-- I know an action item from the last meeting was to draft a revision of the API (probably starting from something similar to the Atlas API). Have you had a chance to get started on this, and are you open for collaboration on this document at
this time? Alternatively, I'd be happy to take a stab at it this week (though I'm not very familiar with the Atlas API-- so my proposal might not look all that similar).</div>
</div>
</blockquote>
<div> </div>
<div>+1, i'd like to see something as well. </div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>What format or template should we be following to create the API documentation? (I see this here: <a href="http://docs.openstack.org/api/openstack-network/2.0/content/ch_preface.html" target="_blank">http://docs.openstack.org/api/openstack-network/2.0/content/ch_preface.html</a>
but this seems like it might be a little heavy for an API draft that is likely to get altered significantly, especially given how this discussion has gone thus far. :/ )</div>
</div>
</blockquote>
<div><br>
</div>
<div>Agree, that's too heavy for API sketch. I think a set of resources with some attributes plus a few cli calls is what could show the picture.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Eugene.</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</span></div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</blockquote>
</div>
<br>
</div>
</div>
</div></div></div>
</div>
</div>
</div>
<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></blockquote></div><br></div></div>