UEC/Eucalyptus installation test: 20090927.1

[Matt Zimmerman]

On Sun, Sep 27, 2009 at 01:10:42PM -0700, Daniel Nurmi wrote:
> I'm also going through the 09272009.1 iso install process today on two
> dells.  I'll have a more full (probably a similar to those already reported)
> summary later today PST.
> 
> Regarding the init scripts/ordering; I thought it might help to propose a
> solution to the 'java services have to stop/start to be loaded' issue.
> [...]
> I know this probably seems a bit convoluted, but I think it may help to
> simplify the auto-registration process for now.  In any case, the ordering,
> with auto-reg in the init scripts, should be:

It is a bit convoluted, and I'm well on my way to having a (much simpler)
upstart configuration to accomplish this.  I intend to set up the following
services:

- eucalyptus (cloud, walrus, sc -- the bits which run in-process)
- eucalyptus-cc (the cluster controller)
- eucalyptus-nc (the node)

For the first one, it seems that I need to pass "--disable-foo" if that
component is not installed or should not be started.  There are also
--remote-foo options.  What do those do?

> eucalyptus-cloud
> eucalyptus-walrus (requires that 'cloud' and 'walrus' is up in order to
> complete walrus registration)
> eucalyptus-sc (requires that 'cloud' and 'sc' is up in order to complete sc
> registration)
> eucalyptus-cc (requires that 'cloud' is up in order to complete cluster
> registration, and that 'cc' is up to complete node registration)

I intend to do the registration at package installation time, rather than
when the service is started, so that package dependencies handle the
ordering for us.

The only possible snag I see with this is that we're determining the IP
address to use at registration time, so if the service moves to a different
host, we won't handle that automagically.  I think that's probably OK for
the moment.

My main unresolved issue is what to do about autoregistration of the nodes.
How do you suggest we handle that?

-- 
 - mdz