On Thu, Apr 29, 2010 at 4:50 PM, Rainer Orth <[email protected]> wrote: > Ethan Quach <[email protected]> writes: > >> I have posted a revision to the derived manifest design. > [...] >> Please review. Comments appreciated. > > A couple of comments, together with my usual assortment of nits: > > p.4: arithimetic) describing the configuration. For example, create mirroring > for the root pool using > ^ e > > p.5 and several others: xml documents -> XML documents > > p.10: load <manifest file> > • Used to load in an AI manifest XML file instance to start > with, or overwrite the current contents of the manifest being > generated. Can be a local file or remote http path. > ^ URL > > I've got an issue with embedding the URLs in the DM script: while > the URLs for the AI manifest are provided by the manifest-locator > service, it seems more flexible to provide access to at least that > one here, so common parts of the URL can be derived in the script > instead of hardcoding. This way, you could transparently move the > AI server without having to touch the scripts. > > set [-i <xpath=value>,...] <xpath=value> > • Add or modify an xpath. For the case where multiple > instances of xpath are valid, xpath must be uniquely > identified using the -i option. > > Since I don't live and breath XML/XPath, this is hard to understand > for me. Do you need an diploma in XML to handle this? > > p.11: • the process still has root uid; any privilege set not explicitly > unset are excessible as > ^ accessible > > p.11: 5.2.6.2 Development and Testing of derived manifest scripts > > This approach of having to boot an AI image to test the scripts > seems completely unacceptable to me. It's almost as restrictive > as the Jumpstart begin and finish scripts, which were very hard to > debug. Since the derivation of the AI manifast is essentially a > text processing issue, I don't see why this would have to be > tested in the AI environment only. It doesn't require any > particular privilege, and should be usable on a running system, > just like the discovery side of the DDU. > > p.11: Environment Variables > > *Please* keep this as environment variables. Despite the constant > lobbying by the ksh93 project (`all the world is ksh93'), not all > sysadmins are fluent in all the details of ksh93, and neither > would it be appropriate to restrict the scripts to something like > Python here. This is not about developer convenience or > preferences, but should provide something that can be used out of > the box from the widest range of scripts and executables. Having > to deal with XML is bad enough, adding additional requirements > seems inappropriate to me.
Which lobbying? The only comments I've seen so far about using POSIX syntax. However I can see that the Sun donkeys don't want to learn and stick with their ancient Bourne shell syntax. Sure, learning and POSIX is only something for pupils and suckers. No wonder Sun was fucked and swallowed by Oracle. Jenny -- Jennifer Pioch, Uni Frankfurt _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
