Re: [libvirt] [PATCH v10 08/19] backup: Parse and output checkpoint XML
On Wed, Jul 24, 2019 at 18:10:47 +0100, Daniel Berrange wrote:
On Wed, Jul 24, 2019 at 06:55:18PM +0200, Peter Krempa wrote:
> On Wed, Jul 24, 2019 at 17:40:51 +0100, Daniel Berrange wrote:
> > On Wed, Jul 24, 2019 at 06:17:24PM +0200, Peter Krempa wrote:
> > > On Wed, Jul 24, 2019 at 17:11:19 +0100, Daniel Berrange wrote:
> > > > On Wed, Jul 24, 2019 at 12:55:58AM -0500, Eric Blake wrote:
>
> [...]
>
> > So overall, either we should turn on validation for all our schemas,
> > or we should require a VALIDATE flag for this new API. Both avoid
> > special case behaviour with the checkpoint APIs.
>
> I definitely do not want to add a new API with no XML validation.
> Whether we'll require bundling a way bigger change which actually may
> break existing APPS using invalid XML is worth together with this, I'm
> not sure.
>
> But adding more legacy cruft seems to be pointless.
I don't think its legacy cruft, when it is our normal practice,
including in the new XML we added just in the release last month.
Validation as standard is only a compelling thing if we're going
todo it universally. When only 1 out of 14 schemas does validation
that doesn't justify the divergance in behaviour IMHO.
Given that we've done VERY badly when adding validation and basically
the only object supporting validation is the domain object (no, not even
the snapshot object supported validation until earlier this month)
having schemas is basically a joke.
If we don't mandate it from the beginning we will never be able to do it
without the risk of breaking users which try to use it wrongly. In my
opinion the only sane approach is to validate always and the only
exception is historical reasons.
Note that requesting dropping mandatory validation will also require
re-introducing the checks that Eric removed as pointles after I asked
twice to add mandatory validation in recent reviews.
At any rate I'm not going to object to dropping mandatory validation,
but it will disappoint me greatly if we do that.
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)