Re: [Xen-devel] [OSSTest PATCH [RFC] 2/4] ts-fedora-install: added for installing fedora guests

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Dario Faggioli writes ("[OSSTest PATCH [RFC] 2/4] ts-fedora-install: added for 
installing fedora guests"):
> Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
...
> +    # Paths within a mirror are different depending on whether we are dealing
> +    # with an actual released distro, one in development, or one being tested
> +    # right before a release (Test Composes or RC-s, see
> +    # https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test).
> +    my $releaseurl= 
> "http://$c{FedoraMirrorHost}/$c{FedoraMirrorSubpath}/releases/$fedora_release/Fedora/$arch/os";;
> +    my $develurl = 
> "http://$c{FedoraMirrorHost}/$c{FedoraMirrorSubpath}/development/$fedora_release/$arch/os";;
> +    my $stageurl = 
> "http://dl.fedoraproject.org/pub/alt/stage/$fedora_release/Fedora/$arch/os";;

I'm not sure I like this kind of downloading of test OS code for each
platform.  This is sustainable for one distro (the Debian which most of
our tests use), but if we need to maintain a local mirror for every
test target OS the infrastructure is going to be a royal pain to
maintain.  And we'll be exposed to a much wider range of failures
which will cause spurious test failures.  This surely applies to
release images - couldn't they just be stored in the osstest images
directory ?

OTOH if we are having a Fedora-specific flight for checking RCs, I
think downloading things directly from the Fedora upstream is fine.

> +    my $fi_url = "$repourl/images/pxeboot";
> +    target_cmd($ho, <<END, 2000);

target_cmd doesn't do set -e.  Perhaps it should ?

> +     wget --quiet -O /tmp/fi_kernel $fi_url/vmlinuz$pae
> +     wget --quiet -O /tmp/fi_initrd $fi_url/initrd$pae.img

You shouldn't use /tmp really like this.  Please use a
flight-and-job-specific directory in ~.

> +    my $install_cfg= <<END;
> +name = '$gho->{Name}'
> +# Fedora installer requires no less than 1GB RAM
> +memory = 1024
> +#
> +kernel      = "/tmp/fi_kernel"
> +ramdisk     = "/tmp/fi_initrd"
> +extra       = "repo=$repourl console=hvc0 text serial ks=$ks_url"
> +#
> +vif = [ 'mac=$gho->{Ether}' ]
> +#
> +on_poweroff = 'destroy'
> +# the below is needed for allowing guest_await_reboot() to trigger
> +on_reboot   = 'preserve'
> +on_crash    = 'preserve'

Perhaps there is other similar code that this could be combined with.

> +    my $authkeys= authorized_keys();
> +    my $rootdev = target_guest_lv_name($ho, $gho->{Name}) . "--disk2";
> +    target_cmd_root($ho, <<END);
> +        set -ex
> +        kpartx -a $gho->{Lvdev}
> +        mount $rootdev /mnt
> +        mkdir -p /mnt/root/.ssh /mnt/etc/ssh
> +        cat <<'ENDKEYS' > /mnt/root/.ssh/authorized_keys
> +$authkeys
> +ENDKEYS
> +        cp -a /etc/ssh/ssh_host_*key* /mnt/etc/ssh/
> +        mkdir -p /mnt/home/osstest/.ssh
> +        cp /mnt/root/.ssh/authorized_keys /mnt/home/osstest/.ssh
> +        chroot /mnt chown -R osstest.osstest /home/osstest/.ssh
> +        umount /mnt
> +        kpartx -d $gho->{Lvdev}
> +END

This messing with authorized_keys is very similar to code that appears
in Debian.pm, TestSupport.pm and/or ts-debian-fixup.

> +    my $runtime_cfg= <<END;

This is duplicating some of the logic in ts-redhat-install ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel