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