<div dir="ltr">A couple of notes:<div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 12:24 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"><div><br></div><div><br></div>
neutron l7-policy-create --type="uri-regex-matching" \<br>
 --attr=URIRegex="static\.example\.com.*"<br>
<div><br>
Presume above returns an ID for the policy $L7_POLICY_ID. We could then<br>
</div>assign that policy to operate on the front-end of the load balancer and<br>
spreading load to the nginx nodes by doing:<br>
<br>
neutron balancer-apply-policy $BALANCER_ID $L7_POLICY_ID \<br>
 --subnet-cidr=<a href="http://192.168.1.0/24" target="_blank">192.168.1.0/24</a><br>
<br>
We could then indicate to the balancer that all other traffic should be<br>
sent to only the Apache nodes:<br>
<br>
neutron l7-policy-create --type="uri-regex-matching" \<br>
 --attr=URIRegex="static\.example\.com.*" \<br>
 --attr="RegexMatchReverse=true"<br>
<br>
neutron balancer-apply-policy $BALANCER_ID $L7_POLICY_ID \<br>
 --subnet-cidr=<a href="http://192.168.2.0/24" target="_blank">192.168.2.0/24</a></blockquote><div>That's cheating! :)</div><div>Once you have both static and webapp servers on one subnet, you'll have to introduce the notion of 'node groups', </div>

<div>e.g. pools, and somehow refer them within single $BALANCER_ID.</div><div><br></div><div>I think notions from world of load balancing are unavoidable in the API and we should not try to get rid of them.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The biggest advantage to this proposed API and CLI is that we are not<br>
introducing any terminology into the Neutron LBaaS API that is not<br>
necessary when existing terms in the main Neutron API already exist to<br>
describe such things. </blockquote><div>But is there much point in this? We'are introducing quite a lot even within this proposal: loadbalancer, l7-policy, healthchecks, etc. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

You will note that I do not use the term "pool"<br>
above, since the concept of a subnet (and its associated CIDR) are<br>
already well-established objects in the Neutron API and can serve the<br>
exact same purpose for Neutron LBaaS API.<br></blockquote><div>The subnet is just not flexible enough. Not to say that some implementations may not support having nodes on different subnets, while may support L7 rules.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> As far as hiding implementation details from the user:  To a certain<br>
> degree I agree with this, and to a certain degree I do not: OpenStack<br>
> is a cloud OS fulfilling the needs of supplying IaaS. It is not a<br>
> PaaS. As such, the objects that users deal with largely are analogous<br>
> to physical pieces of hardware that make up a cluster, albeit these<br>
> are virtualized or conceptualized. Users can then use these conceptual<br>
> components of a cluster to build the (virtual) infrastructure they<br>
> need to support whatever application they want. These objects have<br>
> attributes and are expected to act in a certain way, which again, are<br>
> usually analogous to actual hardware.<br>
<br>
</div>I disagree. A cloud API should strive to shield users of the cloud from<br>
having to understand underlying hardware APIs or object models.<br></blockquote><div> </div><div>I think Stephen's suggestion is not about underlying hardware API, but about the set of building blocks.</div><div>Across all services, Libra/Atlas, ELB, LBaaS those blocks are the same no matter how we name them.</div>

<div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div></div></div>