service check definitions should make 'enabled' as an optional attribute

[sshipway]

A service check definition requires the 'running' and 'enabled' attributes to be set. However the 'enabled' should be optional as we may with to only validate that the service is running, not how it was started (if, for example, a nonstandard service management framework is being used)

[sshipway]

As a workaround for this, you can use a matcher --

service:
  foo:
    running: true
    enabled:
      or:
        - true
        - false

This effectively makes the 'enabled' check a null operation and so only checks the running state.

[aelsabbahy]

Clever workaround. Might be a nice note in the documentation.

[aelsabbahy]

Marking this as approved for the documentation change.

@sshipway let me know if you feel strongly about this needing to be supported outside of the workaround.

I'd have to delve into the code a bit more.. but I remember there was a reason why the check couldn't be optional.

[freeseacher]

Yep. got almost the same issue. but i want to test only if nginx is enabled. no matter if it running or not

// i want to test if my packer image was build well. so actual service run is not really matters

[sshipway]

@freeseacher just use this:

service:
  nginx:
    running:
      or:
        - true
        - false
    enabled: true

[sshipway]

I don't feel particularly strongly that the enabled and running have to be optional, though I think it would be more convenient if they were, as long as the workaround is in the documentation.

[freeseacher]

yes i see. and make it works like this. but for me that looks like hack. i think if i let the option unset it means i don't care. that works in many other places for example user check if not uid/gid set it means don't care

[cread]

I agree that it would be nice if both running and enabled were optional for service. If we don't specify one then we don't care about that state...