Public IP addresses should be assignable by DHCP

[Mark Shuttleworth]

During the installation of Eucalyptus on Ubuntu, one is asked for the IP addresses for publicly visible images. These IP addresses must necessarily be on a subnet that the nodes can see (because they will proxy for the virtual machines), so it should be possible to assign such IP addresses dynamically using DHCP.

When an instance is started, the node controller should ask the DHCP server for a public address for the instance. If it is unable to get one, then the instance should fail to start in the same way that it might fail if there were a shortage of any other kind of resource needed for the instance.

[Mark Shuttleworth (sabdfl)]

There are three related bug reports in this set:

  #454519 - Eucalyptus node controllers should be able to get a DHCP address for public instances
  #454521 - The Ubuntu private cloud installation should skip public IP range question in favour of DHCP
  #454540 - Cloud DHCP requests should include some custom options to help configure IP ranges neatly

[Dustin Kirkland  (kirkland)]

Dan-

Would you mind commenting on this bug? You and I have brainstormed this topic a few times now about the possibilities, but I'm wondering if you could clearly state what (if anything) we should do here in your 1.6.2 stable branch for Lucid. Thanks.

[Daniel Nurmi (nurmi)]

All,

Mark, Dustin and I have discussed some ideas around the notion that having a more 'automated' method of choosing and allocating public IP addresses in the UEC, while keeping Eucalyptus in MANAGED mode in order to support all of the networking features that Eucalyptus provides (Elastic IPs, Security Groups and VLAN isolated VM networks). At the UDS, we decided that these ideas need not be fleshed out for Lucid (Eucalyptus 1.6.2), but they're certainly 'live' in that, at the core, the notion of building into the Ubuntu installation process a model for easily setting up node/VM network address allocation and management would be a powerful sub-system that Eucalyptus could depend upon when it comes to configuring the VM networks. Right now, the Eucalyptus networking modes are highly configurable, but must largely be configured manually as no such sub-system (well defined model for dealing with large collections of dynamic networked machines) is readily available. I believe that building such a system would allow the UEC, as the original report suggests, to present more sophisticated networking modes that are potentially simpler to manage.

[Andy Grimm (agrimm)]

This issue is now being tracked upstream at http://eucalyptus.atlassian.net/browse/EUCA-2664

Please watch that issue for further updates.