A couple of notes:
On Wed, Feb 26, 2014 at 12:24 AM, Jay Pipes <jaypi...@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.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
