>
>
>
> 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.
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.
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.
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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
