Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

failling "See if Vagrant plugins just didn't install" on Fedora 22 #8

Open
phipolis opened this issue Jul 14, 2015 · 5 comments
Open

Comments

@phipolis
Copy link

Trying to complete rvmsudo madscience construct on a fedora 22 x86_64 system and failing "See if Vagrant plugins just didn't install" at ~/.rvm/gems/ruby-2.2.1/gems/madscience-0.0.29/site-cookbooks/madscience-vagrant-cookbook/recipes/default.rb:121.

if I include #{output} in the raise string, only the default plugin is listed:
vagrant-share (1.1.4, system)

The strange thing is that vagrant plugin list looks correct:

[test@host ~]$ /usr/bin/vagrant plugin list
vagrant-aws (0.6.0)
  - Version Constraint: 0.6.0
vagrant-digitalocean (0.7.3)
  - Version Constraint: 0.7.3
vagrant-host-shell (0.0.4)
  - Version Constraint: 0.0.4
vagrant-librarian-chef (0.2.1)
  - Version Constraint: 0.2.1
vagrant-linode (0.1.1)
  - Version Constraint: 0.1.1
vagrant-omnibus (1.4.1)
  - Version Constraint: 1.4.1
vagrant-share (1.1.4, system)

The block also passes in pry if I substitute ALL_PLUGINS = ['vagrant-omnibus','vagrant-librarian-chef','vagrant-aws','vagrant-digitalocean','vagrant-linode','vagrant-host-shell'] so I can't figure out why output is different only within chef. Also strange, Recipe: vagrant::install_plugins succeeds just prior:

  * vagrant_plugin[vagrant-omnibus] action install (up to date)
  * vagrant_plugin[vagrant-librarian-chef] action install (up to date)
  * vagrant_plugin[vagrant-aws] action install (up to date)
  * vagrant_plugin[vagrant-digitalocean] action install (up to date)
  * vagrant_plugin[vagrant-linode] action install (up to date)
  * vagrant_plugin[vagrant-host-shell] action install (up to date)

I was able to reproduce this with a completely clean user account and fresh rvm install.

@noahgibbs
Copy link
Owner

Vagrant keeps multiple lists of plugins. There are the installed files in the appropriate directory (multiple, actually), plus JSON lists internally.

I filed this bug as a reminder that I need to go in and spelunk through Vagrant's private structures for this at some point, because they get out of sync :-(

It's absolutely reproducible on a clean new account -- this is basically a case where sometimes you get errors during installation that Vagrant doesn't notice, and it thinks the plugin installed successfully when it didn't.

@phipolis
Copy link
Author

What is the mechanism by which the vagrant plugin list test gives a different result when invoked in Chef than when invoked in pry or the command line? I could understand your explanation if you were using your own test to verify Vagrant's state, but the only difference seems to be the Chef context.

@noahgibbs
Copy link
Owner

I'm honestly not sure. Originally I thought this was impossible too. But if your explanation (and my original one) was correct, that test should never fail.

And clearly, it fails.

@phipolis
Copy link
Author

I just discovered the difference. Running /usr/bin/vagrant plugin list as root (or with sudo/rvmsudo) lists just the default plugin, while running as my user lists the plugins installed by madscience. The plugins land in /home/[user]/.vagrant.d, but under rvmsudo madscience construct, vagrant searches /root/.vagrant.d !

@noahgibbs
Copy link
Owner

Interesting. I patched around this issue in several places. I might well have missed one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants