mwrock / kitchen-nodes Goto Github PK

View Code? Open in Web Editor NEW

37.0 7.0 24.0 106 KB

A Test Kitchen Provisioner that generates searchable Nodes.

License: Other

Ruby 100.00%

kitchen-nodes's People

Contributors

Stargazers

Watchers

kitchen-nodes's Issues

Gem conflict on Windows workstation, not sure how to solve

This isn't necessarily an issue with kitchen-nodes but the guy on my team exhibiting this issue can install and use chef-zero just fine, and I wouldn't expect the gem dependencies in question to be different.

Disclaimer: my ruby experience is entirely based in Chef. This could turn out to be a painfully n00b-ish issue.

After doing a gem install kitchen-nodes (we try not to use bundler with Chef/test-kitchen) and then issuing a kitchen command:

>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ClientError
>>>>>> Message: Could not load the 'nodes' provisioner from the load path. Please ensure that your provisioner is installed as a gem or included in your Gemfile if using Bundler.

and then the relevant section of .kitchen.log:

E, [2016-03-22T11:31:18.893842 #1716] ERROR -- Kitchen: Class: Kitchen::ClientError
E, [2016-03-22T11:31:18.893842 #1716] ERROR -- Kitchen: Message: Could not load the 'nodes' provisioner from the load path. Please ensure that your provisioner is installed as a gem or included in your Gemfile if using Bundler.
E, [2016-03-22T11:31:18.894842 #1716] ERROR -- Kitchen: ---Nested Exception---
E, [2016-03-22T11:31:18.894842 #1716] ERROR -- Kitchen: Class: Gem::ConflictError
E, [2016-03-22T11:31:18.894842 #1716] ERROR -- Kitchen: Message: Unable to activate chef-12.4.3-universal-mingw32, because mixlib-shellout-2.2.1-universal-mingw32 conflicts with mixlib-shellout (< 2.2, >= 2.0.0.rc.0)

I'm the only other one on our team testing with kitchen-nodes at the moment, and I have no issue but I'm also using a Mac.

Is there something we should explicitly install to resolve this, or is kitchen-nodes just not compatible with the Chef 12.4.3 gem on Windows?

Remove created nodes after run a `kitchen destroy`

Hello,

I really don't know if would be useful to many people, but I guess that would be great to remove the nodes created by provisioner kitchen-nodes.
For me sometime when I destroy the suites related to kitchen-nodes provisioner, the chef-client continues to find that old nodes data.
What do you think about?

Thanks for your work, saves me a lot of time.

Vagrant, VirtualBox, and NAT

Hello! Could you go into some detail about what kitchen driver you're using with this provisioner? It looks like this driver requires the ability to ping each guest from the host. For kitchen-vagrant and virtualbox, the most common setup by far, the default networking mode appears to be NAT, which will fail the ping check in this provisioner.

Aside: I'm also seeing node json files with 'null' for the ip address. Probably isn't good to have nodes with null for ip addresses -- it might be better if the file wasn't generated.

This all might be worth documenting in the README.

Failed to complete #converge action: [undefined method `[]' for #<WinRM::Output:0x4adaab8>]

Has anyone seen this error before?

Kitchen: ---Nested Exception---
Kitchen: Class: Kitchen::ActionFailed
Kitchen: Message: Failed to complete #converge action: [undefined method `[]' for # WinRM::Output:0x4adaab8>]
Kitchen: C:/Users/.../AppData/Local/chefdk/gem/ruby/2.3.0/gems/kitchen-nodes-0.9.0/lib/kitchen/provisioner/finder/winrm.rb:29:in `find_ips'

Running the command shown here https://github.com/mwrock/kitchen-nodes/blob/master/lib/kitchen/provisioner/finder/winrm.rb#L26 manually on the virtualbox windows instance returns what I would expect it to.

Kitchen converge race condition

I know this repository hasn't been contributed to in a long time, and I have also adopted scalp42 fork myself due to compatibility issues, BUT... I'm hoping that posting this issue may get some visibility from someone who may have some suggestions or answers.

What I am experiencing has to do with platform composition and the race condition that manifests because of it. I have a test kitchen suite that I am running where I have 1 Windows Server 2016 node and 3 Windows Server 2019 nodes. For whatever reason the Windows Server 2016 node will blast through the first aspects of a kitchen converge so that it gets to the "Preparing nodes" step before any of the Windows Server 2019 nodes have populated any node data. This causes any node search functionality from the Windows Server 2016 node to fail since there is no node data for the other nodes.

My current attempt at a "solution" is to simply run the converge an initial time, wait for it to fail, and then run converge again. I had not hit this race condition previously and I was always thinking previously that the node data was populated at the end of the kitchen create action and not at the start of the kitchen converge action. I am assuming that with my "solution" the first converge will populate all of the node data and fail, and then the next converge will succeed.

Is there a way to update test kitchen code anywhere/anyhow so that the node data is populated at the end of the kitchen create action and not at the start of the kitchen converge action?

can't load 'nodes' provisioner from load path

We may be missing something easy, but we keep seeing this error when trying to use the 'nodes' plugin:

$ bundle exec kitchen converge postgres
-----> Starting Kitchen (v1.13.2)
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ClientError
>>>>>> Message: Could not load the 'nodes' provisioner from the load path. Please ensure that your provisioner is installed as a gem or included in your Gemfile if using Bundler.
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

Our sanitized .kitchen.yml looks like this:


---
driver:
  name: joyent

transport:
  name: rsync

driver_config:
  joyent_version: '~7.0'
  joyent_username: smartb
  joyent_keyfile: <redacted>
  joyent_keyname: <redacted>
  joyent_url: https://eu-ams-1.api.joyent.com
  joyent_image_id: 643d5524-7eba-4a72-8fca-8dbb84d8d35d # ubuntu-certified-14.04
  joyent_flavor_id: k4-highcpu-kvm-3.75G
  username: ubuntu

provisioner:
  name: nodes
  require_chef_omnibus: 12.13.37

platforms:
  - name: ubuntu-14.04

suites:
  - name: pgbouncer
    run_list:
      - recipe[postgres::pgbouncer]

  - name: postgres-primary
    run_list:
      - recipe[postgres::primary]

  - name: postgres-replica
    run_list:
      - recipe[postgres::replica]

cc: @arochaf @bixu

Trouble searching the node

Here is the search I'm applying:

sql_ip = -> { search(:node, "id:primarysql*") }

And I try to put:

puts "IP Address: #{sql_ip.call[0]['ipaddress']}"

This is the node that I am searching against

{
  "id": "primarysql-Windows",
  "chef_environment": "_default",
  "automatic": {
    "ipaddress": "10.12.235.71",
    "platform": "windows",
    "fqdn": "MTPCTSCID012.consilio.com",
    "recipes": [
      "relativity-scaled-automation::setup_sql"
    ]
  },
  "normal": {
  },
  "run_list": [
    "recipe[relativity-scaled-automation::setup_sql]"
  ]
}

What is returned is

IP Address: ["fe80::a816:9ab7:f164:108e%12", "10.0.2.15"]

which is wrong all together...wthat IP address is not correct?

so I try a different search...

sqlID = []
search(:node, "id:primarysql*").each do |server|
  sqlID.push(server['ipaddress'])
end
puts "FQDN: #{sqlID}"

and this is what is returned...

FQDN: [["fe80::a816:9ab7:f164:108e%12", "10.0.2.15"], "10.12.235.71"]

the second item in the list is correct, but what is the first item? where is that coming from?

I searched my project and there is no such information

kitchen-nodes provisioner needs kitchen-sync sftp finder

Hi, mwrock, thanks for this project, very useful!

I'm working with the kitchen-sync sftp transport (https://github.com/coderanger/kitchen-sync) and this nodes provisioner.

Relevant kitchen yml snippets

driver: vagrant
transport:
  name: sftp
provisioner:
  name: nodes

Versions of gems

kitchen-nodes (0.6.3)
kitchen-sync (2.1.0)
kitchen-vagrant (0.19.0)
test-kitchen (1.4.2)

Kitchen converge fails with:

>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Failed to complete #converge action: [cannot load such file -- kitchen/provisioner/finder/sftp]
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

Looks like we need a new sftp and rsync finder. I've put an sftp one together based on ssh, which seems to work fine... I'll submit a PR for your review

Working Example: Nginx Balancer + 2 App Nodes

Hi Matt

I have built an example of Nodes provisioner based on TestKitchen. Basic idea is of course to demo how to obtain the IPs of the nodes so balancer can do round-robin. Single liner where you can observe how all elements fit into place. If you approve, I will create pull request here so we can demo fully working example of Nodes.

For now example is living here:
https://bitbucket.org/styktv/chef.cookbook.nginx_balancer

Cheers,
Peter

net-scp issue when transferring files to vm

Hi @mwrock ,

Running into an issue:

-----> Starting Kitchen (v1.20.0)
-----> Converging <server-ubuntu-1604>...
       Preparing files for transfer
       Preparing dna.json
       Resolving cookbook dependencies with Berkshelf 6.3.1...
       Removing non-cookbook files before transfer
       Preparing data_bags
       Preparing environments
       Preparing nodes
       Preparing roles
       Preparing validation.pem
       Preparing client.rb
       chef installation detected
       install_strategy set to 'once'
       Nothing to install
       Transferring files to <server-ubuntu-1604>
/opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-scp-1.2.1/lib/net/scp/upload.rb:117:in `stat': No such file or directory @ rb_file_s_stat - /var/folders/nl/frt7q1kd755frfwzdlk5n5rm0000gn/T/server-ubuntu-1604-sandbox-20180406-25631-wk25zw/cookbooks/apt/attributes/default.rb (Errno::ENOENT)
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-scp-1.2.1/lib/net/scp/upload.rb:117:in `set_current'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-scp-1.2.1/lib/net/scp/upload.rb:103:in `next_item_state'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-scp-1.2.1/lib/net/scp.rb:400:in `await_response_state'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-scp-1.2.1/lib/net/scp.rb:369:in `block (3 levels) in start_command'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/channel.rb:320:in `process'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:238:in `block in ev_preprocess'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:529:in `each'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:529:in `each_channel'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:238:in `ev_preprocess'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/event_loop.rb:99:in `each'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/event_loop.rb:99:in `ev_preprocess'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/event_loop.rb:27:in `process'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:216:in `process'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:178:in `block in loop'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:178:in `loop'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:178:in `loop'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:124:in `close'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/test-kitchen-1.20.0/lib/kitchen/transport/ssh.rb:128:in `close'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/test-kitchen-1.20.0/lib/kitchen/transport/ssh.rb:105:in `cleanup!'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/test-kitchen-1.20.0/lib/kitchen/instance.rb:294:in `cleanup!'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/test-kitchen-1.20.0/lib/kitchen/command.rb:205:in `run_action_in_thread'
	from /opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/test-kitchen-1.20.0/lib/kitchen/command.rb:169:in `block (2 levels) in run_action'

Versions:

Chef Development Kit Version: 2.5.3
chef-client version: 13.8.5
delivery version: master (73ebb72a6c42b3d2ff5370c476be800fee7e5427)
berks version: 6.3.1
kitchen version: 1.20.0
inspec version: 1.51.21

kitchen-digitalocean (0.9.8)
kitchen-docker (2.6.0)
kitchen-dokken (2.6.7)
kitchen-ec2 (2.2.1)
kitchen-google (1.4.0)
kitchen-goss (0.0.2)
kitchen-hyperv (0.5.1)
kitchen-inspec (0.23.1)
kitchen-nodes (0.9.1)
kitchen-vagrant (1.3.1)
test-kitchen (1.20.0)

Any ideas? Thanks in advance!

Support Chef Infra Client Version 17.6.18

After a recent upgrade to Chef Infra Client Version 17.6.18, my Chef Infra Client run is failing on the Installing cookbook gem dependencies step, resulting in the below error indicating that there is something amiss with our usage of the kitchen-nodes utility now that we have upgraded the Chef Infra Client Version. Previously, it worked fine with version 16.13.16. Note that we are utilizing the kitchen-nodes-scalp42 variety from @scalp42.

Installing ed25519 1.2.4 with native extensions
STDERR: Gem::Ext::BuildError: ERROR: Failed to build gem native extension.



current directory:

C:/opscode/chef/embedded/lib/ruby/gems/3.0.0/gems/ed25519-1.2.4/ext/ed25519_ref10

C:/opscode/chef/embedded/bin/ruby.exe -I C:/opscode/chef/embedded/lib/ruby/3.0.0

-r ./siteconf20211006-1952-ynh39v.rb extconf.rb

creating Makefile



current directory:

C:/opscode/chef/embedded/lib/ruby/gems/3.0.0/gems/ed25519-1.2.4/ext/ed25519_ref10

make DESTDIR\= clean



current directory:

C:/opscode/chef/embedded/lib/ruby/gems/3.0.0/gems/ed25519-1.2.4/ext/ed25519_ref10

make DESTDIR\=

generating ed25519_ref10-x64-mingw32.def

compiling ed25519_ref10.c

In file included from

c:/opscode/chef/embedded/include/ruby-3.0.0/ruby/missing.h:38:0,

from

c:/opscode/chef/embedded/include/ruby-3.0.0/ruby/defines.h:80,

from

c:/opscode/chef/embedded/include/ruby-3.0.0/ruby/ruby.h:23,

                 from c:/opscode/chef/embedded/include/ruby-3.0.0/ruby.h:38,

                 from ed25519_ref10.c:1:

c:\opscode\chef\embedded\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/include/ieeefp.h:6:22:

fatal error: ansidecl.h: No such file or directory

compilation terminated.

make: *** [ed25519_ref10.o] Error 1



make failed, exit code 2



Gem files will remain installed in

C:/opscode/chef/embedded/lib/ruby/gems/3.0.0/gems/ed25519-1.2.4 for inspection.

Results logged to

C:/opscode/chef/embedded/lib/ruby/gems/3.0.0/extensions/x64-mingw32/3.0.0/ed25519-1.2.4/gem_make.out



An error occurred while installing ed25519 (1.2.4), and Bundler cannot continue.

Make sure that `gem install ed25519 -v '1.2.4' --source 'https://rubygems.org/'`

succeeds before bundling.



In Gemfile:

  kitchen-nodes-scalp42 was resolved to 0.10.0, which depends on

    test-kitchen was resolved to 3.1.0, which depends on

      ed25519

kitchen-nodes fails serverspec test on 2012 node due to unpopulated IP address

Scenario

Vagrant: 1.8.1
Test-Kitchen: 1.4.2
VirtualBox: 5.0.14

Action: Kitchen Verify
Expected result: 0 examples, 0 failures

Result

Failures:

         1) other node has a computername matching node fqdn
            Failure/Error:
       ::WinRM::WinRMWebService.new(
         "http://#{ip}:5985/wsman",
         :plaintext,
         user: 'vagrant',
         pass: 'vagrant',
         basic_auth_only: true
       )
            URI::InvalidURIError:
       the scheme http does not accept registry part: :5985 (or bad hostname?)

This is caused by a blank IP address for the Windows node in test\integration\nodes\node?-windows-2012R2.json.

I'll be sending a PR by with an added serverspec test that checks the IP is valid on the other node prior to trying to WinRM to it.

Net SCP error when using nodes

Returning to a cookbook I wrote a few months ago... I now see this error:

       Removing non-cookbook files before transfer
       Preparing data_bags
       Preparing nodes
       Preparing validation.pem
       Preparing client.rb
-----> Chef Omnibus installation detected (install only if missing)
       Transferring files to <linux-master-ra-centos-73>
C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-scp-1.2.1/lib/net/scp.rb:365:in `block (3 levels) in start_command': SCP did not finish successfully (1):  (Net::SCP::Error)
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/channel.rb:607:in `do_close'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:564:in `channel_closed'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:675:in `channel_close'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:540:in `dispatch_incoming_packets'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:237:in `ev_preprocess'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/event_loop.rb:99:in `each'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/event_loop.rb:99:in `ev_preprocess'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/event_loop.rb:27:in `process'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:216:in `process'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:178:in `block in loop'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:178:in `loop'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:178:in `loop'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/net-ssh-4.1.0/lib/net/ssh/connection/session.rb:124:in `close'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/test-kitchen-1.16.0/lib/kitchen/transport/ssh.rb:115:in `close'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/test-kitchen-1.16.0/lib/kitchen/transport/ssh.rb:98:in `cleanup!'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/test-kitchen-1.16.0/lib/kitchen/instance.rb:285:in `cleanup!'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/test-kitchen-1.16.0/lib/kitchen/command.rb:205:in `run_action_in_thread'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/test-kitchen-1.16.0/lib/kitchen/command.rb:169:in `block (2 levels) in run_action'
        from C:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/logging-2.2.0/lib/logging/diagnostic_context.rb:474:in `block in create_with_logging_context'

Does this mean anything to anyone? If I use chef_zero provisioner this does not happen. I'm currently pretty stumped.

Copy /tmp/kitchen/nodes back to workstation nodes dir after converge

Right now this doesnt seem to bring back the converged node attributes to the nodes directory on the workstation. For example, if you converge a node with an environment, environment attributes are written to the node json file on the instance (/tmp/kitchen/nodes/my-node.json). But the attributes are not written back to the node json file on the workstation (test/fixtures/nodes/my-node.json). The purpose of this would be to then search for the nodes that have attributes from an environment or that were set during a chef-client converge.

Is there a way to copy /tmp/kitchen/nodes from the instance back to the workstation nodes dir after converge?

Seems this could be done with data bags as well, some recipes create data bag items for recipes on other nodes to consume.

Doesn't seem to work with tags?

Using the following kitchen.yml:

---
driver:
  name: vagrant
  customize:
    cpus: 1
    memory: 2048

verifier:
  name: inspec

provisioner:
  name: nodes
  data_bags_path: <%= ENV['HOME'] + '/chef/data_bags' %>
  environments_path: <%= ENV['HOME'] + '/chef/environments' %>
  roles_path: <%= ENV['HOME'] + '/chef/roles' %>
  require_chef_omnibus: <%= ENV['CHEF_VERSION'] %>
  chef_omnibus_url: https://www.chef.io/chef/install.sh
  client_rb:
    environment: kitchen

platforms:
  - name: ubuntu-14.04
    driver:
      image: phusion/baseimage
      box: "ubuntu-14.04-chef-#{ENV['CHEF_VERSION']}"
      network:
        - ["forwarded_port", {guest: 8080, host: 8080, auto_correct: true}]
        - ["forwarded_port", {guest: 5050, host: 5050, auto_correct: true}]
        - ["forwarded_port", {guest: 5051, host: 5051, auto_correct: true}]
        - ["private_network", { type: "dhcp" }]

suites:
- name: master
  driver:
    pre_create_command: docker-compose up -d zk || true
  run_list:
  - recipe[vagrant-ohai]
  - recipe[mesos::master]
  attributes:
    boot2docker: <%= `docker-machine ip docker` %>
- name: slave
  run_list:
  - recipe[vagrant-ohai]
  - recipe[mesos::slave]
  attributes:
    boot2docker: <%= `docker-machine ip docker` %>

Scenario: the mesos::master recipe registers a tag and the mesos::slave looks for the tag.

Unfortunately, trying to converge multiple times, the two nodes don't appear to find each other.

I also checked within the /tmp/kitchen/nodes folder and it appears to look good:

root@master-ubuntu-1404:/tmp/kitchen/nodes# ll
total 156
drwxr-xr-x 2 vagrant vagrant   4096 Mar 26 04:44 ./
drwxrwxr-x 9 vagrant vagrant   4096 Mar 26 04:44 ../
-rw-r--r-- 1 vagrant vagrant 145318 Mar 26 04:45 master-ubuntu-1404.json
-rw-r--r-- 1 vagrant vagrant    382 Mar 26 04:44 slave-ubuntu-1404.json
root@master-ubuntu-1404:/tmp/kitchen/nodes# cat slave-ubuntu-1404.json | jq '.automatic.ipaddress'
"172.28.128.14"

root@slave-ubuntu-1404:/tmp/kitchen/nodes# ll
total 156
drwxr-xr-x 2 vagrant vagrant   4096 Mar 26 04:37 ./
drwxrwxr-x 9 vagrant vagrant   4096 Mar 26 04:44 ../
-rw-r--r-- 1 vagrant vagrant    386 Mar 26 04:44 master-ubuntu-1404.json
-rw-r--r-- 1 vagrant vagrant 145291 Mar 26 04:46 slave-ubuntu-1404.json
root@slave-ubuntu-1404:/tmp/kitchen/nodes# cat master-ubuntu-1404.json | jq '.automatic.ipaddress'
"172.28.128.13"

The master recipe:

  if tagged? "mesos.master.vagrantvbox.#{node.chef_environment}"
    log %|Already tagged Mesos MASTER node (Vagrant VirtualBox) #{node['ipaddress']} as available|
  else
    log %|Tagging Mesos MASTER node (Vagrant VirtualBox) #{node['ipaddress']} as available|
    tag "mesos.master.vagrantvbox.#{node.chef_environment}"
  end

The master log:

       Recipe: mesos::master
         * service[mesos-master] action enable (up to date)
         * service[mesos-master] action start (up to date)
         * log[Tagging Mesos MASTER node (Vagrant VirtualBox) 172.28.128.13 as available] action write

The slave recipe simply does a search for the master tag and defaults to itself if nothing found:

       [2016-03-26T04:44:56+00:00] WARN: mesos => Could not find any node matching "tags:mesos.master.vagrantvbox.kitchen", assuming a single Mesos MASTER node.

Any chance I'd be missing something on the test-kitchen or chef-zero side?

I've noticed it's missing the tag attributes so maybe it's not supported:

root@master-ubuntu-1404:/tmp/kitchen/nodes# cat slave-ubuntu-1404.json
{
  "id": "slave-ubuntu-1404",
  "chef_environment": "kitchen",
  "automatic": {
    "ipaddress": "172.28.128.14",
    "platform": "ubuntu",
    "fqdn": "slave-ubuntu-1404",
    "recipes": [
      "vagrant-ohai",
      "mesos::slave"
    ]
  },
  "normal": {
    "boot2docker": "192.168.99.100"
  },
  "run_list": [
    "recipe[vagrant-ohai]",
    "recipe[mesos::slave]"
  ]

root@slave-ubuntu-1404:/tmp/kitchen/nodes# cat master-ubuntu-1404.json
{
  "id": "master-ubuntu-1404",
  "chef_environment": "kitchen",
  "automatic": {
    "ipaddress": "172.28.128.13",
    "platform": "ubuntu",
    "fqdn": "master-ubuntu-1404",
    "recipes": [
      "vagrant-ohai",
      "mesos::master"
    ]
  },
  "normal": {
    "boot2docker": "192.168.99.100"
  },
  "run_list": [
    "recipe[vagrant-ohai]",
    "recipe[mesos::master]"
  ]

Thanks a lot in advance!

Nodes returned from search are missing attributes from ohai?

I have a cookbook that relies on search to build hostsfile entries for all nodes in the environment. In my case I need to pull the private network interface address out of the node attributes, but for some reason this fails for all the ways I've tested it. Even the ['ipaddress'] attribute of a returned node seems to be nil. I've checked the temp files created by kitchen-nodes and it has all the expected ohai information, but I cannot seem to access them in my chef recipes. Any idea what the issue might be? I can try to provide an example if its not already something youre testing for, unfortunately I cannot share my existing cookbook.

policyfile support

Hello,

do you plan to support policyfile in kitchen-nodes like policyfile_zero provisioner?

Error: Sandbox directory has not yet been created

This only happens on 0.6. Version 0.5 runs quite happily.

>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Failed to complete #converge action: [Sandbox directory has not yet been created. Please run Kitchen::Provisioner::Nodes#create_sandox before trying to access the path.]
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

Some debug info:

I'm on Arch Linux
/opt/chef/bin is the first thing in my $PATH

$ chef --version
Chef Development Kit Version: 0.10.0
chef-client version: 12.5.1
berks version: 4.0.1
kitchen version: 1.4.2

And the output from kitchen diagnose

timestamp: 2015-12-16 17:30:57 UTC
kitchen_version: 1.4.2
plugins:
  driver:
    Docker:
      class: Kitchen::Driver::Docker
      version: 
      api_version: 
  provisioner:
    Nodes:
      class: Kitchen::Provisioner::Nodes
      version: 
      api_version: 
  transport:
    Ssh:
      class: Kitchen::Transport::Ssh
      version: 1.4.2
      api_version: 1
  verifier:
    Busser:
      class: Kitchen::Verifier::Busser
      version: 1.4.2
      api_version: 1
loader:
  process_erb: true
  process_local: true
  process_global: true
  global_config: 
  project_config:
    filename: "/home/michael/development/secretproject/commander/chef/cookbook/.kitchen.yml"
    raw_data:
      driver:
        name: docker
        use_sudo: false
      provisioner:
        name: nodes
        roles_path: test/fixtures/roles
        nodes_path: test/fixtures/nodes
        client_rb:
          audit_mode: ":enabled"
      platforms:
      - name: centos
        driver_config:
          image: secretproject/test-kitchen:6-12.4.1
      suites:
      - name: default
        run_list:
        - recipe[commander::default]
        attributes:
          packaging:
            ds_build_gocd:
              enabled: true
  local_config: 
  combined_config:
    filename: 
    raw_data:
      driver:
        name: docker
        use_sudo: false
      provisioner:
        name: nodes
        roles_path: test/fixtures/roles
        nodes_path: test/fixtures/nodes
        client_rb:
          audit_mode: ":enabled"
      platforms:
      - name: centos
        driver_config:
          image: secretproject/test-kitchen:6-12.4.1
      suites:
      - name: default
        run_list:
        - recipe[commander::default]
        attributes:
          packaging:
            ds_build_gocd:
              enabled: true
instances:
  default-centos:
    platform:
      os_type: unix
      shell_type: bourne
    state_file:
      container_id: bf49a475ed68d37a9e9b648b60bfe63edf3fefe58ac8eb3be131554c9a436b5b
      hostname: localhost
      image_id: 6c1da0217a76
      last_action: create
      port: 32779
      ssh_key: "/home/michael/development/secretproject/commander/chef/cookbook/.kitchen/docker_id_rsa"
    driver:
      binary: docker
      build_context: true
      cap_add: 
      cap_drop: 
      disable_upstart: true
      image: secretproject/test-kitchen:6-12.4.1
      kitchen_root: "/home/michael/development/secretproject/commander/chef/cookbook"
      log_level: :info
      name: docker
      password: kitchen
      platform: centos
      port: 22
      private_key: "/home/michael/development/secretproject/commander/chef/cookbook/.kitchen/docker_id_rsa"
      privileged: false
      public_key: "/home/michael/development/secretproject/commander/chef/cookbook/.kitchen/docker_id_rsa.pub"
      publish_all: false
      remove_images: false
      run_command: "/usr/sbin/sshd -D -o UseDNS=no -o UsePAM=no -o PasswordAuthentication=yes
        -o UsePrivilegeSeparation=no -o PidFile=/tmp/sshd.pid"
      security_opt: 
      socket: unix:///var/run/docker.sock
      sudo: true
      test_base_path: "/home/michael/development/secretproject/commander/chef/cookbook/test/integration"
      tls: false
      tls_cacert: 
      tls_cert: 
      tls_key: 
      tls_verify: false
      use_cache: true
      use_sudo: false
      username: kitchen
      wait_for_sshd: true
    provisioner:
      attributes:
        packaging:
          ds_build_gocd:
            enabled: true
      chef_client_path: "/opt/chef/bin/chef-client"
      chef_metadata_url: 
      chef_omnibus_install_options: 
      chef_omnibus_root: "/opt/chef"
      chef_omnibus_url: https://www.chef.io/chef/install.sh
      chef_zero_host: 
      chef_zero_port: 8889
      client_rb:
        audit_mode: ":enabled"
      clients_path: 
      cookbook_files_glob: README.*,metadata.{json,rb},attributes/**/*,definitions/**/*,files/**/*,libraries/**/*,providers/**/*,recipes/**/*,resources/**/*,templates/**/*
      data_bags_path: 
      data_path: 
      encrypted_data_bag_secret_key_path: 
      environments_path: 
      http_proxy: 
      https_proxy: 
      json_attributes: true
      kitchen_root: "/home/michael/development/secretproject/commander/chef/cookbook"
      log_file: 
      log_level: :info
      name: nodes
      nodes_path: "/home/michael/development/secretproject/commander/chef/cookbook/test/fixtures/nodes"
      require_chef_omnibus: true
      roles_path: "/home/michael/development/secretproject/commander/chef/cookbook/test/fixtures/roles"
      root_path: "/tmp/kitchen"
      ruby_bindir: "/opt/chef/embedded/bin"
      run_list:
      - recipe[commander::default]
      sudo: true
      sudo_command: sudo -E
      test_base_path: "/home/michael/development/secretproject/commander/chef/cookbook/test/integration"
    transport:
      compression: true
      compression_level: 6
      connection_retries: 5
      connection_retry_sleep: 1
      connection_timeout: 15
      keepalive: true
      keepalive_interval: 60
      kitchen_root: "/home/michael/development/secretproject/commander/chef/cookbook"
      log_level: :info
      max_wait_until_ready: 600
      name: ssh
      port: 22
      ssh_key: 
      test_base_path: "/home/michael/development/secretproject/commander/chef/cookbook/test/integration"
      username: root
    verifier:
      busser_bin: "/tmp/verifier/bin/busser"
      http_proxy: 
      https_proxy: 
      kitchen_root: "/home/michael/development/secretproject/commander/chef/cookbook"
      log_level: :info
      name: busser
      root_path: "/tmp/verifier"
      ruby_bindir: "/opt/chef/embedded/bin"
      sudo: true
      sudo_command: sudo -E
      suite_name: default
      test_base_path: "/home/michael/development/secretproject/commander/chef/cookbook/test/integration"
      version: busser

Searching fqdn and ip on windows breaks

a1f9bf7 fixes this.

Sandbox not created errors?

not sure why but when using nodes as provisioner always get the sandbox not created errors

>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Failed to complete #converge action: [Sandbox directory has not yet been created. Please run Kitchen::Provisioner::Nodes#create_sandox before trying to access the path.]

any advice here?

Trying to run multiple 'usable' nodes (which can be connected to directly) and wanted to evaluate how the kitchen-nodes could help do some of this.

Windows FQDN constructed from internal hostname rather than Openstack instance name

Hello;
Kitchen-nodes has been working great for CentOS instances, but I'm having an issue where my Windows 2012 R2 instance will populate the nodes json with the internal windows hostname (like WIN-123BFKDS812 for example) rather than the "kitchen" name for the node defined by the Openstack instance name.

kitchen.yml info

driver:
  name: openstack

provisioner:
  name: nodes

platforms:
  - name: centos-6.7
  - name: windows-2012r2-standard-gui

...

 - name: default
    includes:
      - windows-2012r2
    run_list:
      - recipe[cookbook::recipe]

Here is a normal (working) centos nodes json "automatic" section

  "automatic": {
    "ipaddress": "10.1.1.1",
    "platform": "centos",
    "fqdn": "username-tk-default-cookbook-env.domain.com",
    "recipes": [
      "cookbook::recipe"
    ]
  }

and my incorrect windows nodes json "automatic" section

  "automatic": {
    "ipaddress": "10.1.1.2",
    "platform": "windows",
    "fqdn": "WIN-1OQLPP07BAL.domain.com",
    "recipes": [
      "cookbook::recipe"
    ]
  }

I need to to populate the "fqdn" attribute with something similar to the centos nodes. I saw in the Changelog there were similar issues addressed; is this some setting that I am missing?

Changed some of the info in code for private reasons.

Thanks.

EDIT: Removed the error message after realizing it is generated by a recipe, not kitchen.

Using kitchen-nodes with dokken

Have had wild success with kitchen-nodes and was happy to get the opportunity to personally thank you, @mwrock, before your HashiConf presentation this year. I just recently started moving all my kitchen-vagrant and kitchen-docker stuff over to kitchen-dokken and have also had great success with it. Today I got to a cookbook that requires kitchen-nodes so I tried converting it from kitchen-docker to kitchen-dokken, but it failed. Is this even possible? If not, no worries. Just always look to implement some consistency in my process is all. Cheers.

Todd Michael

test-kitchen dependency version is too old

It's impossible to use the latest version of this gem:

  In Gemfile:
    test-kitchen

    kitchen-inspec was resolved to 1.1.0, which depends on
      test-kitchen (>= 1.6, < 3)

    kitchen-nodes (~> 0.9.1) was resolved to 0.9.1, which depends on
      test-kitchen (~> 1.13)

    kitchen-vagrant was resolved to 1.5.2, which depends on
      test-kitchen (>= 1.4, < 3)

Without setting a version, it installs the version 0.2.0.dev.1 which doesn't work with actual test-kitchen version.

help request with testing

I'm working on a PR to add support for windows 2008R2 (https://github.com/johnsmyth/kitchen-nodes/tree/add_win2008r2_support). It seems to work, however the servspec tests fail because node[:ip_address] is an array instead of a single ip. I can change the tests, but wanted to make sure that I should first- i.e. that the fact multiple ip addresses in node[:ip_address] is valid and not some bug I introduced.

There is also a failing test for a hostname that is failing( : its(:stdout) { should_not match(/#{Regexp.quote(fqdn)}/) } ) but I'm not sure of the purpose of the test?

Btw you need 1.7.2 of the winrm gem to run this on windows 2008r2 or you get an "illegal quoting on line 1" error.

Converge of windows 2008R2 fails with message: Failed to complete #converge action: [Unable to retrieve IPs]

I'm getting an error trying to converge a windows 2008r2 machine with test kitchen, The kitchen logs are pasted below. It seems like it might have something to do with Get-NetIPConfiguration not seeming to be available in powershell 2 (https://github.com/mwrock/kitchen-nodes/blob/v0.4.0/lib%2Fkitchen%2Fprovisioner%2Fip_finder%2Fwinrm.rb#L24 ), however I know I've used kitchen-nodes with 2008r2 before without issue.....

Chef Development Kit Version: 0.11.2
chef-client version: 12.7.2
berks version: 4.2.0
kitchen version: 1.5.0

I, [2016-03-04T16:34:23.098740 #21609]  INFO -- Kitchen: -----> Starting Kitchen (v1.5.0)
I, [2016-03-04T16:34:25.579370 #21609]  INFO -- Kitchen: -----> Creating <test-ad-dc>...
I, [2016-03-04T16:37:36.174724 #21609]  INFO -- Kitchen: -----> Converging <test-ad-dc>...
I, [2016-03-04T16:47:31.988985 #21609]  INFO -- Kitchen: -----> Creating <default-windows-2008r2>...
I, [2016-03-04T16:53:36.905845 #21609]  INFO -- Kitchen: -----> Converging <default-windows-2008r2>...
E, [2016-03-04T16:53:37.631345 #21609] ERROR -- Kitchen: ------Exception-------
E, [2016-03-04T16:53:37.631374 #21609] ERROR -- Kitchen: Class: Kitchen::ActionFailed
E, [2016-03-04T16:53:37.631388 #21609] ERROR -- Kitchen: Message: Failed to complete #converge action: [Unable to retrieve IPs]
E, [2016-03-04T16:53:37.631400 #21609] ERROR -- Kitchen: ---Nested Exception---
E, [2016-03-04T16:53:37.631411 #21609] ERROR -- Kitchen: Class: RuntimeError
E, [2016-03-04T16:53:37.631422 #21609] ERROR -- Kitchen: Message: Unable to retrieve IPs
E, [2016-03-04T16:53:37.631432 #21609] ERROR -- Kitchen: ------Backtrace-------
E, [2016-03-04T16:53:37.631442 #21609] ERROR -- Kitchen: /Users/jsmyth/.chefdk/gem/ruby/2.1.0/gems/kitchen-nodes-0.6.4/lib/kitchen/provisioner/nodes.rb:135:in `active_ips'
E, [2016-03-04T16:53:37.631470 #21609] ERROR -- Kitchen: /Users/jsmyth/.chefdk/gem/ruby/2.1.0/gems/kitchen-nodes-0.6.4/lib/kitchen/provisioner/nodes.rb:123:in `get_reachable_guest_address'
E, [2016-03-04T16:53:37.631483 #21609] ERROR -- Kitchen: /Users/jsmyth/.chefdk/gem/ruby/2.1.0/gems/kitchen-nodes-0.6.4/lib/kitchen/provisioner/nodes.rb:58:in `ipaddress'
E, [2016-03-04T16:53:37.631500 #21609] ERROR -- Kitchen: /Users/jsmyth/.chefdk/gem/ruby/2.1.0/gems/kitchen-nodes-0.6.4/lib/kitchen/provisioner/nodes.rb:103:in `node_template'
E, [2016-03-04T16:53:37.631512 #21609] ERROR -- Kitchen: /Users/jsmyth/.chefdk/gem/ruby/2.1.0/gems/kitchen-nodes-0.6.4/lib/kitchen/provisioner/nodes.rb:41:in `create_node'
E, [2016-03-04T16:53:37.631523 #21609] ERROR -- Kitchen: /Users/jsmyth/.chefdk/gem/ruby/2.1.0/gems/kitchen-nodes-0.6.4/lib/kitchen/provisioner/nodes.rb:34:in `create_sandbox'
E, [2016-03-04T16:53:37.631533 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/provisioner/base.rb:63:in `call'
E, [2016-03-04T16:53:37.631544 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:373:in `block in converge_action'
E, [2016-03-04T16:53:37.631554 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:495:in `call'
E, [2016-03-04T16:53:37.631564 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:495:in `synchronize_or_call'
E, [2016-03-04T16:53:37.631575 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:460:in `block in action'
E, [2016-03-04T16:53:37.631585 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/2.1.0/benchmark.rb:279:in `measure'
E, [2016-03-04T16:53:37.631595 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:459:in `action'
E, [2016-03-04T16:53:37.631605 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:369:in `converge_action'
E, [2016-03-04T16:53:37.631615 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:348:in `block in transition_to'
E, [2016-03-04T16:53:37.631646 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:347:in `each'
E, [2016-03-04T16:53:37.631657 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:347:in `transition_to'
E, [2016-03-04T16:53:37.631667 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/instance.rb:138:in `converge'
E, [2016-03-04T16:53:37.631684 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/command.rb:176:in `public_send'
E, [2016-03-04T16:53:37.631695 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/test-kitchen-1.5.0/lib/kitchen/command.rb:176:in `block (2 levels) in run_action'
E, [2016-03-04T16:53:37.631706 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/logging-2.0.0/lib/logging/diagnostic_context.rb:448:in `call'
E, [2016-03-04T16:53:37.631716 #21609] ERROR -- Kitchen: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/logging-2.0.0/lib/logging/diagnostic_context.rb:448:in `block in create_with_logging_context'
E, [2016-03-04T16:53:37.631727 #21609] ERROR -- Kitchen: ----------------------