UEC/Eucalyptus installation test: 20090927.1

[Daniel Nurmi]

On Sun, Sep 27, 2009 at 1:52 PM, Matt Zimmerman <mdz at canonical.com> wrote:

> 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.
>
>
Another snag may be that, unless my understanding is incorrect, the cloud
service is not running at installation time, which will prevent the ability
to register.  Is this still true?


> 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?
>
>
The thing to consider here is timing; for sure, in order for an individual
node registration to succeed, the following must be true:

1.) CC is up and running
2.) NC is up and running
3.) ssh public key of CC:~eucalyptus is installed in authorized_keys on
NC:~eucalyptus

when these conditions are met, then running 'euca_conf --no-rsync
--register-nodes <ip>' should succeed.

That being said, I believe the opinion was that the node registration
process could be kicked off by the admin manually, after the front-end has
been in installed, whenever new nodes have come up.  Registration of nodes
is idempotent, so the process could also be put into the CC init script if
partial automation is desired (CC would register whatever any nodes that are
running every time it starts).


-Dan

> --
>  - mdz
>



-- 
Daniel Nurmi
Co-Founder, Engineer
Eucalyptus Systems, Inc.

130 Castilian Dr. | Goleta, CA | 93117
Office: 805-845-8000 | Cell: 805-259-5269
Email: nurmi at eucalyptus.com
www.eucalyptus.com

________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090927/c997af71/attachment-0002.htm