Open Stack

A couple of notes:


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.

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.

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.


>
> > 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.

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