Error Standing Up Vagrant Rackspace VM

[markknox]

Trying to stand up a server using the vagrant rackspace plugin. Encountered the following error message:

Bringing machine 'www.server01.sa.com' up with 'rackspace' provider... [www.server01.sa.com] Finding flavor for server... [www.server01.sa.com] Finding image for server... [www.server01.sa.com] Launching a server with the following settings... [www.server01.sa.com] -- Flavor: 1 GB Performance [www.server01.sa.com] -- Image: Ubuntu 12.04 LTS (Precise Pangolin) [www.server01.sa.com] -- Name: www.server01.sa.com [www.server01.sa.com] Waiting for the server to be built... [www.server01.sa.com] Waiting for SSH to become available... [www.server01.sa.com] The server is ready! No host IP was given to the Vagrant core NFS helper. This is an internal error that should be reported as a bug.

Vagrant version 1.4.3 Vagrant Plugin version 0.1.9

Below is the response I received from Rackspace after posting a message with support:

Hello,

I don't believe that Vagrant is supported by Rackspace, but rather the developer of Vagrant, Hashicorp. I can tell you that when you provision a server from the API as Vagrant would, it doesn't provide the IP, but does provide the root password. You can query what the IP is through the API though, so I believe that this is a simple API command that the application is sending incorrectly. I believe the quickest way to resolve this issue is to report it to HashiCorp either directly on their website, or more likely on the support section of the Vagrant website.

http://www.vagrantup.com/support

Please advise and thank you in advance,

Mark

[drpebcak]

Looks like the same thing is happening to #112

[markknox]

Thanks Taylor. I'll keep an eye on this.

Mark

Mark Knox Chief Executive Officer

Dallas/Ft. Worth and Austin, TX (817) 989-6848 office | 512.309.5452 fax knoxtechnologyinc.com www.linkedin.com/in/markaknox

---

CONFIDENTIALITY NOTICE

This email, and any files transmitted with it, are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please delete this email. Thank You.

On Jul 6, 2014, at 7:40 PM, Taylor Price notifications@github.com wrote:

Looks like the same thing is happening to #112

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

[maxlinc]

@markknox can you post a vagrant file as well? I was having a bit of trouble with the vagrantfile posted on #112, so it'd be good to have another example.

Also, I noticed that you're using a pretty old version of Vagrant. The newest version is 1.6.3. We still support 1.4.3, but there's been many improvements to Vagrant since then, so I recommend upgrading if it's possible.

[markknox]

Hi Max,

Would you rather I upgrade my version of Vagrant first and it I still have the same problem post the vagrant file?

Thank you!

Mark

On Jul 7, 2014, at 12:50 PM, Max Lincoln notifications@github.com wrote:

@markknox can you post a vagrant file as well? I was having a bit of trouble with the vagrantfile posted on #112, so it'd be good to have another example.

Also, I noticed that you're using a pretty old version of Vagrant. The newest version is 1.6.3. We still support 1.4.3, but there's been many improvements to Vagrant since then, so I recommend upgrading if it's possible.

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

[maxlinc]

@markknox I'd like to try and get to the bottom of it. The error strikes me as odd, because Vagrant shouldn't even be trying to use NFS unless you explicitly turn it on.

So if you can help me reproduce the issue with a Vagrantfile it'd be useful, but if you're just looking for a quick workaround I'd try an upgrade.

[markknox]

Max,

I will go ahead and post the Vagrantfile for your review.

Thank you,

Mark

Mark Knox Chief Executive Officer

Dallas/Ft. Worth and Austin, TX (817) 989-6848 office | 512.309.5452 fax knoxtechnologyinc.com www.linkedin.com/in/markaknox

---

CONFIDENTIALITY NOTICE

This email, and any files transmitted with it, are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please delete this email. Thank You.

On Jul 7, 2014, at 2:28 PM, Max Lincoln notifications@github.com wrote:

@markknox I'd like to try and get to the bottom of it. The error strikes me as odd, because Vagrant shouldn't even be trying to use NFS unless you explicitly turn it on.

So if you can help me reproduce the issue with a Vagrantfile it'd be useful, but if you're just looking for a quick workaround I'd try an upgrade.

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

[markknox]

@maxlinc

An additional thought. When the server is stood up, additional recipe's that provision the server do use file transfer although I'm not sure if they use NFS or SCP. The interesting thing is that, other than the flavor of server requested by this particular Vagrantfile, we have successfully used the plugin in the past year to stand up several servers.

Mark

[markknox]

