Implement cluster rediscovery/rejoin for FUEL

[Andrey Korolyov]

We need to be able to attach newly installed Fuel master to the every previous deployment having a free lease of address used by previous master. Ideally we should introduce a kind of agent which can run on top of the most common distros and act like proxy(essentially, it *should* be just a couple of NAT forwarder rules plus some kind of DHCP bcast listener plus small agent with ability to change those rules at once by external command). All this work is necessary to rule existing deployments just from one point and not to install multiple masters when one L2 segment gets exhausted.

[Andrew Woodward (xarses)]

We've been using dhcp-helper and dnsmasq dhcp-relay (newer versions) with success to do DHCP request forwarding in the multi-l3 testing. These are both usable in debian testing, so ubuntu should have similar version that works. I couldn't find a usable version in centos that i could get installed in a timely manner

[Matthew Mosesohn (raytrac3r)]

Rejoin should be a 100% separate feature from multi-l3. Please create a separate bug for dhcp-helper and dhcp-relay.

[Andrew Woodward (xarses)]

It is. Just offering insight to what works for me
On Jan 27, 2014 1:05 AM, "Matthew Mosesohn" <email address hidden> wrote:

> Rejoin should be a 100% separate feature from multi-l3. Please create a
> separate bug for dhcp-helper and dhcp-relay.
>
> --
> You received this bug notification because you are a member of Fuel
> Library Team, which is a bug assignee.
> https://bugs.launchpad.net/bugs/1273103
>
> Title:
> Implement cluster rediscovery/rejoin for FUEL
>
> Status in Fuel: OpenStack installer that works:
> New
>
> Bug description:
> We need to be able to attach newly installed Fuel master to the every
> previous deployment having a free lease of address used by previous
> master. Ideally we should introduce a kind of agent which can run on
> top of the most common distros and act like proxy(essentially, it
> *should* be just a couple of NAT forwarder rules plus some kind of
> DHCP bcast listener plus small agent with ability to change those
> rules at once by external command). All this work is necessary to rule
> existing deployments just from one point and not to install multiple
> masters when one L2 segment gets exhausted.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/fuel/+bug/1273103/+subscriptions
>

[Dmitry Pyzhov (dpyzhov)]

This bug should be converted to blueprint

[Dmitry Pyzhov (dpyzhov)]

After creation of blueprint bug should be moved to "Won't fix"

[Dima Shulyak (dshulyak)]

I have a couple of questions:

1. will we have leased ip addresses with macs from previous deployment? or only cidr for previous master installation?
2. wherehave you installed dhcp-relay in your tests?

in my understanding general flow will be smth like that:

1. cat dnsmasq.leases > fuel rejoin --env 1
    nodes will be created in nailgun, with profiles in cobbler/ironic to ensure that they wont be bootstraped,
   what additional configuration will be required?
  should we bind same ips for provided mac addresses?
2. node will lease new ip and put updated info for /api/nodes
  but how node will connect to master?
   if ip configured in /etc/nailgun-agent/config.yaml wont change
  should we add static route via dhcp?
3. who should do all post-configuration? roles reassignment and maybe smth else?
  it can be done with self discovery but it wont be easy

[Dima Shulyak (dshulyak)]

Created bp, closing this bug.

https://blueprints.launchpad.net/fuel/+spec/rejoin-provisioned-nodes