bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: Demo VM ready (was: RE: Public demo instance hosted by third party)
Date Tue, 22 Jan 2013 18:39:50 GMT
On 22/01/13 09:04, Gavin McDonald wrote:
> Hi All,
> As promised, a VM is ready to go.
> Currently gjm, mpoole and myself have access.
> Let me know if anyone else in interested in helping to maintain the demo VM
> as a whole.
> I'd like to help with the setting up of the Demo Instances, so my work is
> done here with my infra
> hat for now, but will continue on with my bh hat on if I may.
> Thanks
> Gav...

Fantastic. Thanks for that Gav!

So, the point of all this was to have two demo instances for people to 
play with - one to show the current release and one to see the absolute 
latest. I'll refer to them as Current and Nightly respectively, with no 
particular justification of those terms.

Each instance will require separate python environments and I have been 
using virtualenv to do this so far. Is this reasonable or would it be 
preferred to create proper sandboxes with something like lxc?

Nightly will update from trunk. Current does not strictly need updating 
from the repos between releases but it might be nice if we did not have 
to consider changing anything on the vm in order to switch between 
versions. If it is truly the current release (rather than the last tag 
or highest version tag) we will probably have to provide an extra 
instruction to release managers to make it work.

For the database I think I suggested PostgreSQL before but perhaps it is 
easier not to worry about this for now - I suspect sqlite is good 
enough. Beyond that, our installation page specifies the following deb 


For the webserver we should additionally need


I believe that is enough to do all the current installation steps as 
long as we are happy to pip install using the requirements file.

And that will probably do us for now but I would like to be getting both 
instances some initial data so that each reset is not too much of a 
blank slate.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message