@maxlinc - please find the contents of the vagrantfile below. I have removed the ssh keypair info, rackspace username and apikey for security purposes.

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  # All Vagrant configuration is done here. The most common configuration
  # options are documented and commented below. For a complete reference,
  # please see the online documentation at vagrantup.com.

  # Define default values for rackspace
  config.vm.box = "kti-rackspace-precise64"
  config.ssh.private_key_path = "[yourprivatekeypath.rsa]"

  #Configure Server 01
  config.vm.define "www.server01.sa.com" do |wwwServer01SaCom|

    #Set up provider-specific options
    wwwServer01SaCom.vm.provider "rackspace" do |rs|
      rs.username        = "[yourusername"
      rs.api_key         = "[yourRackspaceAPIkey]"
      rs.flavor          = /2 GB Performance/
      rs.image           = /Ubuntu 12.04 LTS/
      rs.public_key_path = "[yourpublickey.pub]"
      rs.rackspace_region = "DFW"
    end

    # Enable provisioning with chef solo, specifying a cookbooks path, roles
    # path, and data_bags path (all relative to this Vagrantfile), and adding 
    # some recipes and/or roles.
    #
    wwwServer01SaCom.vm.provision "chef_solo" do |chef|
      chef.cookbooks_path = "cookbooks"
      #chef.roles_path = "../my-recipes/roles"
      #chef.data_bags_path = "../my-recipes/data_bags"
      chef.add_recipe "main"
      #chef.add_role "web"

      # You may also specify custom JSON attributes:
      chef.json = JSON.parse(File.read("cookbooks/nodeServer1.json")) 
    end
  end
end

[maxlinc]

@markknox Thanks, I'll give this a try.

I believe the default transport for synced folder should be rsync.

One interesting thing about both these Vagrantfiles is that you've got a custom box (or at least didn't import it as the "dummy" like in the quick start).

It is possible to store default configuration inside the box, but I've always just specified things like "precise64" via rs.image rather than creating a box. Do you know how "kti-rackspace-precise64" was produced and if it differs from the default "dummy" box at all?

[maxlinc]

Ok, I think I found the problem. Vagrant doesn't actually prefer rsync, it gives it equally priority as NFS (and behind SMB). But, it will only use NFS if it thinks both the host and guest are capable of it. So the reason I'm having some trouble reproducing it is either the choice isn't deterministic because they have equal priority, or Vagrant just doesn't detect my machine or images as NFS-capable.

I'll chat with @elight and @smashwilson about how we can permanently fix this, but in the meantime I think you can work around this by explicitly telling Vagrant you want to use rsync:

    wwwServer01SaCom.vm.provider "rackspace" do |rs, override|
      override.vm.synced_folder ".", "/vagrant", type: "rsync"
      # ...
    end

[maxlinc]

@markknox - I forgot to mention that the workaround assumes you've already upgraded your vagrant version. The configurable rsync sync'ed folder support was added in Vagrant 1.5.

[markknox]

@maxlinc - Thank you for the workaround. I will upgrade to Vagrant 1.5 and give it a try. Also, the "kti-rackspace-precise64" was created from the default "dummy" box at all and does not have any changes. I like the idea, however of specifying the box using rs.image as you described above.

[markknox]

@maxlinc - Upgraded to Vagrant 1.5.4 and tried again. See the output below:

Bringing machine 'www.server01.sa.com' up with 'rackspace' provider... ==> www.server01.sa.com: Finding flavor for server... ==> www.server01.sa.com: Finding image for server... ==> www.server01.sa.com: Launching a server with the following settings... ==> www.server01.sa.com: -- Flavor: 2 GB Performance ==> www.server01.sa.com: -- Image: Ubuntu 12.04 LTS (Precise Pangolin) ==> www.server01.sa.com: -- Name: www.server01.sa.com ==> www.server01.sa.com: Waiting for the server to be built... ==> www.server01.sa.com: Waiting for SSH to become available... ==> www.server01.sa.com: The server is ready! ==> www.server01.sa.com: Rsyncing folder: /Users/Mark/Work/EclipseWorkspace/kti.code-assets/Vagrant/rackspace-railo-msql/ => /vagrant No host IP was given to the Vagrant core NFS helper. This is an internal error that should be reported as a bug.

[markknox]

@maxlinc - also, updated vagrant file to include your workaround. It got further than before but still threw the NFS error.

[maxlinc]

@markknox - I'm trying to dig a bit and see if I can come up with another workaround. You might be able to try explicitly disabling NFS:

 override.vm.synced_folder ".", "/vagrant", type: "nfs", enabled: false

However, it looks like thiss is likely a bug in vagrant itself, not vagrant-rackspace. I checked the Vagrant code, and I see that the error message "No host IP..." means that Vagrant doesn't know the IP address of your machine. If it was the Rackspace machine that was a problem it would say "No guest IP..." And I'm still surprised Vagrant is trying to use NFS at all - I expected it to just use RSync unless you ask for NFS.

It looks similar to https://github.com/mitchellh/vagrant/issues/4128 and https://github.com/mitchellh/vagrant/issues/4011.

[markknox]

@maxlinc - thanks for the workaround. I'll give it a try and let you know.

-Mark

[markknox]

@maxlinc - I tried the workaround and no luck. Same error as above. Please advise.

