> 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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
