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. > > Section 6: > - All the uses cases are not really use cases. To me, they are more > like pseudo-code > describing the code path of different things that can happen when > derived manifests > are used. Okay. I think we need to add some end to end use case scenarios like, "user wants target disk to install on to be derived." Is this what you are thinking? thanks, -ethan > > Thanks, > > --Karen > > Ethan Quach wrote: >> >> The functional spec for AI derived manifests is posted at: >> >> http://www.opensolaris.org/os/project/caiman/auto_install/DerivedManifests/AI_derived_manifests_func_spec.txt >> >> >> >> >> I would appreciate and feedback comments. >> >> >> thanks, >> -ethan >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
