Allow service to be managed outside of kibana class

[bmagistro]

To aid in a dependency/order chain it would be nice to either have "unmanaged" or a new option "external" in "kibana::status" completely skip everything within the "kibana::service" class or allow adding "requires" to the service that is defined there.

In our case, we are setting a configuration that has a dependency on SSL certificates and if the certificates are not present or permissions do not allow the kibana service access, it fails to start until other things have completed. As we are using facls, we cannot put the dependency on kibana as the username will not exist until it has been installed.

If time allows, I may try to do a PR w/ the external scenario described above.

[tylerjl]

Is your use case something that could be solved with dependency declarations on your specific resources that manage the dependent files/SSL certs? For example:

file { '/foo/cert.pem':
  require => Class['::kibana::install'],
  before => Class['::kibana::service'],
}

[bmagistro]

I was trying to come up with a way to leverage the before scenario but didn't get there. We are using fooacl and the way it handles the acls doesn't seem to lend itself to that (as far as I can tell). What it does is build up a script of all the acls and apply it once vs every occurrence of the acl being defined so if you want your dependency it is on Class['fooacl'] vs Fooacl::Conf['my_acl_1']

[tylerjl]

Ah, that makes sense, so it's using the concat fragment pattern. So would something like the following work?

Class['fooacl'] -> Class['::kibana::service']

or:

class { 'fooacl':
  before => Class['::kibana::service'],
}

Depending on how you use fooacl. I know these somewhat feel like workarounds, but whether the specific use case is fooacl or some other special case that someone may have in the wild, I would hesitate to write features in the module for a wide range of special cases if it can be achieved through normal Puppet mechanisms.

[bmagistro]

I completely understand being hesitant to make changes if there is already a mechanism in place and I'm happy to try some ideas. I know I am still figuring out how to piece some of these things together.

We are using fooacl::conf following their examples which may be part of why I was struggling to link them. Our kibana implementation looks like the following. I've substituted a couple variable names and left out some of the lines but has the key areas I think.

class profile::server::kibana (String $param1, String $param2, Integer $param3) {
  class {'kibana':
    require => [ Yumrepo[] ],
    ensure => 'version',
    ....
  }
  kibana_plugin { 'x-pack':
  }
  fooacl::conf { 'kibana_key_acl':
    require => Class['kibana'],
    target => '/path/to/cert.key',
    permissions => [ 'user:kibana:r--' ]
  }
}

[tylerjl]

Gotcha, that makes sense. Based upon my reading of fooacl::conf resources, they include ::fooacl, so that class should be available to create resource ordering with - you can include ::fooacl at some top-level class or node definition to ensure the Class['::fooacl'] resource handle is available to create relationships, as well.

When that resource is available (you could potentially also reorder fooacl::conf before class { 'kibana' :, you can do something like

Class['fooacl'] -> Class['::kibana::service']
Class['::kibana::install'] -> Class['fooacl']

Which just expresses that all of your ACLs should finish up before managing/starting the Kibana service, and that Kibana must be installed before managing ACLs (so users/groups will be available). Do any of these ideas or those from my previous comment help resolve that ordering issue?

[bmagistro]

I didn't realize you could just toss a line like Class['fooacl'] -> Class['::kibana::service'] in there and get the relationship. I had been trying to attach it to a particular block using require/before. Your suggestion appears to be working well. Many thanks for taking the time to help us work through this one, it is greatly appreciated.

[tylerjl]

Excellent, I'm glad it's working for you! I'm going to close this out now, but do let me know if you encounter anything else that may be beneficial to add to the module.