On Wed, Feb 10, 2010 at 3:54 PM, Nicolas Steinmetz <nsteinm...@gmail.com> wrote:
> For now, I have a commands.upd file which can contains commands to execute > against some servers : > Ex : > remote front cd /var/www/myapp && php path/to/script.php -s <arg> : will > execute the given command on all frontals > remote once front cd /var/www/myapp && php /path/to/script2.php -s <arg> -u > <arg> : will execute the command on the first frontal only > remote db mysql -u<usser> -p<pass> -e "SQL Query" : will execute the query > on all db servers It sounds sort of like this is describing roles, to me, and the 'first frontal only' bit sounds like a single host. So 'fab --role front' (run on all frontal [Web?] servers) or 'fab --host front1' (run on the single host 'front1') or something like that? > I would like to do the same without modifying the fabfile.py (to avoid that > at next release there are some old scripts that would be run because they > were forgotten). > Is it clear enough ? Sort of. So you're saying you have some basic functionality / commands, which run every time you invoke your scripts, and you have an 'addon' of sorts that only runs some of the time? Fabric should be able to handle that as long as you organize the commands into task functions and then call only the functions you need. For example, you could have a task 'deploy' which calls a few sub-tasks like your ones above -- the things to execute every time. So "normally" you would just do 'fab --role=whatever deploy'. Any extra functionality could live in another task or tasks and then when you need to do *both* the regular *and* the extra commands, you would call two tasks on the command line: 'fab --role=whatever deploy extra'. Make sense? Am I understanding your needs correctly? On to Unatine's reply...:) On Wed, Feb 10, 2010 at 4:37 PM, Unatine <unat...@gmail.com> wrote: > [...] > But all settings (paths, servers, > applications names) for this applications (testing and production) > change not very often, and so all this settings i'm write in few > python dictionaries. and after run (for example) "fab beta deploy", > i'm пуt deployed application on testing environment beta (but fabfile, > and other included modules, don't contain function "beta" in this case > :)). and if i need new testing environment (gamma), i'm just add new > parameters to dictionary, and i can run deploy command "fab gamma > deploy". [...] It sounds almost like you're adding a more declarative layer (like Chef or Puppet or cfengine) on top of Fabric :) which is something I've been expecting to happen one way or another eventually. I hope whatever you're creating is working out for you -- if you notice any patterns that might be useful for everybody, or if there are new changes to Fabric that would help you out and don't have tickets in Redmine, do let us know :) > i'm also try solve this problem with logging. for now, i'm sometimes > use decorated fabric functions (run, sudo, and so on). decorator just > turn off all function output and redirect stdout with stderr to > logging module. > and this decorated functions use in fabfile. Are you using the decorator from Fabric's test suite? Pending the more thorough logging framework, I should probably abstract that out and make it useful for non-test situations like yours... Best, Jeff -- Jeff Forcier Unix sysadmin; Python/Ruby developer http://bitprophet.org _______________________________________________ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
