Sarah,
In target.dtd (6.3), none of the elements <swap> <dump> or <iscsi>
are defined as sub-elements of any other element. Can you
confirm where in the tree you plan to put these?
Also, next time you push to caiman-docs, can you also commit all the
individual files (ai.dtd, execution.dtd and the sample manifests)?
Thanks,
- Dermot
On 06/23/10 00:32, Sarah Jelinek wrote:
Hi Dave,
Sarah,
Continuing my piecemeal review. Today, it's 6.3 Target Schema.
I see you got a lot of comments here about partition/vdev/slice stuff
so I've confined it to some other items.
- Is the is_root attribute really right at the target level? It
seems to me like it's a pool attribute. What happens if I have
multiple targets with this set to true?
Yes, it should be a zpool attribute. I will move this.
- Similar to discussion on Software schema, will you be removing the
"unknown" from the disk name attribute?
Yes, I removed this.
- Isn't the is_logical attribute of a partition implied by the name
(and therefore redundant)?
Yes, it is in my schema. But, that is an interesting question. Right
now I have the partition name as required, but if the user doesn't
want to specify the name but wants to give other data about the
partition that allows us to create it, either physical or logical, is
this something we want to enable? In AI today we don't require the
name. We can create it based on other attributes.
- Is it really a good idea to default the size_units to gb? In 10
years, that's going to seem so 00's. What about just dispensing with
the separate units attribute and requiring units suffixed to the size
(i.e. 100gb, 2secs, 2tb)? I feel like that might be more comfortable
to the average admin and hold up better over the long term.
Fair point. I will change this to your suggestion.
- Should there be a comment about the format options are expected to be?
The idea is that options shouldn't be set in terms of format. Zpool,
zvol, dataset have a form to the options that are possible, so I could
give a comment about these specifically. But, if the format of the
options changes I want the schema to handle this.
Several things about swap/dump:
- What scope are swap and dump specified under? I don't see any
other reference to them in the schema, so they seem somewhat
disconnected. Maybe that's OK, but the examples didn't show them so
I'm kind of wondering.
They are a target, not a target_device. So, it would look like:
<target>
<swap>
<zvol action="create" name="rpool/swap>
<size>1024mb</size>
</zvol>
</swap>
</target>
The scope of a swap or dump device is global and not specific to a pool.
- Should we have an "automatic" specification for swap/dump (in other
words, use the algorithm that the interactive installers use), or is
its absence expected to imply automatic behavior in AI? If that's
the case, do we need a "none" to disable their creation?
No, we don't need a none. Since this is a subelement of the target
element and not required, their absence means we default to
calculating it. If specified we use the values specified.
- The comment about swap and dump should be more specific that merely
specifying size would create them with a specific name on the (first?
per comment above) root pool.
Yes, I agree. It should be more specific. What I am saying is that if
a size is given, we will create swap in the root pool, otherwise if
zvol data is given we will use that zvol.
- I assume we can specify multiple swap devices?
No, not as I currently have it specified. I can modify this to allow
for multiple swap devices.
- Doesn't seem to be any way to specify swapping on a slice. We do
this in some cases currently, though, and right now the pathological
behavior of ZFS swap when exhausted makes it even preferable.
I thought that swap had to be on a zfs zvol moving forward. I can
certainly change this spec to allow for specifying a slice as one of
the possibilities. What about using a slice for a dump device?
- Wouldn't it make sense to model iscsi as a target_device type?
Yes, it would. Not sure why I didn't do that :-). I will move this as
a target device.
thanks,
sarah
Dave
_______________________________________________
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
