On 04/26/10 12:36, Dave Miner wrote:
On 04/23/10 10:47 PM, Ethan Quach wrote:
I have posted a revision to the derived manifest design.
(I've removed the pieces about an interactive manifest CLI on
the server side, as that needs to be a separate design.)
http://hub.opensolaris.org/bin/download/Project+caiman/DerivedManifests/DerivedManifestsDesignSpec.pdf
Already discussed these offline, but for the formal record:
Introduction - It's probably tangential to this work, but it may be
worth considering whether the criteria mechanism should be made usable
on the bootable AI media, to assist with self-contained turnkey media
installation solutions. Architecturally is there a reason why it
shouldn't be usable?
Our criteria mechanism lives in an install service, and the
interface to the selection mechanism is through a webserver,
so that's a little bit limiting for us to be able to do this.
5.2.4 Might want to clarify here that these are Python API's? Also,
maybe "validate()" instead of "verify()" (and for the command argument
in 5.2.5).
OK agreed. It seems "validate" is the standard terminology
generally used with xml.
Finally, how about making load() incremental, so blocks can be pulled
in wholesale rather than constructed piecemeal with set()?
I thought about this some; pulling in incremental blocks
could be difficult because we don't have context on what to
do with the data getting pulled in. For example, if we are
pulling in a block that defines elements that already exist
in our instance tree, do we replace values in existing, or
create another instance of those elements.
We could perhaps just simply define that incremental load
functionality "appends" (or always creates) new instances
of whatever is defined in the block being pulled in. The
validation step still has to happen at the end of course.
To take advantage of this usage, it implies that the user has
files with xml fragments of AI manifests stored somewhere, and
the derivation process picks the right fragments to load in.
5.2.6 Aren't necessarily restricted to a script, are we? A Python or
other executable would seem to be equally valid.
I was actually grouping Python with script. I will clarify that it can
be any shell, python or perl script. Do we really need to expand it
to be any type of executable? I suppose it could be, but as we
wanted to define this to be admin friendly, the scripting types
seemed to fulfill that.
5.2.6.1 Ought to cover the principle ("full read, limited write") in
the aiuser account authorizations.
I'll add this.
5.2.7 The disk arrays seem clumsy to use; maybe ksh associative arrays
would be better? Also, more on the rationale behind providing these
variables as committed interfaces.
Would using ksh associative arrays restrict what we can run
as the script though? For example, could a plain old sh script
be able to process that?
The rationale behind this was to provide upfront to the script,
the common hardware attributes that are typically used in
derivation so that it doesn't have to go off and do that work
(jumpstart provided something similar.) It is very likely that this
list may evolve over time. I'll update the document with this
information.
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
