Comment 6 for bug 1737567

Hi Rabi,

correct me if I'm wrong. As far as I understand, current implementation
of neutron-lbaas provides (a) an API and (b) a way to use different
drivers  as plugins, which implement LBaaS functionality. For external
systems like Heat these "plugins" are hidden, Heat just calls
neutron-lbaas API, knowing nothing about specifics behind the API.

If this is true, then I guess it's not Heat's or whoever else's business
to know about internals. 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.

What makes it easy to migrate is that Octavia is completely separate
standalone controller, which work without any changes to existing
Neutron/LBaaS configuration. Thus, 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.

In terms of HOT, it can be done in the following way (in the same project) :

# this balancer will be created and maintained using neutron-lbaas
implementation,
# calling Neutron API, which configured to use e.g. F5 driver

   balancer:
     type: OS::Neutron::LBaaS::LoadBalancer
     properties:
       name: balancer
       vip_subnet: { get_resource: lan-subnet }

# this balancer will be created and maintained using Octavia implementation,
# calling Octavia API, which configured to use something else

   balancer_new:
     type: OS::Neutron::LBaaS::LoadBalancer
     properties:
       name: n-balancer
*provider: octavia*
       vip_subnet: { get_resource: lan-subnet }

Thank you.

On 12/12/17 6:56 PM, Rabi Mishra wrote:
>> It is only alternate drivers that do not (yet) have a migration path
> as the octavia driver specification is in it's final reviews.
>
> That's exactly the concern I've. Without the similar drivers[1] existing
> like neutron-lbaas (though I've no clue how many of them are being used
> and work) being available, how do we expect heat lbaas users migrate? I
> know it's not an issue for users using the default octavia
> backend/driver with neutron-lbaas. Are we expecting users using things
> like haproxy namespace driver move to use the default implementation
> with octavia?
>
> [1]https://github.com/openstack/neutron-
> lbaas/tree/master/neutron_lbaas/drivers
>

--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison