Open Stack

Hi Greg,

Thanks for the replay, comments inline.

On Wed, Jun 29, 2016 at 9:59 PM, Gregory Haynes <greg at greghaynes.net> wrote:

> On Wed, Jun 29, 2016, at 10:26 AM, Nir Magnezi 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/
> [2]
> 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
> [4]
> 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
>
>
> Thanks,
> Nir
>
>
> I have an alternative suggestion - Maybe we shouldn't be templating out
> the init scripts? What we are effectively doing here is code-gen which
> leads to problems exactly like this, and fixing it with more code gen
> actually makes the problem more difficult.
>
>
The incompatibility to systemd is not due to usage of templates and code
generated files is a nice and useful tool to have.


> I see two fairly straightforward ways to not require this templating:
>
> 1) Use the agent to write out config for the init scripts in to
> /etc/defaults/amphora and have the init scripts consume that file (source
> variables in that file). The init script can then simply be a static file
> which we can even bake in to the image directly.
>

systemd does not use init script, which is why the current code is
incompatible to the distros i mentioned.

>
> 2) Move the code which requires the templating in to another executable
> which the init scripts call out to. e.g. create a amphora-net-init
> executable that runs the same code as in the pre-up section of the upstart
> script. Then there is no need for templating in the init scripts themselves
> (they will all simply call the same executable) and we can also do
> something like bake init scripts directly in to the image.
>

I'm not sure I follow you here. but anyhow we cannot just give up the
templates. how would you handle the parameters currently passed to those
templates? some if them you cannot know in advance and just hardcode.

>
>
> My thinking is that this is only going to get more complex - what are we
> going to do to support the new ubuntu LTS which is systemd based? Or if
> folk show up with other distros that match neither? Its a lot easier to
> decouple the init scripts, which are target specific, from configuration
> specific components and avoid this issues all together.
>

Well, there is a solution that I mentioned in my first mail. both neutron
LBaaS and L3 agents take care of everything needed as far as namespaces ,
nics and processes. that would leave you with a single binary to activate
upon boot.


>
> HTH,
> Greg
>
>
Nir

> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160629/4ee160d9/attachment.html>