launchpad-dev team mailing list archive

[Elliot Murphy <elliot@xxxxxxxxxxxxx>]

On Sun, Sep 26, 2010 at 6:41 PM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> wrote:
> We can even 'run' postgresql in this fashion, and have it return the
> DB name to use.

This would be fantastic - having to configure postgres *at all* in
order to get a launchpad dev system running is a barrier to the drive
by contributor IMO. I believe I've already pointed you at
implementation details for firing up an ephemeral instance of postgres
(which I originally stole from jeroen).

> Now, the cheap test iteration case can be addressed:
>  - devs run eval `bin/run -i test --daemonise`
>   - this outputs all the variables for all the servers started.
>  - test code looks for a *per-service* information about pid files etc.
>   e.g. LP_LIBRARIAN_PIDFILE and LP_LIBRARIAN_CONFIGFILE rather than
> LP_PERSISTENT_TEST_SERVICES
>  - to kill, eval `bin/test-servers --stop`
>   (Which will kill the daemonised wrapper, and unset the environment
> variables).
>  - If LP_PERSISTENT_TEST_SERVICES is set and a service isn't running,
> I propose to error, because I think it usefully indicates a bug in
> that external process, and this is easier than detecting both 'not
> started yet' and 'started but crashed' - especially given the test
> runners tendancy to fork sub runners.

This is a really nice generalization of the pattern I was trying to
use for all the servers on my last project, you've managed to make the
rules much simpler and uniform.

> Concurrent testing then is easy: as long as all the fixtures are
> meeting this contract, if the *default* behaviour is to  bring up a
> unique instance, everything will come up fine.
>
>
> Note that in this model there is never a need to do more than 'kill
> helper-pid' to shut something down: that helper pid will encapsulate
> all the cleanup logic, kill-9ing, dropdb of temporary dbs etc, and the
> helper code should be simple and robust. This will help give us a
> simple, robust interface.

And this is my favorite part, so much simpler than what I've seen in
the past. I can't wait to see this in action.
-- 
Elliot Murphy | https://launchpad.net/~statik/