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?
- Section 3.3: dry-run: will it be supported at all? If so, how?
- 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?
- 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.
- 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.
- 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.
- 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.
- 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?
- 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?
- Section 3.4.8.5: Just curious, are we going to use the manifest-writer
in anyway for this?
- 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.
Thanks,
--Karen
On 10/22/10 09:14, Darren Kenny wrote:
Hi,
I'd like to ask for some feedback and review of the CUD-based AI implementation
by November 2nd.
The document can be got at:
http://hub.opensolaris.org/bin/download/Project+caiman/CUE_docs/AItoCUDDesign%2Dv0.1.pdf
Many thanks,
Darren.
_______________________________________________
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