Thanks,

Mark

[jtreminio]

I have also run into this issue. Basically my RS instance is not longer responding to Vagrant :\

[maxlinc]

If you're using Vagrant 1.6+, it looks like you can disable NFS with this:

config.nfs.functional = false

Please let me know if that works.

I've also opened https://github.com/mitchellh/vagrant/issues/4192 in vagrant itself, because the NFS code (both for synced_folder and some chef_solo specific options) are all in that project.

[markknox]

@maxlinc - I'll check it out and let you know.

[markknox]

@maxlinc - Ok, I finally through my hands up in surrender and removed all boxes and plugins, upgraded Vagrant to version 1.6.3 and reinstalled the rackspace box and plugin. I stood up the server without any workaround code in the vagrant file and did not get the NFS error. However, now I am getting this error which I wasn't getting before:

==> www.server01.sa.com: [2014-07-15T22:07:49+00:00] INFO: * Chef 10.14.2 * ==> www.server01.sa.com: [2014-07-15T22:07:50+00:00] INFO: Setting the run_list to ["recipe[main]"] from JSON ==> www.server01.sa.com: [2014-07-15T22:07:50+00:00] INFO: Run List is [recipe[main]] ==> www.server01.sa.com: [2014-07-15T22:07:50+00:00] INFO: Run List expands to [main] ==> www.server01.sa.com: [2014-07-15T22:07:50+00:00] INFO: Starting Chef Run for www.server01.sa.com ==> www.server01.sa.com: [2014-07-15T22:07:50+00:00] INFO: Running start handlers ==> www.server01.sa.com: [2014-07-15T22:07:50+00:00] INFO: Start handlers complete. ==> www.server01.sa.com: [2014-07-15T22:07:50+00:00] WARN: Using java::default instead is recommended. ==> www.server01.sa.com: ================================================================================ ==> www.server01.sa.com: Error executing action install on resource 'package[update-notifier-common]' ==> www.server01.sa.com: ================================================================================ ==> www.server01.sa.com: Chef::Exceptions::Package ==> www.server01.sa.com: ------------------------- ==> www.server01.sa.com: update-notifier-common has no candidate in the apt-cache ==> www.server01.sa.com: Resource Declaration: ==> www.server01.sa.com: --------------------- ==> www.server01.sa.com: # In /tmp/vagrant-chef-2/chef-solo-1/cookbooks/main/recipes/default.rb ==> www.server01.sa.com: ==> www.server01.sa.com: 20: # provides /var/lib/apt/periodic/update-success-stamp on apt-get update ==> www.server01.sa.com: 21: package "update-notifier-common" do ==> www.server01.sa.com: 22: notifies :run, resources(:execute => "apt-get update"), :immediately ==> www.server01.sa.com: 23: end ==> www.server01.sa.com: 24:

Note the message: "update-notifier-common has no candidate in the apt-cache"

Any ideas what might be going on now?

Thanks!

Mark

[maxlinc]

@markknox That's a good error! It's coming from chef, not vagrant (or vagrant-rackspace), which means you've successfully started a server, rsync'ed your cookbooks to it, and invoked chef. It's failing on line 21 of main/recipes/default.rb.

You'll probably get better support from the Chef community, but to me it looks like the issue is that the "update-notifier-common" package was not found. It might be that you need to run apt-get update before trying to install the package.

I recommend checking out the opscode-cookbooks/apt, the community cookbooks that handles recommended apt-cache tuning. It's default recipe:

installs the update-notifier-common package to provide the timestamp file used to only run apt-get update if the cache is more than one day old

[markknox]

@maxlinc - thanks for the info. Placing the "include_recipe apt" at the very top of the vagrantFile solved the issue stated above. Thanks for all your assistance in trying to track down the NFS issue. Still not sure why it is present in earlier versions of Vagrant but glad that the latest seems to have corrected the problem.

Cheers!

Mark

[jtreminio]

@maxlinc thanks, this fixed the issue for me.

[michaelsbradleyjr]

I'm experiencing this issue with vagrant 1.6.3, but setting config.nfs.functional = false per @maxlinc worked for me.

[maxlinc]

So - workaround confirmed: @markknox @jtreminio @michaelsbradleyjr

How about you @drpebcak? I'd like to fix things so the workaround isn't necessary or nfs is supported, but I just want to make sure no one is blocked right now.

[michaelsbradleyjr]

It's not a work of art by any means (and is also a work in progress), but here's an operational Vagrantfile, and supporting files, partly derived from the coreos-vagrant project, which makes use of the vagrant-rackspace plugin:

https://github.com/NCCTS/nccts.org/tree/master/vagrant/rackspace

Note that the Vagrant file implements two workarounds related to folder syncing:

override.vm.synced_folder ".", "/vagrant", disabled: true

-and-

config.nfs.functional = false

Anyway, I thought someone here might find it useful, so there you go.