<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi guys,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I have been catching up on this interesting thread around the object model, so sorry in advance to jump in late in this debate, and if I missed some of the
subtleties of the points being made so far. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I tend to agree with Sam that the original intention of the current object model was never tied to a physical deployment. We seem to be confusing the tenant-facing
object model which is completely logical (albeit with some “properties” or “qualities” that a tenant can express) from the deployment/implementation aspects of such a logical model (things like cluster/HA, one vs. multiple backends, virtual appliance vs. OS
process, etc). We discussed in the past, the need for an Admin API (separate from the tenant API) where a cloud administrator (as opposed to a tenant) could manage the deployment aspects, and could construct different offerings that can be exposed to a tenant,
but in the absence of such as admin API (which would necessarily be very technology-specific), this responsibility is currently shouldered by the drivers.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">IMO a tenant should only care about whether VIPs/Pools are grouped together to the extent that the provider allows the tenant to express such a preference.
Some providers will allow their tenants to express such a preference (e.g. because it might impact cost), and others might not as it wouldn’t make sense in their implementation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Also the mapping between pool and backend is not necessarily 1:1, and is not necessarily at the creation time of pool, as this is purely a driver implementation
decision (I know that currently implementations are like this, but another driver can choose a different approach). A driver could for example delay mapping a pool to a backend, until a full LB configuration is completed (when pool has members, and a VIP is
attached to the pool). A driver can also move these resources around between backends, if it finds out, it put them in a non-optimal backend initially. As long as the logical model is realized and remains consistent from the tenant point of view, implementations
should be free to achieve that goal in any way they see fit.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Youcef<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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:enikanorov@mirantis.com]
<br>
<b>Sent:</b> Wednesday, February 19, 2014 8:23 AM<br>
<b>To:</b> Samuel Bercovici<br>
<b>Cc:</b> OpenStack Development Mailing List; Mark McClain; Salvatore Orlando; sbalukoff@bluebox.net; Youcef Laribi; Avishay Balderman<br>
<b>Subject:</b> Re: [Neutron][LBaaS] Object Model discussion<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Hi Sam,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">My comments inline:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Feb 19, 2014 at 4:57 PM, Samuel Bercovici <<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think we mix different aspects of operations. And try to solve a non “problem”.</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">Not really, Advanced features we're trying to introduce are incompatible by both object model and API.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">From APIs/Operations we are mixing the following models:</span><o:p></o:p></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">1.</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Logical model (which as far as I understand is the topic of this discussion) - tenants define what they need logically 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">default_pool,
l7 association, ssl, etc.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">That's correct. Tenant may or may not care about how it is grouped on the backend. We need to support both cases. <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">2.</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Physical model – operator / vendor install and specify how backend gets implemented.
</span><o:p></o:p></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">3.</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Deploying 1 on 2 – this is currently the driver’s responsibility. We can consider making it better but this should not impact the logical model.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">I think grouping vips and pools is important part of logical model, even if some users may not care about it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><o:p> </o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think this is not a “problem”.
</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In a logical model a pool which is part of L7 policy is a logical object which could be placed at
any backend and any existing 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 and accordingly configure the backend that those 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
are deployed on.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> That's not how it currently works - that's why we're trying to address it. Having pool shareable between backends at least requires to move 'instance' role from the pool to some other entity, and also that changes a number of API aspects.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If the same pool that was part of a l7 association will also be connected to a vip as a default pool,
than by all means this new 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 pair can be instantiated into some back end.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The proposal to not allow this (ex: only allow pools that are connected to the same lb-instance to
be used for l7 association), brings the physical model into the logical model.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">So proposal tries to address 2 issues: <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1) in many cases it is desirable to know about grouping of logical objects on the backend <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2) currently physical model implied when working with pools, because pool is the root and corresponds to backend with 1:1 mapping<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think that the current logical model is fine with the exception that the two way reference between
vip and pool (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) should be modified with only vip pointing to a pool (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)
which allows reusing the pool with multiple vips. </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">Reusing pools by vips is not as simple as it seems. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">If those vips belong to 1 backend (that by itself requires tenant to know about that) - that's no problem, but if they don't, then:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1) what 'status' attribute of the pool would mean?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2) how health monitors for the pool will be deployed? and what their statuses would mean?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3) what pool statistics would mean?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">4) If the same pool is used on <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">To be able to preserve existing meaningful healthmonitors, members and statistics API we will need to create associations for everything, or just change API in backward incompatible way.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">My opinion is that it make sense to limit such ability (reusing pools by vips deployed on different backends) in favor of simpler code, IMO it's really a big deal. Pool is lightweight enough to not to share it as an object.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Eugene.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>