Open Stack

Currently we use /etc/nailgun-agent/nodiscover file to prevent early run of
nailgun-agent (and thus its conflict with cloud-init). We put this file
when we build an image [0] and then we remove this file at the late stage
of system start process when cloud-init is done [1]. Anyway this does not
look good and we'd better replace cloud-init with something else like
puppet and run this configuration during provisioning even before booting
into target operating system. Besides, running Puppet during provisioning
to do initial configuration will allow us to configure other services/files
in a consistent way. So, I prefer option #3. Let's write a spec for this.

[0]
https://github.com/openstack/fuel-agent/blob/master/fuel_agent/manager.py#L961
[1]
https://github.com/openstack/fuel-agent/blob/master/cloud-init-templates/boothook_fuel_9.0_ubuntu.jinja2#L91



Vladimir Kozhukalov

On Fri, Aug 12, 2016 at 8:29 AM, Georgy Kibardin <gkibardin at mirantis.com>
wrote:

> Guys,
>
> Currently, at the time of the first boot Mcollective on slaves is
> configured by Cloud-init (host, port etc.) and by Nailgun agent when node
> identity is written. This happens in any order and already caused several
> problem which were fixed in bounds of https://bugs.launchpad.net/
> fuel/+bug/1455489. The last fix relies on hostname to figure that the
> provisioning is over and prevent Nailgun agent from messing with
> Mcollective. This solution is quite hacky and, I think, we need to come up
> with a better fix. So, the options are:
>
> 1. Do nothing
>   + No effort, no regression
>   - Existing solution is fragile and not simple enough to be sure that
> there are obviously no more bugs.
>   - Cloud-init does things on early boot stages which is a bit hard to
> debug.
>
> 2. "Manual" Mcollective configuration, triggered by Nailgun agent.
>   + Quite simple
>   - Not "cross-distro"
>   - Not consistent with the remaining configuration tasks (rewriting them
> worsens the problem above)
>
> 3. Use Puppet to configure Mcollective. (copy necessary input data into
> the chroot env and run puppet inside it)
>   + Using puppet is consistent with the way Fuel configures things
>   - It is not consistent with remaining configuration tasks, which is done
> via Cloud-init and moving them to Puppet takes some time.
>
> 4. Some other tool?
>
> New options, cons and pros are very welcome!
>
> Best,
> Georgy
>
> __________________________________________________________________________
> 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/20160816/f4cb113b/attachment.html>