After today's CUD meeting, I think we're about finished. Here are some
of the notes and changes which came about from the meeting.
On 1/19/11 3:19 PM, Drew Fisher wrote:
- 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
Darren confirmed that AI would be responsible for properly filling out
the DOC with what's missing from the XML, if a proper configured can be
logically determined.
- 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.
The <logical> element now has "noswap" and "nodump" attributes which
default to false (the user wants swap and 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">
A new subelement to <zpool> was added for BEs. The only attribute is
for the name of the BE. There was no need for an action attribute.
-----
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">
This situation has been remedied to change the "use_existing" action
value to "use_existing_solaris2". The "name" attribute is now no longer
required. If a name is specified with "use_existing_solaris2", it will
be ignored by AI.
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>
The force attribute has been restored as a safety net for the users.
"is_root" was confirmed to be removed.
3: I need some assistance with commenting. If people have
suggestions for more/better comments, awesome!
I still need this. If people have suggestions for comments, please let
me know.
Thanks!
-Drew
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
