On 01/19/11 10:19 PM, Drew Fisher wrote:
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.
Drew, so how would a user specify they specifically don't want swap or
dump zvols created ?
If you don't mark a vdev as swap or dump, the installer will by default
attempt to create swap and dump zvols, so not specifying them does not
mean "do not create".
cheers
Matt
- 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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
