Vagrant Issues

[joeyespo]

Opening this to have a one-stop shop for all things Vagrant. (This way, I'll know about them and can help address them!)

[joeyespo]

I know @abnor was having trouble last week. I dug deeper this week and I think this thread can shed some light on what we were seeing.

Afaik, the root of the problem is that Windows doesn't like symlinks. (Or it's more general than that? Although it did work for others, so maybe not.) Virtualenv uses them extensively on Linux. Since Vagrant shares a specific directory, there's "protocol error" issues.

@abnor Kill all VirtualBox-related processes (or restart) then run the git shell as an administrator. If that doesn't help, try this (first!) or this or this from that same thread.

Let me know if any of these help!

[zbynekwinkler]

It should clear the env directory before starting. I've been testing this on windows and now I have env with mixed content (part from windows and part from vagrant).

Compared to plain linux or plain windows install it is slow as hell 😓. Just installing all the requirements.txt takes ages.

What I do not understand is why it works at all. Default box is precise64 and my windows install is 32bit. How can 64bit guest work under 32bit host?

Ok, I got all the way to ./env/bin/swaddle local.env ./recreate-schema.sh which results in psql: FATAL: role "root" does not exist.

When I try vagrant ssh (since I am not sure how to use the things vagrant has set up) and try psql it says psql: FATAL: role "vagrant" does not exist. Running psql postgres://gittip:gittip@localhost:5432/gittip returns the same. I am not sure who and why is looking for vagrant role.

Following the README.md instructions I was able to run

sudo -u postgres createuser --superuser $USER
createdb $USER

At this moment plain psql command connects to a fresh $USER database. So now empty DATABASE_URL does work (running make schema with empty DATABASE_URL worked). Also make run gives me working gittip.

