Hi William,
William Schumann wrote: > 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. that sounds reasonable - thanks a lot for looking into this ! Jan > > 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 >>
