UEC/Eucalyptus installation test: 20090927.1
mdz at canonical.com
Sun Sep 27 21:52:52 BST 2009
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
- 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-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
> 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
My main unresolved issue is what to do about autoregistration of the nodes.
How do you suggest we handle that?
More information about the ubuntu-devel