Cyclical dependencies when using Sensu Enterprise and the Enterprise API

[ghoneycutt]

Description of problem

• What did you do?

Brought up sensu-server-enterprise vagrant VM and applied the code below.

• What happened?

Got an error about a cyclical dependency

Error: Failed to apply catalog: Found 1 dependency cycle:
(Sensu_enterprise_dashboard_api_config[sensu-server.example.com] => Service[sensu-enterprise-dashboard] => Class[Sensu::Enterprise::Dashboard] => Sensu::Enterprise::Dashboard::Api[sensu-server.example.com] => Sensu_enterprise_dashboard_api_config[sensu-server.example.com])

• What did you expect to happen?

No error.

• How can someone reproduce the problem?

Apply this puppet code. Note that FACTER_SE_USER and FACTER_SE_PASS environment variables need to be populated.

class { '::sensu':
  enterprise                   => true,
#  enterprise_version           => $::sensu::enterprise_version,
  enterprise_dashboard         => true,
#  enterprise_dashboard_version => $::sensu::enterprise_dashboard_version,
  enterprise_dashboard_host    => $::fqdn,
  enterprise_dashboard_port    => 3000,
  enterprise_dashboard_refresh => '5',
  enterprise_dashboard_ldap    => {
    'basedn'                     => "cn=users,dc=domain,dc=tld",
    'groupbasedn'                => "cn=groups,dc=domain,dc=tld",
    'userbasedn'                 => "cn=admins,dc=domain,dc=tld",
    'binduser'                   => "cn=binder,cn=users,dc=domain,dc=tld",
    'bindpass'                   => 'secret',
    'server'                     => 'localhost',
    'port'                       => 389,
    'roles'                      => [
      {
        'name'    => 'operators',
        'members' => ['group1','group2'],
      },
      {
        'name'     => 'guests',
        'members'  => ['employees','contractors'],
        'readonly' => true,
      }
    ],
    'security'            => 'starttls',
    'userattribute'       => 'sAMAccountName',
    'disablenestedgroups' => true,
  },
  enterprise_user  => $::se_user,
  enterprise_pass  => $::se_pass,
  install_repo     => true,
  log_level        => 'info',
  purge => {
    config => true,
  },
#  rabbitmq_cluster => $rabbitmq_cluster,
#  redis_db         => $redis_db,
#  redis_host       => $redis_host,
#  version          => $client_version,
}

sensu::enterprise::dashboard::api { $::fqdn:
  datacenter => 'USW2',
  port       => 4567,
}

Command used and debugging output

• What does your puppet config look like (including any hiera config)

Using the sensu-server-enterprise vagrant VM.

• Is this a masterless or master based puppet setup?

masterless

Platform and version information

• Your OS: EL 7
• Your Ruby version:

# /opt/puppetlabs/puppet/bin/ruby --version
ruby 2.1.9p490 (2016-03-30 revision 54437) [x86_64-linux]

• Your version of Puppet: 4.10.8 open source
• Your version of Sensu: sensu-enterprise-2.6.1-1.noarch
• Your version of this module: 2.35.0

Anything else to add that you think will be helpful?

Start with figuring out what is different between this config which does not work and the config used in the VM which does.

[glarizza]

It looks like the sensu_enterprise_dashboard_api_config type has code to automatically setup a notify (https://github.com/sensu/sensu-puppet/blob/master/lib/puppet/type/sensu_enterprise_dashboard_api_config.rb#L11-L15) on the sensu-enterprise-dashboard service. When you use the Sensu::Enterprise::Dashboard::Api defined type, it's defining a sensu_enterprise_dashboard_api_config instance as well as setting up a dependency on the sensu::enterprise::dashboard class (https://github.com/sensu/sensu-puppet/blob/master/manifests/enterprise/dashboard/api.pp#L42). The type sets up a notify on the service (which implies 'before' as well as the refresh), and the class sets up a require on the sensu::enterprise::dashboard class which contains the Service['sensu-enterprise-dashboard] declaration (https://github.com/sensu/sensu-puppet/blob/master/manifests/enterprise/dashboard.pp#L82-L90), which creates a circular dependency.

We can tackle this a number of ways (including getting the service in its own class so it can be included and not required), but I don't have as much familiarity with the module as @ghoneycutt does - do you have a recommendation Garrett before I start moving things around?

[ghoneycutt]

We recently did work to pull in subclasses that did not stand on their own. So classes with names like ::config ::service ::install were consolidated and we don't want to go back to that model.

[glarizza]

Sure, that makes sense when there's no reason for those to stand alone (i.e. you're not doing multiple OSes). I'm going to continue working a couple of angles to find the best way to handle it

[alvagante]

I suppose this one can be closed now @ghoneycutt

[ghoneycutt]

Thanks @glarizza @alvagante