http://defect.opensolaris.org/bz/show_bug.cgi?id=7794
http://cr.opensolaris.org/~wmsch/bug-7794/
Conferred with Ethan, Sarah. Agreed to modify the RNG schema ai_manifest.rng to relax the requirement that ignored tags result in
validation failures, particularly since bug 7794 required the user to supply tags that were ignored. This also solves the problem
of dealing with default values appearing only on the AI client side (from the previous code review request).
Resubmitted schema changes once more for review.
Retested schema.
During server-side testing of "installadm add", noticed that when a combined manifest is submitted for validation, the manifest is
validated against both the image-specific schema *and* the schema in /usr/share/auto_install/. If the schema in
/usr/share/auto_install/ were somehow incompatible with a schema stored in an image, this could result in a manifest that could not
pass validation from both schemas and, although perfectly valid for the image, would nonetheless fail validation. Filed bug 15449
to cover this: http://defect.opensolaris.org/bz/show_bug.cgi?id=15449 where the problem is explained in more detail.
William
Previous text--------------------------v
Conferred with Ethan. Concluded that since the RNG schema could handle slice and partition actions (create, delete, preserve)
separately, it would be advantageous to use this to individually screen for correct combinations of elements for an action.
So, for the slice delete case, the 'slice_size' is not needed and not required. Furthermore, specifying slice_size with the delete
action will cause the manifest validation to fail (read further about default values and flag day).
Separated handling of partition actions create, and delete, and delete further
by partition number or starting sector and optional size.
Separated handling of slice actions create, delete, and preserve.
Invalid, meaningless and ignored combinations will now result in validation
failures.
Recall that the AI server isn't processing ai_manifest.defval.xml, and it is not necessary on the AI server - only on the AI client.
Since ai_manifest.defval.xml is processed by one and not the other, the schema must be flexible enough to tolerate the default
values from ai_manifest.defval.xml even in contexts when the tag is illegal (validator cannot tell whether the tag comes from the
defaults file or from the manifest).
For example, if a user is deleting a partition by partition number, the size units are irrelevant, but since megabyte size units are
provided in the defaults file, the default value must not invalidate the manifest on the AI client side on that basis.
So any manifests that would previously be required to provide slice_size on the AI server side (per the bug) will now result in a
validation failure on the AI server side if the manifest value is not the default slice size from ai_manifest.defval.xml (zero).
Recommend a flag day for AI manifests.
For partition_size, partition_type, the same logic applies (see bug). Also, see bug for explanation of why defaults are currently
necessary.
In order to handle the defaults seamlessly, duplicated default values from ai_manifest.defval.xml in ai_manifest.rng. Added
comments to ai_manifest.defval.xml to help to avoid problems.
Also refined slice_size, partition_size elements, changing the type from generic text field to a choice of max_size, MAX_SIZE, or
integer (unsignedLong) only.
Also provided tebibyte (TiB), mebibyte (MiB), gibibyte (GiB) units for sizes, since IEEE and CIPM endorse them. No programming code
changes are necessary (skeptics, see auto_parse.c).
Tested permutations of slice, partition create, delete, preserve with ManifestServ with and without the default values to cover both
AI client and server sides. Tested default.xml. Tested also with JING validator for a 2nd opinion. Checked behavior against AI
client code. (To test with ManifestServ, copy ai_manifest.rng from the webrev, ai_manifest.defval.xml to /tmp and make test custom
/tmp/ai_manifest.xml (not combined manifest) and run "ManifestServ ai_manifest.xml".)
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
