On 07/12/10 15:10, Dave Miner wrote:
On 07/12/10 05:56 PM, Ethan Quach wrote:
Dave,
On 07/08/10 14:01, Dave Miner wrote:
Ethan,
A little later than requested, but comments on this update.
An overall nit is that this could use some spell-checking. More typos
than I'm used to :-)
Interesting. I just reran spell-check on the document and it reports no
errors. Intentionally misspelled a word and check still reports no
errors.
I'll figure out what's broken; but I suppose I really should have
known I
wasn't a perfect speller :-)
You're usually better than this doc was :-)
5.2.6: I'm concerned about the "supported scripting types" statement.
This would seem to imply that we'll keep perl 5 (some variant thereof)
part of the installation media. Imminent package refactoring will
remove its historical entanglement with the system core, I believe, so
its presence isn't a given, and I'm somewhat reluctant to commit here.
Python's mildly problematic because of our dependency on it; upgrade
to some later version may put 2.6 on the undesirable list, but I guess
that's something we'd have to address at a larger scale. Perhaps a
more limited commitment initially that excludes perl and is explicit
that only ksh93 is supported of the shells would be advisable?
I agree, an initial limited commitment would probably be the more
prudent thing to do. I am ok with excluding perl and limiting the shell
to ksh93. (I would actually be fine with excluding python initially
as well
for that matter.)
Python's going to be there, so I think we should just include it.
OK. I'll leave that in.
5.2.6.2: It would be nice to be able to do some testing without having
to boot an AI client. Would it be possible (and sufficient) to
package up the aimanifest command, the aiuser account, and some sort
of aitest command that could run the script in the same sort of
environment (including the environment variables from 5.2.7) as
auto-install would? Seems like this would help you with development,
actually :-)
Having such a command could help testing to some level, but it wouldn't
entirely test all aspects.
1. A set of env variables can be mocked up by such an aitest command
to test that the script executes properly (but the values of the
environment
variables obviously won't be what they are when the script runs on real
clients).
2. For cases where the script calls additional commands, it would be
hard to test outside of the AI image its intended to run in. AI images
may differ from release to release wrt what commands are available in
them and the aiuser account as well, so an 'aitest' command run on the
server, or wherever, won't quite capture this aspect of validation.
I agree that it won't be perfect emulation, but it would seem to allow
one to get the major issues figured out before going to the real
environment so that hopefully there's less rebooting and groping
around required there.
I'm not so concerned about variance in the available commands, as I
expect we will arrive at a stable core definition before too long
(it's a product issue that needs to be addressed).
So if (1) is the predominant case we're validating against, I am not sure
we really need to provide a separate command to wrap around this
testing. We can package 'aimanifest' and the 'aiuser' account to be
installed on the server, and then simply provide a template ENV file
filled in with dummy values where a user can then use it to:
$ . ENV_file
$ export AIM_MANIFEST=/tmp/foo
$ export AIM_MANIFEST_LOG=/tmp/foo.log
$
$ su aiuser ./script
The latter two variables could actually be in the ENV file as well. And
also, the user could tweak the values in the ENV file to more closely
resemble clients they will ultimately run the script on. Do you think
this is sufficient over providing a wrapper command?
5.2.7: In the SI_MANIFEST_SCRIPT description, is the location the URL?
Yes. If you think URL is more clear, I can change the description.
(I didn't want to use URL at first since with the prompt case, a file
path
may be supported; but thinking about it now, for that case file://
can be
used in the value.)
Or just say "path or URL".
OK.
thanks,
-ethan
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
