<div dir="ltr"><div>Hi Sam,</div><div><br></div>My comments inline:<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 4:57 PM, Samuel Bercovici <span dir="ltr"><<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.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,<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">I think we mix different aspects of operations. And try to solve a non “problem”.</span></p></div></div>
</blockquote><div>Not really, Advanced features we're trying to introduce are incompatible by both object model and API.</div><div><br></div><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"><u></u></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:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><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.</span></p></div></div></blockquote><div>That's correct. Tenant may or may not care about how it is grouped on the backend. We need to support both cases. </div><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><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><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.
<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>3.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><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.</span></p></div></div></blockquote><div>I think grouping vips and pools is important part of logical model, even if some users may not care about it.</div><div><br></div><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"><p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><br></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think this is not a “problem”.
<u></u><u></u></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.</span></p></div></blockquote><div> 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.</div>
<div><br></div><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"><u></u><u></u></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.<u></u><u></u></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.</span></p></div></div></blockquote><div>So proposal tries to address 2 issues: </div><div>1) in many cases it is desirable to know about grouping of logical objects on the backend </div><div>2) currently physical model implied when working with pools, because pool is the root and corresponds to backend with 1:1 mapping</div>
<div><br></div><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"><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">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. </span></p></div></div></blockquote><div>Reusing pools by vips is not as simple as it seems. </div><div>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:</div>
<div>1) what 'status' attribute of the pool would mean?</div><div>2) how health monitors for the pool will be deployed? and what their statuses would mean?</div><div>3) what pool statistics would mean?</div><div>4) If the same pool is used on </div>
<div><br></div><div>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.</div><div>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.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div></div></div></div>