On 12/24/09 01:20 AM, Ethan Quach wrote: > caimanians, > > Below is a strawman for how derived manifests could work. Would > appreciate comments/thoughts by 1/13. >
Overall, seems like this can get to something workable. Some questions/comments. - I'd think we'd want to be able to self-identify a particular manifest as regular or dynamic without relying on an extra metadata file (point 2 under 2.1). I must admit that I'm not quite sure why we'd need to make this distinction, though. My thought is that any manifest could be made dynamic merely by publishing a script along with it. - Based on earlier conversation, I'd sort of expected more similarity between the aimanifest and "installadm add-manifest" interfaces than you seem to be suggesting. Is there a reason you went a different direction? It's not obvious to me. For example, the issue you note about referencing nodepaths in the aimanifest case seems to be somewhat mitigated by the add-manifest functionality to select particular elements. Adding a "search" type of function could also help this issue, maybe? Anyway, I think the question of whether we can provide a common interface for manifest manipulation should be explored further. - Looking at the aimanifest functions, it seems like a "delete" (or "unset") function is missing, and I'm not sure what the real difference is between add & modify; maybe just "set" is sufficient? - I really think we want this functionality to work regardless of the boot mode to provide consistent capability whether network- or media-based booting is used. Seems like the metadata is the stumbling block, so that leads to the question of whether we really need it (see comment above)? - Bravo for shorter element names! Dave
