On Sun, 2006-10-15 at 09:21 -0500, Narayan Desai wrote: > While this can be done, the key intuition is that a system that builds > a larger, abstract interface will necessarily make a lot more > assumptions about mechanisms (how are addresses configured in > /etc/hosts, how are users created, how are cronjobs created).
The downside of keeping things coarse-grained is that you can run into combinatorial bloat, and simple reversability might come at the cost of more fragile maintenance of the files. Fine-grained modelling is essentially a question of trying to minimize duplication within the spec, and ultimately a normalization concern. And clearly, there are tradeoffs. > These mechanisms will be fragile when you allow users to make local > modifications and then attempt to interpret them in the higher-grained > language. Agreed. > The goal here is to support a model where you have a specification > that can validate it against all current states so that you can > understand: > - Which hosts are out of spec > - Why they are out of spec These seem orthogonal to the granularity of config modeling. > - What parts of the system are not reflected in the spec How does a tool go about doing that ? That would require that the tool has a very intimate understanding of configurations; e.g. how do you know that /etc/auto.foo needs to become part of the spec without understanding /etc/auto.master ? David _______________________________________________ lssconf-discuss mailing list lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
