Hi Sarah,
On 05/10/10 08:20, Sarah Jelinek wrote:
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.
That might not work very well. There's likely not going to be enough
room in the AI environment to hold a big archive file.
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.
In the above, it sounds like what's being built is an archive with
the manifest used to deploy it contained within it? I'm not seeing
how the AI client run derived manifests mechanism plays in there.
Perhaps we can talk about this some more so that I get a better
understanding.
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.
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 :-).
OK. I make sure to clarify that when I update the document.
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.
Not necessarily. The proposal specifies how a default manifest
for a service can be changed, but doesn't say the manifest currently
set as the default can be removed.
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.
Agreed on this behavior, if we were to go this route. However, changing
whether or not an install service must always have a default manifest
seems to be orthogonal to this project, so I am going to leave the current
behavior as is. So I am going to update the document to be clear and note
that
The manifest currently set as the default cannot be removed from
an install service. One must set the default to be some other manifest
first before being able to remove that one.
-ethan
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
