Page MenuHomeClusterLabs Projects

Bring CIB schema and parsing code into closer alignment
Open, LowPublic

Assigned To
None
Authored By
kgaillot
Thu, Mar 28, 4:40 PM
Tags
  • Restricted Project
  • Restricted Project
  • Restricted Project
Referenced Files
None
Subscribers

Description

We rely on RNG schema validation to prevent many configuration mistakes from entering the CIB. However validation can be disabled (validate-with="none"), so the code has to be careful not to assume XML has been validated.

Some of this can be separated into subtasks for convenience.

Normalization

The steps RNG validation follows are not always identical to what Pacemaker's XML parsing ("unpacking") code does. In particular, some RNG definitions (such as <data type="ID"/> and <value>) normalize whitespace by stripping leading and trailing whitespace and replacing any other whitespace sequences with a single space (see xml:id, and search Relax NG Tutorial for normalization). Our code does not do this, so some values can pass validation and be rejected by the unpacking code.

Create a new function (maybe pcmk__normalize_xml_data()) that takes a raw XML attribute value and performs the same normalization that RNG does. Use it wherever we parse the appropriate data types.

Non-empty values

Requiring an attribute via the schema does not require it to be non-empty. There is likely some mismatch between where empty strings are allowed by the schema and rejected by the code. For cases where we do want to require attribute values to be non-empty, update the attributes to use a new schema definition for a non-empty string, for example:

<define name="non-empty-string">
   <data type="string">
      <except><value></value></except>
   </data>
</define>

It will need to be done at a minor or major version bump so we can use an XSL transform to update any nonconforming existing CIBs. What the transform should do is not obvious; simply removing empty attributes could make it fail validation, and not all affected attributes will have defaults that could be substituted.

Consistency

There are likely places in the unpacking code that either assume the data has been validated, or do validation differently from the schema. We should update the code and/or schema to make them accept the same values wherever possible.

Event Timeline

kgaillot created this task.
kgaillot created this object with edit policy "Restricted Project (Project)".
kgaillot moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
<define name="non-empty-string">
   <data type="string">
      <except><value></value></except>
   </data>
</define>

It turns out that due to the same normalization you described, any value that consists of only spaces is rejected. Not just empty strings.

Which might be fine for our purposes, but we need to be aware of it.

In T800#11838, @nrwahl2 wrote:
<define name="non-empty-string">
   <data type="string">
      <except><value></value></except>
   </data>
</define>

It turns out that due to the same normalization you described, any value that consists of only spaces is rejected. Not just empty strings.

Which might be fine for our purposes, but we need to be aware of it.

Yep, maybe better to call it something like whitespace-normalized-string.