Jan, Thanks for the comments ...
On 01/13/10 06:01, Jan Damborsky wrote: > Hi Ethan, > > please see my questions/comments below. > > Thank you, > Jan > > > 1. Introduction > --------------- > > From the text it seems that only elements in AI manifest could be > derived. Is derivation of SC manifest also considered ? Yes, I've been thinking about how that could work with this proposed mechanism AI manifest, but first I would really like to have a discussion on whether or not system config spec needs to be derivable at all (or at least, whether or not we leave it up to the user to derive it.) Comparitively, the sysidcfg was not derivable, yet was automatically dynamic for the pieces that needed to be. i.e. users could leave out the host-specific pieces of config --hostname, static IP-- from the sysidcfg spec, yet they can get dynamically set correctly on the installed target by the installer. The convenience of this usage is that the user doesn't have to deal with setting up the derivation, yet its still dynamic. Also, there's no requirement for system config that justifies the need for dynamic derivation like that needed for the AI manifest (other than the known host-specific pieces of config mentioned). So I'm wondering if we should first pursue something a little bit more automatic, that perhaps just covers the known host-specific config parameters, before providing full dynamic derivation capability for system config file. > > 2.1 - Client-side spec > ---------------------- > > I concur with Dave that for purposes of derived manifest, metadata > file is not really needed (as other mechanisms could be used to distinguish > between static manifest and derivation script - e.g. by inspecting the > contents > of the file) and perhaps we would like to avoid it, since it seems to > constitute > limitation in some scenarios - e.g. for bootable AI, where support > for derived manifest might be desirable in cases that bootable AI is > consumed in non-interactive way (for instance by VMC). See my response to Dave's mail on this. > > To be honest, I am not quite sure what is the purpose of '-i' option for > 'add' and 'modify' aimanifest subcommands - could you please help me to > understand which kind of problem it addresses ? For cases where there can be one-or-more of a manifest element. An example is the <ai_device_partitioning> tag. If <start_sector> is what we want to modify, we'd need to identify which <ai_device_partitioning> <start_sector> to change. The -i interface is to be able to uniquely identify which <ai_device_partition>. As Dave pointed out, this usage is different than what's proposed in the interactive CLI on the server. I need to think about this some more and reconcile the interfaces. > > 2.2 Server-side spec > -------------------- > > I think that server could also figure out automatically if the > file provided is the static manifest or derivation script - > there would be no need for user to remember both '-s' and '-m' > options and which is for what. Yes agreed, and thanks for pointing that out. If we can establish a way to do this for the client side, it should be used here as well. > > just a nit (misspelled <manifest>): > > installadm add-manifest -m <manfiest> -n <svcname> \ > -> > installadm add-manifest -m <manifest> -n <svcname> \ > > > 3. Manifest tags > ---------------- > > +1 for this simplification :-) > > 4. Creating/modifying manifests on the server. > ---------------------------------------------- > > I vote for support for 'export-manifest' subcommand available > as I think it would be also useful for 'add-manifest', since users > might create new manifests by modifying existing ones and with > 'export-manifest' there would be no need to think about keeping > those 'manifest templates' somewhere. This is a good point. And thinking about it some more, we should probably provide 'export-manifest' regardless whether or not we choose to do the interactive CLI, as its use with the raw xml file format would be beneficial. thanks, -ethan > > > > On 12/24/09 07:20 AM, Ethan Quach wrote: >> caimanians, >> >> Below is a strawman for how derived manifests could work. Would >> appreciate comments/thoughts by 1/13. >> >> >> thanks, >> -ethan >> >> >> >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