Running psql -U gittip -d gittip says authentication failed. It seems this version of psql has trouble parsing the DATABASE_URL :(. I suggest using $USER for both role and dbname and keeping DATABASE_URL empty by default. Also installing 9.3 by default now #1158 would match the current production environment.

[zbynekwinkler]

https://www.virtualbox.org/manual/ch03.html#intro-64bitguests so 64bit on 32bit works.

[zbynekwinkler]

Oh, and I failed to get working plain windows install because I was not able to compile the binary extensions we have.

[chadwhitacre]

For a plain Windows install you'd probably want pre-built binaries of psycopg2 (what else?).

http://www.stickpeople.com/projects/python/win-psycopg/

[zbynekwinkler]

Pre-built psycopg2 does not play nice with pip & virtualenv (I could not
make it work). Also libsass is needed.

On 21 January 2014 14:37, Chad Whitacre notifications@github.com wrote:

For a plain Windows install you'd probably want pre-built binaries of
psycopg2 (what else?).

http://www.stickpeople.com/projects/python/win-psycopg/

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1887#issuecomment-32885232
.

[joeyespo]

@zwn I couldn't get psycopg2 to work on Windows without Vagrant either. Well, without replacing what's in vendor manually. This was why I was such a strong advocate of a pure-Python local run with, e.g. sqlite, or using Vagrant with only downside being its long boot time.

As for the non-empty env directory. That's a good catch. We should probably use an entirely different directory like vagrant-env so you can run with and without Vagrant. Can the "env" directory be configured with an ENV variable?

[chadwhitacre]

@joeyespo Can we update this ticket based on open hack? Where do we stand now?

[chadwhitacre]

Bumping from DevX to DevX★.

[chadwhitacre]

@joeyespo This ticket is vague. Can we put a point on it? Let's use it to track upgrading Vagrant to Postgres 9.3. Eh?

[joeyespo]

@whit537 this was to track any issues new devs have, really.

Postgres is one. The 'env' directory is another. For the latter, is there a way to use a different 'env' directory so there's no clashes when running with Vagrant and running without? Say, "vagrant-env"? That way Vagrant can safely assume it can delete that when it needs cleaned.

[chadwhitacre]

@joeyespo I'd rather not keep long-running dust collectors like this around. Let's make specific tickets for specific problems. That way we avoid cluttering up the issue tracker (it's bad enough as it is!) and we ensure that we have actionable items that we can then prioritize.

[chadwhitacre]

Since we started talking about the env dir earlier on this thread, I've reticketed the Postgres upgrade as #1959.

[zbynekwinkler]

I have vagrant working on windows with almost empty Vagrantfile and this gist script. I was having troubles with shared folders. For one, it was slow as hell and sometimes it failed to create the virtualenv (it was also being mixed up with the files already there). I think that a usable middle ground would be to keep the env inside vagrant-native filesystem and share only the source files.

[joeyespo]

@zwn My thoughts were to have a dedicated vagrant-env directory so that the file issue would go away. Namely, the newlines differences were creating a lot of problems. It's also good grant Vagrant the right to delete its own 'env' variant when a clean is needed so it's not overstepping any boundaries, i.e. "Vagrant why did you delete all my env files? I was using Linux!"

If we can cusomize the env directory, then yes, we could keep it in the vagrant-only filesystem and still call it env. +1 for that.

[zbynekwinkler]

I was thinking of mount --bind olddir newdir but I don't know if that works over the shared folders or if it fixes the problem. Will try tomorrow. Feel free to beat me to it 😉 We would also have to change from rm -rf env to rm -rf env/*.

If that does not work we need to make the name of the virtualenv directory configurable.

@joeyespo Do you have a preference? While Chad starts to improve the user onboarding, we can do something about developer onboarding 😺

[joeyespo]

What would you be mounting? The virtualenv running within Vagrant can generate the env directory in the virtual filesystem. (But I think you're saying that and I'm missing your point.)

[zbynekwinkler]

Directory www.gittip.com is currently shared so it lives on the host system. When in vagrant, make env writes to directory www.gittip.com/env. I would be mounting empty guest-native directory over www.gittip.com/env so that vagrant can feel free to do with the contents anything it pleases and does not clash with its possible contents from non vagrant usage. If you had different idea how to make vagrant generate env in guest-native directory while keeping www.gittip.com shared, I am all ears 😃

[zbynekwinkler]

But it is not working for me anyway. The population of the env directory fails with

InstallationError: Command python setup.py egg_info failed with error code -9

but for different runs it fails for different packages 😠. The third run finished successfully in 3:30s (fourth failed again at a different place). When run on the guest filesystem only (the whole repo being there instead of just the env dir) it took 2:05s and has not failed a single time.

So, with this I think I am done with vagrant specific stuff. I am going to keep using vagrant to tune the get-gittip.sh script but I will not focus on vagrant specific stuff because it just does not seem worth it to me. The script should be able to bring current Ubuntu LTS release to a state where one can do gittip development (others can use it as a source of info for what might need to be installed on their system).

Anyone feel free to pick up the vagrant specifics.

[joeyespo]

Oh yeah, I was saying have the env directory live somewhere else within Vagrant. Like /usr/var/www.gittip.com/env or something. (Not sure where the proper place to put it is, but just so long as it's on Vagrant and not in the shared directory.)

The contents should still be there when you return to Vagrant, and it won't be in the gittip repo this way so Vagrant is free to do what it wants with it e.g. clear it when needed.

(I'm also not sure what you mean by guest-native.)

[zbynekwinkler]

That's what I meant by guest-native. I am not sure if its worth the effort to make the env dir configurable to support this.

[joeyespo]

Perhaps not.

If we're fully supporting and encouraging Vagrant, I believe we should. There's still the possibility of a pure-Python local run though, which every time we tinker with Vagrant, seems like less and less work in comparison.

[patcon]

@joeyespo fwiw, I think this might be the solution to the disagreement that we were having at the retreat about Docker vs config management tools (Chef/Puppet/Ansible/newfangle):
https://github.com/mitchellh/packer

Packer has builders.

Packer has provisioners.

A provisioner, like the chef-solo one, knows how to create an image on a builder platform such as DigitalOcean or Docker.

[chadwhitacre]

My sense is that the Vagrantfile has settled down and some folks (@clone1018 @patcon) are actively using it for development. Closing. Let's reticket specific issues that arise.

[joeyespo]

👍