Hi Ethan,
On 01/15/10 09:28 AM, Ethan Quach wrote: > 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. That is a good point. I agree it does not necessarily mean it would need to be done as part of derived manifest project - the dynamic aspect is important, as there are scenarios when users would like to determine that configuration automatically (hostname, static_ip), e.g. from central database. > > 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. I think it is also matter of how heterogeneous is the environment admin has to take care of - then possibility to dynamically determine other sysconfig stuff might become interesting - (e.g. locale). > >> >> 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. ok. > >> >> 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. I see - I understand now. Thank you for clarifying this. > >> >> 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. I agree. Thank you, Jan
