How can set dynamic attribute value in .kitchen.yml

Question

I am using kitchen with ec2 driver. I would like to add Name tag to ec2 instances based on the instance name kitchen creates. If I had a 'default' suite and was using centos7.2, kitchen list would name the instance 'default-centos-72'.

I could hard code something like this:

suites:
  - name: default
    driver_config: 
      tags: { "Name": "kitchen-default-centos-72" }

But what I'd really like is something like this:

suites:
  - name: default
    driver_config: 
      tags: { "Name": <%= figure out instance name and prepend kitchen- %> }

My example suggests using ERB which seems like the way to go to me. But I can't seem to figure out what code to use to get the name of the instance. I tried using a bit of Kitchen::Config.new... but couldn't figure out something that worked. Any suggestions would be much appreciated.

Answer 1

Took me a while but I finally ran across an example that may have showed me the light. While looking through the InSpec options for kitchen I found you can have it output a results file with the platform and suite name that was used during the test run. The below syntax in your platforms: block nested under the driver: option should work. I haven't tested this by examining the instance during a run but hopefully I can find some time to do that soon. If it doesn't work let me know and we can tweak it until it does.

platforms:
  - name: ubuntu
    driver:
      tags:
        Name: test-kitchen-%{platform}-%{suite}

How this should work is that the .kitchen.yml file gets run through an ERB pre-processor so the %{platform} resolves to an instance variable during the loop across the platforms and suites arrays.

Answer 2

As far as I can tell there seems to be no straightforward way to include instance properties in the kitchen YAML. I added the following snippet to my kitchen.yml to check what is available in the kitchen YAML's ERB namespace:

<%
puts "Instance vars: #{instance_variables}"
puts "Local vars: #{local_variables}"
puts "Global vars: #{global_variables}"
puts "Methods: #{methods}"
%>

The results when running kitchen create for a specific instance were disappointing, containing nothing that looks like instance specification data:

Instance vars: []
Local vars: [:_erbout, :spec, :bin_file]
Global vars: [:$-0, :$\, :$DEBUG, :$-W, :$0, :$-d, :$-p, :$PROGRAM_NAME, :$:, :$-I, :$LOAD_PATH, :$", :$LOADED_FEATURES, :$,, :$/, :$INPUT_LINE_NUMBER, :$-l, :$-a, :$INPUT_RECORD_SEPARATOR, :$ORS, :$OUTPUT_RECORD_SEPARATOR, :$PROCESS_ID, :$NR, :$@, :$!, :$DEFAULT_INPUT, :$PID, :$PREMATCH, :$CHILD_STATUS, :$LAST_MATCH_INFO, :$LAST_READ_LINE, :$DEFAULT_OUTPUT, :$MATCH, :$fileutils_rb_have_lchown, :$POSTMATCH, :$LAST_PAREN_MATCH, :$IGNORECASE, :$ARGV, :$fileutils_rb_have_lchmod, :$stdin, :$stdout, :$stderr, :$>, :$<, :$., :$FILENAME, :$-i, :$*, :$SAFE, :$thor_runner, :$_, :$~, :$;, :$-F, :$?, :$$, :$ERROR_INFO, :$&, :$`, :$', :$+, :$=, :$KCODE, :$-K, :$ERROR_POSITION, :$FS, :$FIELD_SEPARATOR, :$OFS, :$OUTPUT_FIELD_SEPARATOR, :$RS, :$VERBOSE, :$-v, :$-w]
Methods: [:inspect, :to_s, :to_yaml, :to_json, :instance_variable_defined?, :remove_instance_variable, :instance_of?, :kind_of?, :is_a?, :tap, :methods, :instance_variable_set, :protected_methods, :instance_variables, :instance_variable_get, :private_methods, :public_methods, :method, :define_singleton_method, :public_send, :singleton_method, :public_method, :extend, :to_enum, :enum_for, :<=>, :===, :=~, :!~, :eql?, :respond_to?, :freeze, :object_id, :send, :display, :class, :nil?, :hash, :dup, :singleton_class, :clone, :then, :itself, :yield_self, :untaint, :taint, :tainted?, :untrusted?, :trust, :frozen?, :untrust, :singleton_methods, :equal?, :!, :__id__, :==, :instance_exec, :!=, :instance_eval, :__send__]

The local variable spec looked hopeful at first, but turned out to be a GemSpec object.

All things considered, you will probably have to create a convention to always specify the instance in some external way. You could use for example an environment variable of your choice, which you could then access in the template as <%= ENV['<VARNAME>'] %> (where you replace <VARNAME> with the name of your environment variable). There are probably other ways of getting the information in there, but you will still have to specify it in more places than just the Test Kitchen command.