<div dir="ltr">Hi Jay,<div><br></div><div>Just a quick response:</div><div><br></div><div>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. </div>
<div><br></div><div>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.</div><div>Things get more complicated when you need fine-grained control.</div>
<div><br></div><div>Looking at your proposal it reminds me Heat template for loadbalancer. </div><div>It's fine, but we need to be able to operate on particular objects.</div><div><br></div><div>Thanks,</div><div>Eugene.</div>
<div><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 21, 2014 at 10:29 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, 2014-02-20 at 15:21 +0400, Eugene Nikanorov wrote:<br>
<br>
>         I agree with Samuel here.  I feel the logical model and other<br>
>         issues<br>
>         (implementation etc.) are mixed in the discussion.<br>
><br>
> A little bit. While ideally it's better to separate it, in my opinion<br>
> we need to have some 'fair bit' of implementation details<br>
> in API in order to reduce code complexity (I'll try to explain it on<br>
> the meeting). Currently these 'implementation details' are implied<br>
> because we deal with simplest configurations which maps 1:1 to a<br>
> backend.<br>
<br>
</div>I disagree on this point. I believe that the more implementation details<br>
bleed into the API, the harder the API is to evolve and improve, and the<br>
less flexible the API becomes.<br>
<br>
I'd personally love to see the next version of the LBaaS API be a<br>
complete breakaway from any implementation specifics and refocus itself<br>
to be a control plane API that is written from the perspective of the<br>
*user* of a load balancing service, not the perspective of developers of<br>
load balancer products.<br>
<br>
The user of the OpenStack load balancer service would be able to call<br>
the API in the following way (which represents more how the user thinks<br>
about the problem domain):<br>
<br>
neutron balancer-type-list<br>
<br>
# Returns a list of balancer types (flavors) that might<br>
# look something like this perhaps (just an example off top of head):<br>
<br>
- simple:<br>
    capabilities:<br>
      topologies:<br>
        - single-node<br>
      algorithms:<br>
        - round-robin<br>
      protocols:<br>
        - http<br>
      max-members: 4<br>
- advanced:<br>
    capabilities:<br>
      topologies:<br>
        - single-node<br>
        - active-standby<br>
      algorithms:<br>
        - round-robin<br>
        - least-connections<br>
      protocols:<br>
        - http<br>
        - https<br>
      max-members: 100<br>
<br>
# User would then create a new balancer from the type:<br>
<br>
neutron balancer-create --type=advanced --front=<ip> \<br>
 --back=<list_of_ips> --algorithm="least-connections" \<br>
 --topology="active-standby"<br>
<br>
# Neutron LBaaS goes off and does a few things, then perhaps<br>
# user would run:<br>
<br>
neutron balancer-show <balancer_id><br>
<br>
# which might return the following:<br>
<br>
front:<br>
  ip: <ip><br>
  nodes:<br>
    - <uuid> <-- could be a hardware device ID or a VM ID<br>
      ip: <fixed_ip><br>
      status: ACTIVE<br>
    - <uuid><br>
      ip: <fixed_ip><br>
      status: STANDBY<br>
back:<br>
  nodes:<br>
    - <uuid> <-- could be ID of an appliance or a VM ID<br>
      ip: <fixed_ip><br>
      status: ONLINE<br>
    - <uuid><br>
      ip: <fixed_ip><br>
      status: ONLINE<br>
    - <uuid><br>
      ip: <fixed_ip><br>
      status: OFFLINE<br>
<br>
No mention of pools, VIPs, or really much else other than a "balancer"<br>
and the balancer "type", which describes capabilities and restrictions<br>
for a class of balancers. All implementation details are hidden behind<br>
the API. How Neutron LBaaS stores the data behind the scenes should not<br>
influence the forward user-facing API.<br>
<br>
Just my two cents,<br>
-jay<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>