On Friday 14 February 2014 16:08:10 Richard W.M. Jones wrote: > On Fri, Feb 14, 2014 at 03:48:34PM +0100, Pino Toscano wrote: > > Hi, > > > > currently virt-builder's index contains only x86_64/amd64 images, so > > asking virt-builder to produce an image always produce a x86_64 > > image, regardless of the host. This also mean that trying to > > produce, say, a new fedora-20 image from an i686 not only would > > produce an unexpected result, but also would prevent to e.g. > > install packages on it. > > > > So virt-builder and its index need to be able to distinguish the > > architecture; choosing the architecture could be a --arch parameter > > for virt-builder, but what about the keys in the index since it > > needs to preserve compatibility with former versions? > > Maybe a solution could be: > > a) adding arch=.. keys in entries > > An observation: All current images are x86-64, so you can assume if > arch= is missing then it means arch=x86_64.
Sounds fair. > > b) rename (or just copy, to avoid breaking older virt-builders) keys > > to> > > $distro-$version-$arch > > > > c) to not break compatibility with user input virt-builder joins > > > > $user_selection + $arch = $user_selection-$arch, and looks in the > > index > > > > d) default $arch to `uname -m/p`, if --arch is not specified > > I think (d) for the following reasons. The list above was not actually a choice of possibilities, but a list of steps to do (IMHO) ;) > We ought to keep: > > virt-builder fedora-20 > > doing the Right Thing, which for the vast majority of users, on x86-64 > host, means they want an x86-64 guest. True, that's what I want to achieve. > > If aarch64 becomes popular, then: > > virt-builder fedora-20 > > should build an aarch64 image. Reason: building an x86-64 image isn't > very useful, because the user wouldn't immediately be able to run it > (or: it would run very very slowly). I'm not sure to understand: are you implying that at some point the default output might be aarch64 (or whatever is the cool arch at that time)? > If people want to do strange stuff, they can use the --arch option. Right. > > Or maybe an even idea could be to give the index file a suffix with > > the architecture name... although that could break users specifying > > an absolute URL for an own index of distros... > > Yup, sounds complicated. > > For 1.26 I would like to change (again) how virt-builder finds its > index. > > The idea is to have /etc/virt-builder.d/... file(s) which each list > an upstream source, so for example: > > /etc/virt-builder.d/fedora.conf > > would contain: > > name=Fedora > source=http://cloud.fedoraproject.org/metadata/index.asc > fingerprint=blah blah > > which would list all Fedora cloud images (assuming we publish ARM > cloud images in future, they would be in the same place). > > As these are configuration files, people could add their own. This sounds like a better idea indeed -- I guess also our current hardcoded remote location would become just a config file shipped by default? (This way distros can even not use it, if they feel to.) > > Also, two side notes related to the "different architecture > > handling" > > issue: > > 1) the naming of architectures can change between distros (e.g. > > amd64 vs> > > x86_64 vs x64, powerpc vs ppc) -- a simple hardcoded mapping in > > virt-builder should do the job, I guess? > > Even better, list what architectures we support in the man page, and > refuse to process index files that contain other names. Hm, not sure about this; while hardcoding does not seem nice (although would be a small mapping), rejecting unknown architectures that might work OOTB might be worse. > > 2) what should be done with commands/operations (e.g. --install) > > that > > > > try to run stuff from the guest, when the host and guest > > architectures are different? Always deny, deny but allow with a > > configure switch, or don't bother and let the user get their > > failure? > > I would say: if host arch != requested guest arch, then deny. It's > the principle of least surprise for users, and people can always use a > firstboot script. > > We can fix it later, as it is theoretically possible to run qemu in > TCG to emulate other architectures, just real slow. Reasonable enough, I'd say. -- Pino Toscano _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs