<div dir="ltr"><div><div><div><div>Hey Sergey--<br><br></div>Apologies for the delay in my response. I'm still wrapping my head around your option 2 suggestion and the implications it might have for the code base moving forward. I think, though, that I'm against your option 2 proposal and in favor of option 1 (which, yes, is more work initially) for the following reasons:<br><br></div>A. We have a precedent in the code tree with how the stand-alone and active-standby topologies are currently being handled. Yes, this does entail various conditionals and branches in tasks and flows-- which is not really that ideal, as it means the controller worker needs to have more specific information on how topologies work than I think any of us would like, and this adds some rigidity to the implementation (meaning 3rd party vendors may have more trouble interfacing at that level)...  but it's actually "not that bad" in many ways, especially given we don't anticipate supporting a large or variable number of topologies. (stand-alone, active-standby, active-active... and then what? We've been doing this for a number of years and nobody has mentioned any radically new topologies they would like in their load balancing. Things like auto-scale are just a specific case of active-active).<br><br></div>B. If anything Option 2 builds more less-obvious rigidity into the implementation than option 1. For example, it makes the assumption that the distributor is necessarily an amphora or service VM, whereas we have already heard that some will implement the distributor as a pure network routing function that isn't going to be managed the same way other amphorae are.<br><br></div>C. Option 2 seems like it's going to have a lot more permutations that would need testing to ensure that code changes don't break existing / potentially supported functionality. Option 1 keeps the distributor and amphorae management code separate, which means tests should be more straight-forward, and any breaking changes which slip through potentially break less stuff. Make sense?<br><div><div><br></div><div>Stephen<br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 29, 2016 at 7:12 AM, Sergey Guenender <span dir="ltr"><<a href="mailto:GUENEN@il.ibm.com" target="_blank">GUENEN@il.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif" size="2">I'm working with the IBM team implementing
the Active-Active N+1 topology [1].</font><br><br><font face="sans-serif" size="2">I've been commissioned with the task
to help integrate the code supporting the new topology while a) making
as few code changes and b) reusing as much code as possible.</font><br><br><font face="sans-serif" size="2">To make sure the changes to existing
code are future-proof, I'd like to implement them outside AA N+1, submit
them on their own and let the AA N+1 base itself on top of it.</font><br><br><font face="sans-serif" size="2">--TL;DR--</font><br><br><font face="sans-serif" size="2">what follows is a description of the
challenges I'm facing and the way I propose to solve them. Please skip
down to the end of the email to see the actual questions.</font><br><br><font face="sans-serif" size="2">--The details--</font><br><br><font face="sans-serif" size="2">I've been studying the code for a few
weeks now to see where the best places for minimal changes might be.</font><br><br><font face="sans-serif" size="2">Currently I see two options:</font><br><br><font face="sans-serif" size="2">   1. introduce a new kind
of entity (the distributor) and make sure it's being handled on any of
the 6 levels of controller worker code (endpoint, controller worker, *_flows,
*_tasks, *_driver)</font><br><br><font face="sans-serif" size="2">   2. leave most of the code
layers intact by building on the fact that distributor will inherit most
of the controller worker logic of amphora</font><br><br><br><font face="sans-serif" size="2">In Active-Active topology, very much
like in Active/StandBy:</font><br><font face="sans-serif" size="2">* top level of distributors will have
to run VRRP</font><br><font face="sans-serif" size="2">* the distributors will have a Neutron
port made on the VIP network</font><br><font face="sans-serif" size="2">* the distributors' neutron ports on
VIP network will need the same security groups</font><br><font face="sans-serif" size="2">* the amphorae facing the pool member
networks still require</font><br><font face="sans-serif" size="2">    * ports on the pool member
networks</font><br><font face="sans-serif" size="2">    * "peers" HAProxy
configuration for real-time state exchange</font><br><font face="sans-serif" size="2">    * VIP network connections
with the right security groups</font><br><br><font face="sans-serif" size="2">The fact that existing topologies lack
the notion of distributor and inspecting the 30-or-so existing references
to amphorae clusters, swayed me towards the second option.</font><br><br><font face="sans-serif" size="2">The easiest way to make use of existing
code seems to be by splitting load-balancer's amphorae into three overlapping
sets:</font><br><font face="sans-serif" size="2">1. The front-facing - those connected
to the VIP network</font><br><font face="sans-serif" size="2">2. The back-facing - subset of front-facing
amphorae, also connected to the pool members' networks</font><br><font face="sans-serif" size="2">3. The VRRP-running - subset of front-facing
amphorae, making sure the VIP routing remains highly available</font><br><br><font face="sans-serif" size="2">At the code-changes level</font><br><font face="sans-serif" size="2">* the three sets can be simply added
as properties of common.data_model.LoadBalancer</font><br><font face="sans-serif" size="2">* the existing amphorae cluster references
would switch to using one of these properties, for example</font><br><font face="sans-serif" size="2">    * the VRRP sub-flow would
loop over only the VRRP amphorae</font><br><font face="sans-serif" size="2">    * the network driver,
when plugging the VIP, would loop over the front-facing amphorae</font><br><font face="sans-serif" size="2">    * when connecting to the
pool members' networks, network_tasks.CalculateDelta would only loop over
the back-facing amphorae</font><ul><li></li></ul><font face="sans-serif" size="2">In terms of backwards compatibility,
Active-StandBy topology would have the 3 sets equal and contain both of
its amphorae.</font><br><br><font face="sans-serif" size="2">An even more future-proof approach might
be to implement the sets-getters as selector methods, supporting operation
on subsets of each kind of amphorae. For instance when growing/shrinking
back-facing amphorae cluster, only the added/removed ones will need to
be processed.</font><br><br><font face="sans-serif" size="2">Finally (thank you for your patience,
dear reader), my question is: if any of the above makes sense, and to facilitate
the design/code review, what would be the best way to move forward?</font><br><br><font face="sans-serif" size="2">Should I create a mini-blueprint describing
the changes and implement it?</font><br><font face="sans-serif" size="2">Should I just open a bug for it and
supply a fix?</font><br><br><font face="sans-serif" size="2">Thanks,</font><br><font face="sans-serif" size="2">-Sergey.</font><br><br><font face="sans-serif" size="2">[1] </font><a href="https://review.openstack.org/#/c/234639" target="_blank"><font face="sans-serif" size="2">https://review.openstack.org/#/c/234639</font></a><br><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>