Ethan, Thank you for the reply.
Joe On 03/ 2/10 02:32 PM, Ethan Quach wrote: > > > 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 >>
