On 04/28/10 04:23 PM, Ethan Quach wrote:
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.
Those seem to be implementation issues, not architecture. Really, the
core function here is mapping a set of criteria to a manifest;
self-contained media could essentially short-circuit to a "local"
service that just runs the criteria mapping without all the
communication protocols. I realize that the current implementation
probably needs some restructuring to allow this. Like I said, it's
somewhat tangential to what you're doing here but as we're looking at
restructuring that code for other reasons, I'd like to see the
architecture provide for consistency in this area.
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.
I'd think you have the same problem with any "set" operations, though.
I envision the fragments as merely bulk versions of that, so what is the
behavior you propose when set is called on a path that already exists?
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.
I guess I'd turn it around: how would you prevent it from being any
garden variety executable? Or, perhaps, how would you prevent a
garden-variety executable from being merely wrapped in a script?
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?
Maybe not, but then again these are convenience features, so if you want
convenience, use a better tool :-). Really, I think it's reasonable to
center design on a shell that's less than 25 years old.
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.
I guess I see the rationale for the ones that are complex to sort out,
but nodename or architecture seem on the trivial side. I guess if it
helps with migration I'll buy it, but if that were the primary
motivation then would it make more sense to use the exact names that
Jumpstart provided?
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
