Andrea Righi wrote: > [snip] > > I think your approach is very interesting instead, that means you're not a > complete newbie :-), but I have to admit that it will really break backward > compatibility... > I agree 100% on the backward compatibility problem.
> To summarize, we have 2 different approaches: > > 1) the "diff" approach: the most local scripts must be written "on top" of the > effects made by the most global scripts (problem: irreversible effects) > > 2) the "alternatives" approach: the most local scripts are mutually exclusive > with the most gloabal scripts (more exactly a local script excludes a more > global script that has the same number) > My suggestion was that exclusion is based on number AND name. This makes accidental overrides harder. > I think that both of them are valid. But I've to say that I prefer the 1st > approach. > > One advantage of 1) is that if you need to execute the same script in all the > nodes it's enough to define the script as "all" (simple). In the 2nd approach > there could be a "group" or "hostname" script that excludes the more global > script (maybe even erroneously); in this case you could replicate the same > operations from the global script into the local script, but in this way > you've > to *remember* that, and it is surely more difficult to maintain and to apply > future changes... > With my approach you can do the same. If you already have group scripts or hostname scripts with the same number and name as the all-script you want to create and you don't want your all-script to be overriden, then you can simply choose another name or another number. The propability of accidentall giving a script the same name and number is not that high IMO and does not outweight the advantages my approach would have. I think the propability of making mistakes is far higher if you have to deal with reversing changes made by one script and having complex dependencies on the ordering of your scripts. > Moreover, I like 1) because it uses the same concept of SystemImager overrides > (/var/lib/systemimager/overrides/README), that means no mutual exclusion and > files are distributed in the order: global, group, hostname. This has proven > to > be a nice approach, mainly because you don't have to replicate the same files > in > multiple overrides, and this helps a lot from the maintenance point of view > and > it's less error prone. > I'm not familar enough with overrides to comment on that. > OTOH the big disadvantage of the 1st approach is that it's not possible to > handle irreversible scripts and exclusions. > > Other opinions? > Also I don't like the _MUTEX_ version either, because it makes it even harder to see which scripts are run and in which order. > > Thanks for listening, > > Thomas Krause > > Thank you for the good comments, > -Andrea > Thomas Krause ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ sisuite-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
