On 04/29/10 07:50, Rainer Orth wrote:
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.
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.
I'm not quite sure I understand. Are you asking just to
export where we got the script that is currently running
as an env variable, so script logic can use that to derive
where to load an XML instance from?
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?
Hopefully not. The xpath is just the nodepath reference to
an element in the XML. So for example, if the AI manifest
has an element tag for the target disks as <target_disk>
with a child for <name>, it would be refrenced as
aimanifest set target_disk/name=<foo>
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.
It depends on what logic you have in your script really. The
point of running it in the AI environment is to test that
everything the script calls is available in the AI image and is
accessible by 'aiuser'. In a simple case where the script is not
doing anything more than using the exported env variables
and calling aimanifest to update a manifest file, I suppose it
could be tested off the AI image.
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.
As noted from other responses, associative array variables
might be used for some of the variables, which are still env
variables but not usable in bourne shell.
p.11: 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.
This should be clarified to be the DNS domain.
I think AI_ARCH, AI_KARCH and AI_MODEL should be augmented like
e.g. automount(1M):
Can you elaborate on what you mean by this?
AI_CPU<- uname -p
AI_NATISA<- isainfo -n
AI_PLATFORM<- uname -i (== AI_MODEL?)
The JS variable used for this was SI_MODEL, hence kept the
"MODEL" part to be consistent.
Apart from that, this looks very much like a step in the right
direction.
Thanks for your comments. And thanks for the nits.
-ethan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
