Development environment

[jessevondoom]

Our current vagrant setup is out of date and pretty far off what we're actually deploying for our hosted stuff. I think it's time we look at building up a new development environment — ideally one that can also be the kernel of a better distribution method for people looking to run their own instances.

So this is really multiple things. We want to:

• Ditch the old single/mutli hosted/distributed mindset
• Drop support for sqlite
• Build a box we can test with as close to our production servers as possible
• Build a box that could be launched to S3/Rackspace/similar by anyone looking to run their own
• Pre-populate the database with three admin users: one empty account, one full with demo data/settings, one for development use (the demo data/settings might need to live in a separate/private repo since it would include keys, etc.)

Vagrant is nice for the ability to store a vagrantfile in our repo and let folks just vagrant up. Would be nice to keep that. How much of out puppet scripts remain viable in that environment? How hard is maintenance?

Opening this issue to serve as a thread for development.

[paperscissors]

A big thing for me is some way to more easily flip env variables with re-provisioning the box.

[jeffsheltren]

@paperscissors could you give an example?

[paperscissors]

@jeffsheltren two things i ran into while trying to setup a self-signed cert--- on vagrant we need to set the API URI via env variables in vagrant settings, or else all of the CSS and JS are broken on HTTPS on the machine.

@jessevondoom also just introduced a quick and dirty debug mode that requires a debug flag in those vagrant env variables. To the best of my knowledge vagrant up nor reload will reload these variables, only provision. It's not the end of the world, but every time i run provision I'd have to setup SSL all over again.

On the subject of SSL--- now that we're dealing with Stripe and SSL is required to run the seed, should we just bake a self-signed cert into the box provisioning?

[jessevondoom]

Yeah I think we definitely want to add a self-signed cert or install letsencrypt or something. A few other seeds require SSL, and more will follow.

Re: dubug and envvars: the current vagrant is set up to add Apache environment variables that trump whatever's in the ini. Was a feature, kind of now a bug. Think we ditch that and let this box read off the local cashmusic.ini.php file and be done with it.

[paperscissors]

That sounds like a better approach!

[jeffsheltren]

Ideally we would use the puppet tree that's already used for the test/stage/production server environments since that will be as close as we can get to matching those servers in a local developer environment. We already have Vagrant configuration and instructions there which make it possible to bring a VM online locally using Vagrant + Virtualbox. So instead of trying to reproduce the Puppet configuration somewhere else, I'd like to focus on using that existing tree and working to make the Vagrant setup (for Virtualbox) there as easy and automated as possible. Once that's working, we can start looking at leveraging that to let people deploy Rackspace or other VMs using the same Vagrant / Puppet tree.

The Vagrant image there is already configured to mount your local platform repo under an apache document root, load an empty DB into MySQL, and add a dev user to login as. Testing this with @waferbaby we've found some issues with the site under that environment that we'll need to sort out, but I believe we can get that going, especially with some help from @jessevondoom.

We'll definitely need to think a bit about SSL since we'll need that enabled on the VM and it isn't currently. Let's Encrypt is interesting, although I'm not sure it'd work for our use case; I'll review it though. We may need to stick with a self-signed cert using a pre-set hostname (we're already assuming vagrant-multi1.cashmusic.org within Vagrant/Puppet, so I'll plan to stick with that if nobody complains).

Anyway, long story short, I'd like to focus on the existing Puppet tree and make improvements there to make the development setup easier. Could we start opening up specific issues in that issue queue for bug fixes/improvements? First off, I'll suggest we need to rename the repo, though I'll have to make some changes server-side to account for that change...

@paperscissors @jessevondoom If I understand correctly about the vagrant env variables for the old Vagrant -- are those just changing things within cashmusic.ini.php? If so, that's something that the developer could do directly in the file under the other/new Vagrant setup. If there's other specific functionality needed, let's discuss.

[waferbaby]

@jeffsheltren: Yeah, Let's Encrypt is a great service, but the certs are short-lived - I could see that being an unnecessary nightmare 😁 Self-signed makes sense.

[paperscissors]

@waferbaby @jeffsheltren can't you set them to auto-renew though?

[jessevondoom]

Two points to @jeffsheltren's comment:

1. We're currently using sqlite for the Vagrant setup because I had trouble setting up MySQL on Vagrant. Which is dumb. But I wasn't familiar so much with puppet and did most of it...not so well. So we need to add MySQL and then yeah...the same Vagrant installer will work pretty much out of the box.
2. Far easier/better news with the way the environment variables work. Right now we put them all into memory as Apache environment variables which actually lets them supersede whatever's in the actual cashmusic.ini.php file. (A holdover from Cloud Foundry days.) Mostly did this so I could maintain a MySQL install and have them work in parallel. So we can ditch it entirely...just delete that step completely and the dev will regain control over settings with their cashmusic.ini.php file.