Thomas Krause wrote: > Hey, > >> [...] >> - pre/post install scripts are executed in the following order: >> - [0-9][0-9]all.* >> - [0-9][0-9]IMAGENAME.* >> - [0-9][0-9]BASE_HOSTNAME.* >> - [0-9][0-9]GROUPNAME.* >> - [0-9][0-9]HOSTNAME.* >> [...] > > I'm not sure how it is currently implemented in SI, but I see the following > problems with this suggestion: > > 1. If I understand correctly the ordering with a number prefix does only > work within a class. So for example if I have a script > 10all.configuresomestuff and some other *all-scripts depend on the changes > made by this script, I can't override this script for some other group. The > group scripts will only run, after all dependent *all-scripts are already > run. > > 2. You can't really 'override' a script, so that e.g. the group-script will > run INSTEAD of the all-script, you can only revert the changes made by these > higher level scripts (if they are reversible at all).
Correct. I understand your perspective here. > > Instead I suggest the following scheme: > > 1. Ordering is global between all classes, so a 10all.script will run after > a 09GROUPNAME.script, but before a 11GROUPNAME.script. If you don't want > that you can achieve the same ordering as above by renumbering your scripts > (this could even be done automatically when upgrading from a previous > version). > > 2. You can override a script by choosing the same name and number for a > script, but with a different scope. So for example if you have a script > 10all.networking and a script 10MYGROUP.networking, then > 10MYGROUP.networking will run on every host in the 'MYGROUP'-group INSTEAD > of the 10all.networking script. On all other hosts the 10all.networking > script will run obviously. If you don't want this behavior you can simply > choose another name or ordering (or simply call the overridden script from > your script). > > This would also be more similar to the way the master-script is choosen. In > fact except for the numeric part at the beginning the logic is exactly the > same! > > Just my 2ct... > > And yes, I realize I'm probably totally wrong here, it will horribly break > backward compatibility and I'm a complete newbie ;-) 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... 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) 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... 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. OTOH the big disadvantage of the 1st approach is that it's not possible to handle irreversible scripts and exclusions. Other opinions? > Thanks for listening, > Thomas Krause Thank you for the good comments, -Andrea ------------------------------------------------------------------------- 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
