Hi Ethan, On Mon, 15 Jun 2009, Ethan Quach wrote:
> Karen, > > Thanks for taking a look at this ... > > > Karen Tung wrote: >> Hi Ethan and team, >> >> Here are my comments: >> >> Section 1.3: >> - Shouldn't there be a dependency on the parser to allow data from >> the manifest to be modifiable? > > I should probably note that possibility. I mentioned > below that on the server, a base manifest will be validated > when a user adds one to an install service on the server, > but I don't really describe how; its not yet clear to me > whether we want the parser to do anything special for this. > >> >> Section 2: >> - Will one derived manifest correspond to 1 derivation module? >> If I have code in 1 derivation module that can be re-used by >> 2 different derived manifests, would I have to register this >> same derivation module 2 times, each time with a different manifest? > > yes. > >> >> Section 3.3: >> - Perhaps it is implied, but I think it would be more clear to explicitly >> say >> whether the associated module with the >> derivation functions is automatically deleted or not when you delete a >> derived manifest. > > okay, I'll add that. > >> >> Section 5.2, second paragraph, "The installadm add subcommand....." >> - Just curious, how would the server env be able to determine whether >> the the given manifest and the derivation module will derive a valid >> manifest, >> before the values are actually derived. From the server side, I think >> we can validate that all fields that require values either have values or >> have functions to derive a value. We can also validate that the function >> they specify indeed exist in the derivation module. Until we have >> the context of the client, I don't think you can really execute any code.. > > This is true. The wording should be changed here to note > the exact validation that is being done on the server. As > you note, its not quite going to be like validation of a full > non derived manifest on the server. > >> >> Section 5.3 >> - Will this new smf service for deriving the XML file end when it has >> completed >> it's work? Will it output a "new" manifest with the derived values to >> be consumed by the auto-install smf service? > > yes and yes. > >> Before it create this "new" manifest, >> will it also validated the manifest syntactically, semantically...etc.. >> So, the auto-install >> smf service can assume that the given manifest is valid and not need to do >> duplicate work? > > It could do the same type of validation as would have > been done on the server for a complete manifest (I think > right now that's just syntactical validation.) before > coming "online". > >> - Also, since this smf service is separate from the the auto-install smf >> service, >> how would the output/error from this service be reported? Will it be a >> separate >> log file from the auto-install service? > > Its a separate log file. One of the things the AI client redesign proposes is to consolidate all the installation related logging into the auto-install service log. A central log location like this helps users in not having to look at multiple places to determine what's going on. It seems we're moving in the opposite direction by creating another log file the user needs to keep track of. Alok
