Open Stack

On Thu, 2014-02-20 at 15:21 +0400, Eugene Nikanorov wrote:

>         I agree with Samuel here.  I feel the logical model and other
>         issues
>         (implementation etc.) are mixed in the discussion.
>  
> A little bit. While ideally it's better to separate it, in my opinion
> we need to have some 'fair bit' of implementation details
> in API in order to reduce code complexity (I'll try to explain it on
> the meeting). Currently these 'implementation details' are implied
> because we deal with simplest configurations which maps 1:1 to a
> backend.

I disagree on this point. I believe that the more implementation details
bleed into the API, the harder the API is to evolve and improve, and the
less flexible the API becomes.

I'd personally love to see the next version of the LBaaS API be a
complete breakaway from any implementation specifics and refocus itself
to be a control plane API that is written from the perspective of the
*user* of a load balancing service, not the perspective of developers of
load balancer products.

The user of the OpenStack load balancer service would be able to call
the API in the following way (which represents more how the user thinks
about the problem domain):

neutron balancer-type-list

# Returns a list of balancer types (flavors) that might
# look something like this perhaps (just an example off top of head):

- simple:
    capabilities:
      topologies:
        - single-node
      algorithms:
        - round-robin
      protocols:
        - http
      max-members: 4
- advanced:
    capabilities:
      topologies:
        - single-node
        - active-standby
      algorithms:
        - round-robin
        - least-connections
      protocols:
        - http
        - https
      max-members: 100
   
# User would then create a new balancer from the type:

neutron balancer-create --type=advanced --front=<ip> \
 --back=<list_of_ips> --algorithm="least-connections" \
 --topology="active-standby"

# Neutron LBaaS goes off and does a few things, then perhaps
# user would run:

neutron balancer-show <balancer_id>

# which might return the following:

front:
  ip: <ip>
  nodes:
    - <uuid> <-- could be a hardware device ID or a VM ID
      ip: <fixed_ip>
      status: ACTIVE
    - <uuid>
      ip: <fixed_ip>
      status: STANDBY
back:
  nodes:
    - <uuid> <-- could be ID of an appliance or a VM ID
      ip: <fixed_ip>
      status: ONLINE
    - <uuid>
      ip: <fixed_ip>
      status: ONLINE
    - <uuid>
      ip: <fixed_ip>
      status: OFFLINE

No mention of pools, VIPs, or really much else other than a "balancer"
and the balancer "type", which describes capabilities and restrictions
for a class of balancers. All implementation details are hidden behind
the API. How Neutron LBaaS stores the data behind the scenes should not
influence the forward user-facing API.

Just my two cents,
-jay