<div dir="ltr">Hi Jay,<div><br></div><div>Thanks for suggestions. I get the idea.</div><div>I'm not sure the essence of this API is much different then what we have now.</div><div>1) We operate on parameters of loadbalancer rather then on vips/pools/listeners. No matter how we name them, the notions are there.</div>
<div>2) I see two opposite preferences: one is that user doesn't care about 'loadbalancer' in favor of pools/vips/listeners ('pure logical API')</div><div>another is vice versa (yours). </div><div>3) The approach of providing <span style="font-family:arial,sans-serif;font-size:13px">$BALANCER_ID to pretty much every call solves all my concerns, I like it.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">Basically that was my initial code proposal (it's not exactly the same, but it's very close).</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">The idea of my proposal was to have that '</span><span style="font-family:arial,sans-serif;font-size:13px">balancer' resource plus being able to operate on vips/pools/etc.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">In this direction we could evolve from existing API to the API in your latest suggestion.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div>Thanks,<br></div><div>Eugene.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 25, 2014 at 12:35 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">Thanks, Eugene! I've given the API a bit of thought today and jotted<br>
down some thoughts below.<br>
<div class=""><br>
On Fri, 2014-02-21 at 23:57 +0400, Eugene Nikanorov wrote:<br>
>         Could you provide some examples -- even in the pseudo-CLI<br>
>         commands like<br>
>         I did below. It's really difficult to understand where the<br>
>         limits are<br>
>         without specific examples.<br>
> You know, I always look at the API proposal from implementation<br>
> standpoint also, so here's what I see.<br>
> In the cli workflow that you described above, everything is fine,<br>
> because the driver knowы how and where to deploy each object<br>
> that you provide in your command, because it's basically a batch.<br>
<br>
</div>Yes, that is true.<br>
<div class=""><br>
> When we're talking about separate objectы that form a loadbalancer -<br>
> vips, pools, members, it becomes not clear how to map them backends<br>
> and at which point.<br>
<br>
</div>Understood, but I think we can make some headway here. Examples below.<br>
<div><div class="h5"><br>
> So here's an example I usually give:<br>
> We have 2 VIPs (in fact, one address and 2 ports listening for http<br>
> and https, now we call them listeners),<br>
> both listeners pass request to a webapp server farm, and http listener<br>
> also passes requests to static image servers by processing incoming<br>
> request URIs by L7 rules.<br>
> So object topology is:<br>
><br>
><br>
>      Listener1 (addr:80)           Listener2(addr:443)<br>
>                |             \                /<br>
>                |                 \        /<br>
>                |                      X<br>
>                |                  /         \<br>
>          pool1(webapp)             pool2(static imgs)<br>
> sorry for that stone age pic :)<br>
><br>
><br>
> The proposal that we discuss can create such object topology by the<br>
> following sequence of commands:<br>
> 1) create-vip --name VipName address=addr<br>
> returns vid_id<br>
> 2) create-listener --name listener1 --port 80 --protocol http --vip_id<br>
> vip_id<br>
> returns listener_id1<br>
> 3) create-listener --name listener2 --port 443 --protocol https<br>
> --sl-params params --vip_id vip_id<br>
><br>
> returns listener_id2<br>
<br>
> 4) create-pool --name pool1 <members><br>
><br>
> returns pool_id1<br>
> 5) create-pool --name pool1 <members><br>
> returns pool_id2<br>
><br>
> 6) set-listener-pool listener_id1 pool_id1 --default<br>
> 7) set-listener-pool listener_id1 pool_id2 --l7policy policy<br>
><br>
> 7) set-listener-pool listener_id2 pool_id1 --default<br>
<br>
> That's a generic workflow that allows you to create such config. The<br>
> question is at which point the backend is chosen.<br>
<br>
</div></div>From a user's perspective, they don't care about VIPs, listeners or<br>
pools :) All the user cares about is:<br>
<br>
 * being able to add or remove backend nodes that should be balanced<br>
across<br>
 * being able to set some policies about how traffic should be directed<br>
