Re: [Fab-user] env.user and prev_user in the presence of env.hosts
Hi Justin, On Tue, Apr 12, 2011 at 10:41 PM, Justin Donaldson donald...@bigml.com wrote: First off, congrats on fabric, this is a really useful tool. Thanks! I was confused by some behavior in fabric. When you set env.user in one function, it will typically be passed on to the next, just like any other field set on env. However, when env.hosts are present, env.user is discarded without any indication of what's happening. snip The question is, what is the purpose for this behavior? I couldn't find anything in the documentation that explained why it was doing this. See http://docs.fabfile.org/en/1.0.1/usage/env.html#user -- it should explain what is going on. The best way to work around it for now is to mutate env.users to prefix the host strings with username@ instead of setting env.user, e.g.:: def user(name): env.hosts = [name + @ + x for x in env.hosts if @ not in x] In other words, it would change ['host1', 'host2'] to ['name@host1', 'name@host2']. env.user only really works as intended if set at module level instead of at runtime (IIRC; it's been a while since I touched this part of things.) This isn't a very good design and will definitely change in future releases. There's work going on now to make tasks more object oriented, for example, which will straighten a lot of this out instead of relying on env to be both informational and for configuration. The next question is, is there a group of people that are sharing best tips, etc. for using fabric on cloud based systems? Is there a better option? I'd rather not invent the wheel, or force square pegs in round holes here. No specific group, but I would definitely welcome discussion on that here, and it comes up on IRC relatively frequently as well. I'm personally using more cloud stuff now than I used to, to say nothing of the increasing amount of user contributions in the same space -- so improvements should come along relatively quickly. Best, Jeff -- Jeff Forcier Unix sysadmin; Python/Ruby engineer http://bitprophet.org ___ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
Re: [Fab-user] env.user and prev_user in the presence of env.hosts
On Fri, Apr 15, 2011 at 4:31 PM, Justin Donaldson donald...@bigml.com wrote: Thanks Jeff, didn't catch that bit in the documentation. I added another pull request for your consideration. Right now we actually organize via Redmine instead of GH -- could you please make a ticket at code.fabfile.org and put a link to your pull request? :) Well, it's Friday, so here's a half cocked thought: Could you assign the output of one fab request to another as an input? It would require some special syntax, and some currying. I recognize the use case but I find the suggested implementation to be a bit on the confusing/complicated side :( To help users share data between task functions without doing it all themselves via env (which is how it should be done now), I think these are the options: 1) Automatically fill eg env.previous_result with the return value of task functions. Not much removed from the current your functions have to know how to talk to each other by writing/reading your own env vars but at least it's a bit cleaner / delimited. 2) Dink around with kwargs in some semi-magical fashion -- your approach, or an inverse approach where we just add an extra kwarg (again eg previous_result=return value) which has its own set of pluses/minuses compared to your approach. (I feel it's a little cleaner on the invoking/task definition end, but also requires gross metaprogramming re: tasks which do not define this extra kwarg or **kwargs.) 3) Take advantage of the upcoming move to object-oriented tasks and have fabric.main simply attach the return value of task1 as an attribute on task2, which may then opt to access that data as necessary. Similar to 1) but isn't using a global shared state, only a per-task-object state -- feels a lot cleaner. We could also do something with methods here if we wanted, instead of just using objects as data bags -- many possibilities. I think 3) makes the most sense -- this would be a new feature regardless and that seems like by far the cleanest way to implement it. Type errors, etc. for arguments would need to be handled by the authors of the fab functions (they would no longer be just strings), but it would otherwise mesh with the existing syntax. Just an FYI that we have half-formed plans regarding the general problem of task arguments and typing: http://code.fabfile.org/issues/show/69 -Jeff P.S. Going on the road again for the next 4 days so if I am delayed in replying, that's why =) -- Jeff Forcier Unix sysadmin; Python/Ruby engineer http://bitprophet.org ___ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
[Fab-user] env.user and prev_user in the presence of env.hosts
First off, congrats on fabric, this is a really useful tool. I'm using fab with some cloud based infrastructure, especially in situations where host names are transient, and a number of other configuration/connection issues come into play. I was confused by some behavior in fabric. When you set env.user in one function, it will typically be passed on to the next, just like any other field set on env. However, when env.hosts are present, env.user is discarded without any indication of what's happening. I had one workflow set up as follows: #fabfile ... def build_ami() : # build an amazon ami, retrieve the public dns name, and use it to update env.hosts def user(name) : # set env.user to the name argument def ssh(index=0) : # ssh into the first host in env.hosts ... I was building ubuntu ami's, and running the command as follows: $ fab build_ami user:ubuntu ssh However, I soon learned that once env.hosts are set (in build_ami), user:ubuntu will not actually change env.user (it saves the value in prev_user, and resets it after ssh returns), and ssh will try to login with the original user name. I could set the name inside build_ami with an argument, but I wanted to use the original env.user inside this function for ec2 tagging purposes. I was able to work around this by using env.user_local The question is, what is the purpose for this behavior? I couldn't find anything in the documentation that explained why it was doing this. The next question is, is there a group of people that are sharing best tips, etc. for using fabric on cloud based systems? Is there a better option? I'd rather not invent the wheel, or force square pegs in round holes here. Thanks again, -Justin -- Justin Donaldson, BigML, Inc. o: 313-31BIGML | c: 919-BUZZJJD ___ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
