Hi Sarah, Sarah Jelinek wrote: > Ethan Quach wrote: >> >> >> Dave Miner wrote: >>> Sarah Jelinek wrote: >>>> Ethan Quach wrote: >>>>> >>>>> >>>>> Dave Miner wrote: >>>>>> Ethan Quach wrote: >>>>>>> >>>>>>> >>>>>>> Dave Miner wrote: >>>>>>>> Ethan Quach wrote: >>>>>>>>> >>>>>>>>> Notes and decisions from previous meetings have been posted >>>>>>>>> to the project page here: >>>>>>>>> >>>>>>>>> http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/DerivedProfilesProblemStatment/ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Regarding note 2, Scope: It seems like we actually would >>>>>>>> support both, based on the proposed separation of the >>>>>>>> derivation process into a separate SMF service; by supplying an >>>>>>>> alternate instance or implementation of that service, a user >>>>>>>> could do complete, from-scratch derivation if that was >>>>>>>> preferred for their situation. In that case, this is really >>>>>>>> more about what the default, provided capability will require >>>>>>>> of the user, right? >>>>>>>> >>>>>>> >>>>>>> Yes, that is correct. We are describing here what AI by >>>>>>> default provides for this functionality. >>>>>>> Supplying an alternate instance or implementation, while >>>>>>> possible, isn't something I was planning on explicitly stating >>>>>>> in the functional spec. >>>>>>> >>>>>> >>>>>> Why not? >>>>> >>>>> I was thinking about supportability. Would it be something >>>>> we officially support? But if that doesn't matter in the context >>>>> of a functional spec, then I can certainly state it. >>>> >>>> I don't think we should support full derivation. We may allow for >>>> deriving of every field, but the actual derivation of the manifest >>>> from top to bottom seems like we could introduce possible >>>> compatibility issues. I believe the intent of not allowing this >>>> scenario made it easier for us to ensure manifest/schema >>>> compatibility for validation. >>>> >>> >>> The manifest format will be an interface, and in fact a public one >>> of some sort, so I don't see what issues it creates that we wouldn't >>> already have. What do you think they would be? >> >> The issue stated in the notes is that if and when our manifest >> format has changes from build to build, any code that is building >> the manifest file from scratch may need rework to know about >> the changes. Puts some burden on the user. >> >> .... but I guess this same thing applies to the base manifest >> from build to build. >> > Actually, you are right. The user has to know what the base manifest > contents are and what can be derived from build to build regardless. > We have to publish a base manifest of some sort for each build that > could be used in the derived manifest processing. The base manifest > will be versioned along with any other standard manifests provided by > the build which is essentially an interface for users.
I wasn't thinking we'd be delivering additional things for a base manifest. It's based on the same schema, so users could take the standard one we provide today and rip/delete stuff from it. And use the same documentation we're providing for regular manifests to see the description of all the possible parameters, and write a base manifest with whatever they want. How they specify what parameters are derived is something we need to define, and this would be in the documented procedure for using derived manifests. > They could create a manifest from scratch with this interface. > > So, not allowing the users to create a full manifest from scratch > isn't correct, we should allow both. With the current functionality defined, everything in a manifest can be derived. But the functional blocks we've defined don't explicitly allow for scripting that generates a manifest file from scratch. To me this is a very different approach and requires a separate set of functional descriptions on the spec. Do you feel strongly that we need to provide this method of deriving manifest, or is allowing all fields to be derived sufficient? thanks, -ethan > > thanks, > sarah > ***** >> >> -ethan >> >
