On 05/03/10 05:42, Jan Damborsky wrote:
On 04/30/10 08:23 PM, Ethan Quach wrote:
On 04/28/10 07:25, Jan Damborsky wrote:
Hi Ethan,
it looks pretty good - I have only couple of questions/comments.
Thank you,
Jan
5.2.5
I am wondering if we might need to support 'commit' as well,
especially with respect to 5.2.6.2. Or would be the changes
automatically flushed to the resultant manifest ? At which point ?
When the script finishes execution, the DMM will always issue
a validate, to check validity, and a commit, to output the resultant
manifest, so its not needed through aimanifest.
But who will take care of 'commit' if derivation script is invoked
from command line (5.2.6.2), in which case I assume DMM is not going to
be involved ?
Something that's probably not obvious is that each individual
call to aimanifest will end up writing out to file. Because each
call is executed as a separate process and has to finish and
return back to the script, the in-memory resultant manifest in
the manifest input module library has to be written out to real
storage each time. So for example, a single call to "aimanifest set ..."
would internally have to call the following methods
init()
load() [to load the current state of file]
set() [set whatever is being requested to be set]
commit() [to write out current state of file]
As a result, at the end of the script, the file will already be there.
This also means that if the script died anywhere in the middle,
the resultant file upto that time is also available for inspection.
5.2.6.1
Could you please elaborate more on the problem we are going
to solve by running derivation script as aiuser ?
It is not quite obvious why this mechanism is needed.
The purpose of this functionality is to dynamically build the derived
manifest based on system attributes, and we are restricting access
of the script to essentially be able to do that. This functionality is
not meant to provide for a open "begin phase" to generically do
anything. So the design here is that script will have 'read-only'
access to the system, with very restricted 'write' access.
If my understanding is correct, in other words, the intent is to
avoid potential 'misuse' of derivation mechanism for other than
derivation purposes - e.g. for labeling the disks ?
Yes.
5.2.6.2
In 5.2.5 it is mentioned that derivation script needs the
running environment to be established by the consumer (e.g.
determining name of resultant manifest and exposing it via
environment variable).
How it will work for purposes of testing ? Will it be up to
user to take care of those steps ?
Yes the user has to take care of an extra step, and I forgot to
document that in 5.2.6.2 We will expose the environment variable
name, AI_MANIFEST, that aimanifest consumes. User can set
this manually, and test
# export AI_MANIFEST=/tmp/foo
# ./script
That should actually be
# su aisuer script
thanks,
-ethan
I got it now.
Thank you very much for clarifying this,
Jan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
