Move regexregex to params for consistency

[lvrfrc87]

Environment

• netcompare version:

Proposed Functionality

Use Case

[chadell]

I don't understand this issue 😓

[lvrfrc87]

Let me get my head around it and might try to remember what i meant. Next time would be good to add some context :D

[lvrfrc87]

@chadell

As it stands now, regex check type is define as per example below

    "regex",
    {"regex": ".*UNDERLAY.*", "mode": "match"},
    "result[0].vrfs.default.peerList[*].[$peerAddress$,peerGroup]",

if you look at parameter_match check type, we define as below

    "parameter_match",
    {"mode": "no-match", "params": {"localAsn": "65130.1100", "linkType": "external"}},
    "result[0].vrfs.default.peerList[*].[$peerAddress$,localAsn,linkType]",

To keep the structure more consistent, the ideal would be to have regex define as per below:

    "regex",
    {"mode": "match", "params": {"regex": "*UNDERLAY.*"},
    "result[0].vrfs.default.peerList[*].[$peerAddress$,peerGroup]",

Would that make sense?

@pszulczewski your opinion is much appreciated

[pszulczewski]

In parameter check having params is justified as you may have different number of k:v pairs and you don't know key names.
In regex you have only one k:v pair, and the key is always regex, you don't really need params.

For me it's good as it is in regex.

In operator check, we have double nested params which I am not sure if inecessary.