On Wed, 2014-02-26 at 16:11 +0400, Eugene Nikanorov wrote: > 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. 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev