On Mon, May 21, 2018 at 07:44:40PM +0100, Daniel P. Berrangé wrote: > On Mon, May 21, 2018 at 03:29:28PM -0300, Eduardo Habkost wrote: > > On Sat, May 19, 2018 at 08:05:06AM +0200, Markus Armbruster wrote: > > > Eduardo Habkost <ehabk...@redhat.com> writes: > > > > > > [...] > > > > About being more expressive than just a single list of key,value > > > > pairs, I don't see any evidence of that being necessary for the > > > > problems we're trying to address. > > > > > > Short history of a configuration format you might have encountered: > > [snip] > > > > How confident are we a single list of (key, value) is really all we're > > > going to need? > > > > > > Even if we think it is, would it be possible to provide for a future > > > extension to trees at next to no cost? > > > > I'm confident that a list of key,values is all we need for the > > current problem. > > I'm not convinced. A disk image may work with Q35 or i440fx, or > work with any of virtio, ide or sata disk. So that already means > values have to be arrays, not scalars. You could do that with a > simple key,value list, but only by defining a mapping of arrays > into a flattened form. eg do we allow repeated keys, or do we > allow array indexes on keys.
No problem, we can support trees if it's necessary. > > The point here is to allow users to simply copy an existing disk > > image, and it will contain enough hints for a cloud stack to > > choose reasonable defaults for machine-type and disk type > > automatically. Requiring the user to perform a separate step to > > encapsulate the disk image in another file format defeats the > > whole purpose of the proposal. > > It doesn't have to mean more work for the user - the application > that is used to create the image can do that on their behalf. > oVirt for example can import/export OVA files, containing OVF > metadata. I could imagine virt-manager, and other tools adding > export ability without much trouble if this was deemed a desirable > thing. Bundling gives ability to have multiple disk images in one > archive, which is something OVF does. I have the impression that "the application that is used to create the image" is a very large set. It can be virt-manager, virt-install, virt-manager, or even QEMU itself. Today people can simply create a VM on virt-manager, or run QEMU manually, and upload the qcow2 image directly from its original location (they don't need to copy/export it). Don't we want the same procedure to keep working instead of requiring users to use another tool? -- Eduardo