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?
Thanks, doug > On Jun 29, 2016, at 9:26 AM, Nir Magnezi <nmagn...@redhat.com> wrote: > > Hello, > > Lately, I've been working on a fix[1] 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[2] 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[3] 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[4][5] 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[1] 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. > > [1] https://review.openstack.org/#/c/331841/ > <https://review.openstack.org/#/c/331841/> > [2] > 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> > [3] > 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> > [4] > 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> > [5] > 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> > > > Thanks, > Nir > __________________________________________________________________________ > 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
__________________________________________________________________________ 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
