The old email thread has gotten out of control with a slew of sub
conversations started, so I wanted to refresh the discussion in order to
streamline this a bit more. I have also included a rough draft of the
new target DTD schema file for review.
Before I get to the DTD, I wanted to recap some of the outstanding
issues with the original target schema discussion:
- in_zpool / in_vdev attributes for <disk>, <partition>, and <slice>
objects.
Right now, it appears to be that some folks are advocating that in_zpool
or in_vdev can be excluded from a physical element's attributes IF
certain criteria are met. The client will be responsible for
programatically determining what is missing and will populate the DOC
as appropriate so TI can properly execute
- swap / dump on slices and zvols.
Since both swap and dump are considered attributes of a slice or zvol,
they should be simple boolean true|false in the schema. I would also
like to propose removing the concept of a "no_swap" and "no_dump"
attribute. If a user decides not to mark a slice or zvol as swap, the
clients are responsible for determining what is needed and will create
zvols or slices as appropriate. Same goes for zvol dump devices.
- BE elements are absent
I realized that we have a DOC class for BEs but no schema definition for
them. Do we need one? If so, what attributes would be needed? If a
schema definition IS needed, I propose it be a sub-element of <zpool>
(so BEs can be associated with the zpool they are a part of) with an
"action" and "name" attribute. "action" would use the typical
"create"|"destroy" model as zpools currently do:
<!ELEMENT be EMPTY>
<!ATTLIST be name CDATA #REQUIRED>
<!ATTLIST be action (create|destroy) "create">
-----
With this new DTD, I want to bring up a few points that Dermot and I
have been talking about.
1: The old DTD had this comment
<!ELEMENT partition (slice*, size?)>
<!ATTLIST partition action (create|delete|use_existing) "create">
<!--
A partition name is a numeric value, e.g. 1, will be
interpreted as partition 1. If a name is not provided
the user must specify the use_existing action, otherwise
this will be an invalid specification.
-->
I feel strongly about being explicit in these manifests. Forcing users
to not supply a name AND set an action of "use_existing" in order to use
an existing Solaris2 partition on the disk is clunky and messy. This
goes further by using phrases of "use_existing" in <partition> but
"preserve" in <slice>. To me, in English, those two words are synonyms
but to TI/TD they're very different.
If this kind of specification is wanted, i.e. "Use the first Solaris2
partition on this disk", can we have an attribute which is set to "true"
to explicitly tell TI what the user wants to do? Something like:
<!ATTLIST partition use_solaris2 (true|false) "false">
2: I have removed the "force" and "is_root" attributes for <slice>.
The "force" attribute is already implied when the user/client sets an
action of "create". "create" actions destroy the existing object (if
present), before (re)creating it. The "is_root" attribute is redundant
with the "is_root" attribute for zpools. Since we no longer allow UFS
root, there's no need for an is_root attribute on <slice>
3: I need some assistance with commenting. If people have suggestions
for more/better comments, awesome!
Thanks!
-Drew
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
