<div dir="ltr">Hi Youcef,<div><br></div><div>The point is to be able to share IP address, it really means that two VIPs(as we understand them in current model) need to reside within same backend (technically they need to share neutron port).</div>
<div>We decided not to expose any 'colocation hint' (like loadbalancer_id) in the API, so we really can't create two vips on one backend right now.</div><div><br></div><div>I'm sorry this all creates so much confusion.</div>
<div>In order to understand why we need additional entity, you need to keep in mind the following things:</div><div> 1) We have a notion of root object. From user perspective it represents logical instance, from implementation perspective it also represents how that instance is mapped to a backend (agent, device), which flavor/provider/driver it has, etc</div>
<div> 2) We're trying to change vip-pool relationship to m:n, if vip or pool remain the root object, that creates inconsistency because root object can be connected to another root object with different parameters.</div>
<div><br></div><div>To resolve issue #2 we can do basically two similar things: </div><div>- introduce another entity instead on a vip to make that m:n relationship (listener), </div><div>- as was initially suggested, to introduce 'instance' entity to colocate vips, both </div>
<div><br></div><div>Hope that helps.</div><div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 27, 2014 at 5:20 AM, Youcef Laribi <span dir="ltr"><<a href="mailto:Youcef.Laribi@citrix.com" target="_blank">Youcef.Laribi@citrix.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Eugene,<u></u><u></u></span></p><div class="">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal" style="margin-left:.5in">1) In order to allow real multiple 'vips' per pool feature, we need the listener concept.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">It's not just a different tcp port, but also a protocol, so session persistence and all ssl-related parameters should move to listener.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Why do we need a new ‘listener’ concept? Since as Sam pointed out, we are removing the reference to a pool from the VIP in the current model, isn’t this enough
 by itself to allow the model to support multiple VIPs per pool now?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.5pt;font-family:"Arial","sans-serif"">lb-pool-create  ….
</span><span style="font-size:11.5pt;font-family:Wingdings">à</span><span style="font-size:11.5pt;font-family:"Arial","sans-serif"">$POOL-1</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.5pt;font-family:"Arial","sans-serif"">lb-vip-create …..$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1…
</span><span style="font-size:11.5pt;font-family:Wingdings">à</span><span style="font-size:11.5pt;font-family:"Arial","sans-serif""> $VIP-1<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.5pt;font-family:"Arial","sans-serif"">lb-vip-create …..$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1…
</span><span style="font-size:11.5pt;font-family:Wingdings">à</span><span style="font-size:11.5pt;font-family:"Arial","sans-serif""> $VIP-2<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Youcef<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Eugene Nikanorov [mailto:<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>]
<br>
<b>Sent:</b> Wednesday, February 26, 2014 1:26 PM<br>
<b>To:</b> Samuel Bercovici<br>
<b>Cc:</b> OpenStack Development Mailing List (not for usage questions)</span></p><div><div class="h5"><br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion<u></u><u></u></div></div><p></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hi Sam,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I've looked over the document, couple of notes:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">1) In order to allow real multiple 'vips' per pool feature, we need the listener concept.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">It's not just a different tcp port, but also a protocol, so session persistence and all ssl-related parameters should move to listener.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">2)<span style="font-family:"Arial","sans-serif""> <span style>ProviderResourceAssociation - remains on the instance object (our instance object is VIP) as a relation attribute. </span></span><u></u><u></u></p>

</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Though it is removed from public API, so it could not be specified on creation. </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Remember provider is needed for REST call dispatching. The value of provider attribute (e.g. ProviderResourceAssociation) is result of scheduling.</span><u></u><u></u></p>

</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">3) As we discussed before, pool->vip relation will be removed, but pool reuse by different vips (e.g. different backends) will be forbidden for implementation simplicity, because
 this is definitely not a priority right now. </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">I think it's a fair limitation that can be removed later.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">On workflows:</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">WFs #2 and #3 are problematic. First off, sharing the same IP is not possible for other vip for the following reason:</span><u></u><u></u></p>

</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">vip is created (with new model) with flavor (or provider) and scheduled to a provider (and then to a particular backend), doing so for 2 vips makes address reuse impossible if we
 want to maintain logical API, or otherwise we would need to expose implementation details that will allow us to connect two vips to the same backend.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">On the open discussion questions:</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">I think most of them are resolved by following existing API expectations about status fields, etc.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Main thing that allows to go with existing API expectations is the notion of 'root object'.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif"">Root object is the object which status and admin_state show real operability of the configuration. While from implementation perspective it is a mounting point between logical config
 and the backend.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The real challenge of model #3 is ability to share pools between different VIPs, e.g. between different flavors/providers/backends. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">User may be unaware of it, but it requires really complex logic to handle statistics, healthchecks, etc. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I think while me may leave this ability at object model and API level, we will limit it, as I said previously.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Eugene.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Feb 26, 2014 at 9:06 PM, Samuel Bercovici <<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I have added to the wiki page:
<a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#1.1_Turning_existing_model_to_logical_model" target="_blank">
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#1.1_Turning_existing_model_to_logical_model</a> that points to a document that includes the current model + L7 + SSL.</span><u></u><u></u></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Please review.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Regards,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">                -Sam.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Samuel Bercovici
<br>
<b>Sent:</b> Monday, February 24, 2014 7:36 PM</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<u></u><u></u></p>
</div>
<p class="MsoNormal"><b>Cc:</b> Samuel Bercovici<br>
<b>Subject:</b> RE: [openstack-dev] [Neutron][LBaaS] Object Model discussion<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I also agree that the model should be pure logical.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think that the existing model is almost correct but the pool should be made pure logical. This
 means that the vip </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">ßà</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">pool relationships needs also to become any to any.</span><u></u><u></u></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Eugene, has rightfully pointed that the current “state” management will not handle such relationship
 well.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">To me this means that the “state” management is broken and not the model.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I will propose an update to the state management in the next few days.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Regards,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">                -Sam.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Mark McClain [<a href="mailto:mmcclain@yahoo-inc.com" target="_blank">mailto:mmcclain@yahoo-inc.com</a>]
<br>
<b>Sent:</b> Monday, February 24, 2014 6:32 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Feb 21, 2014, at 1:29 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica","sans-serif"">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.</span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">I agree with Jay.  We the API needs to be user centric and free of implementation details.  One of my concerns I’ve voiced in some of the IRC discussions is that too many implementation
 details are exposed to the user.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">mark<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>

<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>
<br></blockquote></div><br></div>