Use deployment tools to install a test server on localhost?

[jimallman]

This would be a nice way to handle the quirks and complexities of our system, but so far it's pretty tricky on systems other than the expected Debian GNU/Linux.

In our scripts, we've made lots of assumptions about things like home directories. So installing on another system like OS X will necessarily involve some kind of privileged "preflight" script to enable services, create users and directories, etc. There are probably other obstacles ahead.

Perhaps the real answer is to use a local VM (VirtualBox, Parallels, VMWare, etc) with a minimal Debian. Or a prepared VM (opentree and admin users already created, keys in place) that's ready to accept push commands.

[jimallman]

To explore this further, I've added a branch to deployed-systems that adds a new server-config file localhost.config that tries to deploy the devtree server to localhost.

[jar398]

Or maybe docker.

-- apologies for brevity / using handheld gizmo --

On Aug 5, 2014, at 22:18, Jim Allman notifications@github.com wrote:

This would be a nice way to handle the quirks and complexities of our system, but so far it's pretty tricky on systems other than the expected Debian GNU/Linux.

In our scripts, we've made lots of assumptions about things like home directories http://en.wikipedia.org/wiki/Home_directory#Default_home_directory_per_operating_system. So installing on another system like OS X will necessarily involve some kind of privileged "preflight" script to enable services, create users and directories, etc. There are probably other obstacles ahead.

Perhaps the real answer is to use a local VM (VirtualBox, Parallels, VMWare, etc) with a minimal Debian. Or a prepared VM (opentree and admin users already created, keys in place) that's ready to accept push commands.

— Reply to this email directly or view it on GitHub https://github.com/OpenTreeOfLife/opentree/issues/403.

[jar398]

I don't think that incrementally enhancing the deployment system is necessarily a good investment. It really needs an overhaul, or we need to switch to something like ansible.

Why do you want to use a local VM? It is very easy to set up new EC2 servers and I'll make one for anyone who wants one. The asterales system is ready to be used if what you need is the whole system and not just the front end.

On Tue, Aug 5, 2014 at 10:18 PM, Jim Allman notifications@github.com wrote:

This would be a nice way to handle the quirks and complexities of our system, but so far it's pretty tricky on systems other than the expected Debian GNU/Linux.

In our scripts, we've made lots of assumptions about things like home directories http://en.wikipedia.org/wiki/Home_directory#Default_home_directory_per_operating_system. So installing on another system like OS X will necessarily involve some kind of privileged "preflight" script to enable services, create users and directories, etc. There are probably other obstacles ahead.

Perhaps the real answer is to use a local VM (VirtualBox, Parallels, VMWare, etc) with a minimal Debian. Or a prepared VM (opentree and admin users already created, keys in place) that's ready to accept push commands.

— Reply to this email directly or view it on GitHub https://github.com/OpenTreeOfLife/opentree/issues/403.

[jimallman]

Why do you want to use a local VM?

To quote @kcranston from a recent discussion on IRC:

two use cases: 1. me, today: I want to make a simple UI change and test locally before creating a pull request. 2. A new developer wants to test the application for his / her use.

So it would be great to have a more "lightweight" option for getting up and running. Agreed that docker or a pre-built appliance could work well for these use cases, if it's easy to push and test changes.

I'll hold off on any work here for now, since (as you point out) the deployment system is still kind of in flux.

[jimallman]

@jar398, @kcranston, @temi : I spent most of this weekend tinkering with a fork of @temi 's Ansible deployment repo. I cleaned up some problems with the Ansible playbook (i.e., task and role definitions) and learned enough about Ansible to confirm that it can handle all the complications (virtualenv, etc) we would throw at it.

I'm setting this aside for now, but we might want to revisit this and come up with a series of playbooks to handle use cases like routine deployment, code review, and isolated systems for scientific exploration.

[jar398]

I spent some time on this over the weekend. The user name for the user running the services is no longer hardwired as 'opentree'; you can set it in the configuration file. I tested this and it seems to work. (I missed one spot in one of the apache configuration files, need to get back to that.)

There's currently an assumption that the files are located relative to that user's home directory, but this should be easy to generalize (I'll make an issue for this as I may not get to it this week).

We're very close to being able to use the deployment system to run locally or in a VM. Not that I'm opposed to a rewrite of the deployment scripts, though.

On Mon, Sep 29, 2014 at 12:48 PM, Jim Allman notifications@github.com wrote:

@jar398 https://github.com/jar398, @kcranston https://github.com/kcranston, @temi https://github.com/temi : I spent most of this weekend tinkering with a fork of @temi 's Ansible deployment repo https://github.com/OpenTreeOfLife/opentree-install. I cleaned up some problems with the Ansible playbook (i.e., task and role definitions) and learned enough about Ansible to confirm that it can handle all the complications (virtualenv, etc) we would throw at it.

I'm setting this aside for now, but we might want to revisit this and come up with a series of playbooks to handle use cases like routine deployment, code review, and isolated systems for scientific exploration.

— Reply to this email directly or view it on GitHub https://github.com/OpenTreeOfLife/opentree/issues/403#issuecomment-57190588 .

[temi]

great! will check it out.