<br>
I do realize that AWS ELB's API uses the term "listener" in its API, but<br>
I'm not convinced this is the best term. And I'm not convinced that<br>
there is a need for a "pool" resource at all.<br>
<br>
Could the above steps #1 through #6 be instead represented in the<br>
following way?<br>
<br>
# Assume we've created a load balancer with ID $BALANCER_ID using<br>
# Something like I showed in my original response:<br>
<div class=""><br>
neutron balancer-create --type=advanced --front=<ip> \<br>
 --back=<list_of_ips> --algorithm="least-connections" \<br>
 --topology="active-standby"<br>
<br>
</div>neutron balancer-configure $BALANCER_ID --front-protocol=http \<br>
 --front-port=80 --back-protocol=http --back-port=80<br>
<br>
neutron balancer-configure $BALANCER_ID --front-protocol=https \<br>
 --front-port=443 --back-protocol=https --back-port=443<br>
<br>
Likewise, we could configure the load balancer to send front-end HTTPS<br>
traffic (terminated at the load balancer) to back-end HTTP services:<br>
<br>
neutron balancer-configure $BALANCER_ID --front-protocol=https \<br>
 --front-port=443 --back-protocol=http --back-port=80<br>
<br>
No mention of listeners, VIPs, or pools at all.<br>
<br>
The REST API for the balancer-update CLI command above might be<br>
something like this:<br>
<br>
PUT /balancers/{balancer_id}<br>
<br>
with JSON body of request like so:<br>
<br>
{<br>
  "front-port": 443,<br>
  "front-protocol": "https",<br>
  "back-port": 80,<br>
  "back-protocol": "http"<br>
}<br>
<br>
And the code handling the above request would simply look to see if the<br>
load balancer had a "routing entry" for the front-end port and protocol<br>
of (443, https) and set the entry to route to back-end port and protocol<br>
of (80, http).<br>
<br>
For the advanced L7 policy heuristics, it makes sense to me to use a<br>
similar strategy. For example (using a similar example from ELB):<br>
<br>
neutron l7-policy-create --type="ssl-negotiation" \<br>
 --attr=ProtocolSSLv3=true \<br>
 --attr=ProtocolTLSv1.1=true \<br>
 --attr=DHE-RSA-AES256-SHA256=true \<br>
 --attr=Server-Defined-Cipher-Order=true<br>
<br>
Presume above returns an ID for the policy $L7_POLICY_ID. We could then<br>
assign that policy to operate on the front-end of the load balancer by<br>
doing:<br>
<br>
neutron balancer-apply-policy $BALANCER_ID $L7_POLICY_ID --port=443<br>
<br>
There's no need to specify --front-port of course, since the policy only<br>
applies to the front-end.<br>
<br>
There is also no need to refer to a "listener" object, no need to call<br>
anything a VIP, nor any reason to use the term "pool" in the API.<br>
<br>
Best,<br>
-jay<br>
<div class="HOEnZb"><div class="h5"><br>
> In our current proposal backend is chosen and step (1) and all further<br>
> objects are implicitly go on the same backend as VipName.<br>
><br>
><br>
> The API allows the following addition:<br>
> 8) create-vip --name VipName2 address=addr2<br>
> 9) create-listener ... listener3 ...<br>
> 10) set-listener-pool listener_id3 pool_id1<br>
><br>
><br>
> E.g. from API stand point the commands above are valid. But that<br>
> particular ability (pool1 is shared by two different backends)<br>
> introduces lots of complexity in the implementation and API, and that<br>
> is what we would like to avoid at this point.<br>
><br>
><br>
> So the proposal makes step #10 forbidden: pool is already associated<br>
> with the listener on other backend, so we don't share it with<br>
> listeners on another one.<br>
> That kind of restriction introduces implicit knowledge about the<br>
> object-to-backend mapping into the API.<br>
> In my opinion it's not a big deal. Once we sort out those<br>
> complexities, we can allow that.<br>
><br>
><br>
> What do you think?<br>
><br>
><br>
> Thanks,<br>
> Eugene.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
>         > Looking at your proposal it reminds me Heat template for<br>
>         > loadbalancer.<br>
>         > It's fine, but we need to be able to operate on particular<br>
>         objects.<br>
><br>
><br>
>         I'm not ruling out being able to add or remove nodes from a<br>
>         balancer, if<br>
>         that's what you're getting at?<br>
><br>
>         Best,<br>
>         -jay<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>
><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>
<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>