Should we keep vagrant as a means of deployment?

ARTbio / GalaxyKickStart

Ansible playbooks for Galaxy Server deployment

GNU General Public License v3.0

24 stars 22 forks source link

Should we keep vagrant as a means of deployment? #176

Closed mvdbeek closed 6 years ago

mvdbeek commented 8 years ago

I see a few pro's and con's here (quite subjective though!):

Pro:

(slightly) easier to use then docker on a mac or windows
If we do manage to test an image (vagrant in docker maybe?), we can also test migrations over time (from very old to newest)

Cons:

More complicated to use/deploy then docker
More difficult to test
Changing ubuntu base-images -- we don't have an update procedure for this
We haven't documented how to persist data (have we ever tried?)
A lot of backend tchnologie (VMware, Virtualbox, Docker) -> a lot of potential difficulties
~~No idea what ansible version is running in the base images~~ ansible is running on the host (d'oh)
More difficult to debug / less familiar with the stack.

drosofff commented 8 years ago

Vagrant used to work in the master branch. I don't like the idea of fixing a bug by not supporting the feature any more.

mvdbeek commented 8 years ago

Sure, that is not the reason I made this list, I had this in my head for some time now. There are valid points in that list. Most importantly we would need to describe the procedure to persist data. That would probably need to happen through network exports, and that will be quite different based on the host OS, with a lot of things that can go wrong. And I think this is a bit out of scope for galaxy kickstart. But it's up for discussion, that's why I made this issue. An alternative way forward is to insist treating Vagrant images as ephemeral (ie do no real work here!), we remove the automatic provisioning and we insist people connect with ansible as described in the section just before Cleaning up

drosofff commented 8 years ago

I like the vagrant part of the software a/ because it's an additional way to show the adaptability of the software to multiple configuration. Many bioinformatician use VM for themselves and for biologists. Saying it differently, it's part of the show case and I always thought that "git clone & vagrant up" is pretty convincing. b/ Indeed its part of the testing of the system, even if it is not used by "customers".

Again, my point is that, currently, in the master branch, vagrant up is working (I retested it yesterday). This is not as we were talking of a picky and failing initiative for running gks on a personal computer under mac os x or windows. So I will not argue for a strong support of this feature, but I take the failing of vagrant up in the dev branch as a sign of something is going wrong. If we just have to ensure that the user as an up to date image, it's easy to document.

mvdbeek commented 8 years ago

This is not as we were talking of a picky and failing initiative for running gks on a personal computer under mac os x or windows.

I would really value it if you go through the items in the list that I have mentioned. Because I personally think this is actually a failing initiative for running gks on a personal computer under mac os x or windows or linux. And we'll have to support this over time.

Please see this uncoupled from the PR (which is working for me, which just shows again that it is a technology that is more difficult to test because of more unknown variables in the mix)

drosofff commented 8 years ago

I would really value if you go through the answers I have mentioned, too.
Sorry by I will not see this uncoupled from the PR: you may have thought for a while to abandon vagrant support, but tell me why it is popping out now.