vagrant-omnibus breaks "vagrant ssh" when upstream Internet connection is down

[juliandunn]

Because vagrant-omnibus tries to connect to rubygems.org to validate the Chef version, it'll cause any vagrant operation to fail if the upstream Internet connection is down. example:

borkbork:~/devel/chef-cookbooks/wrapper (master)$ vagrant ssh
/Applications/Vagrant/embedded/lib/ruby/1.9.1/rubygems.rb:543:in `initialize': not in gzip format (Zlib::GzipFile::Error)
    from /Applications/Vagrant/embedded/lib/ruby/1.9.1/rubygems.rb:543:in `new'
    from /Applications/Vagrant/embedded/lib/ruby/1.9.1/rubygems.rb:543:in `gunzip'
    from /Applications/Vagrant/embedded/lib/ruby/1.9.1/rubygems/remote_fetcher.rb:239:in `fetch_path'
    from /Applications/Vagrant/embedded/lib/ruby/1.9.1/rubygems/spec_fetcher.rb:260:in `load_specs'
    from /Applications/Vagrant/embedded/lib/ruby/1.9.1/rubygems/spec_fetcher.rb:231:in `block in list'
    from /Applications/Vagrant/embedded/lib/ruby/1.9.1/rubygems/spec_fetcher.rb:227:in `each'
    from /Applications/Vagrant/embedded/lib/ruby/1.9.1/rubygems/spec_fetcher.rb:227:in `list'
    from /Applications/Vagrant/embedded/lib/ruby/1.9.1/rubygems/spec_fetcher.rb:150:in `find_matching_with_errors'
    from /Applications/Vagrant/embedded/lib/ruby/1.9.1/rubygems/spec_fetcher.rb:89:in `fetch_with_errors'
    from /Applications/Vagrant/embedded/lib/ruby/1.9.1/rubygems/dependency_installer.rb:110:in `find_gems_with_sources'
    from /Users/juliandunn/.vagrant.d/gems/gems/vagrant-omnibus-1.0.2/lib/vagrant-omnibus/config.rb:59:in `retrieve_latest_chef_version'
    from /Users/juliandunn/.vagrant.d/gems/gems/vagrant-omnibus-1.0.2/lib/vagrant-omnibus/config.rb:39:in `finalize!'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/config/v2/root.rb:44:in `block in finalize!'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/config/v2/root.rb:43:in `each'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.2.2/lib/vagrant/config/v2/root.rb:43:in `finalize!'
<etc>

Maybe it should just let the user specify anything and not do any validation on the host, and fail the guest run if the user has specified an invalid version?

[tmatilai]

As a user I want to specify :latest. =) So there has to be some way to fetch version number for that (#2).

But what about an environment variable (e.g. CHEF_VERSION) that would have higher precedence than the config? Possible values for example "latest", "ignore" (to disable the plugin), or a version number string.

[juliandunn]

@tmatilai That's fine, but I'm suggesting that perhaps the determination of :latest could be done on the guest side. Rather than just unconditionally wgetting the install.sh, we only do that if the current version is different than the desired one?

Either way I think blocking or breaking vagrant when the Internet connection is down seems like bad behavior.

[cromulus]

Shouldn't vagrant-omnibus only be run on vagrant provision or vagrant up , as opposed to other commands? Slowing down vagrant ssh seems counterproductive.

[tmatilai]

The installer only runs on up/reload/provision commands. And #48 even restricts execution to cases when the provisioners are run (although that won't work perfectly in Vagrant 1.3.x, only before and after). But that's not released yet.

But true enough, as @juliandunn said the latest version fetching should be included in the install action (or as own action), and not done in config validation.

I would anyway like to include this plugin's functionality into Vagrant core for Vagrant 1.5, so we can refactor in that transition too.

[davisein]

In addition to that, it should handle the error better and allow the command to continue. I was in a public wifi and I couldn't vagrant up my box until I realised the internet connection required to pass a login site. It should allow the execution of vagrant up if the connection doesn't work or the file is not correct.

[schisamo]

So if the upstream network connection is down how is vagrant-omnibus supposed to pull an Omnibus Chef package down for installation?

The validation of the Chef version string and resolution of :latest to a real version number occurs as part of Vagrant's build in validation system. This validation is not tied to a particular action/command and kicks in anytime the Vagrantfile is loaded/evaluated.

I believe this is the right place for this version validation but will work to make things a little more resilient to situations where a network connection does not exist.

[tmatilai]

@schisamo one issue though is that the validation is done even if the plugin is not even enabled, i.e. there is no nil check for config.chef_version before hitting the internet. And no check if any provisioners are going to run, but that can't even be checked here, only after the validation.

[schisamo]

@tmatilai roger.

So I think I'm going to:

• Skip validation if config.chef_version is nil
• Print a warning but continue with the requested command/action in the case the internet connection is down.

Does this sound like a good compromise to everyone?

[tmatilai]

Sounds good to me.

[cromulus]

Hey all!

Seems to me that :latest should always be a valid version number...

Additionally, I think it makes sense to try to remove the network dependency in the config validation. Some vagrant commands, like ssh, are unnecessarily slowed by the network round trip. Validation of the version should really happen only at install time, not at parse time.

Thoughts?

Sent on the move.

On Jan 14, 2014, at 1:00 AM, Seth Chisamore notifications@github.com wrote:

@tmatilai roger.

So I think I'm going to:

Skip validation if config.chef_version is nil Print a warning but continue with the requested command/action in the case the internet connection is down. Does this sound like a good compromise to everyone?

— Reply to this email directly or view it on GitHub.

[floodedcodeboy]

Just my 2 cents worth, but I really don't think that this should be called at the vagrant up or vagrant reload points unless it's a first run (when provisioning happens by default if enabled) or run with --provision. I guess this is something to take up with the vagrant team.

Not being able to boot your vagrant box because you don't have an internet connection is a serious usability/productivity fail.

@schisamo any idea when a solution will be in place?

[schisamo]

I've got a fix for this mostly working, want to do some more testing before pushing. Hoping that happens by end of week.

[jquast]

After upgrading/installing the latest published vagrant and omnibus plugin, (vagrant 1.4.3, vagrant-omnibus (1.2.1)), I can't halt a VM.

$ vagrant halt
There are errors in the configuration of this machine. Please fix
the following errors and try again:

Omnibus Plugin:
* '' is not a valid version of Chef.

A list of valid versions can be found at: http://www.opscode.com/chef/install/

This vagrant and Vagrantfile makes no use of chef or this plugin.

[parndt]

I worked around this by editing the gem (~/.vagrant.d/gems/gems/vagrant-omnibus-1.2.1/lib/vagrant-omnibus/config.rb) and commenting out these lines. A total hack/monkey patch, but it is a pretty great solution when you're offline and need it to work!

[benjaminws]

Hi! Just wanted to note that I ran into this today.

I tested the approach mentioned here https://github.com/schisamo/vagrant-omnibus/issues/13#issuecomment-32193842 and it worked as intended, near as I could tell.

If it'd would help things move along, I'd be happy to throw down a PR.