Salt: Unable to supply integer arguments to saltstack via command line

[rsmekala]

Description of Issue

Consider the comand: salt 'vmx' junos.shutdown reboot=True at="16:34"

Using the above command, one would expect the arguments recieved by module to be:
{u'reboot': True, u'at': u'16:10'}

But salt implements an integer parsing logic around it, and the arguments received by module are: {u'reboot': True, u'at': 970}

I don't quite understand why to parse string arguments to integers.

Versions Report

Both master and proxy minion operating of same box.

▶ salt --version
salt 2019.2.0 (Fluorine)

[ScoreUnder]

If you are using bash or a compatible shell to run that command, then the quotes you have are being stripped out because the shell thinks it's shell syntax. Try escaping them, e.g. 'at="16:34"' or at=\"16:34\".

[rsmekala]

@ScoreUnder The suggested workaround is working for me. However, I do need some questions to be clarified before I propose the workaround to the client.

• Is this something that was recently introduced in salt ?? I don't remember facing the issue in any of the earlier releases of saltstack. Or is it introduced in newer bash versions ??

• Even if the quotes are escaped, I don't observe any reason something like 16:10 to be parsed to 970. It seems quite obvious to me that 16:10 is not an integer. Does bash do the parsing of the integer as well ??

• What additional operations does salt do on receiving arguments from command line ??

[ScoreUnder]

As I am not a member of the team working on Salt, please take this with a pinch of salt (hehe), but I'll try to answer this to the best of my ability:

Is this something that was recently introduced in salt ??

This seems to have been introduced some time in 2013 in response to #5224

Or is it introduced in newer bash versions ?? / Does bash do the parsing of the integer as well ??

Bash does not parse the integer, but it does strip out the quotes from the command line. As far as I know this behaviour was taken from earlier ancestors to bash, like the Korn shell and the original Bourne shell.

I don't observe any reason something like 16:10 to be parsed to 970. It seems quite obvious to me that 16:10 is not an integer.

I think the rationale here is that it "looks like" a time interval, so it is converted from [hh:]mm:ss format to just seconds.

What additional operations does salt do on receiving arguments from command line ??

After splitting out the key=value format (the reboot=True gets split into reboot and True for example), then the value is parsed as YAML (the same language used to parse SLS files after templating). This is what is converting the string True from the command line into Python's boolean True, but it is also what turned the 16:10 into a single integer.

It is probably worth noting that YAML does not parse time durations if they start with a zero. So the behaviour you were observing previously might have been with numbers like 09:30, which for whatever reason is treated as a plain string by YAML.

[ScoreUnder]

It is actually surprisingly hard to find people taking note of that behaviour of YAML online, but it is mentioned here (ctrl+f Sexagesimal numbers) https://medium.com/@sidneyliebrand/the-greatnesses-and-gotchas-of-yaml-5e3377ef0c55

[max-arnold]

There is a CLI option to skip YAML parsing for specific arguments:

salt --help | grep -A 3 no-parse
  --no-parse=argname1,argname2,...
                        Comma-separated list of named CLI arguments (i.e.
                        argname=value) which should not be parsed as Python
                        data types

salt 'vmx' junos.shutdown reboot=True at="16:34" --no-parse=at

It is also often useful for arguments that could be interpreted as booleans: https://twitter.com/SaltTips/status/1101486688281477120

[rsmekala]

@ScoreUnder Thanks. I understand the logic causing the issue.

@ScoreUnder @max-arnold Thanks for the workarounds. I'll propose them to the client.

Closing the issue. Thanks for the quick help. 👋