Exception while declaring a service

[teintuc]

When applying a second time a simple kube service declaration:

$namespace="hello-world"

kubernetes_service { "$namespace-svc":
  ensure => present,
  require => [Kubernetes_namespace["$namespace"]],
  metadata => {
    name => $namespace,
    namespace => $namespace,
    labels => {
      'app' => $namespace
    },
  },
  spec => {
    ports => [{'port'=>80, 'targetPort'=>8080}],
    selector => {'app' => $namespace},
    type => 'LoadBalancer',
  },
}

It produces the following error:

Error: undefined method `keys' for "hello-world":String
/etc/puppetlabs/code/environments/production/modules/kubernetes/lib/puppet_x/puppetlabs/swagger/fuzzy_compare.rb:30:in `test_complex_structure'
/etc/puppetlabs/code/environments/production/modules/kubernetes/lib/puppet_x/puppetlabs/swagger/fuzzy_compare.rb:51:in `block (2 levels) in test_complex_structure'
/etc/puppetlabs/code/environments/production/modules/kubernetes/lib/puppet_x/puppetlabs/swagger/fuzzy_compare.rb:50:in `collect'
/etc/puppetlabs/code/environments/production/modules/kubernetes/lib/puppet_x/puppetlabs/swagger/fuzzy_compare.rb:50:in `block in test_complex_structure'
/etc/puppetlabs/code/environments/production/modules/kubernetes/lib/puppet_x/puppetlabs/swagger/fuzzy_compare.rb:30:in `collect'
/etc/puppetlabs/code/environments/production/modules/kubernetes/lib/puppet_x/puppetlabs/swagger/fuzzy_compare.rb:30:in `test_complex_structure'
/etc/puppetlabs/code/environments/production/modules/kubernetes/lib/puppet_x/puppetlabs/swagger/fuzzy_compare.rb:22:in `fuzzy_compare'
/etc/puppetlabs/code/environments/production/modules/kubernetes/lib/puppet/type/kubernetes_service.rb:33:in `insync?'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/property.rb:277:in `safe_insync?'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:123:in `sync_if_needed'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:88:in `block in perform_changes'

The reason is that in our case we have mcollective installed in the same ruby environment (which is the case of puppet AIO). Mcollective uses the stomp gem which also defines a symbolise_keys which is not recursive. The keys from sub hashes are not transfomed to symbols which makes the fuzzy comparator unhappy.

The quick fix would be to rename the symbolise_key function to something more specific to this project.

Thanks.

[teintuc]

I opened this PR #24 to fix the problem

[garethr]

Thanks, I've merged the upstream change and the referenced PR. Much appreciated.

[walkamongus]

It seems like this is still an issue. When trying to add a label to a kubernetes_deployement, I'm getting this error thrown on the value of the new label.

For instance, if I update

kubernetes_deployment { "myapp":
  ensure => present,
  metadata => {
    'labels' => {
      'app' => 'myapp',
    },
...

to

kubernetes_deployment { "myapp":
  ensure => present,
  metadata => {
    'labels' => {
      'app'  => 'myapp',
      'test' => 'puppet',
    },

I get Error: undefined method 'keys' for "puppet":String

[walkamongus]

I've tracked this down to https://github.com/garethr/garethr-kubernetes/blob/master/lib/puppet_x/puppetlabs/swagger/fuzzy_compare.rb#L43

As the function descends into the metadata structure, eventually normalized_should[key][inner_key] looks like normalized_should[:labels][:test], which means the recursive function is called with test_complex_structure('puppet', nil) and then blows up at https://github.com/garethr/garethr-kubernetes/blob/master/lib/puppet_x/puppetlabs/swagger/fuzzy_compare.rb#L23 when the keys method is called on a String.

[masterzen]

@walkamongus can you try our fork here: https://github.com/daysofwonder/garethr-kubernetes or this version with PR #39 applied ?

I think this will fix your issue. Our fork is just all PR open by @teintuc or myself here (or in puppet-swagger) applied.

Note that there's one thing that doesn't yet work for us is removing an annotation.

[walkamongus]

Thanks @masterzen -- I actually applied the change in #38 and it fixed my issue and additional labels were automatically added to my deployment. I assume this PR is already in your fork as well? I'll switch over if so.

[masterzen]

@walkamongus, yes our fork contains this PR but also #34, #38, and #40. We've been using it in production for a few months now if that matters.

[walkamongus]

Thanks! will try it out!