Hi Carlton, What I've done is perhaps not quite your use case as I separate my hosts on a project basis, but maybe you can make it work for you. I have separated choosing the host from my other tasks, with something like this:
@roles('A_servers') def projA(): '''Specifies that subsequent commands apply to the 'A' project''' env.project = ProjectA() @roles('B_servers ') def projB(): '''Specifies that subsequent commands apply to the 'B' project''' env.project = ProjectB() def build(): '''Builds the project''' env.project.build() ProjectA and ProjectB are classes which know how to do their own thing, both derived from a common base class which defines stuff like the build() method. Then I call it like this: > fab projA build The call to the 'projA' task is enough to persist the choice of hosts to any subsequent task, and also of course sets up the right project class to use for the actual task, in this case 'build'. You can add other tasks to the line or create a single 'do_it_all' task to call all the other tasks as you please. Hope this helps, Robin -----Original Message----- From: fab-user-bounces+robin.pellatt=ext.oami.europa...@nongnu.org [mailto:fab-user-bounces+robin.pellatt=ext.oami.europa...@nongnu.org] On Behalf Of Carlton Gibson Sent: 02 February 2011 12:41 To: fab-user@nongnu.org Subject: [Fab-user] Can Fabric have (simple) multi-server wrapper tasks? Hi All, I'm using Fabric to manage a fairly standard (?) Django deployment. We have front end web server which handles static media and proxies to a pair of application servers. Updating the application is fairly simple but it involves a sequence of steps across the different servers. For this we use roles, via the decorators, which works perfectly but we end up with a long command string: $ fab run_tests freeze_requirements update_repository create_snapshot update_virtualenv update_media update_nginx graceful_migrate What I want here is to wrap this in a single task so I can just call: $ fab deploy As you see coming, the trouble is that the @role decorators aren't evaluated within the deploy task, so this approach fails. It's easy enough to wrap in a shell script, but that's outside the fabfile. Otherwise there's the ugly option of manually munging env.host_string with the deploy task. 1. Is there another way I'm missing? (Quite possibly :-) 2. Would it be feasible to able a command line option to say, "get your list of tasks from here", which would address this use-case? Regards, Carlton _______________________________________________ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user ********************************************************************************************** IMPORTANT: This message is intended exclusively for information purposes. It cannot be considered as an official OHIM communication concerning procedures laid down in the Community Trade Mark Regulations and Designs Regulations. It is therefore not legally binding on the OHIM for the purpose of those procedures. The information contained in this message and attachments is intended solely for the attention and use of the named addressee and may be confidential. If you are not the intended recipient, you are reminded that the information remains the property of the sender. You must not use, disclose, distribute, copy, print or rely on this e-mail. If you have received this message in error, please contact the sender immediately and irrevocably delete or destroy this message and any copies. ********************************************************************************************** _______________________________________________ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user