<font size=2 face="sans-serif">Stephen, Michael, thank you for having
a look.</font><br><br><font size=2 face="sans-serif">I'll respond to every issue you mentioned
when I get to work on Sunday.</font><br><br><font size=2 face="sans-serif">Until then, in case you don't mind inspecting
a small diff, just to clarify my point, please have a look at a rather
straightforward change, which</font><br><font size=2 face="sans-serif">1. exemplifies pretty much all I'm currently
proposing (just splitting amphorae into semantic sub-clusters to facilitate
code-reuse)</font><br><font size=2 face="sans-serif">2. I'm hoping should provide everything
needed (and thus frictionless review) for the virtual non-shared distributor
of active active topology</font><br><font size=2 face="sans-serif">3. is quite transparent for other topologies,
including future active-active shared, hardware, what-have-you, just because
it's fully compliant with existing code</font><br><br><a href=https://github.com/sgserg/octavia/commit/030e786ce4966bbf24e73c00364f167596aef004><font size=2 color=blue face="sans-serif">https://github.com/sgserg/octavia/commit/030e786ce4966bbf24e73c00364f167596aef004</font></a><br><br><font size=2 face="sans-serif">Needless to say, I wouldn't expect anything
like this to be merged until we see an end-to-end working (virtual-private-d'tor)
AA N+1 create-lb proof of concept (not destroying existing topologies).</font><br><br><font size=2 face="sans-serif">I'm not married to this idea, it's just
something I came up with having spent a few weeks in front of the code,
trying to imagine how the simplest active-active use-case would go around
performing the same tasks (vrrp, vip plugging, etc.).</font><br><br><font size=2 face="sans-serif">-Sergey.</font><BR>