Re: [Fab-user] Beta 1 out

[Niklas Lindström]

Hi!

2009/7/9 Jeff Forcier <address@hidden>:
> 2009/7/9 Niklas Lindström <address@hidden>:
>
>> 1. It seems the old issue I had with a command failing to return
>> ("tomcat start") is in 0.9b1 but not on master (provided "git-checkout
>> 0.9b1" switches to that and "git-checkout master" switches back, which
>> is how I tested this).
>
> Can you refresh my memory about this issue? I recall hearing about it
> but don't have time to go find the old email right now :(
>
> 0.9 and master are still nearly identical right now so it would be
> kind of odd for a bug to exist in only one of them -- fwiw.

Ouch, I had only done a "git fetch", so I was sort of lying. :( I can
see now that master behaves the same, that it, it freezes. What I do
is this (on an ubuntu server)::

    def restart():
        sudo('/etc/init.d/tomcat6 stop')
        sudo('/etc/init.d/tomcat6 start')

Stop works, start works, but the process just hangs there (cannot
ctrl-c, have to kill it):

    [the-server] out:  * Stopping Tomcat servlet engine tomcat6
    [the-server] out:    ...done.
    [the-server] sudo: /etc/init.d/tomcat6 start
    [the-server] out:  * Starting Tomcat servlet engine tomcat6
    [the-server] out:    ...done.
    ## dead in the water...

Will this: "Updating e989277..dc65d87" give you a clue of when this
behaviour changed? (I should help you dig if you can't reproduce this,
if I get/take the time..)


>> 3. I have to decorate commands with @roles even if they only call
>> other commands that are already decorated with @roles. Is this
>> intentional/hard to fix?
>>
>> 4. A thing which worked in the old fabric 0.1, was to call another
>> function which sets ``env.hosts`` (actually, I think it only worked
>> via @depends).
>
> These are both because of the new execution model, where the host list
> (meaning hosts and/or roles) a function runs on is determined at
> runtime, *before* entering your function. The best way to work around
> this for now is to set env.roles or env.hosts within a function (like
> with your #4) but to call that function on the command line and _not_
> within another function.
>
> In your example, you need to do "fab setup_a ls_a" and remove the
> "setup_a()" call within your "ls_a" function. I do this now to provide
> "environments", e.g. "fab staging deploy" or "fab production deploy"
> and so on.
>
> If it comes up that there are things you or others need to do that are
> not pretty easily solved like above, I may try to reinstate the older
> execution model as an option, but for now I'd prefer to keep things
> simple as long as it doesn't cause too much heartbreak (so let me know
> if it does!)

I understand. Well, my problem is two-fold.

As described in #3, its a tiny bit annoying that role isn't picked up
from a "composite" command, since I may want to do several things at
once and not duplicate the role(s) of those things in the "composite".

As for #4, I use "environments" + roles for this effect as you
suggest. But I have had cases where I'd like to do something like
(based on your example) ``prod_deploy`` (a bit contrieved, I know). So
perhaps it'd be nice to determine host list as late as possible?

I previously "faked" the roles feature (set a host dict in env similar
to roledefs with "environment" commands, and activated that role with
functions picking hosts from this dict. That's why I saw the "eager
hosts" effect in my script -- I still used that and had to do e.g.
"fab integration main main_deploy", altough "main_deploy" actually
invoked "main".

My remaining thing with this is that I could also use "requires" with
this, so that commands that needed a role (as opposed to "main_deploy"
which depends on the main role settings. Now when I use the generic
"restart", I can complain about a missing "environment", but not that
it requires a role as well. (It would also be kinda cool if
@roles("*") or similar worked, but of course I can supply the (3)
roles I have explicitly.)

(Context: "main" is the main app; I also have "service" (search
indexing etc) and a "examples" which are data providers to "main"..)


>> 5.  `fabric.contrib.files.exists` fails intermittently (on an ubuntu
>> server). I get the feeling it fails to capture the result "in time" or
>> something.. Instead, I use ::
>>
>>        exists = lambda path: not run("test -d %s" % path).failed
>
> If you could dig into this a bit more, I'd really appreciate it. I
> don't see why using 'test' would garner consistent results where 'ls'
> is somehow intermittent -- they shouldn't be that different. When you
> say intermittently, do you mean with the exact same invocation, or
> that it works for some inputs but not others?

The exact same invocation, oddly enough. But I *cannot* reproduce this
with the current master (nor 0.9b1..). Will get back if I find out
what this was about.. (That said, I still like the "test" solution a
bit, especially since you can base an "isdir" on that as well. But
that's just a suggestion. ;) )

I do wonder if the "restart" hanging failing and this working have
anything to do with each other under the hood (alas, 'fraid I've got
no more time to dig right now..)

> Thanks for all the feedback :)

Thanks for all the work. ;)

Best regards,
Niklas