Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Customize does not support OpenStack provider #171

Closed
xmik opened this issue May 21, 2015 · 2 comments · Fixed by #172
Closed

Customize does not support OpenStack provider #171

xmik opened this issue May 21, 2015 · 2 comments · Fixed by #172

Comments

@xmik
Copy link
Contributor

xmik commented May 21, 2015

A Hash of customizations to a Vagrant virtual machine supports some Vagrant providers, e.g. it does not support openstack provider. Real use case: when I set in .kitchen.yml:

    driver_config:
      box:  'debian-7.5-chef-11.16.4'
      ssh_key: '~/.ssh/id_rsa'
      customize:
        keypair_name: 'my-ssh-key'

The generated Vagrantfile should contain

  c.vm.provider :openstack do |p|
      p.keypair_name = "my-ssh-key"
  end

but instead it does:

  c.vm.provider :openstack do |p|
  end
xmik added a commit to ai-traders/kitchen-vagrant that referenced this issue May 21, 2015
@xmik xmik changed the title Customize does not supports OpenStack provider Customize does not support OpenStack provider May 25, 2015
xmik added a commit to ai-traders/kitchen-vagrant that referenced this issue May 26, 2015
@tyler-ball
Copy link
Contributor

Hey @xmik - is there a reason you're using kitchen-vagrant instead of kitchen-openstack? As you see in your PR, all of the logic for customize is driven through an ERB file which is hard to read, test and maintain. If we can avoid adding more logic to it then we will.

We don't really want to add a catch-all else statement in the ERB because its probably not going to work for everything else (as demonstrated by the variety of elements already in the case statement). We would prefer to have a openstack-specific block that could be expanded to include other providers that match the same format. But again, we don't want to expand that ERB any more if we can help it.

You can supply a custom Vagrantfile.erb that you could format with whatever you want. If your proposed change is the only change you need from the base template that Test Kitchen provides, then it may not be worth it creating your own custom Vagrantfile. But its an option - would you want to use that? You can set the path to your custom Vagrantfile.erb with

driver:
  vagrantfile_erb: /path/to/file

If you do want to continue with a PR that supports openstack, you'll have to also add test coverage for it.

@xmik
Copy link
Contributor Author

xmik commented May 29, 2015

@tyler-ball, thanks for response. I use kitchen-vagrant instead of kitchen-openstack:

  • in order to avoid very long configuration in .kitchen.yml. Vagrant boxes make it possible.
  • kitchen-vagrant supports Windows, kitchen-openstack does not (as indicated in Enhancement: Windows Support kitchen-openstack#45, I also tried it and it did not work for me. However, there came a PR 4 days ago to support Windows, I didn't try it yet).
  • I also use docker and wanted to avoid using 3 kitchen providers (kitchen-vagrant for OpenStack Windows, kitchen-openstack for OpenStack Linux machines, kitchen-docker for docker containers).

I saw the option that I can supply a custom Vagrantfile.erb, but I didn't want to supply it in each cookbook.

It sounds reasonable to avoid catch-all else statement in Vagrantfile.erb. I'll change it to support only openstack vagrant provider and I'll add tests.

xmik added a commit to ai-traders/kitchen-vagrant that referenced this issue May 29, 2015
xmik added a commit to ai-traders/kitchen-vagrant that referenced this issue May 29, 2015
tyler-ball added a commit that referenced this issue Jun 24, 2015
…ders

Customize supports other vagrant providers, fixes #171
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants