On 05/03/10 18:23, [email protected] wrote:
Hi Ethan,
Thank you for your response. Comments in-line.
Thank you,
Clay
[snip...]
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.
Then root would be a pain to su to on Live CD installed systems... If the
/etc/user_atts file is populated with lines like:
ai_user::::type=role;auths=<auths to achieve read all; write limited>
equach::::roles=ai_user
And then you populate a password for ai_user in /etc/shadow, you
should be fine to su to it. This is the same way in which we achieve
root as a role on the Live CD, I believe?
Sorry, I was thinking profile there. Yes, we can make aiuser 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.
I would not be surprised to find zones or Ops Center having a way to
express a machine too which we might be able to leverage or at least
standardize on.
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".
I would suspect some admins will need to check that their script
generates expected output on an expected machine. A VBox instance will
afterall look vastly different than a big machine.
Checking for exact output correctness for exact machines
would ultimately have to be run on those machines. But that
would have to be done with any mechanism that involves
client-side run code.
If we can specify a machine in a reasonable notation for dumping to
XML (as discussed above), then perhaps we could record such data on
the server and simply use this for the crietia data and to provide an
off-line validator?
This doesn't completely validate the script though. If the
script runs code to get other client specific attributes to
use, that obviously won't execute the same off-line.
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.
I agree the user shouldn't have to do this step but for the underlying
transport it'd be nice to keep everything together and this would
provide a convientent way to publish a stub manfiest with its
derivation command.
A stub, or base, manifest isn't required to be given along with the
derivation script however.
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.
In the past, I've found in lab environments, if a machine has a
graphics device I probably want it to have X but otherwise, it's
probably a different type of machine which I'd like to configure
specially. It'd be nice to keep these differences in something already
written (the AI manifest repository) rather than having to write my
own modification storage engine and application script.
This same rationale can be said for any piece of server side criteria
really.
I think we need to evaluate how useful that particular criteria will be as a
usable criteria on the server-side.
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.
This is the same as proposed for derived manifests -- especially if we
download the executible on demand instead of baking it in the image.
Also, we could consider providing more to the user (i.e. the output of
prtconf/smbios).
But that's why its a run client-side. Additional system information can
be gathered and used in the derivation process.
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
I don't think there's any reason we can't have a way to use the
aimanifest XML editor command to allow for criteria updates and as a
more simple but longer process to support the ability to remove and
republish a criteira set as one can now.
b) with the assertion above that criteria sets
are not large, its makes this really usable.
I think that's still a debatable assertion. Jon's e-mail points out
that there's more complexity than is apparent even with the current
paultry set of criteria.
His mail points out a want for multiple criteria sets, and the want
for ordering precedence of the sets; but the sets themselves are
not that complex. I'd agree that the ordering of sets is an issue that
is not yet resolved though.
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 think the ability to publish a manifest but leave it offline (or
unassociated with any criteria sets) and then to add and remove
criteria via an XML manifest as we do now, but with the manifest to
associate provided on the command line. Also, the ability to provide
multiple criteria sets in one XML file. So we'd have more simple usage
akin:
installadm:
[other stuff...]
register manifest.xml -c criteria1.xml [-c criteria2.xml [...]] serivce
unregister manifest-name service
change-registration manifest-name -a -c criteria1.xml [-c
critera2.xml [...]] service
[the above would add a criteria set]
-d -i criteria-set-#|-c criteria1.xml [-c
criteria2.xml [...]] service
[the above would delete a criteria set]
-m [-i criteria-set-#] service
[the above would open all criteria sets
in the aimanfiest editor or just the
criteria set specified]
I agree, an interactive editor could be leveraged to do modification of
criteria of already published manifests as well. I will take a note of this
for the design of that tool.
But I'm still not sure about the use of xml files with criteria in them vs.
criteria directly on the command line. For cases where a simple criteria
is desired like MAC=foo, I wouldn't want to have to write that into a file
first, just to then feed it into the command.
One thing we could do here is simply to provide both modes, -c for directly
specified criteria on the command line, and -C pointing to a file.
-ethan
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.
I believe the ability to specify updating the manifest with a criteria
set to mbe more natural than publishing twice, further, I see the
ability to open in the aimanifest editor a more user
friendly/hand-holding experience available. Then to allow an admin to
either keep criteria manifests on a per-machine basis, register could
allow multiple criteria manifests at a time, while criteria manifests
could hold multiple criteria sets for those who want to provide a
number of machines all at once (e.g. every data analysis machine in a
lab).
Thank you,
Clay
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
