Open Stack

 > Hi Sergey,  Welcome to working on Octavia!

Thanks, glad to be joining! :^)
Please read a further explanation of my proposal down below.

 > I'm not sure I fully understand your proposals, but I can give my
 > thoughts/opinion on the challenge for Active/Active.
 >
 > In general I agree with Stephen.
 >
 > The intention of using TaskFlow is to facilitate code reuse across
 > similar but different code flows.
 >
 > For an Active/Active provisioning request I envision it as a new flow
 > that is loaded as opposed to the current standalone and Active/Standby
 > flow.  I would expect it would include many existing tasks (example,
 > plug_network) that may be required for the requested action.  This new
 > flow will likely include a number of concurrent sub-flows using these
 > existing tasks.
 >
 > I do expect that the "distributor" will need to be a new "element".
 > Because the various stakeholders are considering implementing this
 > function in different ways, we agreed that an API and driver would be
 > developed for interactions with the distributor.  This should also
 > take into account that there may be some deployments where
 > distributors are not shared.

I too expect a new model element to represent distributor, including its 
own API.

Virtual distributor does seem to share some behavior with amphora.

For instance, consider the "create load balancer" flow:
  * get_create_load_balancer_flow gets-or-creates a few nova instances, 
waits till they boot and marks them in DB
  * get_new_LB_networking_subflow allocates and plugs VIP on both 
Neutron and amphorae sides; security group handling included
  * when needed, get_vrrp_subflow creates a VRRP group on the LB and 
configures/starts it on amphorae
  * amphorae get connected to the members' networks
  * if listeners are defined on LB
    * haproxy services get configured and started including "peers" 
configuration
    * VIP network connections get Neutron security groups blessing

All parts of this flow seem to apply to the active-active topology too.

My intent is to try and reuse most of this rather involved flow by 
treating distributors as both a subset of "front-facing" amphorae and 
the "vrrp running" amphorae, while the original amphorae would be 
treated as both "back-facing" (for haproxy configuration, members' 
networks plugging, etc.) and "front-facing" (for VIP network 
plugging/processing).

If this leads to changing a lot of existing code or changing it 
non-trivially, I'll drop this idea, as my hope is to have less code 
review, not more.

 > I still need to review the latest version of the Act/Act spec to
 > understand where that was left after my first round of comments and
 > our mid-cycle discussions.
 >
 > Michael

Thanks,
-Sergey.