bundle not found

[nrel]

bundle not found

[GUI]

Hm, it looks like perhaps the vagrant box didn't finish provisioning (basically, installing all the needed dependencies, such as bundler, git, etc). Provisioning automatically happens when you run vagrant up for the first time. Provisioning can take a while, but it sounds like it may have died before it completed. Do you remember getting any errors at that earlier vagrant up step?

You can try re-running the provisioning process by running vagrant provision (from your host computer's terminal and not after SSHing into the vagrant box). If you run that again, does it look like it succeeded (again, it can take a while to run)? Or if not, can you provide the output from running that command?

Assuming the provisioning succeeds on a second try, then you should be able to pickup again with the installation instructions at the vagrant ssh step.

[jots]

When I ssh'd into the vagrant, my other shell (the one I ran vagrant up from) was hung at this:
[default] -- v-csdb-3: /tmp/vagrant-chef-1/chef-solo-3/data_bags
[default] Running provisioner: Vagrant::Provisioners::Shell...

is it supposed to come back to a command line? It had been stuck there for 60 minutes or so.

I just now ctrl-c'd it and am running:

% vagrant provision
[default] Running provisioner: Vagrant::Provisioners::Shell...

will it come back to a command line when it's done?
any idea how long it's supposed to run? downloading the
base unix machine only took a few minutes.

i am running this on a windows 7 box.

thanks!

[GUI]

Ah, I actually just ran into this same issue on a coworker's Windows box last week while trying Vagrant on Windows for the first time. Vagrant should work on Windows (since abstracting everything into a platform-agnostic VM is the point of Vagrant), however I think this is related to a current bug in Vagrant and Windows. It's been fixed by hashicorp/vagrant#1182 but a new stable release hasn't been made yet.

In the mean time, I think you can work around this by commenting out lines 48-50 in your Vagrantfile. Then I'd run:

$ vagrant destroy # Just so we're back to a clean Vagrant box, since we install bundler and capistrano slightly differently (via rbenv).
$ vagrant up
# I believe the Chef-based provisioning should still work. Assuming that works...

$ vagrant ssh
$ sudo mkdir -p /srv/sites && sudo chown vagrant /srv/sites # Manually run one of the steps we commented out from the Vagrantfile

# Then continue with the rest of the post-'vagrant ssh' steps from the README

As I mentioned, the provisioning can take some time, but your terminal shouldn't hang like that, and you should be getting all sorts of output to your screen, telling you what it's doing. For reference, though, this takes maybe around 20 minutes to do everything from scratch (but this is a one time thing). If the process looks like it's hanging again, let me know, though.

Hopefully they'll release a new version of Vagrant soon that includes this fix for Windows, but in the mean time, I think this might let you get up and running without too much inconvenience.

[jots]

Thanks so much Nick! I hand patched vagrant with your suggestion and made it much further. I did vagrant destroy then vagrant up, and got stuck here:

[2012-12-10T00:37:18+00:00] INFO: Processing execute[yum -q makecache] action run (/tmp/vagrant-chef-1/chef-solo-1/cookbooks/yum/providers/repository.rb line 79 )

Error executing action run on resource 'execute[yum -q makecache]'

Mixlib::ShellOut::ShellCommandFailed

Expected process to exit with [0], but received '1'
---- Begin output of yum -q makecache ----
STDOUT:
STDERR: http://downloads-distro.mongodb.org/repo/redhat/os/i386/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404"
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: 10gen. Please verify its path and try again

I think it's that i386 is gone and now there are these:
http://downloads-distro.mongodb.org/repo/redhat/os/
but i'm not sure which one nor what file to edit to use the new one,

[jots]

I changed /etc/yum.repos.d/10gen.repo to:
baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/i686

after reading:
http://ulaptech.blogspot.com/2011/03/new-yum-repo-for-mongodb.html

So I have made it past that error.

[GUI]

Ah, sorry for all the trouble. There was a bug in our mongo installation scripts when installing onto 32 bit systems (the URL was wrong). If you git pull down the latest changes, and then run vagrant provision again, I think this should at least fix this issue. Sorry you're sort of the guinea pig for deploying this on Windows and to a 32-bit CentOS box, but thanks for helping solve some of these issues! Let me know if you run into anything else.

[jots]

No trouble at all. I'm not sure why it chose 32 bit centos, my windows is 64 bit.

question: what user should I be after I ssh in and begin setting up the apps?
I became root and ran all the commands, at the end it said deployment successful,
but I cannot connect to http://localhost:8080/

I installed lynx on the box and could not connect to http://localhost:8080/ or http://localhost:80/

I run:
[root@api api-umbrella-web]# netstat -tulpn | grep :80
tcp 0 0 0.0.0.0:8082 0.0.0.0:* LISTEN 20355/nginx
tcp 0 0 0.0.0.0:8055 0.0.0.0:* LISTEN 20355/nginx

So nothing is listening on 80 or 8080.
am I missing a step, or should I not have run the steps as root?

[GUI]

Hm, interesting that it picked the 32-bit box for you. We try to detect what system you're on in the Vagrantfile and pick the appropriate CentOS box (maybe not necessary, but I've had issues in the past running 64-bit guest OSes on 32-bit host OSes, even if your hardware is 64 bit). In any case, I don't think this should be causing issues now that you've gotten everything installed. But I'll definitely try to test all this out on some Windows machines myself sometime soon.

