Hi Ethan,
Thank you sending out your revision! I don't mean to be a jerk or
broken record but I do still feel this design opens up too much
roll-your-own which will not only be a disservice to our customers but
ourselves to know what our customers needs are. I'd much prefer that we
provide a more constrained API or UI and also make our lives easier by
trying to find off-the-shelf answers to many of the questions raised
rather than coding our own way of doing things.
Thank you,
Clay
Comments:
--------
p. 9/10 It would be nice to see the aimanifest command follow a standard
such as XQuery so we don't have to come up with our own XML
manipulation ideas. A good example and perhaps fully useable
implementation would be the Oracle Berkley DB XML interface[1].
p. 10 Should the aiuser account be a role instead, since it's not to be
logged in and we could su to the role?
p. 11 Should these be dumpped into an XML file for the user to parse as
they wish? I think we could hit limitations using shell variables
(for example AI_DISKLIST could be 1,024+ devices all of length 8-9
characters if the short ctd format)? Further, AI_DOMAIN name could
be either DNS or NIS, it seems more extensibility would be good
to plan for.
Further, if using XML we could use constructs for disks and such
from Sarah's XML schema work which admins should be familiar with
already. Also, if using BDB's XQuery interface we could point
admins to that as a way to query the XML file if they don't want
to parse it.
p. 11 Can we perhaps envision any way to provide a priori validation for
an administrator? It seems rebooting an M9000 over and over again
is a great way to upset any patient person
p. 12 Perhaps if a base manifest is to be provided we could simply
base64 encode the script/executable and embed it in the manifest
inside an appropriate tag, so that the process of including a
script is the same as publishing a normal manifest.
p. 13 I really dislike making the criteria a command line option as the
criteria interface was designed to be extended and made richer.
Already one can end up with a lengthy set of criteria as I've
previously pointed out. Disk information, hostname and devies
present are some criteria which would be useful to add for
example. Or ways as I've discussed privately to allow an admin to
extend the criteteria set. Also, providing this as a command line
interface means the only way to record the AI server's
configuration in a configuration management database is a script
of installadm commands opposed to simply the XML manifests used.
This also makes the ability to publish multiple criteria for a
manifest more difficult than what is envisioned in bug 12445 "Need
to allow multiple criteria sets per manifest publication".
I don't see the other changes such as criteria modification to be
a bad idea though. I think the previous method of deleteing a
criteria set via /usr/lib/installadm/delete-manifest -i <instance>
<manifest> <AI directory>; and republishing to be a PITA.
[1]: Berkely DB XML XQuery compliant XML manipulation
http://www.oracle.com/technology/documentation/berkeley-db/xml/gsg_xml/cxx/modifydocument.html
On Fri, 23 Apr 2010, 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
