Works with Vagrant 1.2?

[antifun]

It's entirely possible I'm doing it wrong, but I think I am not, and I can't figure out how to get values from the .vagrantuser YAML into the visibility of Vagrant itself.

My ultimate goal is to pass some/all parameters from the user-configuration YAML into puppet as facts, but when I couldn't get that to work I started simple and tried the following:

Vagrant::Config.run do |config|
   config.user.local = {
     "dev_email_address" => "halp"
   }
   puts "#{config.user.local.dev_email_address}"
   [lots of other vagrantfile stuff]
end

And when I run vagrant user parameters, I get the following output:

#<Vagrant::Config::V1::DummyConfig:0x0000010311d3d0>
There were warnings and/or errors while loading your Vagrantfile.
Your Vagrantfile was written for an earlier version of Vagrant,
and while Vagrant does the best it can to remain backwards
compatible, there are some cases where things have changed
significantly enough to warrant a message. These messages are
shown below.

Warnings:
* Unknown configuration section 'user'. If this section was part of
a Vagrant 1.0.x plugin, note that 1.0.x plugins are incompatible with 1.1+.

There were warnings and/or errors while loading your Vagrantfile.
Your Vagrantfile was written for an earlier version of Vagrant,
and while Vagrant does the best it can to remain backwards
compatible, there are some cases where things have changed
significantly enough to warrant a message. These messages are
shown below.

Warnings:
* Unknown configuration section 'user'. If this section was part of
a Vagrant 1.0.x plugin, note that 1.0.x plugins are incompatible with 1.1+.

# Vm 'web'
 All Parameters
 --------------------------------------------------
 Empty

# Vm 'db'
 All Parameters
 --------------------------------------------------
 Empty

(I should note I have two VMs in this vagrantfile.)

So something between the implementation, possibly with version 1.2 of vagrant, and the README is not matching up. Either that, or I'm doing something really dumb. Any suggestions appreciated.

Thanks in advance.

-m

[antifun]

I should also note that this variant

  config.user = {
    "dev_email_address" => "halp"
  }

  puts "#{config.user.dev_email_address}"

produces the same output.

[maoueh]

Hi @antifun,

I did not test the plugin with 1.2 directly, but since the plugin API did not change between 1.1 (which I have tested with success) and 1.2, it should work like a charm.

The first thing I can see is that you have a bad Vagrant config initialization. The first line you wrote above (Vagrant::Config.run do |config|) is for Vagrant 1.0.x. The new way to initialize a Vagrant config in vagrant 1.1.x and 1.2.x is by using this line instead: Vagrant.configure("2") do |config|.

What I can see at first is that you have Vagrant 1.2 and installed the plugin for this version (by doing vagrant plugin install nugrant). However, having the config initialized with 1.0.x style makes Vagrant enter some backward compatibility mode and warn you that you use 1.0.x style. In this mode, plugin installed are not loaded (even when they provides the 1.0.x compatibility like Nugrant). To solve this, you will need to update your Vagrantfile.

Second, in the Vagrantfile you should only specify defaults values like this:

config.users.defaults = {
  "local" => {
    "dev_email_address" => "i_am_helping@you.com"
  }
}

This will set some default values so they could still be overridden by specifying them in a .vagrantuser file located at the same level of your Vagrantfile (or in your $HOME dir) that would contain:

local:
  dev_email_address: "overrides_i_am_helping@you.com"

So, a simple test to check that plugin and Vagrant works without problem is to put this content in a Vagrantfile:

Vagrant.configure("2") do |config|
   config.user.defaults = {
     "local" => {
       "dev_email_address" => "halp"
     }
   }

   puts config.user.local.dev_email_address
end

Then, simply do vagrant -v and in the console, you should see halp then some Vagrant output about its version.

Tell me if it makes sense to you and that the simple test that I gave you work. If you further question or it's still does not work, I will be happy to assist you further.

Regards,
Matt

[maoueh]

On a side note, I recheck the README of the project and I can see that all examples are with Vagrant config file done for 1.0.x (but it is not mentioned explicitly). I will adjust this next week to only use examples that works with Vagrant 1.2+ so new Vagrant users that should use 1.2 in principle will have working examples right from the README.

[antifun]

You were absolutely right -- I had used that Vagrantfile for many months, and while it still "worked" in 1.2, it was not loading any plugins. Thanks.

So I'd like to make it such that I can enumerate a Bag:

module Nugrant
  class Bag
    include Enumerable

      def each(&block)
        @bag.each(&block)
      end

    end
  end
end

So that I can do this in the Vagrantfile:

      config.user.local.each do |name, value|
        puppet.facter[name] = value
      end

Any objections?

[maoueh]

Glad it works now :)

No, I don't have any objections. In fact, I think it's a pretty good addition. I didn't had this use case in mind but it perfectly make senses.

I have some free time tonight, I will implement this and push a new version of the plugin.

[antifun]

I took a run at this myself. Couldn't figure out why the tests were failing, until I realized that the method-style calling convention (config.user.local.first as opposed to config.user.local['first']) was colliding with methods from the Enumerable module (there is a method Enumerable.first).

Just adding an each method does what I need, though it doesn't get you any Enumerable goodness in and of itself.

[maoueh]

Yes, that's the problem when using method_missing, you start colliding with predefined functions. That's why I recently started to prefix all method in Bag with __ to avoid as much possible restrictions on what parameter names you can have.

I guess for now the best option is to only add each, which will be restricted as a parameter name. I'm not sure there is a good solution to the colliding problem unless I remove getting parameter with function-like access deep.parameter which I think it's a nice to have.

I'm ready to review your PR when it's ready.

[antifun]

I figured that was the issue. If you can come up with another way of doing it, I'd be interested. Actually, implementing something like to_hash would be one way to do it as well...

Anyway. each fulfills my need; if you feel like pushing that out I'd be content.

[maoueh]

I just pushed version 1.1.0 to RubyGems. By doing vagrant plugin install nugrant, Vagrant should update Nugrant to its latest version.

This version adds a .each method at any level so you should be able to iterate through the keys.

Vagrant.configure("2") do |config|
  config.user.defaults = {
    'local' => {
        'first' => "value1",
        'second' => "value2"
    }
  }

  config.user.local.each do |name, value|
    puts "Parameters #{name}: #{value}"
  end
end

Tell me if it works on your side. If yes, I'm going to close the issue.

[antifun]

This looks good to me. Thanks!

On Thu, May 16, 2013 at 11:25 PM, Matthieu Vachon
notifications@github.comwrote:

I just pushed version 1.1.0 to RubyGems. By doing vagrant plugin install
nugrant, Vagrant should update Nugrant to its latest version.

This version adds a .each method at any level so you should be able to
iterate through the keys.

Vagrant.configure("2") do |config|
config.user.defaults = {
'local' => {

    'first' => "value1",
    'second' => "value2"
}

}

config.user.local.each do |name, value|
puts "Parameters #{name}: #{value}"
endend

Tell me if it works on your side. If yes, I'm going to close the issue.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-18043186
.

[maoueh]

@antifun I've decided that Bag will implement Enumerable in version 2.0. For parameters clashing with methods, there will always be the index lookup for those cases. I think it will be better like this, we will see in the long run how it goes but I think it's a good move.

Thank you for this suggestion.

Regards,
Matt