On Thu, May 10, 2018 at 09:24:24AM -0500, Eric Blake wrote: > On 05/09/2018 11:55 AM, Max Reitz wrote: > > Currently, you can give no encryption format for a qcow file while still > > passing a key-secret. That does not conform to the schema, so this > > patch changes the schema to allow it. > > > > Signed-off-by: Max Reitz <mre...@redhat.com> > > --- > > > ## > > # @BlockdevQcowEncryptionFormat: > > # > > # @aes: AES-CBC with plain64 initialization vectors > > # > > +# @from-image: Determine the encryption format from the image > > +# header. This only allows the use of the > > +# key-secret option. (Since: 2.13) > > +# > > # Since: 2.10 > > ## > > { 'enum': 'BlockdevQcowEncryptionFormat', > > - 'data': [ 'aes' ] } > > + 'data': [ 'aes', 'from-image' ] } > > Overkill. Why not just: > > > ## > > # @BlockdevQcowEncryption: > > @@ -2728,9 +2748,11 @@ > > # Since: 2.10 > > ## > > { 'union': 'BlockdevQcowEncryption', > > - 'base': { 'format': 'BlockdevQcowEncryptionFormat' }, > > + 'base': { '*format': 'BlockdevQcowEncryptionFormat' }, > > 'discriminator': 'format', > > - 'data': { 'aes': 'QCryptoBlockOptionsQCow' } } > > + 'default-variant': 'from-image', > > 'default-variant': 'aes' > > > + 'data': { 'aes': 'QCryptoBlockOptionsQCow', > > and call it good, because there are no other options to pick from, so > 'from-image' would always resolve to 'aes' anyway.
Sounds reasonable because qcowv1 is a dead format we don't intend to add more features to. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|