Regarding the last deployment steps, those are intended to be run as the default "vagrant" user, but I don't think running them as root should cause any problems. HAProxy should be running on port 80, but it looks like it might not be started. This might be related to the earlier Vagrantfile lines we commented out. Can you try running sudo /etc/init.d/haproxy restart? You might also try restarting nginx too, since it might have similar issues (even though it appears to be running): sudo /etc/init.d/nginx restart

Basically, those lines are in our Vagrantfile to work around a boot sequence issue with how Vagrant shares data and how we do deployments. Until Vagrant releases a fix and with those lines commented out, you'll have to run those 2 restart commands any time you completely shutdown the vagrant box and start it back up (however, this shouldn't be an issues if you suspend and resume the VM).

Hopefully this will finally do the trick, but give me a shout if it doesn't. Thanks for your patience!

[jots]

/etc/init.d/haproxy restart
[ALERT] 344/202559 (20505) : parsing [/etc/haproxy/haproxy.cfg:167] : Unknown host in 'mapsdb-dev.nrel.gov:80'
[ALERT] 344/202559 (20505) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg

looking at the file I see
166 balance roundrobin
167 server api_georeserv1 mapsdb-dev.nrel.gov:80
168 # Solar Metrics API Services Backend
[...] other hosts mentioned ...

I'm guessing I missed a step in configuring haproxy. looking now, but shout out if you know it.

[GUI]

Oh, no. I think some of our internal configuration must have made its way into this open source project. Whoops! Lemme take a look.

[GUI]

Okay, I think I have this resolved, but I did some git history re-writing to get rid of some files that shouldn't have been committed in the first place (I thought I had taken care of this when it was open-sourced, but I guess I missed these).

You can git pull down the latest changes inside api-umbrella, but unfortunately I think the git history rewriting I did was naughty and might lead to all sorts of git wackiness. I think the easiest thing to do is to just blow away this directory and redeploy it (it shouldn't take too long). To do that:

# From the api-umbrella directory. Either on Windows or inside Vagrant
$ git pull
$ rm -rf workspace/api-umbrella-router .git/modules/workspace/api-umbrella-router
$ git submodule update

$ vagrant ssh

# Cleanup some symlinks to now deleted files
$ rm /etc/haproxy/conf/backend.d/*.cfg

# Redeploy the router...
$ cd /vagrant/workspace/api-umbrella-router
$ cp config/mongoid.yml.example config/mongoid.yml && cp config/redis.yml.example config/redis.yml
$ bundle install --path=vendor/bundle
$ cap vagrant deploy

Sorry again for all the troubles, but thanks for helping get to the bottom of some of the issues. The overall platform is a couple years old and has been hammered in production for a while, but unfortunately it's pretty newly open-sourced. I haven't had nearly as much time as I'd like to test, document, and work on the open sourced code, but hopefully that'll be changing in the coming months. And in the mean time, I'm happy to try to help you get this up and running. Thanks again.

[jots]

I started over. I followed the steps in the README.md and it worked!

If anyone's trying to get this going on windows, just make sure you patch your
vagrant, and it should work.

The first time I tried loading http://localhost:8080/ it timed out, but it worked when I reloaded.

Now to see about actually using it. :-)
Thanks for helping me get it going Nick.

[GUI]

Excellent! Glad you got it working. Just to double check, does this wiki page seem to outline the basic process you had to go through to get it working on Windows? https://github.com/NREL/api-umbrella/wiki/Running-API-Umbrella-in-Windows-on-Vagrant-1.0.5

Also, I pushed some changes live that fix a few important issues. The basic process for updating now that you have it all up and running should basically be:

$ git pull # From the base api-umbrella directory

$ vagrant ssh

$ cd /vagrant/workspace/api-umbrella-router
$ bundle install
$ cap vagrant deploy

$ cd /vagrant/workspace/api-umbrella-web
$ bundle install
$ cap vagrant deploy

In addition, I tried to actually add some very basic introductory instructions on how to perform certain tasks in API Umbrella. So if you're interested in playing around, I hope they might be of some help. See the new Using API Umbrella section of the README.

[jots]

Yes, I think those instructions are good for windows. although I didn't change my Vagrant file, instead I edited my vagrant installation indicated by this patch you mentioned:
obscurerichard/vagrant@780dc31
files are in c:\vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant (for me)
it was a simple 1 or 2 line change for 2 files.

also, vagrant ssh doesn't work on windows.
I have ssh from cygwin (or mingw i forget) and so do:
ssh -p 2222 vagrant@localhost
with a password of vagrant

and I think that was it.