FR: Set the hostname of the system at creation time.

[glaisne]

🗣️ Foreword

Thank for taking the time to fill this feature request fully. Without it we may not be able to , and the issue may be closed without resolution.

🙍 Problem Statement

There is no capability to set the hostname of the system at creation time (yml file). Many of our existing (dev/test/stage/prod) systems already have their hostname set and some recipes utilize that. But for kitchen we can't accurately test these recipes in AWS. We are utilizing the hostname resource which requires a reboot and breaks the rest of the recipe test. So, it takes kitchen 2 runs to test these recipes.

❔ Possible Solution

adding hostname: or vm_hostname: to the driver would resolve this issue.

⤴️ Describe alternatives you've considered

Again, we are using hostname resoruce which requires a reboot. Unfortunately, we can't move back to using Vagrant for testing becuase one step is installing an AWS agent which validates that it is an AWS-hosted system and will fail if it is not.

➕ Additional context

So, without the hostname being set at creation time, we have to rely on the hostname resource and the subsequent reboot. We also can't go back to non-AWS hosting as one of the software installations require to be an AWS hosted system.

Thanks for looking at this!

[JaBurd]

Is it possible to leverage a .kitchen.yml attribute for this? ohai should set it in production, but I think you should also be able to supply the hostname via attribute in test kitchen so it's available during testing.

[glaisne]

Every kitchen.yml variation I've tried doesn't work (hostname:, vm_hostname:, under driver:, under suites:...).
driver:
name: ec2
region:
shared_credentials_profile:
aws_ssh_key_id:
subnet_id:
hostname: yml1.xyz.local
vm_hostname: yml2.xyz.local

provisioner:
name: chef_zero
product_name: chef
product_version: 15.8.23
client_rb:
file_cache_path: 'c:\chef\cache'
chef_license: accept

verifier:
name: inspec

platforms:

• name: windows-2012r2

suites:

• name: testing
  run_list:
  • recipe[]
    driver:
    vm_hostname: yml3.xyz.local
    hostname: yml4.xyz.local

transport:
ssh_key: ''

[JaBurd]

In your suites: section you'd want to set an attribute value for "hostname: 'my.host.name"

As shown in the documentation: https://docs.chef.io/workstation/config_yml_kitchen/

  - name: suite_name
    run_list:
      - recipe[cookbook_name::recipe_name]
    attributes: { foo: "bar" }
    excludes:
      - platform-version
  - name: suite_name
    driver:
      name: driver_name
    run_list:
      - recipe[cookbook_name::recipe_name]
    attributes: { hostname: "yml3.xyz.local" }
    includes:
      - platform-version

[glaisne]

So, I've gone over this multiple different ways and included other chef experts without any luck making this work. In the end, there is nothing in the logs and no indicator on the system (that I can find) that even references the specified hostname.

[JaBurd]

Hmm, that's true, it's probably a system attribute that would get over-written/ridden anyway. 🤔

This may not be feasible unless there's some way to "spoof" the system hostname.

[JaBurd]

Another option and might be easier is to set "tags" on the system that define what the system is. I'm assuming you're using the Hostname to make some logic decisions based off of that. But you could also tag a system as a "web server" or "database server" or whatever you want. Your logic would read those tags vs the hostname to make the required decisions. You're effectively separating the actual hostname which is a system value and does require some rebooting to set (I'm not sure how you get around that) from the logic you want your code to perform.

Ideally you want the underlying hardware to not really have an impact on what your logic is. i.e. you'd strive to not really care about what the systems hostname is, but what "type" of system is it and what actions do I need to perform to ensure it can serve that function. Once your load balancer is setup and the ec2 is getting the proper traffic on the proper ports, the logic should only be concerned with ensuring the services on those ports are functioning the way they should be.

Also using AWS you can set EC2 tags, or you can set Chef Tags, either should work fine for this situation. I tend to prefer the Chef Tags as they can be setup in the CF Templates on build and your Chef code can just pull them to consume them.