Comment 7 for bug 1737567

I would suggest we move this to a ML discussion for everyone to participate.

> Octavia team claims to be a complete replacement to current implementation (including plugin architecture for 3rd party drivers) and sooner or later other vendors will align their drivers with new architecture.

As I mentioned earlier that claim is probably not accurate, when it's about supporting other drivers. IMO, having the api compatibility is not enough. When we're replacing existing heat resources to use Octavia(API) directly we probably have to think about heat lbaas users that don't use octavia. If we provide a new set of resources, then it would probably be ok.

>if Heat will provide a way to choose provider (neutron-lbaas or octavia), then customers will continue to use neutron-lbaas as long as it will be required, with their specific drivers (haproxy, F5, A10, etc), gradually migrating to Octavia when time will come.

Heat already provides that, though it uses neutron lbaas api extenstions and not the octavia API (you've to set the service provider for lbaas config ex. service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default).

We would probably not like to have the logic in the resources to call two different api endpoints based on the 'provider' choice in resource properties and then provide more functionality for the ones using 'octavia'.