Installed mongo-10gen is newer than candidate package about api-umbrella HOT 6 CLOSED

@GUI Thanks for the instantaneous response Nick—I see you flying through the repo and bumping the versions of all these components. Just close the issue when you're done and I'll try again starting clean. You rock!

from api-umbrella.

I believe this should now be fixed by 2f6e373. If you pull down the latest and try again, do you have better luck? (And if you're new to Vagrant, after doing a git pull, you should be able to pick up where chef left off by running vagrant provision)

This mongo business broke due to how we're specifying mongo versions and how Mongo manages their yum repository. Right now we're locking on a specific version of Mongo from their repo, which works for most 3rd party repos, but it looks like 10gen yanks the previous versions as soon as they release a new one. A new version just got released today (2.4.6), so that's what broke this. So our current approach is a little brittle and I probably need to revisit this, but this should at least work for now.

I've also belatedly updated some of the README documentation, so I believe things should be smoother sailing for you now. But if anything's still not working or you have any questions, feel free to reach out.

from api-umbrella.

Oh, and after doing a git pull, I think you'll also have to do a git submodule update --recursive to fetch the latest versions of all the git submodules (pesky git submodules...).

from api-umbrella.

Got past the mongo install just fine. I'm seeing some different problems now... will try to resolve them myself... if I can't, I'll open a new issue. Thanks!

from api-umbrella.

I slightly misspoke with regards to the root cause of this mongodb package problem earlier (it wasn't anything with 10gen's yum repo, but an issue with our chef cookbook). This did only crop up if we were trying to install the non-latest version, but I think I was finally able to fix the underlying problem in the cookbook in a non-brittle way. So now I think that should resolve this initial issue in a way that shouldn't break again the next time a new version of mongodb gets released. Thanks for pointing this out!

I ran through the whole bootstrap process from scratch and spotted a few other potential issues for a brand new setup (sorry we haven't stayed on top of initial bootstrapping process). In the process of fixing those I may have pushed some temporarily broken stuff to this repo (surrounding nginx, ruby, and passenger), so my apologies if I broke things while you were in the middle of trying again. I believe I've just pushed the last fix to resolve the initial bootstrap issues, so hopefully things should work for you now if you fetch the latest (for real this time ;). But feel free to open other issues if you're still running into any problems.

(And if you happen to have have ended up in a funky state due to the broken stuff I had temporarily pushed live, you can always vagrant destroy and vagrant up to start completely over. But since that can take a while, if the issue is what I think it might be, you might be able to fix your existing VM by vagrant ssh and then inside there run: sudo rm /opt/rbenv/versions/1.9.3-p448/gems. Then back on your host machine run vagrant provision to pickup where the provisioning left off. But I'm not entirely sure that's what you're running into, just a guess based on what I broke..)

from api-umbrella.

Thanks so much. After a vagrant destroy this time vagrant up went perfectly. Definitely all fixed now. My last problem involved my cpu being pegged for an hour on the installation of libcurl. Weird! With all the submodules I can't trace which commit fixed the problem (maybe nginx?), but in any case, this time the whole setup process from the README went swimmingly. Again, thank you for the quick response! Looking forward to exploring the API Umbrella now!

from api-umbrella.