While I can’t comment on the Islandora piece, I’ll make the following comments about Vagrant in the context of how we use it as part of our development and ops process:

- Vagrant is used as described below for “disposable environments and consistent workflow” for testing our automation scripts and tools - we use fairly barebones Vagrantfiles to bring up VMs that match our production environment targets, then provision those with the same Ansible playbook intended to be used in production. This lets us rapidly develop and test our automation before turning it loose on an environment outside our local machines

- production servers are also virtual machines, using KVM on Red Hat; these get provisioned with the same Ansible playbooks developed initially using Vagrant. There’s nothing inherently unsound about the idea of running using virtual machines in production, provided you understand the reasons behind and accept the overhead of doing so (in our case, our production VMs are launched and managed on a large, dedicated cluster intended for virtualization)

- it’s possible the idea is to use Vagrant as a virtual machine management solution in production; I agree with others below that this isn’t an optimal solution, nor I think would Vagrant’s creators (I personally Hashicorp has blurred the lines on this in recent years as they try to extend their business model, which may be where some of this is coming from)

- if the position is that Vagrant is the same class of environment isolation tool as RVM or virtualenv, that’s a misunderstanding; RVM or virtualenv create isolated environments with very little overhead running on the same system, while Vagrant creates virtual machines with all the overhead that entails

ALAN HARNUM
SENIOR INCLUSIVE DEVELOPER
INCLUSIVE DESIGN RESEARCH CENTRE, OCAD UNIVERSITY

E [log in to unmask]<mailto:[log in to unmask]>

On Apr 7, 2016, at 1:56 PM, Annamarie C Klose <[log in to unmask]<mailto:[log in to unmask]>> wrote:

Thank you to everyone who provided feedback on this issue. I've posted my question to the Islandora Google group, as well. I'll be meeting with my university's IT department on Monday. I appreciate your help!

Anna

-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Cindi Blyberg
Sent: Wednesday, April 06, 2016 5:46 PM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [CODE4LIB] Islandora & Vagrant - Development use only?

Cary, the snippet to your email as shown in my inbox only showed the first sentence. Glad to read the rest! :)

On Wed, Apr 6, 2016 at 2:01 PM, Cary Gordon <[log in to unmask]<mailto:[log in to unmask]>> wrote:

I disagree with the statement that "Vagrant is not a good idea for
production.” Vagrant is a terrible idea for production, and it is not
designed for that.

We use Ansible to build Islandora, and, after three years of talking
about it we are starting to use it with Docker. We are an AWS shop, so
we use Docker with AWS elastic container service, which could come in
handy if one of your archives gets slashdotted.

Cary

On Apr 6, 2016, at 8:53 AM, Chris Fitzpatrick
<[log in to unmask]<mailto:[log in to unmask]>>
wrote:

Vagrant is not a good idea for production. It's really for people to
work against a copy of the production environment.
Like you can use Vagrant, then update a ansible or puppet or chef
script then deploy that to yr VM.
Hashicorp is making something called Otto which is supposed to
replace Vagrant for end-to-end deployments like this, but that's in alpha now.

Vagrant isn't  like virtualenv at all. Virtualenv is a way to
maintain Python dependencies by mucking around with some environment variables.
It's
more like Ruby's bundler.

It's kinda more like Docker. Docker makes linux containers. Nobody
knows what those are, but they work great.

I've seen Vagrant used in production and it supposedly worked well
but
the
guy who set it up left and things went bad. It wasn't a performance
issue,
it's just really hard for the replacement to figure out what's going on.
Use Vagrant with Ansible/Puppet/Chef. Or use Docker. Or use all of
that, for the win.



On Wed, Apr 6, 2016 at 3:55 PM, Francis Kayiwa <[log in to unmask]<mailto:[log in to unmask]>> wrote:

On 4/6/16 9:49 AM, Annamarie C Klose wrote:

Hi, all,

Can anyone provide a technical explanation as to why it is not
appropriate to install Islandora on a public server with Vagrant?
Despite
all the documentation instructing that Vagrant is for development
only, my
university's IT department thinks Vagrant makes Islandora more
secure
for
production use. They have also stated "Vagrant is used to keep
dependencies
separate on machines in the same way Pythons Virtualenv or Ruby's
Docker
is." Unfortunately, secure networking is outside of my expertise.
I'm concerned that Vagrant's virtualization is a poor substitute
for the
real
thing. Before I add hundreds of records to Islandora, I'd like to
make
sure
that I'm building my library's digital collections on a steady
foundation.
Any advice and/or explanations to give IT is welcome.



If we agree  that your University IT are the Operations people find
the nicest way to tell them how the developers of Vagrant view the
tool
below

https://www.vagrantup.com/docs/why-vagrant/

Specifically. "...If you are an operations engineer, Vagrant gives
you a disposable environment and consistent workflow for developing
and
testing
infrastructure management scripts..."

You are also correct in being wary about having a production
application running on Vagrant. A part of me wants to test that
just for laughs,
but it
will be painful to set up for them and the performance will
horrible for you.

Cheers,
./fxk

--
"Anyone attempting to generate random numbers by deterministic
means is, of course, living in a state of sin."
-- John Von Neumann