Updated configuration schema with missing OpsGenie alerter options

[lstyles]

Description

As discussed in #1539, schema update for missing OpsGenie alerter properties.

Checklist

• I have reviewed the contributing guidelines.
• I have included unit tests for my changes or additions.
• I have successfully run make test-docker with my changes.
• I have manually tested all relevant modes of the change in this PR.
• I have updated the documentation.
• I have updated the changelog.

Questions or Comments

[jertel]

Do you have an example of a config that uses the opsGenieArgs type instead of a string array?

[lstyles]

I'm not sure. I was aiming to handle this:

# opsgenie_teams_args:
#     team_prefix:'team'

from: https://github.com/jertel/elastalert2/blob/master/examples/rules/example_opsgenie_frequency.yaml#L40-L41

I'm making a lot of assumptions here but I think the following works (correct me if I'm wrong):

opsgenie_teams:
  - {}-Team
opsgenie_teams_args:
  - arg1

and this also works:

opsgenie_teams:
  - {property_name}-Team
opsgenie_teams_args:
  property_name: 'team'

The second one is what's used in examples and it's not a string array, unless I'm missing something.

[lstyles]

I've put together a test and the positional param variation doesn't work. It expects a dictionary in _args properties.

Is there a better way to represent a dictionary in the schema than what I did with opsGenieArgs?

I think arrayOfStrings should be removed as an option completely.

[jertel]

What threw me off is the opsgenie_subject_args which is listed as also being a type of opsGenieArgs, but this property is only supported as a string array.

Your opsGenieArgs looks ok to me. opsgenie_details uses a slightly different approach, but it requires at least one key/value pair, whereas these don't. @nsano-rururu what do you think of this type definition?

Here's what I propose:

• make opsgenie_subject_args always an array of strings
• make opsgenie_recipients_args always an opsGenieArgs as you suggested
• make opsgenie_teams_args always an opsGenieArgs as you suggested

[lstyles]

The change to opsgenie_subject_args wasn't on purpose. I must have fat fingered something.

Reverted, and I've updated the other two.

[nsano-rururu]

No problem.