<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:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{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;}
/* List Definitions */
@list l0
{mso-list-id:977147128;
mso-list-type:hybrid;
mso-list-template-ids:151582444 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1710835824;
mso-list-type:hybrid;
mso-list-template-ids:405439842 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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,<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 think we mix different aspects of operations. And try to solve a non “problem”.<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">From APIs/Operations we are mixing the following models:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span dir="LTR"></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.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span dir="LTR"></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.
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span dir="LTR"></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.<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">Another “problem“, which all the new proposals are trying to solve, is placing a pools which can be a root/default for a vip
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">ß</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 relationship also
as part association with l7 policy of another vip</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">ß</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
that is configured in another backend.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think this is not a “problem”.
<o:p></o:p></span></p>
<p class="MsoNormal"><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: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:Wingdings;color:#1F497D">à</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">pool
are deployed on.<o:p></o:p></span></p>
<p class="MsoNormal"><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: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.<o:p></o:p></span></p>
<p class="MsoNormal"><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.<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 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: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. This also means that all those vips will be placed on the same place as the pool they are pointing to as their default pool.<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">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -Sam.<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"><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"><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> Tuesday, February 18, 2014 9:35 PM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Cc:</b> Youcef Laribi; Samuel Bercovici; sbalukoff@bluebox.net; Mark McClain; Salvatore Orlando<br>
<b>Subject:</b> [Neutron][LBaaS] Object Model discussion<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi folks,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Recently we were discussing LBaaS object model with Mark McClain in order to address several problems that we faced while approaching L7 rules and multiple vips per pool.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">To cut long story short: with existing workflow and model it's impossible to use L7 rules, because<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">each pool being created is 'instance' object in itself, it defines another logical configuration and can't be attached to other existing configuration.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">To address this problem, plus create a base for multiple vips per pool, the 'loadbalancer' object was introduced (see <a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance">https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance</a>
).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">However this approach raised a concern of whether we want to let user to care about 'instance' object.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My personal opinion is that letting user to work with 'loadbalancer' entity is no big deal (and might be even useful for terminological clarity; Libra and AWS APIs have that) especially if existing simple workflow is preserved, so the 'loadbalancer'
entity is only required when working with L7 or multiple vips per pool.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The alternative solution proposed by Mark is described here under #3:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion">https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">In (3) the root object of the configuration is VIP, where all kinds of bindings are made (such as provider, agent, device, router). To address 'multiple vips' case another entity 'Listener' is introduced, which receives most attributes
of former 'VIP' (attribute sets are not finalized on those pictures, so don't pay much attention)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">If you take closer look at #2 and #3 proposals, you'll see that they are essentially similar, where in #3 the VIP object takes instance/loadbalancer role from #2.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Both #2 and #3 proposals make sense to me because they address both problems with L7 and multiple vips (or listeners)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">My concern about #3 is that it redefines lots of workflow and API aspects and even if we manage to make transition to #3 in backward-compatible way, it will be more complex in terms of code/testing, then #2 (which is on review already and
works).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The whole thing is important design decision, so please share your thoughts everyone.<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>
</body>
</html>