[PATCH v2 4/8] Cleanup diskSourceNetwork and diskSourceFile schema

[Peter Krempa]

On Tue, Apr 26, 2022 at 16:15:06 +0530, Rohit Kumar wrote:
> 
> On 21/04/22 8:29 pm, Peter Krempa wrote:
> > On Fri, Apr 08, 2022 at 10:48:47 -0700, Rohit Kumar wrote:
> > > Moving diskSourceNetwork and diskSourceFile's Source definition
> > > under 'define' element, so that it will be easier to reuse it
> > > at multiple places.
> > > 
> > > Signed-off-by: Prerna Saxena <prerna.saxena at nutanix.com>
> > > Signed-off-by: Florian Schmidt <flosch at nutanix.com>
> > > Signed-off-by: Rohit Kumar <rohit.kumar3 at nutanix.com>
> > > ---
> > >   src/conf/schemas/domaincommon.rng | 60 +++++++++++++++++--------------
> > >   1 file changed, 34 insertions(+), 26 deletions(-)
> > > 
> > > diff --git a/src/conf/schemas/domaincommon.rng b/src/conf/schemas/domaincommon.rng
> > > index c0c14fe558..58eb9670d4 100644
> > > --- a/src/conf/schemas/domaincommon.rng
> > > +++ b/src/conf/schemas/domaincommon.rng

[...]

> > > +          </attribute>
> > > +        </optional>
> > > +        <ref name="diskSourceCommon"/>
> > > +        <optional>
> > > +          <ref name="storageStartupPolicy"/>
> > > +        </optional>
> > Startup policy definitely makes no sense for the nvram.
> Should this be removed after parsing as well, If we are not mentioning these
> in schema defination ?
> Should we report error if user provides startup policy, encryption or
> security labels  ?
> > 
> > > +        <optional>
> > > +          <ref name="encryption"/>
> > Due to the way how the 'pflash1' storage source is initialized
> > encryption is NOT yet supported.
> > 
> > You'll also need to reject it after parsing.
> Right. I did not understand what does rejecting it meaning here. Is it
> reporting error like encryption is not supported ? or is it just
> deallocating 'Auth' field from virStorageSource after parsing ?

Reporting an error when it is passed by the user.

The proper place to do this would be in the appropriate function in
qemu/qemu_validate.c

> > 
> > > +        </optional>
> > > +        <zeroOrMore>
> > > +          <ref name="devSeclabel"/>
> > I don't think the code is wired up to actually handle seclabels even if
> > the parser parses them.
> Right. I will remove it from schema defination. Thanks!

Also since the parser helper will parse them you'll need to reject any
seclabels if provided by the user.

Libvirt's schema is not mandatorily checked against the XML thus the
parser can get non-schema-conforming XML. Thus this has to be handled
explicitly