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.
p.11: AI_DISKSIZES A comma-separated list of disk sizes on the install client,
corresponding to AI_DISKLIST. The sizes are in Mb.
^ MB certainly :-)
AI_DOMAINNAME The domainname that the client is set with in the install
environment.
Which domainname? The DNS domain, I suppose, as opposed to the
NIS domain.
I think AI_ARCH, AI_KARCH and AI_MODEL should be augmented like
e.g. automount(1M):
AI_ARCH <- arch
AI_KARCH <- uname -m
AI_CPU <- uname -p
AI_NATISA <- isainfo -n
AI_PLATFORM <- uname -i (== AI_MODEL?)
p.12: used to add a regular XML manifest instance file. Installadm can
^ lowercase
Apart from that, this looks very much like a step in the right
direction.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
