Cycling dependancy in Hiera-based config

[rikwasmus]

• ruby 1.9.3p194
• puppet 3.7.3

Yaml-based hiera setup, applied in order (merge deeper @ hiera):

Main config shared everywhere (init style = false because we have a local .deb repo where init is already taken care of when installing consul):

consul::config_dir: '/etc/consul.d'
consul::install_method: 'package'
consul::init_style: false
consul::ui_package_name: 'consul-web-ui'
consul::package_name: 'consul'
consul::config_hash:
  datacenter: 'datacentername'
  data_dir: '/var/lib/consul'
  domain: 'dcs.consul'
  retry_join: 
    - '10.0.0.1'
    - '10.0.0.2'
    - '10.0.0.3'

Consul-master config:

consul::config_hash:
  log_level: 'INFO'
  server: true
  bootstrap_expect: 3
  ui_dir: '/usr/share/consul/web-ui'
  client_addr: '0.0.0.0'

consul::services:
  'zookeeper':
    tags: [ 'mesos' , 'master' ]
    port: 2181

Apply results in:

Error: Could not apply complete catalog: Found 1 dependency cycle:
(File[/etc/consul.d/service_zookeeper.json] => Class[Consul::Run_service] => Service[consul] => Class[Consul::Run_service] => Class[Consul] => Consul::Service[zookeeper] => File[/etc/consul.d/service_zookeeper.json])

Unless I'm doing something wrong in Hiera of course...

[rikwasmus]

Hm, merging config like that appears (which is very handy for a multiple datacenter setup etc.) was also only working for me after a local edit....

-  $config_hash_real = merge($config_defaults, $config_hash)
+  $config_hash_real = merge($config_defaults, hiera_hash('consul::config_hash'),$config_hash)

... which apparently had something to do with 76bc1ef ... but beside that little tidbit change, I would be running v0.4.6 now.

[solarkennedy]

This surprises me because we have a test for this:
https://github.com/solarkennedy/puppet-consul/blob/master/spec/classes/init_spec.rb#L247

If there was a dependency loop when settings consul::services then that test would fail to compile?

[tayzlor]

Im hitting this as well -

Error: Could not apply complete catalog: Found 1 dependency cycle: DEBUG [9817a86d] DEBUG [9817a86d] (File[/etc/consul/service_haproxy.json] => Class[Consul::Run_service] => Service[consul] => Class[Consul::Run_service] => Class[Consul] => Consul::Service[haproxy] => File[/etc/consul/service_haproxy.json]) DEBUG [9817a86d]

[rikwasmus]

It could be it's about an incomplete consul definition which causes it. Once I hiera_merge it like mentioned, the problem disappears, but without merging (which granted, would result in an incomplete / faulty consul config), this dependency cycle happens, so with just:

consul::config_hash:
  log_level: 'INFO'
  server: true
  bootstrap_expect: 3
  ui_dir: '/usr/share/consul/web-ui'
  client_addr: '0.0.0.0'

consul::services:
  'zookeeper':
    tags: [ 'mesos' , 'master' ]
    port: 2181

Arguable, this is incomplete, but probably it gives more clear error messages when:

• either defaults for the missing data which causes the loop are provided
• or missing data which causes the loop is checked and the code is aborted there & then

[tayzlor]

Changing the merge() function as you describe above makes no difference for me, I am still receiving the same error. Having a look into it now...

Changing the spec test to

context "When the user provides a hash of services" do
    let (:params) {{
      :config_hash => {
        'log_level' => 'INFO',
        'server'    => 'true',
        'bootstrap_expect' => 3,
        'ui_dir' => '/usr/share/consul/web-ui',
        'client_addr' => '0.0.0.0'
      },
      :services => {
        'test_service1' => {
          'port' => '5',
          'tags' => ['tag1', 'tag2']
        }
      }
    }}

    it { should contain_consul__service('test_service1').with_port('5') }
    it { should have_consul__service_resource_count(1) }
  end

still does not cause the spec test to fail for some reason (but I still definitely have the cycle issue)