Hi Karen,
Thanks for the review.
On 10/25/10 11:55 PM, Karen Tung wrote:
> Hi Darren,
>
> Very nice and clear spec, I do have a few comments:
>
> - The engine provides the ability to stop/resume. I know that's probably
> not a normal use case for the AI application. Is there any plan to
> provide that as a private feature somehow for the AI developers or
> those debugging AI to save sometime?
It's certainly very likely since I'm sure Matt and myself could use it too,
should I be documenting this in the design, or just in a README?
>
> - Section 3.3: dry-run: will it be supported at all? If so, how?
Forgot about dry-run - certainly if checkpoints support it - but I wonder how
much is feasible in dry-run mode only when doing an install - especially around
the TI stage...
AFAIR some checkpoints (via the Engine) support dry-run, so it should be
possible to use that, shouldn't it?
Still, it's a developer feature rather than end-user, isn't it?
I may look at adding a 'developer' appendix if it's useful - what do you think?
>
> - Section 3.3: "Run the install" section, will progress be reported as a
> percentage? Or
> people just see progress because they see something posted in the log file?
> Is the AI app going to register a progress handler with the logger to
> pro-actively
> get the progress and log it?
Good question, and Dave also raised this (due to some bugs in this area).
I've not figured out how to report progress, other than the current way which is
via the log file, which is the current solution.
I will probably send out an e-mail to discuss this further.
>
> - Section 3.3.1.1: "Register checkpoints" bullet. It would be useful
> to list the exact list of checkpoints and their names used in the AI app
> in the design spec
> somewhere to make sure that the if we ever change the names for
> <software> in the manifest,
> we know what might get affected in the code.
I've been trying to explicitly avoid the need to expose this.
While I know the Transfer Software nodes need a matching checkpoint, I've been
talking with Ginnie and Jean about having a Transfer factory method that would
generate the checkpoint from the software node - that way the name (if provided)
in the manifest doesn't have to match the internal name of the checkpoint,
rather it's likely that the checkpoint will do the opposite and match the name
in the manifest...
Also, there is not requirement to have a name in the manifest, so that's also
something to be looked at - and generating dummy names if none is specified.
>
> - Section 3.3.1.1: "Execute the install" bullet. This indicates that all
> checkpoints will be executed without interruption by the engine.
> Will the checkpoints be executed with stop-on-error equal to true?
> It might be useful for stop-on-error to be false for some of the ICT
> related checkpoints.
That's interesting - I would have thought that it better to fail totally than
continue in an AI case, I'll mention it anyway.
>
> - 3.3.1.2: Why is the AIFileHandler Class needed? You can just add a
> new FileHandler pointing to a location other
> than where the default log is, if you don't want to use the default log.
Agreed, we just copied this from DC :)
But after looking close, there is good reason for it in DC since the output
directory might not exist, so it caches logged messages until it does exist...
So to sum up, this doesn't apply for us, so removed it.
>
> - 3.4.2: second bullet, 2nd sentence. This talks about checking every
> <software> node
> has a corresponding checkpoint. For DC, it is about consistency,
> because the DC user
> specifies both the checkpoint name and the software node name. So, we
> want to make sure
> they are the same. For AI, the user only have control on the <software>
> node in the manifest.
> They should not have knowledge or control over the name that's used for
> the checkpoints.
> For the AI app, I believe it's important to make sure they are
> consistent in case either the
> AI app or the manifest is updated in the future, and things get out of sync.
As mentioned above, we are looking at ways of not having to care about the name
of the <software> node in the non-DC applications. If this works we don't need
to worry about there being a need to match the names in the user's XML provided,
it'll be taken care of internally - and by the Transfer module.
I'll put in some text to describe this proposed changes.
>
> - 3.4.3, first bullet, "DeviceDriverUpdateLive". I asked Jack, he told
> me that the result
> of "search all" gets saved somewhere after it is applied to the live image.
> That way, after install, the same drivers will get installed to the new
> BE without
> having to do the search again. Will these results be saved in the DOC
> somewhere?
The exact details of that I've not figured out, I do know that they are
remembered from the Live BE install - the DOC would be the correct place to put
it ideally, but that will depend on what the current DDU python code does.
I've added this to the document here too.
>
> - Section 3.4.8.2: which class will be registered with the engine?
> BootConfigurationBaseCheckpoint
> which will make decision based on whether the architecture is x86 or
> Sparc? or
> the actual BootConfigurationSPARC and BootconfigurionX86 checkpoint will
> be registered?
The one registered would be the one that is appropriate.
The call would be something like:
(cp_path, cp_class_name) = BootConfiguration.get_checkpoint_info()
engine.register_checkpoint("boot-config", cp_path, cp_class_name)
So the get_checkpoint_info() method would get the appropriate one.
>
> - Section 3.4.8.5: Just curious, are we going to use the manifest-writer
> in anyway for this?
At the moment, no - I'd like to focus on the replication of existing
functionality, but it's certainly something we can look at later.
>
> - 3.5.2: I think the imported interface table also should list the DDU
> libraries in the ON gate
> that will be used for the DDU related checkpoints.
Done.
Thanks,
Darren.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
