Hi Devstack people, I have developed two devstack plugins (for neutron-lbaas and octavia), and I think I am stretching the capabilities of the devstack plugin architecture.
Neutron-lbaas is the load balancer framework for OpenStack. By default it uses a fairly simple haproxy-based agent to actually perform its load balancing tasks. It has a devstack plugin that works well, all I need to do is add the appropriate "enable_plugin" and "enable_service" lines to my local.conf and the plugin code sets up everything nicely. So far so good. Octavia is a reference implementation (currently in stackforge) that will plug in to neutron-lbaas and provide scalable, HA-capable load balancing agents above and beyond the default implementation. I have also written a devstack plugin for Octavia, and it also works reasonably well (I still need to finish up a few loose ends in it). That plugin works well too, by adding the appropriate enable_plugin and enable_service entries to local.conf. So adding this: enable_plugin neutron-lbaas https://git.openstack.org/openstack/neutron-lbaas enable_plugin octavia https://git.openstack.org/stackforge/octavia enable_service q-lbaasv2 enable_service octavia enable_service o-cw enable_service o-hk enable_service o-hw to my local.conf results in a working lbaasv2/Octavia devstack. Now what I would like to do is automate as much of this Octavia-specific information as possible in neutron-lbaas. In principle, if I could specify enable_plugin neutron-lbaas https://git.openstack.org/openstack/neutron-lbaas enable_service q-lbaasv2 enable_service octavia All there remaining knowledge could be written into neutron-lbaas/devstack. So I tried this, and added code to the neutron-lbaas plugin.sh that enabled the Octavia plugin and services. I have tried running "enable_plugin octavia ...." from various points in the neutron_lbaas/devstack/plugin.sh, but it appears that by the time we begin loading plugins it is too late to be doing this. Does this seem like something that could be made to work, or does it sound too fragile, dangerous, etc? I would appreciate any comments. Thanks, Al __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
