<div dir="ltr">Hi Samuel,<div><br></div><div>We've actually been avoiding having a deeper discussion about status in Neutron LBaaS since this can get pretty hairy as the back-end implementations get more complicated. I suspect managing that is probably one of the bigger reasons we have disagreements around object sharing. Perhaps it's time we discussed representing state "correctly" (whatever that means), instead of a round-a-bout discussion about object sharing (which, I think, is really just avoiding this issue)?</div><div><br></div><div>Do you have a proposal about how status should be represented (possibly including a description of the state machine) if we collapse everything down to be logical objects except the loadbalancer object? (From what you're proposing, I suspect it might be too general to, for example, represent the UP/DOWN status of members of a given pool.)</div><div><br></div><div>Also, from an haproxy perspective, sharing pools within a single listener actually isn't a problem. That is to say, having the same L7Policy pointing at the same pool is OK, so I personally don't have a problem allowing sharing of objects within the scope of parent objects. What do the rest of y'all think?</div><div><br></div><div>Stephen</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 22, 2014 at 11:06 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 Stephen,<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><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">The issue is that if we do 1:1 and allow status/state to proliferate throughout all objects we will then get an issue to fix
it later, hence even if we do not do sharing, I would still like to have all objects besides LB be treated as logical.<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">The 3<sup>rd</sup> use case bellow will not be reasonable without pool sharing between different policies. Specifying different
pools which are the same for each policy make it non-started to me. <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">-Sam.<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""> Stephen Balukoff [mailto:<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>]
<br>
<b>Sent:</b> Friday, November 21, 2014 10:26 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">I think the idea was to implement 1:1 initially to reduce the amount of code and operational complexity we'd have to deal with in initial revisions of LBaaS v2. Many to many can be simulated in this scenario, though it does shift the burden
of maintenance to the end user. It does greatly simplify the initial code for v2, in any case, though.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">Did we ever agree to allowing listeners to be shared among load balancers? I think that still might be a N:1 relationship even in our latest models.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">There's also the difficulty introduced by supporting different flavors: Since flavors are essentially an association between a load balancer object and a driver (with parameters), once flavors are introduced, any sub-objects of a given
load balancer objects must necessarily be purely logical until they are associated with a load balancer. I know there was talk of forcing these objects to be sub-objects of a load balancer which can't be accessed independently of the load balancer (which
would have much the same effect as what you discuss: State / status only make sense once logical objects have an instantiation somewhere.) However, the currently proposed API treats most objects as root objects, which breaks this paradigm.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">How we handle status and updates once there's an instantiation of these logical objects is where we start getting into real complexity.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">It seems to me there's a lot of complexity introduced when we allow a lot of many to many relationships without a whole lot of benefit in real-world deployment scenarios. In most cases, objects are not going to be shared, and in those cases
with sufficiently complicated deployments in which shared objects could be used, the user is likely to be sophisticated enough and skilled enough to manage updating what are essentially "copies" of objects, and would likely have an opinion about how individual
failures should be handled which wouldn't necessarily coincide with what we developers of the system would assume. That is to say, allowing too many many to many relationships feels like a solution to a problem that doesn't really exist, and introduces a lot
of unnecessary complexity.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In any case, though, I feel like we should walk before we run: Implementing 1:1 initially is a good idea to get us rolling. Whether we then implement 1:N or M:N after that is another question entirely. But in any case, it seems like a bad
idea to try to start with M:N.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Stephen<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Thu, Nov 20, 2014 at 4:52 AM, Samuel Bercovici <<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.com</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">Hi,<br>
<br>
Per discussion I had at OpenStack Summit/Paris with Brandon and Doug, I would like to remind everyone why we choose to follow a model where pools and listeners are shared (many to many relationships).<br>
<br>
Use Cases:<br>
1. The same application is being exposed via different LB objects.<br>
For example: users coming from the internal "private" organization network, have an LB1(private_VIP) --> Listener1(TLS) -->Pool1 and user coming from the "internet", have LB2(public_vip)-->Listener1(TLS)-->Pool1.<br>
This may also happen to support ipv4 and ipv6: LB_v4(ipv4_VIP) --> Listener1(TLS) -->Pool1 and LB_v6(ipv6_VIP) --> Listener1(TLS) -->Pool1<br>
The operator would like to be able to manage the pool membership in cases of updates and error in a single place.<br>
<br>
2. The same group of servers is being used via different listeners optionally also connected to different LB objects.<br>
For example: users coming from the internal "private" organization network, have an LB1(private_VIP) --> Listener1(HTTP) -->Pool1 and user coming from the "internet", have LB2(public_vip)-->Listener2(TLS)-->Pool1.<br>
The LBs may use different flavors as LB2 needs TLS termination and may prefer a different "stronger" flavor.<br>
The operator would like to be able to manage the pool membership in cases of updates and error in a single place.<br>
<br>
3. The same group of servers is being used in several different L7_Policies connected to a listener. Such listener may be reused as in use case 1.<br>
For example: LB1(VIP1)-->Listener_L7(TLS)<br>
|<br>
+-->L7_Policy1(rules..)-->Pool1<br>
|<br>
+-->L7_Policy2(rules..)-->Pool2<br>
|<br>
+-->L7_Policy3(rules..)-->Pool1<br>
|<br>
+-->L7_Policy3(rules..)-->Reject<br>
<br>
<br>
I think that the "key" issue handling correctly the "provisioning" state and the operation state in a many to many model.<br>
This is an issue as we have attached status fields to each and every object in the model.<br>
A side effect of the above is that to understand the "provisioning/operation" status one needs to check many different objects.<br>
<br>
To remedy this, I would like to turn all objects besides the LB to be logical objects. This means that the only place to manage the status/state will be on the LB object.<br>
Such status should be hierarchical so that logical object attached to an LB, would have their status consumed out of the LB object itself (in case of an error).<br>
We also need to discuss how modifications of a logical object will be "rendered" to the concrete LB objects.<br>
You may want to revisit <a href="https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit#heading=h.3rvy5drl5b5r" target="_blank">
https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit#heading=h.3rvy5drl5b5r</a> the "Logical Model + Provisioning Status + Operation Status + Statistics" for a somewhat more detailed explanation albeit it uses the LBaaS v1 model
as a reference.<br>
<br>
Regards,<br>
-Sam.<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><u></u><u></u></p>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<p class="MsoNormal">Stephen Balukoff <br>
Blue Box Group, LLC <br>
<a href="tel:%28800%29613-4305%20x807" value="+18006134305" target="_blank">(800)613-4305 x807</a> <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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div>
</div>