On 03/02/10 08:52, Joseph J VLcek wrote: > On 02/25/10 10:51 AM, Ethan Quach wrote: >> Hi all, >> >> Thanks for the feedback and input on the strawman. Before sending out a >> refresh to that, below is a description on the >> problem and requirements, which were not included in the >> strawman. >> >> Please see the following for a description of that, and on >> the approaches considered for the design solution. >> >> >> thanks, >> -ethan >> >> >> >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > > > Ethan, > > I'm learning as I go so if I miss the point with this suggestion > please explain... > > Regarding: > > >> For cases where systems are intended to be deployed identically, and >> which >> have similar or identical hardware, it would be possible to simply >> use the >> same manifest files for each of these systems. However, when these sets >> of systems have variances in hardware attributes, it may not be >> possible to >> do so, (for example a different disk set or types) and separate manifest >> files would still have to be maintained for them, though their >> installation >> parameters otherwise should be common. > > When I read that an idea came to mind: Could we have a manifest > "Include" concept? > > Where systems with variances could it be advantageous to have a > minimal manifest that describes only the differences and "Include" a > sharable manifest that identifies the rest of the parameters?
Where inclusion works, I don't see why not. But I think that is more a factor of how we design the schema. As you note below, it doesn't address the number of manifests when in large-scale environments. > > This would not limit the number of manifests but manifest maintenance > could be simplified. > In the case where a common attribute needed to change for all systems > the administrator would only need to change it in one place. Yes, inclusion would help there. -ethan > > Sort of how DHCP manages macros... > > Just a thought. > > Joe >
