state.single does not respect requirements

[madduck]

Consider the following CLI invocation:

# salt-call -l trace state.single file.managed /tmp/test require="{'pkg':'sudo'}" 2>&1 | grep sudo
root     11472  6530  0 Jan30 pts/2    00:00:00       sudo -i
root     29259 11473  0 10:51 pts/2    00:00:00           python /home/madduck/code/salt/scripts/salt-call -c /home/madduck/code/salt/local/etc/salt --no-color -l trace state.single file.managed /tmp/test require={'pkg':'sudo'}
root     29260 11473  0 10:51 pts/2    00:00:00           grep sudo

I think that Salt should not execute this state because its requirements
cannot be fulfilled. However, it seems that state.single does not care about
requirements.

[thatch45]

Right, state.single is just executing a single state function and does not invoke highstate or read in any sls data. state.single is made to allow you to execute a state in a vacuum, so I don't think that this request makes much sense, since a "single" state call cannot read in an requisite, the data is just not there.

[madduck]

This is good reasoning, and noone in their right mind would pass require to state.single. However, for consistency, if they do, then the execution should fail IMHO.

[thatch45]

This is very nit-picky, and some state functions do accept a require option, so we can't filter directly on it.

[madduck]

I don't mean to be nit-picking, but this is a design issue: you are requiring a higher entity (highstate) to ensure requirements, whereas I would wish for each entity to enforce their own requirements, refusing to do work unless they are enabled to do so.

[UtahDave]

@madduck, if you want to enforce requirements you can use state.sls.

[madduck]

Yes, albeit this requires an SLS file to be present.

Anyway, I think the issue is less about getting this functionality implemented than about putting my finger on a question of design. Maybe if Salt ever gets rewritten or seriously refactored, this will be taken into account.