On 3 Dec 2012, at 17:25, Andy Doan andy.doan@linaro.org wrote:

On 12/03/2012 02:37 AM, Dave Pigott wrote:

...

Hi all,

I've been worrying this one all weekend, and woke up this morning at 3:30AM with it all whirling round my head. I think I have an outline of how we're going to manage this, and I would like to get your comments/additions/brickbats before I add it all to the BP:

1. Move over to MAC address based DHCP serving for all

infrastructure Currently the IP address of every device in the infrastructure (cloud nodes, gateway, control etc etc etc) is all done by static assignment. This is bad for a number of reasons. My only concern here (lack of knowledge, rather than well founded fear) is on control itself. Can the DHCP server serve itself an IP address, or is this going to be the one exception?

The DHCP server should have its IP done statically. Also - I think we should use dnsmasqd's dhcp server. This would allow us to manage DHCP from our ssh-gateway (192.168.1.32). However, I'm not sure if that would interfere with our main lab router setup. dnsmasq is cool because it would allow us to define things in one like:

#somewhere in /etc/dnsmasq.conf: dhcp-host=11:22:33:44:55:66,foo,192.168.0.10

OK - So you're suggesting that gateway becomes our dhcp server, right? I was thinking about doing this as well, but I worried that we might be changing too many things at once. However, I'll take a look at dnsmasq as a way forward.

...

2. Reserve 192.168.0.x for the public IP addresses for Cloud

instances and 192.168.1.x for infrastructure. I'm pretty sure I can do this in dhcp.conf. Essentially this is a block list that only serves in those spaces if they are explicitly assigned by MAC addresses. The reason for this is trying to maintain the small existing cloud IP pool, which can't be assigned by dhcp MAC address, because it's managed by the cloud. (See my self argument in point 4.)

I'm not sure how much we have to worry about MACs and if it goes in 192.168.0.x or 192.168.1.x. I *think dnsmasqd will register the ip address with its DNS server when the DHCP server gives out an address. dhcpd has something similar as well (a rough link not verified):

http://www.held.org.il/blog/2011/01/make-dhcp-auto-update-dynamic-dns/

...

3. Go round every infrastructure node, and move it to dhcp served

address

+1

...

4. Drop the cloud pool of IP addresses and create the new range and

restart the instances of the cloud. Alternatively, I could just extend the pool to add the 192.168.0.x range. This is less disruptive because it means the existing instances won't have to be re-started/re-created. I think I +1 this myself. :D

don't know enough about openstack, but sounds sensible.

...

5. Reconfigure dhcp.conf to 192.168.x.x/16

if you do 4, you might want to make sure you exclude 192.168.0.x from the range it assigns. Also - maybe not dhcp.conf :)

Yeah, that was sort of what I was trying to say in point 2.

...

6 Restart DHCP

7. Restart networking on every node

My concern here would be that this will mean some disruption, so I would recommend that we wait until I have the new scheduler backup server in place so that we don't lose any jobs. Once control is back up we should run some test jobs through it just to be on the safe side.

I think we'll have to assume some downtime for this. I'm not sure how having a backup scheduler helps much. These changes are probably going to know everything offline for a period of time, no?

Well, yes, but not much, at least not the way I was thinking of doing it. Essentially, I would make the changes to dhcp, restart dhcp, and then go round each node reconfiguring and restarting networking. That *should* mean very little disruption. If we're going to move to dnsmasq, a similar approach could be taken, in that we simultaneously take down dhcp on control and start dnsmasq on gateway, and then go round restarting everything.

Dave