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

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3786 bytes --]

On ven, 2013-12-13 at 16:44 +0000, Ian Jackson wrote:
> Dario Faggioli writes ("[OSSTest PATCH [RFC] 2/4] ts-fedora-install: added for installing fedora guests"):
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> ...
> > +    # 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 ?
> 
I'm not sure what "osstest images directory" is; I'll check. What I care
is for these jobs to keep being usable in standalone mode, if going that
way is not a problem wrt that, I think I can.

Also, this are not .iso or disk images, they're just a kernel and a
ramdisk, but I guess that does not make much of a difference.

I'll check what RH testcases do, as well as what Roger did for FreeBSD,
as I remember seeing something about downloading images and storing them
in the proper place in those patches too.

> 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 ?
> 
Ok.

> > +	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 ~.
> 
And that would be for the sake of keeping the installer's kernel and
initrd and have them archived together with the logs?

I was under the impression that this won't be much useful, but I guess
it would, in case something goes wrong during installation and one wants
to debug... Is that the reason?

> > +    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.
> 
Ok, I'll see if I can factor a bit more (valid also for the other
comments that were expressed below this point for this patch).

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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