On 04/26/10 14:58, [email protected] wrote:
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].
Its simply referencing xpaths from the xml, what is so non-standard
about that? The choice of subcommands was to make it similar to what
will be proposed as the interactive CLI to manipulate manifests
(though that is not included in this design doc), and other Solaris tools.
The XQuery Update syntax seems a little low level to me and doesn't seem
appropriate as the end user interface for our purposes here. The XQuery
stuff could potentially be the underlying component that 'aimanifest' uses
to do its work, but I think it useful to present a small layer of semantic
through 'aimanifest' because we can make some things simpler.
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?
You can't su to a 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.
The XML work Sarah is working on defines components which
will end up being used for AI manifest itself, so familiarity with
that would actually help with knowing the xpaths to reference.
But that definition is for target instantiating, and we can't
necessarily assume it will exactly coincide with what we need to
present as all of the diskinfo on the system and their attributes, etc.
Having said that, its not impossible to present both really.
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
They can boot any system into the AI image to test, even a VBox
instance. The aspect of what is being tested here is to know that
what's going to be run and called by the script is available in the
image and accessible by "aiuser".
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.
Embedding in the manifest doesn't seem ideal either though.
Having a base manifest to start with is optional, and it doesn't
have to come from the server.
p. 13 I really dislike making the criteria a command line option as
the
criteria interface was designed to be extended and made richer.
I'm not opposing that the set of criteria available be extended or
made richer, but I don't see its use going any further than how its
used today.
Already one can end up with a lengthy set of criteria as I've
previously pointed out.
But we also pointed out that that wasn't a realistic criteria
set. In the example, there included a MAC address. Once MAC
is given, that's only ever going to match a single system, so
why the need for the others.
The use of criteria on the server fall under the following cases:
1. map to any
- our default specification achieves this.
2. map to a single explicit system
- a single criteria like, MAC, IPaddr, or hostname achieves this.
3. map to a class or subclass of systems.
- examples of this are
"platform Y systems on subnet X"
"x86 systems more than 6GB Mem"
which are all typically achievable with just a couple of criteria.
Disk information, hostname and devies
present are some criteria which would be useful to add for
example.
Hostname, yes, and perhaps some aspects of disk information.
But I'm skeptical about why devices would be needed.
Or ways as I've discussed privately to allow an admin to
extend the criteteria set.
There's no way to allow the admin to extend the criteria set
on the fly without running an arbitrary command on the client
for them.
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.
OK. I do see this point, and moving it completely out to the
command line comes with that trade off. But I am proposing to
move it because a) we *have* to provide subsequent updating of
criteria after a manifest has been published. And the clearest
way to provide that is as proposed in this design, which is
command line based, so there's going to be familiarity of handling
criteria there, and b) with the assertion above that criteria sets
are not large, its makes this really usable.
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".
Can we find a way to envision it differently then.
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.
This is a must.
-ethan
[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
