suggestion: logging state

[thekuffs]

I come to Salt after doing a lot of research and experimentation with Puppet. One of the patterns I would use for Puppet was the platform gatekeeping approach:

if ! ($::operatingsystem in ['centos', 'rhel']) {
  fail("Operating system '${::operatingsystem}' not supported")
}

That will abort compilation of the manifest immediately and provide the info in the returned report. It allows me to make manifests that aren't tested on all platforms and be assured that one of my fellow administrators won't accidentally apply untested code.

It's a bit of a trivial example, as it should be pretty easy to document for one's team which states would work on which platforms. And you would hope that whomever you allow to work on your configuration infrastructure wouldn't be a buffoon ;) - I liked having the mechanism as a parachute for both basic and advanced cases.

I'd like to get some of that functionality in Salt as well. Say through the use of a log state.

{% if grains['os_family'] == 'RedHat' %}
# do a thing
{% else %}
"'a thing' is not supported on {{ grains['os_family'] }}":
  log.abort

Or maybe for testing:

"does this {{ pillar['thing'] }} concatenate {{ pillar['correctly'] }}?":
  log.info

I don't know. My log.info example seems a little contrived. But log.abort is still pretty valuable.

I considered the feasibility of putting something like this in the jinja context, as the only variability in your states comes from templating. But that means it wouldn't follow the rest of Salt's ideology for multiple state renderers.

[thatch45]

Are you familiar with the failhard option?
http://docs.saltstack.org/en/latest/ref/states/failhard.html

This was made for this case, as for adding in log data I think that we could just make a failhard state that accepted a number of things to check on and to fail hard and early, no need to mess around in Jinja :)

[thekuffs]

I had not seen the failhard option, thank you for the heads up.

I don't think it quite meets my needs, though. My use case was as more of a sanity check in an SLS. I don't want a state to even attempt to resolve at all if the grains and pillar it depends on are out of whack. A failhard state might be the right solution, depending. I'd like to give it an implicit ordering preference. Such that any failhard states are resolved first before attempting the rest of the tree.

I agree that jinja isn't the place for this, I just wanted to provide some of my background thinking.

[thatch45]

Are you familiar with finite ordering?
http://docs.saltstack.org/en/latest/ref/states/ordering.html#the-order-option

We could write a state that could do this directly as well, one that would add failhard internally and set a default order of 1

[thekuffs]

Wow, I was not familiar with the ordering option. I thought I had a pretty good grasp on the documentation, but clearly I do not.

That combination sounds perfect.

[thatch45]

I want to make the docs all get ordered out in a manual style setup, but time is not on my side :)

[thekuffs]

The combination of ordering and failhard didn't really end up solving my issue. I'd like to revisit the option of a 'failure' state.

I saw some discussion about exception handling for states recently. I think that an exception would be a good vector for transmitting the failure back up to the calling instance.

I'd be happy to provide a proof-of-concept if needed.

[thatch45]

Thant interesting, I will reopen this then

[dlindquist]

So, as I see it, a workaround can look a bit like this...

a:
  cmd.run:
    - name: echo something
{% if grains['os'] != 'CentOS' %}
fail-state:
  cmd.run:    
    - name: echo prerequisite failed && /bin/false
    - order: 0    
    - failhard: True
{% endif %}
z:
  cmd.run:
    - name: echo else

It seems to me that a new/custom state module could handle this (common?) case a bit better. Something like...

pre-condition:
  check.assert:
    - grains:
      os: 'CentOS'
    - pillars:
      custom_pillar1: 'value'
    - order:0
    - failhard: True

Such a state could yield intelligent output on what particular conditions were checked / failed. For example, the state module output could contain "Assertion grains['os'] == 'CentOS' failed."

One issue I see with pushing the check deeper into the state is that it wouldn't support creation of more detailed checks. For example, creating a check that the major version of grains['osrelease'] is greater than 5 (grains['osrelease'].

Thoughts?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.