Open Stack

Hi Jay,

Thanks for suggestions. I get the idea.
I'm not sure the essence of this API is much different then what we have
now.
1) We operate on parameters of loadbalancer rather then on
vips/pools/listeners. No matter how we name them, the notions are there.
2) I see two opposite preferences: one is that user doesn't care about
'loadbalancer' in favor of pools/vips/listeners ('pure logical API')
another is vice versa (yours).
3) The approach of providing $BALANCER_ID to pretty much every call solves
all my concerns, I like it.
Basically that was my initial code proposal (it's not exactly the same, but
it's very close).
The idea of my proposal was to have that 'balancer' resource plus being
able to operate on vips/pools/etc.
In this direction we could evolve from existing API to the API in your
latest suggestion.

Thanks,
Eugene.


On Tue, Feb 25, 2014 at 12:35 AM, Jay Pipes <jaypipes at gmail.com> wrote:

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