10:58 a.m.
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/