Ethan Quach <[email protected]> writes:
> 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?
Indeed: otherwise, whenever you need to move the AI server, you have to
change every script that uses aimanifest load.
>> 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>
Ok, thanks. Since this is a design spec and not a users guide, this
should fine. Actual user/admin documentation will have to provide some
examples to clarify.
>> 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.
True, there could be commands missing from the AI environment, but since
this is simply inspecting the target machine, everything but that check
should be possible on a live system for a regular unprivileged user. As
I said, when DDU can do it, why not derived manifests?
>> 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.
This is not only about bourne shell, but about several other scripting
languages as well: e.g., can perl, python, or some C program easily deal
with them? They certainly can deal with `regular' environment
variables, which, while they might be clumsy in some cases, are the
least common denominator.
>> 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?
Sure: provide additional variables as automount(1M) does, which allows
for the use of $CPU, $NATISA, and $PLATFORM in maps. Most of this is
uname output, so one might just be complete here.
>> 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.
Ok, while PLATFORM is the automount nomenclature. Perhaps provide both?
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
