[openstack-dev] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors
dougwig at parksidesoftware.com
Wed Jun 29 16:10:43 UTC 2016
Interesting discussion, but the first question I’d ask is ‘why’ ?
Unlike openstack server software, the amphora are meant to be black box appliance images, so why do we want to run different distros on them? Is there a deployment scenario you’re concerned with, or other use case?
> On Jun 29, 2016, at 9:26 AM, Nir Magnezi <nmagnezi at redhat.com> wrote:
> Lately, I've been working on a fix for the amhpora-agent, which currently only support Debian based flavors such as Ubuntu.
> The main Issues here:
> 1. NIC hot plugs: Ubuntu's ethX.cfg files looks different from ifcfg-ethX files which are accepted in Linux flavors such a RHEL, CentOS and Fedora, read more in the fix commit msg.
> 2. The usage of Flavor specific features such as 'upstart'.
> I would like to have a discussion about the second bullet mentioned above.
> Due to the fact that in Octavia the loadbalancer runs inside of an instance (Amphora), There are few actions that need to take place in the Amphora instance boot process:
> a. namespace and NIC created.
> b. amphora agent starts
> c. haproxy (and possibly keepalived) start
> The Amphora-agent leverages the capabilities of 'upstart' to make that happen, which is a bit problematic if we wish it to work on other flavors.
> The default cloud image for Amphora today is Ubuntu, yet there are few more options such as CentOS and Fedora.
> Unlike the Ubuntu base image, which uses 'sysvinit', The latter two flavors use 'systemd'.
> This creates incompatibility with the jinja2 templates used by the agent.
> The way I see it there are two possible solutions for this:
> 1. Include a systemd equivalent in the fix that will essentially duplicate the functionality mentioned above and work in the other flavors.
> 2. Have a the amphora agent be the only binary that needs to be configured to start upon boot, and that agent will take care of plugging namespaces and NICs and also spawning needs processes. This is how it is done in lbaas and l3 agents.
> While the latter solution looks like a more "clean" design, the trade-off here is a bigger change to the amphora agent.
>  https://review.openstack.org/#/c/331841/ <https://review.openstack.org/#/c/331841/>
>  https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L128 <https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L128>
>  https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L27 <https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L27>
>  https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/upstart.conf.j2 <https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/upstart.conf.j2>
>  https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/sysvinit.conf.j2 <https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/sysvinit.conf.j2>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev