UEC installer status

[Matt Zimmerman]

Bcc: 
Subject: Re: UEC installer status
Reply-To: 

(resending to ubuntu-devel)

On Thu, Sep 24, 2009 at 10:00:55PM +0100, Colin Watson wrote:
> Quick notes from the UEC installer testing I did this evening:
> 
>   * I ran into yet another debootstrap bug (sigh), quickly fixed in
>     1.0.19.
>
>   * It would be nice if the cluster told you the admin URL on boot so
>     that you don't have to look it up in the documentation.

Please file this as a bug and tag 'eucalyptus'.

>   * The first time I tried the node installation, it failed to download
>     the preseed file from the cluster because it had got the IPv6
>     address and I don't have IPv6 routing set up between my VMs. The
>     failure was rather messy and didn't let me continue anyway (fixed in
>     bzr), but I wonder if we should fix euca_find_cluster to actively
>     prefer IPv4 addresses.

Please file a bug for this one as well, tag eucalyptus.

>   * The answer to the encrypt-home-directory question wasn't correctly
>     carried over from cluster to node installation (fixed in bzr).

Is this important for beta?

>   * dhcpd failed to start when the installed node booted. Syslog says
>     that it's configured to listen on virbr0. Shouldn't this be br0
>     instead? I'm not entirely sure where it's getting this from - I
>     think it must be
>     /etc/libvirt/qemu/networks/{,autostart/}defaults.xml, as that's the
>     only mention of virbr in /etc. At any rate, I think it's also
>     generally lacking in configuration. Is it correct for us to be
>     installing a DHCP server on each node?

I don't know the answer to this.  Dan?

>   * euca_conf --discover-nodes doesn't do word-splitting correctly on
>     the list of discovered nodes (fixed in bzr).
> 
>   * euca_conf --discover-nodes incorrectly offers the cluster as well as
>     nodes (fixed in bzr).
> 
>   * euca_conf --discover-nodes prints:
> 
>       warning: //var/lib/eucalyptus/keys//node-cert.pem doesn't exists!
>       warning: //var/lib/eucalyptus/keys//cluster-cert.pem doesn't exists!
>       warning: //var/lib/eucalyptus/keys//node-pk.pem doesn't exists!
>       warning: //var/lib/eucalyptus/keys//cluster-pk.pem doesn't exists!
> 
>       Trying rsync to sync keys with "172.16.153.34"...The authenticity of host '172.16.153.34 (172.16.153.34) can't be established.
>       [usual ssh stuff when you don't have the host key]
> 
>     (Typo: "doesn't exists" -> "doesn't exist" in four places in
>     euca_conf, only one of which is responsible for this.)
> 
>     I assume that this is because cluster auto-registration isn't
>     happening (bug 434590).

Shoudl 434590 be fixed for beta?

>     We probably ought to use 'ssh -oStrictHostKeyChecking=no' in the
>     --discover-nodes case (not in the general case, I think; it's not
>     perfect to turn off host key checking in general, but it's
>     definitely not good to turn it off when you might have to use
>     password authentication). This is a bit fiddly so I didn't do it on
>     the spot.
> 
>   * I therefore went to register the local cloud components using
>     Thierry's instructions in bug 434590. I note that we really ought to
>     add the cloud machine's own ssh key to /etc/ssh/known_hosts or
>     something so that you don't have to use --local-sync.

Bug please.

>   * Now euca_conf --discover-nodes is happier, but it first tries to
>     rsync keys to root on the nodes, rather than to the eucalyptus user.
>     Is there any particular reason for this, or can we change this to
>     rsync to ${EUCA_USER}@${REMOTE}:${DESTDIR}/ instead? I'm not
>     comfortable with installing anything in root's authorized_keys, even
>     if it is only a computing node.

Sounds reasonable to me.

>   * At this point I *think* I have everything registered and working. I
>     can't find any way to actually confirm that all the components are
>     registered properly, though? I can't actually upload VM images to it
>     since I'm testing this in VMs and nested virtualisation is probably
>     not going to work very well.
> 
>     As such, I think this is as far as I can go with testing for now,
>     although this seemed fairly worthwhile since I found several
>     unreported bugs.

Which of the above items need to be fixed in the archive before it is worth
spinning and testing a new ISO build?

-- 
 - mdz