nova scheduler utils parse_option needs more sanity check

[Surojit Pathak]

nova/scheduler/utils - parse_options() needs to do more sanity check.[1]

>>> from nova.scheduler import utils
>>> utils.parse_options(['a>=5', 'b>3'])
[('a>', '5')]
>>>

The default separator is '='. So '>' gets filtered out but '>=' gets allowed. This is even worse as it pollutes the key for the config opt.

One possible solution is to apply a grammar compatibility, what can be an accepted opt-name, like variable name in a language. for the LeftHandSide of the opt expression, the way it applies 'converter' to the RightHandSide.

reported version of nova
[suro@oxy-dev nova (master)]$ git log -1
commit 78db34c0b59cc04883e1ffa215313092c15ce7c8

[1] - https://github.com/openstack/nova/blob/stable/liberty/nova/scheduler/utils.py#L222

[Chris Dent (cdent)]

I can confirm that the behavior demonstrated happens. What I can't decide is if this matters. The defined syntax for a scheduler option (in nova.conf) is <name>=<value>, <name>=<value> and the interface to parse_options is to split on sep (which defaults to '=').

By that logic everything is working exactly as defined.

The assertion is that parse_options should be defensive in the face of what amounts to typos, because it already is to some extent.

I think there are two ways we could go here:

* switch to making parse_options accept a class of characters for name and do an rpartition or rpslit (limited to one split) instead of partition. The let ValueError happen on either converter failing on value or name not being comprised of the character class (this is effectively the same as the right hand grammar suggestion described above).
* stop filtering bad things at all, just split on sep and let the bad names bubble up: if we filter them people will never know to fix them.

[Ed Leafe (ed-leafe)]

Not a bug, as `parse_options` takes an optional `sep` argument. If you wish to use '>=', pass that in as the `sep` named parameter.