Open Stack

Hi Stephen,

A couple of inline comments:


>    -
>       BBG proposal just has attributes for both and IPv4 address and an
>       IPv6 address in its "VIP" object. (Meaning it's slightly different than a
>       "VIP" as people are likely to assume what that term means.)
>
> This is a correct approach. VIP has single neutron port, which however may
have ip address on several subnets at once, so ipv4+ipv6 is easily solved
within 1 VIP.
I think that's a preferred way.

>
>    -
>
> *Maybe we should wait until the survey results are out?*
> No sense solving for use cases that nobody cares about, eh.
>
> *Maybe we should just look at the differences?*
> The core object models we've proposed are almost identical. Change the
> term "Listener" to "Load Balancer" in my model, and you've essentially got
> the same thing as the Rackspace model.
>
I guess you meant VIP, not Listener.
I think what is more important is tree-like configuration structure.
However having Loadbalancer as the root object vs VIP has difference in
meaning. Loadbalancer implies several L2 ports for the frontend (e.g.
multiple VIPs with own ip addresses) while VIP implies only one L2 port.

For example, I understand the Rackspace model is using a join object
> between "load balancer" and "vip" so these can have a n:m relationship--
> and this is almost entirely to solve use case #14 in the document.
>
This is clearly an overkill to share VIPs between loadbalancer instances.


> *We need to decide what "load balancer" means and go that.*
> This has been something that's come up a lot, and the more we ignore it,
> it seems to me, the more it just adds to the confusion to the discussion.
>
> Rackspace is defining a load balancer as:  An entity that contains
> multiple VIPs, but only one tcp/udp port and protocol (
> http://en.wikipedia.org/wiki/Load_balancing_%28computing%29) .
>
It may have a default pool (named just pool in API object).  It also may
> have a content switching object attached that defines L7 rules.
>
I may have missed something, did you mean one tcp/upd port and protocol per
VIP?  Or otherwise how is that possible?

>
> *What does "the root" mean when we're looking at an object graph, not a
> tree? Or maybe the people most likely to use the single-call interface
> should have the strongest voices in deciding where it should actually be
> placed?*
> I think probably the biggest source of contention over the API proposals
> thus far are what object should be considered the "root" of the tree.
>
'root object'  has the sole purpose of transforming arbitrary graph of
objects into a tree.
We can't move forward without properly defining it.

This whole concept seems to strike me as odd-- because when you have a
> graph, even if it's somewhat tree-like (ie. there are leaf nodes), does the
> term "root" even apply? Can someone please tell me what criteria they're
> using when they say that one object should be a "root" and another should
> not?
>
Criterias are:
- user can think of an object as representation of 'logical service
instance' (logical loadbalancer)
- workflow starts with object creation
- it makes sense to apply attributes like Flavor (service requirements) to
it.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140508/8979e938/attachment.html>