From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [OSSTest PATCH [RFC] 2/4] ts-fedora-install: added for installing fedora guests Date: Fri, 13 Dec 2013 19:12:54 +0100 Message-ID: <1386958374.3980.42.camel@Solace> References: <20131212221933.11164.46804.stgit@Solace> <20131212225332.11164.99188.stgit@Solace> <21163.14674.870408.97251@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5201340115723564207==" Return-path: In-Reply-To: <21163.14674.870408.97251@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============5201340115723564207== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OhNyutHy0HJLmVgIkbay" --=-OhNyutHy0HJLmVgIkbay Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On ven, 2013-12-13 at 16:44 +0000, Ian Jackson wrote: > Dario Faggioli writes ("[OSSTest PATCH [RFC] 2/4] ts-fedora-install: adde= d for installing fedora guests"): > > Signed-off-by: Dario Faggioli > ... > > + # 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=3D "http://$c{FedoraMirrorHost}/$c{FedoraMirrorSubp= ath}/releases/$fedora_release/Fedora/$arch/os"; > > + my $develurl =3D "http://$c{FedoraMirrorHost}/$c{FedoraMirrorSubpa= th}/development/$fedora_release/$arch/os"; > > + my $stageurl =3D "http://dl.fedoraproject.org/pub/alt/stage/$fedor= a_release/Fedora/$arch/os"; >=20 > 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 ? >=20 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. >=20 > > + my $fi_url =3D "$repourl/images/pxeboot"; > > + target_cmd($ho, <=20 > target_cmd doesn't do set -e. Perhaps it should ? >=20 Ok. > > + wget --quiet -O /tmp/fi_kernel $fi_url/vmlinuz$pae > > + wget --quiet -O /tmp/fi_initrd $fi_url/initrd$pae.img >=20 > You shouldn't use /tmp really like this. Please use a > flight-and-job-specific directory in ~. >=20 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=3D < > +name =3D '$gho->{Name}' > > +# Fedora installer requires no less than 1GB RAM > > +memory =3D 1024 > > +# > > +kernel =3D "/tmp/fi_kernel" > > +ramdisk =3D "/tmp/fi_initrd" > > +extra =3D "repo=3D$repourl console=3Dhvc0 text serial ks=3D$ks_u= rl" > > +# > > +vif =3D [ 'mac=3D$gho->{Ether}' ] > > +# > > +on_poweroff =3D 'destroy' > > +# the below is needed for allowing guest_await_reboot() to trigger > > +on_reboot =3D 'preserve' > > +on_crash =3D 'preserve' >=20 > Perhaps there is other similar code that this could be combined with. >=20 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 --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-OhNyutHy0HJLmVgIkbay Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iEYEABECAAYFAlKrTiYACgkQk4XaBE3IOsSWcACgnS8B3XYMnkMMTVv0LtwkR5iK 6RMAn0a/oCEpVx3VZ4Y+khGzzdbmA9VO =WTOt -----END PGP SIGNATURE----- --=-OhNyutHy0HJLmVgIkbay-- --===============5201340115723564207== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5201340115723564207==--