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. 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. thanks, sarah ***** > > -ethan >
