Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

opsgenie: Moved from deprecated, non documented teams to responders field. #1863

Merged
merged 1 commit into from
May 13, 2019

Conversation

bwplotka
Copy link
Member

@bwplotka bwplotka commented Apr 26, 2019

Fixes: #1818
Fixes: #1342

Some decisions I made:

  • "Teams" config option will fail on unmarshalling the config. I marked it as deprecated. AM is 0.x version it should be fine (?)
  • I allow the use case for dynamic set of responders from alert's label using templating. Seems like it fits into how others fields are treated.
  • I allow for full flexibility, so you can use any type you want. There is no validation. I don't think it is worth as Opsgenie changes those things (?). Let me know if it's needed. I think if the type is wrong and create alert will fail it's fine as "validation"

Signed-off-by: Bartek Plotka bwplotka@gmail.com

@bwplotka
Copy link
Member Author

Will fix tests tomorrow.

@bwplotka
Copy link
Member Author

Tests should be fixed.

@bwplotka bwplotka force-pushed the issue1818 branch 3 times, most recently from 6f8ee98 to 54f633c Compare April 28, 2019 16:17
Copy link
Member

@simonpasquier simonpasquier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @bwplotka! I've left a few comments.

@@ -9,7 +9,7 @@

!.golangci.yml
!/cli/testdata/*.yml
!/cli/config/testdata/*.yml
!/config/testdata/*.yml
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

!/cli/config/testdata/*.yml should be kept AFAICT.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok (:

}

type OpsGenieConfigResponder struct {
// One of those 3 should be filled.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a check for this when unmarshaling the struct and return an error if necessary?

}

if c.Teams != "" {
// Should we allow this for backward compatibility? Should we fill responders from this?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that we can't propagate the deprecation to the user in the logs, I think that a hard failure is preferred.

Tags string `yaml:"tags,omitempty" json:"tags,omitempty"`
Note string `yaml:"note,omitempty" json:"note,omitempty"`
Priority string `yaml:"priority,omitempty" json:"priority,omitempty"`
// Teams field is deprecated.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No strong feeling about this one but I'd rather remove the field as part of the change.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Up to you guys (: The problem is that we will not fail the config unmarshalling if people will be still on Teams (and they will be). Thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The unmarshaling should still fail as we use yaml.UnmarshalStrict().

@bwplotka bwplotka force-pushed the issue1818 branch 2 times, most recently from e67726c to 90fe1c8 Compare April 30, 2019 20:41
@bwplotka
Copy link
Member Author

Thanks for initial review @simonpasquier , PTAL

Copy link
Member

@simonpasquier simonpasquier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Delegating it to @mxinden and @stuartnelson3 now...

Copy link
Contributor

@stuartnelson3 stuartnelson3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no complaints from me

@simonpasquier
Copy link
Member

@bwplotka you would need to resolve the conflicts...

@bwplotka
Copy link
Member Author

bwplotka commented May 9, 2019

done (:

…ield.

Teams config option will fail unmarshalling as it is deprecated.

Fixes prometheus#1818

Signed-off-by: Bartek Plotka <bwplotka@gmail.com>
@bwplotka
Copy link
Member Author

bwplotka commented May 9, 2019

Is this build flake? After changelog rebase suddnely tests are red

@simonpasquier
Copy link
Member

Yes, it looks like a flake, I've re-run the workflow.

@hrancic
Copy link

hrancic commented Jul 30, 2019

A question, if you would be so kind. Will the yml configuration file still work with alertmanager 0.18.0 if teams are set up according to https://prometheus.io/docs/alerting/configuration/#opsgenie_config ?

# Comma separated list of team responsible for notifications.
[ teams: <tmpl_string> ]

or should it be changed to something like:

responders:
     name: <tmpl_string>
     type: team

?

@simonpasquier
Copy link
Member

@hrancic the documentation should be updated (and fixed) in a few minutes.

@hrancic
Copy link

hrancic commented Aug 2, 2019

Another question. Our current configurations look something like this:

teams: <tmpl_string>

these templates (which have some conditional logic) are creating a comma separated lists of teams. We would like to upgrade our alertmanager version. How do you propose we migrate to the new version?

@bwplotka
Copy link
Member Author

bwplotka commented Aug 2, 2019

@hrancic do you mean how to specify multiple teams?

responders:
- name: "teamA"
  type: team
- name: "teamB"
  type: team
- name: "teamC"
  type: team
(...)

@hrancic
Copy link

hrancic commented Aug 2, 2019

yes, but writing them one by one is out of the question. Will responders: <tmpl_string> work? Where this template creates the following from a list of teams:

- name: "teamA" 
  type: team
- name: "teamB"
  type: team
- name: "teamC"
  type: team
(...)

@bwplotka
Copy link
Member Author

bwplotka commented Aug 2, 2019

yes, but writing them one by one is out of the question

Why?

Will responders: <tmpl_string> work?

It will not work in current version. (:

@hrancic
Copy link

hrancic commented Aug 2, 2019

We don't know who responders are before the alert is created. We create an alert and then decide its destination while sending it. teams: <tmpl_string> was a model which enabled us to determine the teams after the alert is fired but before sending it to opsgenie. We would like to have something like this:

responders:
 - names: <tmpl_string>
   type: teams

@bwplotka
Copy link
Member Author

bwplotka commented Aug 2, 2019

From my side that is a fair request. Do you mind adding an Github issue with those details on AM? We can improve this indeed. (:

@anandsinghkunwar
Copy link

anandsinghkunwar commented Dec 23, 2019

@hrancic Was an issue filed?
EDIT: It seems it was #1987

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

opsgenie: Move from not supported team field to responders for alert routing. Specify OpsGenie responders
5 participants