Jan,
There seems to be a consensus that passing the zfs and zpool properties
as a text string is a better approach than having individual XML
elements that are validated for each property.
note: Mount point is a property for zfs create, but a separate option
for zpool create (-m),
From zpool man page:
zpool create [-fn] [-o property=value] ... [-O file-system-property=value]
... [-m mountpoint] [-R root] pool vdev ...
Changing proposal to have a single text string element that includes:
- all options
- all zpool properties
- all zfs file system properties
User must provide any options indicators (-m, -O, -o)
AI will provide -f and -R.
This should provide maximum flexibility and independence between AI and zfs.
It was mentioned that some validation could still be done, but it would
be very limited, given that the options and properties can change
without notice.
William
Jan Damborsky wrote:
> William Schumann wrote:
>>
>>
>> Dave Miner wrote:
>>> William Schumann wrote:
>>>> Since the OpenSolaris Automated Installer is being enhanced to
>>>> create zfs pools, setting properties of zfs filesystems and pools
>>>> should also be considered.
>>>>
>>>> A zfs root pool is created automatically when OpenSolaris is
>>>> installed, and the design proposal includes creating other zfs
>>>> pools and extending them to multiple disks.
>>>>
>>>> This message suggests possibilities for new features for the the
>>>> OpenSolaris Automated Installer. Community input is requested.
>>>>
>>>
>>> I'm not clear on what you're proposing, exactly, but it appears that
>>> you're suggesting something other than just passing through a list
>>> of ZFS properties. The concern I would have about any other
>>> approach is that the ZFS property list is extensible, including user
>>> properties, and so I'm skeptical there's value added by AI knowing
>>> anything about the specifics of the properties.
>> Are you proposing just passing through a text string that specifies
>> options:
>> zfs create -o <option string>
>> where option string is a list of zfs options as you would type on a
>> command line? This seems fraught with risk as it would be difficult
>> to validate, and the smallest syntax error or inappropriate usage
>> would break the install.
>
> When describing how to prepare target system for the installation,
> I think there is always certain amount of risk that the result will
> not be compliant with initial user intent - with respect to this
> there are more risky parts there we can't (or don't plan) to take care
> of - e.g. typo in disk name can blow away user's data disk.
>
> In cases like the one mentioned above, my feeling is that we should
> let ZFS take care of validation and make sure that failures are correctly
> reported to the user providing him with appropriate feedback which
> will allow/help him to correct the manifest instead of put any
> restrictions
> there.
>
> Thank you,
> Jan
>
