manifest setting not honored about kitchen-puppet HOT 20 CLOSED

it looks for the manifest in the manifests directory of the root path

from kitchen-puppet.

try changing
File.join(config[:root_path], 'manifests', manifest)
to
File.join(config[:root_path], 'manifests', config[:manifest])

from kitchen-puppet.

i don't think the above is necessary though.
try running test kitchen with the debug option

from kitchen-puppet.

I'm saying that the 'override' in the suites does not work. setting the manifest in the provisioner option does work

from kitchen-puppet.

Overides in suites is handled by core test kitchen code so this is not an issue in the plugin code.
It could be that because even through this is provisioner code it is using a plugin architecture designed for drivers and maybe driver parameters cannot be specified in suites?
in the longer term this code will go into code test-kitchen.
If you want to pursue this i suggest you run with debug and maybe put in puts in the test kitchen code.
you could also move my code into the provisioner part of test-kitchen and see if it works there.

from kitchen-puppet.

won't fix is ok for me. are you in conversation with @FNichols about integration?

from kitchen-puppet.

it is a pull request in test-kitchen

from kitchen-puppet.

@neillturner I still see this behavior. Putting manifest: init.pp under the provisioner options works. Do you have a status update for this pr?

from kitchen-puppet.

sorry don't remember this. what is the problem again so i can reproduce?

from kitchen-puppet.

@ehaselwanter I am able to set provisioner options at the suite level by adding it into the provisioner config hash. Test-kitchen reads in native YAML and setting provisioner options are allowed globally.
Try:

suites:
  - name: default
    provisioner:
      manifest: init.pp

I have found that this can work with all provisioner options to set them at the suite-level. To check, you can always run: kitchen diagnose and check the provisioner hash for the correct parameters that you wish to specify.

from kitchen-puppet.

@grubernaut: It should work as expected. Same like with chef. You have to create multiple suites in the directory. Have a look at an example, did not come around to write a blog post about it

https://github.com/ehaselwanter/puppet-kitchen-example/tree/multiple-suites

from kitchen-puppet.

I setup things like this in my kitchen.yml:

provisioner:
name: puppet_apply
manifests_path: manifests
modules_path: my_modules
hiera_data_path: hieradata
require_puppet_omnibus: false
require_chef_for_busser: false
puppet_omnibus_url: bad_url
puppet_debug: true
puppet_verbose: true

suites:
name: sinopia
provisioner:
custom_facts:
role_name1: base
role_name2: sinopia
driver_config:
network:
['forwarded_port', {guest: 4783, host: 4783}]
['private_network', { ip: '192.168.99.99' } ]

from kitchen-puppet.

@ehaselwanter I agree it should "Just Work". But setting the parameters under the provisioner hash does still set provisioner options per suite.

suites:
  - name: web
    provisioner:
      manifest: web.pp
  - name: database
    provisioner:
      manifest: database.pp

Having the above in my .kitchen.yml allows me to set per-suite provisioner parameters.

Unless I'm understanding the problem wrong?

from kitchen-puppet.

what do you mean by "provisioner options" ? define the manifest?

https://github.com/ehaselwanter/puppet-kitchen-example/blob/multiple-suites/.kitchen.yml

suites:
  - name: default
    manifest: site.pp
  - name: the_other_suite
    manifest: site.pp

± kitchen list
Instance                          Driver   Provisioner  Last Action
default-nocm-ubuntu-1204          Vagrant  PuppetApply  <Not Created>
the-other-suite-nocm-ubuntu-1204  Vagrant  PuppetApply  <Not Created>

± tree test/integration
test/integration
├── default
│   ├── Modulefile
│   ├── Puppetfile
│   ├── Puppetfile.lock
│   ├── bats
│   │   └── verify_installed.bats
│   ├── puppet
│   │   └── manifests
│   │       └── site.pp
│   └── serverspec
│       ├── ntp_spec.rb
│       └── spec_helper.rb
└── the_other_suite
    ├── puppet
    │   ├── Modulefile
    │   ├── Puppetfile
    │   ├── Puppetfile.lock
    │   └── manifests
    │       └── site.pp
    └── serverspec
        ├── ntp_spec.rb
        └── spec_helper.rb

9 directories, 13 files

from kitchen-puppet.

thanks for that. when i get a moment i will test.

from kitchen-puppet.

hm. @neillturner : Maybe I did not express myself clearly: it just works. you do not need to re-open. I'm using it that way.

or I miss understood. (@grubernaut: does the example work for you, is it what you expect?)

checkout the testrepo/branch to see it working:

https://github.com/ehaselwanter/puppet-kitchen-example/blob/multiple-suites/

I really have to write a blog post for this example ...

from kitchen-puppet.

@ehaselwanter yeah, that works for me as well.

I was just mentioning that you can set suite-specific parameters for the provisioner hash.

---
driver_plugin: docker

provisioner:
  name: puppet_apply
  puppet_version: 3.5.1-1puppetlabs1
  manifests_path: manifests
  modules_path: 'modules/minted'
  hiera_config_path: .kitchen_hiera.yaml
  hiera_data_path: hieradata
  puppet_config_path: puppet.conf
  resolve_with_librarian_puppet: true
  require_chef_for_busser: true

platforms:
  - name: ubuntu-12.04
    driver_config:
      socket: <%= ENV['DOCKER_HOST'] %>
      use_cache: true
      provision_command:
        - dpkg-reconfigure -au
        - apt-get install -y apt-utils
        - apt-get install -y python-software-properties

suites:
  - name: web
    provisioner:
      manifest: web.pp
      custom_facts:
        role: website
  - name: database
    provisioner:
      manifest: database.pp
      custom_facts:
        role: database

Yields suite-specific provisioner parameters. (I've removed a lot of the cruft from the kitchen diagnose output, but it's showing the same:

instances:
  web-ubuntu-1204:
    state_file:
    driver:
    provisioner:
      custom_facts:
        role: website
      manifest: web.pp
  database-ubuntu-1204:
    state_file: 
    driver:
    provisioner:
      custom_facts:
        role: database
      manifest: database.pp

This is the same as setting suite-specific attribute values with chef shown here. Our provisioner just doesn't have an attributes hash to set common values such as a run_list.
But by adding any provisioner parameters that you wish to set at the suite level to a provisioner hash, you can set suite-specific provisioner parameters.

from kitchen-puppet.

@neillturner @grubernaut : I lost track, what is not working then?

from kitchen-puppet.

@ehaselwanter @neillturner It is working, and I believe we can close the issue. Just was making the point that we can set provisioner attributes at a suite level as well. There's no documentation for it though, and it may be a good thing to highlight in your blog @ehaselwanter, as that helped me a whole lot when I was digging into kitchen-puppet.

from kitchen-puppet.

closed again

from kitchen-puppet.