<font size=2 face="sans-serif">I'm working with the IBM team implementing
the Active-Active N+1 topology [1].</font><br><br><font size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">--TL;DR--</font><br><br><font size=2 face="sans-serif">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 size=2 face="sans-serif">--The details--</font><br><br><font size=2 face="sans-serif">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 size=2 face="sans-serif">Currently I see two options:</font><br><br><font size=2 face="sans-serif">   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 size=2 face="sans-serif">   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 size=2 face="sans-serif">In Active-Active topology, very much
like in Active/StandBy:</font><br><font size=2 face="sans-serif">* top level of distributors will have
to run VRRP</font><br><font size=2 face="sans-serif">* the distributors will have a Neutron
port made on the VIP network</font><br><font size=2 face="sans-serif">* the distributors' neutron ports on
VIP network will need the same security groups</font><br><font size=2 face="sans-serif">* the amphorae facing the pool member
networks still require</font><br><font size=2 face="sans-serif">    * ports on the pool member
networks</font><br><font size=2 face="sans-serif">    * "peers" HAProxy
configuration for real-time state exchange</font><br><font size=2 face="sans-serif">    * VIP network connections
with the right security groups</font><br><br><font size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">1. The front-facing - those connected
to the VIP network</font><br><font size=2 face="sans-serif">2. The back-facing - subset of front-facing
amphorae, also connected to the pool members' networks</font><br><font size=2 face="sans-serif">3. The VRRP-running - subset of front-facing
amphorae, making sure the VIP routing remains highly available</font><br><br><font size=2 face="sans-serif">At the code-changes level</font><br><font size=2 face="sans-serif">* the three sets can be simply added
as properties of common.data_model.LoadBalancer</font><br><font size=2 face="sans-serif">* the existing amphorae cluster references
would switch to using one of these properties, for example</font><br><font size=2 face="sans-serif">    * the VRRP sub-flow would
loop over only the VRRP amphorae</font><br><font size=2 face="sans-serif">    * the network driver,
when plugging the VIP, would loop over the front-facing amphorae</font><br><font size=2 face="sans-serif">    * when connecting to the
pool members' networks, network_tasks.CalculateDelta would only loop over
the back-facing amphorae</font><ul><li></ul><font size=2 face="sans-serif">In terms of backwards compatibility,
Active-StandBy topology would have the 3 sets equal and contain both of
its amphorae.</font><br><br><font size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">Should I create a mini-blueprint describing
the changes and implement it?</font><br><font size=2 face="sans-serif">Should I just open a bug for it and
supply a fix?</font><br><br><font size=2 face="sans-serif">Thanks,</font><br><font size=2 face="sans-serif">-Sergey.</font><br><br><font size=2 face="sans-serif">[1] </font><a href=https://review.openstack.org/#/c/234639><font size=2 face="sans-serif">https://review.openstack.org/#/c/234639</font></a><BR>