Open Stack

On Wed, 2014-02-26 at 16:11 +0400, Eugene Nikanorov wrote:

> On Wed, Feb 26, 2014 at 12:24 AM, Jay Pipes <jaypipes at gmail.com>
> wrote:

>         neutron l7-policy-create --type="uri-regex-matching" \
>          --attr=URIRegex="static\.example\.com.*"
>         
>         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 and
>         spreading load to the nginx nodes by doing:
>         
>         neutron balancer-apply-policy $BALANCER_ID $L7_POLICY_ID \
>          --subnet-cidr=192.168.1.0/24
>         
>         We could then indicate to the balancer that all other traffic
>         should be
>         sent to only the Apache nodes:
>         
>         neutron l7-policy-create --type="uri-regex-matching" \
>          --attr=URIRegex="static\.example\.com.*" \
>          --attr="RegexMatchReverse=true"
>         
>         neutron balancer-apply-policy $BALANCER_ID $L7_POLICY_ID \
>          --subnet-cidr=192.168.2.0/24
> That's cheating! :)

:)

> Once you have both static and webapp servers on one subnet, you'll
> have to introduce the notion of 'node groups', 
> e.g. pools, and somehow refer them within single $BALANCER_ID.

Agreed. In fact, I had a hangout with Stephen yesterday evening to chat
about just this thing.

I admit that the notion of a named pool of instances would be necessary
in these cases.

That said, what it all boils down to is generating a list of backend IP
addresses. Whether we use a subnet_cidr or a named pool ID, all that is
happening is allowing the user to specify a group of nodes together.

So, I'd love it if both options were possible (i.e. allow subnet_id,
subnet_cidr, pool_id and pool_name when specifying groups of nodes with
balancer-apply-policy) 
> 
> I think notions from world of load balancing are unavoidable in the
> API and we should not try to get rid of them.
>  
>         The biggest advantage to this proposed API and CLI is that we
>         are not
>         introducing any terminology into the Neutron LBaaS API that is
>         not
>         necessary when existing terms in the main Neutron API already
>         exist to
>         describe such things. 
> But is there much point in this? We'are introducing quite a lot even
> within this proposal: loadbalancer, l7-policy, healthchecks, etc.

Fair point. Was just brainstorming :)
> 
>         You will note that I do not use the term "pool"
>         above, since the concept of a subnet (and its associated CIDR)
>         are
>         already well-established objects in the Neutron API and can
>         serve the
>         exact same purpose for Neutron LBaaS API.
> The subnet is just not flexible enough. Not to say that some
> implementations may not support having nodes on different subnets,
> while may support L7 rules.

Agreed. Would just like it to be an option instead of forcing the user
to create a pool if they don't need to (i.e. the subnet would work just
fine...)

>         > As far as hiding implementation details from the user:  To a
>         certain
>         > degree I agree with this, and to a certain degree I do not:
>         OpenStack
>         > is a cloud OS fulfilling the needs of supplying IaaS. It is
>         not a
>         > PaaS. As such, the objects that users deal with largely are
>         analogous
>         > to physical pieces of hardware that make up a cluster,
>         albeit these
>         > are virtualized or conceptualized. Users can then use these
>         conceptual
>         > components of a cluster to build the (virtual)
>         infrastructure they
>         > need to support whatever application they want. These
>         objects have
>         > attributes and are expected to act in a certain way, which
>         again, are
>         > usually analogous to actual hardware.
>         
>         
>         I disagree. A cloud API should strive to shield users of the
>         cloud from
>         having to understand underlying hardware APIs or object
>         models.
>  
> I think Stephen's suggestion is not about underlying hardware API, but
> about the set of building blocks.
> Across all services, Libra/Atlas, ELB, LBaaS those blocks are the same
> no matter how we name them.

Sure, understood. Just trying to brainstorm a bit on how to keep
flexibility in the LBaaS API while also simplifying it as much as
possible.

Best,
-jay