Hi Ethan,
My comments below. I tried not to repeat others comments.
Section 3
-You mentioned earlier in the document:
"As we flush out the requirements for replication, this
may also be a desired form of input so as to be able to capture into a
replication archive, some abstract level of disk layout configuration that
needs to be deployed with the replication archive."
In the requirements you state this must be usable for AI(basically). I know
that the design for this is for AI, but could a requirement be that this
could provide a general purpose client derivation mechanism? I ask
because it
seems to me that we could derive a manifest to include in the archive,
or at
least specify the abstraction for example the disk layout, in the
replication archive. If this were the case, the requirement wouldn't be
restricted to usable with the automated installer in any of its use
environments.
Section 4
-You note that the system configuration profile will be designed in a
separate proposal. Is the plan to ultimately be able to derive the system
config profile as well?
-Why aren't the abstractions, which you list as part of the solution for
scalability, part of this design? You include the moving of the criteria
to the command line as part of this design. I guess to me that including
any abstract definitions in this design that you have defined would
make this more complete.
Section 5.2.3: Derived Manifest Module
-You mention copying the resultant manifest file to the system. This
might conflict with the manifest file we are going to generate from
the run of AI. Why do we need to copy this manifest over since we
will generate one automatically, which will likely have more element
values specified?
Section 5.2.4 Manifest Input Module
-load(), where does the initial instance document come from? Is this user
supplied in their script?
-Also with the multiple schema definitions, transfer, execute, etc... can
the user manipulate only instance documents for these schemas, and not the
whole AI instance document? Not sure if this would be useful, but wondering.
-verify(), why do we need this? It seems to me when a user sets an xpath
value
we could do verification then, or at load of the new instance document. I am
not sure we need a separate verify. Shouldn't it just be automatic?
Section 5.2.7
-I assume that the users are not limited to these environment variables
in terms of system discovery? They can 'read' pretty much anything they
want, right? But only write aimanifest commands? The requirement you have
in Section 3 "List of client attributes to base derivation on should
support
all of the needed uses cases. Should be customizable or extensible
otherwise" kind of implies this list is complete, but that isn't clear.
Section 5.3.2
-If the user doesn't specify a default manifest, does the client fail if it
can't match any criteria? I assume there isn't a 'default' default manifest.
thanks,
sarah
*****
On 04/23/10 08: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
Please review. Comments appreciated.
thanks,
-ethan
_______________________________________________
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
