Dave, Thanks for going through this...
On 01/12/10 14:19, Dave Miner wrote: > 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. Self-identifying was definitely a goal, and I'm glad you brought it up since I did want to discuss this a bit. One way I'd thought it could be done is to use the heuristic of detecting an XML file vs. a script file, but wasn't sure that'd be a solid enough way to determine the difference and be able cover the precise error cases of misinterpretation of one over the other. But maybe I was just over thinking that bit. > My thought is that any manifest could be made > dynamic merely by publishing a script along with it. From the usage standpoint, this is pretty much the case. A user only needs to publish a dynamic manifest script. The option of using "aimanifest load" in the script allows the flexibility loading any other manifest instance (even one a user had published into an install service for this sole purpose.) > > - 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. The key difference was that use of "installadm add-manifest" is interactive, and a live user can much more easily inspect where they are, and traverse. It seemed awkward to have to script selection and unselection of hierarchy, and also seemed to make the script more prone to errors, as the need for sequentiality of "selection" (and "unselection") would be needed. So the addition of the nodepath reference in aimanifest is an attempt to shorthand a separate hierarchy selection, without "selection". > Adding a "search" type of function could also help this issue, > maybe? Do you mean for the aimanifest case or the interactive case? It wouldn't seem very helpful for the former, unless there's a use case for it to be used as an interactive tool on the client. I haven't really thought about that yet... > Anyway, I think the question of whether we can provide a common > interface for manifest manipulation should be explored further. Indeed, I lost track of that a bit. I agree, making the interfaces as similar as possible should be a goal. > > - 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 was thinking "modify" used with a blank value could be used to unset. "add" and "modify" were to cover the case where nodepath elements are one-or-more. I think though, with the ability to uniquely identify, they could be a single command. (I may have added the need to uniqely identify after having add and modify.) But per the comment above, this interface both on the server-side and aimanifest, needs some hashing out... > > - 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)? Thanks for this input, and yes the delineater being in separate metadata was the crux. thanks, -ethan > > - Bravo for shorter element names! > > Dave
