KarmicCloudInstaller

Summary

Allow Ubuntu Server users to set cloud properties of a machine during installation.

Release Note

Ubuntu Enterprise Cloud configuration is now available from the server CD, with a facility to do automatic node setup.

Rationale

Eucalyptus-based clouds can be set up now on Ubuntu, but the process is a bit involved. We would like to simplify it.

Assumptions

People with complex setups are likely to do a certain amount of by-hand work anyway. The process most in need of simplification is that of installing a relatively simple single-cluster cloud, and focusing on that will give us the biggest bang for our buck.

We explicitly do not assume that the person doing the installation is the network administrator, although it may make some things easier if they are (for example, control of the DHCP server will make it easier for them to set up bulk PXE booting, but we will support CD installations for those who can't do this).

The network is assumed to be trusted to the extent that people are not actively spoofing IP addresses on it. (We do not assume that, for example, nobody is sniffing network traffic.)

Design

General interface

Eucalyptus installation will be accessed using a new entry on the server CD's boot menu. (This will probably be equivalent to something like anna/choose_modules=eucalyptus-udeb, so it will also be accessible by PXE-boot configuration or expert mode.) If this entry is selected, then the installer will send out mDNS queries to discover if there is a running cluster controller on the network. It will then ask whether the user wants to install a cluster or a node, with the default set according to the results of the mDNS queries (if there is a cluster controller, the default is node, otherwise the default is cluster). This question may, as usual, be preseeded.

Installation then proceeds largely as normal, but with the following modifications depending on the selected installation type:

Cluster installation

In cluster mode, the cloud and cluster controller packages will be installed (and WALRUS when 1.6 is available). Behind the scenes, this is a new eucalyptus-simple-cluster task.

When installed, the Eucalyptus binary packages will ask a small number of debconf questions to ensure that the cluster is sanely configured. This should be limited to the essentials, probably just network configuration details. In general, the number of questions asked at installation time still needs to be kept under control, but with this approach there is no additional question load on the basic server installation.

The cluster will automatically be registered with the cloud on installation.

Running cluster controllers will advertise themselves using DNS-SD, using the service name _eucalyptus._tcp with the TXT record type=cluster.

On the "don't repeat yourself" principle, the cluster will provide a preseed file in a well-known location on its web frontend that exports sufficient information about the environment to perform a noninteractive node installation from the point when node mode is selected (with the possible exception of partitioning, which can be edited manually into this file if desired).

Node installation

As above, the first act of the node installation process is to download a preseed file from the discovered cluster, which governs the rest of the installation. Where possible, after installation, Eucalyptus should be up and running with no further configuration required (though of course administrators may want to do more specialised configuration for complex cases).

The node controller package will be installed, along with the Amazon EC2 tool packages and ubuntu-virt-server. Behind the scenes, this is a new eucalyptus-node task.

Since we assume that the network is trusted to the extent that IP addresses are not being actively spoofed, we can bootstrap authentication over the network (especially in netboot cases, where the node has to trust the system offering it its kernel anyway!). The preseed file will include instructions for writing out an .ssh/authorized_keys file including the public half of a key owned by the cluster controller. The cluster can then ssh to the node after installation to generate system keys that authenticate it to the cluster.

Running node controllers will advertise themselves using DNS-SD, using the service name _eucalyptus._tcp with the TXT record type=node. A program will exist on the cluster controller to discover nodes that are not already listed in NODES= using mDNS queries, offer them in bulk to the cluster administrator running that program, and register them in bulk (the rough equivalent of euca_conf -addnode or euca_sync_key) on confirmation; this permits a large batch of nodes to be quickly and easily registered, while permitting simple verification at the level of IP addresses.

Implementation

Cluster installation

The eucalyptus-cc package's init script will register itself with a local cloud controller if all of the following conditions are met:

  • The cluster does not already have keys, indicating an existing registration
  • The cloud binaries exist on the local machine

DNS-SD service

Use of the _eucalyptus._tcp service name requires registration. Dmitrii of the Eucalyptus team has agreed to this.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Discarded ideas

We considered creating a separate UEC (Ubuntu Enterprise Cloud) CD so that we can ask more flexible questions there, but rejected this; we would rather have everything available on the server CD instead of increasing the number of download choices.

We had hoped to be able to send distinct DNS-SD advertisements for unregistered nodes, but it turns out that nodes do not really know reliably whether they are registered. Filtering out nodes already registered to the current cluster in the discovery script is an adequate workaround.

CategorySpec

FoundationsTeam/Specs/KarmicCloudInstaller (last edited 2009-08-14 10:07:28 by 82-69-40-219)