Hi Ethan,
My responses inline...
On 05/ 7/10 06:22 PM, Ethan Quach wrote:
Sarah,
Thanks for reviewing. Comments, in-line.
On 05/04/10 12:28, Sarah Jelinek wrote:
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.
But wouldn't the archive specification be elements of the manifest
that AI consumes? If so, it'd seem that the general statement that
it be usable with the automated installer covers that. If you're
thinking
that the replication case not be used with AI as the installer, then
yeah I'd agree, but I didn't think that was the case, or at least we
didn't know that yet.
Yes, the plan is to have the archive specification be an element of the
manifest that AI consumes. Although, if we can use a script as the
manifest during server setup, we could easily extend this to be an
archive as the manifest 'source' on service setup. In that case, we
could embed a manifest that we derived from the running system in the
archive, which the AI client would then use to fulfill the install
request, while utilizing the actual archive source bits to install.
It seems to me if this can run on a client for AI, it could be extended
to run on a live client, a user could run the scripts, gather the info,
create a manifest, archive up the bits, and create the full archive.
This isn't a priority for this project now, but I am looking at ways to
get a replication mechanism going and this might be helpful to that.
Section 4
-You note that the system configuration profile will be designed in a
separate proposal.
The note in section 4 is meant to address the portion of the change
that involves moving the SC manifest portion out from the current
criteria manifest.
ok.
Is the plan to ultimately be able to derive the system
config profile as well?
The specification of the manifest input module (5.2.4), being generic
to xml and not necessarily any specific schema, should be able to
accommodate for dynamically updating the SC profile in the same
way the AI manifest can be updated, but the actual derivation driver --
the custom user specified script -- imo is not ideal for use with the
SC profile. But it could be used in that way if we wanted. I would
like to explore other ways to do "derivation" of the SC profile first
however though.
ok, fair enough.
-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.
They're not included because we don't know what they all are
yet, and they will be an evolving change to the manifest. The
assertion though, is that the built-in abstractions aren't going
to satisfy all of the cases needed for derived manifests, in that
they don't allow the user to define the logic by which to derive.
So the intention of this design is only meant to document the
latter approach.
Ok.
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?
It gives a record of what the script produced, so I think it'd be
useful to store that. And we can use a different name for the
files really.
I think we need to store these as different names.
Section 5.2.4 Manifest Input Module
-load(), where does the initial instance document come from? Is this
user
supplied in their script?
Yes the user has to specify that in the script. If the user wants to
use the default one on the media for example, they can reference
that local file in the 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.
I think that's a matter of how the Manifest input Module (5.2.4)
will get implemented. As specified, it should allow for that since
the schema its initialize with is passed in.
ok.
-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?
Because the separate set() calls are used to set individual elements,
the state after a set possibly won't validate.
ok.
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?
Yes. If we were to limit them to only these env variables, we
wouldn't be running this script on the client at all.
This isn't clear in the document. At least to me :-).
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.
The list isn't complete. But the fact that we're running the
script on the client allows users to "read" whatever else may
be desired. That's really what fulfills the requirement.
ok.
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.
That's a good question, and I don't quite have an answer yet.
Today, the install service is always has a default manifest, partly
because it is sorta baked in, and partly because we wanted to
make the initial setup case really easy. But I suppose there's no
real reason why an install service has to always have a default.
(For example, if the user wanted to explicitly set a service up
that way.) I need to think about this some ... would like to hear
thoughts from others on this as well.
It seems that a service could be setup without a default, based on the
new proposal for criteria and default manifest setting.
I think that if a service doesn't have a default manifest and the
criteria doesn't match to a manifest, then the client should fail.
Because we can't assume anything about what the user wants to do.
sarah
****
thanks,
-ethan
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
