Hi Jay, Just a quick response:
The 'implementation detail in API' that we all are arguing about is some hint from the user about how logical configuration is mapped on the backend(s), not much detail IMO. Your proposed model has that, because you create the balancer at once and the driver can easily map submitted configuration to *some* backend or even decide how to split it. Things get more complicated when you need fine-grained control. Looking at your proposal it reminds me Heat template for loadbalancer. It's fine, but we need to be able to operate on particular objects. Thanks, Eugene. On Fri, Feb 21, 2014 at 10:29 PM, Jay Pipes <jaypi...@gmail.com> wrote: > 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 > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
