On Fri, Feb 21, 2014 at 05:49:03PM +0100, Pino Toscano wrote:
On Friday 21 February 2014 16:29:23 Richard W.M. Jones wrote:
On Fri, Feb 21, 2014 at 05:17:59PM +0100, Pino Toscano wrote:
Add an architecture field for all the entries in each index, so we know which architecture they are (not used right now, but will be in the future).
The problematic part here is properly marking with the correct architecture: since we only know the current index on libguestfs.org contains x86_64/amd64 images, entries coming from it are marked that way; images in all the other indexes (user-provided ones) are not known to us, so assume they are using the same architecture as virt-builder, hence the special "@same".
A few questions:
- Would it be better/easier if we ditched the whole idea of VIRT_BUILDER_SOURCE being a list? It wasn't really a great idea in hindsight, and we could change it now. It's even possible to not have VIRT_BUILDER_SOURCE at all, everything is configured through the config files.
I was following the "keep compatibility" principle we have so far in libguestfs, so part of the current patch was also in that sense. (Of course the additions of arch to Index_parser would still apply.) Ditching VIRT_BUILDER_SOURCE (and VIRT_BUILDER_FINGERPRINT with it) would be okay for me as well, that could indeed simplify some stuff that I'm currently working on.
I totally agree with the principle, but it's only the API where we absolutely have to keep compatibility. For the tools we have been a bit looser -- for example, infamously rewriting virt-inspector and making it incompatible with earlier versions. In the case of virt-builder, it's a new tool, not widely used, we're not going to change how the majority of the tool works for the majority of users, but if there are things which are obviously broken/confusing (and I think VIRT_BUILDER_SOURCE is one) then we should get rid of those. Another way to look at it is that we don't need to maintain compatibility within development releases. And VIRT_BUILDER_SOURCE using lists was added in the 1.25 series.
- Can we force people to put an arch= field in the index, and if it is missing, assume x86_64?
My idea/implementation so far had arch= in the .conf files: this way, one could in principle keep an existing (optionally signed) index somewhere, adding a .conf file pointing to it, and describing which architecture would have the images in that index. Hmm, now that I think about it, - adding arch= in indexes is backward compatible - an user-supplied index could also have images with different architectures so I will move arch= to indexes.
I think this is better.
Regarding requiring arch= in indexes: this would mean users providing indexes right now would need to update them (and re-sign, in case) to have them working with future virt-builder 1.26.
I suspect this might have to happen anyway, since virt-builder 1.26 is going to be a better and a bit different tool from 1.24. On the other hand, we don't have to rebuild the index for arch= because it can default to x86_64 if not present.
While not a big deal, it would prevent the "ship this .conf file pointing to my index" to work OOTB. Having arch= optional (with implicit "@same") would not be a big deal either, at least IMHO.
Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/