[FEATURE REQUEST] Provide not only augeas actions but also augeas checks

[hramrach]

Is your feature request related to a problem? Please describe.

The docs say https://docs.saltproject.io/en/latest/ref/states/all/salt.states.augeas.html

zabbix-service:
  augeas.change:
    - lens: services.lns
    - context: /files/etc/services
    - changes:
      - ins service-name after service-name[last()]
      - set service-name[last()] "zabbix-agent"
      - set "service-name[. = 'zabbix-agent']/port" 10050
      - set "service-name[. = 'zabbix-agent']/protocol" tcp
      - set "service-name[. = 'zabbix-agent']/#comment" "Zabbix Agent service"
      - rm "service-name[. = 'im-obsolete']"
    - unless: grep "zabbix-agent" /etc/services

This is not a way to manage the file. The string zabbix-agent may be in the file but commented out. There might be a service like zabbix-agent-ng.

Describe the solution you'd like

Augeas upstream provides both functions to change the file and get data from the file. When the file is modified by augeas the check that the modification was applied should also be done by Augeas.

If I did not use Salt but rather Augeas upstream tools I could write a check that parses the file and looks if "zabbix-agent" service definition is present, and execute the actions to add it when it is not.

Here the check is implemented with 'grep' which has very little idea about the structure of the file rather than with Augeas, the very thing Augeas is supposed to prevent. Figuring out the correct regular expression to check for presence of a service with grep, and tuning it to cover all edge cases is error-prone, and a waste of time. This is what Augeas aims to avoid.

Describe alternatives you've considered

Of course, it's possible to write a python-augeas tool for adding services, and include both the check and the action in the tool so that no check is needed in Salt, and in fact no Augeas support at all. It can call the tool with the generic run action.

There is also the possibility to store the whole services file in the state rather than adding a single service to it. After all the services file is well compatible across systems, and there is no problem with having too many services.

In situations when a configuration file varies wildly across different systems, and including features from one system on another would cause problems storing the whole file may yield very complex template. Also some files may not be fully managed by Salt and modifications by other tools may be allowed. In these cases Augeas support would be helpful for changing only part of the file. However, in all but the simplest cases a check if the change should be applied is also needed, and that is not provided.