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

Add Support for Alerts for Uptime Checks #1419

Closed
danaelhe opened this issue Sep 29, 2023 · 9 comments
Closed

Add Support for Alerts for Uptime Checks #1419

danaelhe opened this issue Sep 29, 2023 · 9 comments
Labels
api-parity Feature supported in the DigitalOcean API not yet implemented in doctl good first issue hacktoberfest suggestion

Comments

@danaelhe
Copy link
Member

Overview:
Now that we've added doctl support for uptime checks (#1386), we should follow up with supporting uptime alerts so that we support the entire feature set.

Instructions

  1. Clone this repo
  2. Create file: doctl/commands/uptime_alerts.go
  3. Reference this PR and the API documentation for creating support for uptime alerts in doctl. You will need to use the digitalocean/godo package to make the API calls. Refer to uptime checks: add crud methods #1386 on how that was done.
  4. Create a test file.
  5. Create PR for us to review and merge 🎆
@danaelhe danaelhe added suggestion good first issue api-parity Feature supported in the DigitalOcean API not yet implemented in doctl hacktoberfest labels Sep 29, 2023
@danaelhe danaelhe changed the title Support alerts for uptime checks Add Support for Alerts for Uptime Checks Sep 29, 2023
@dhanusaputra
Copy link

hi, can I work on this please? thanks

@mikesmithgh
Copy link
Contributor

Hi @danaelhe, I am looking into this for #Hacktoberfest and have some questions around the expected arguments.

I see alerts are a part of checks: /v2/uptime/checks/$CHECK_ID/alerts.

I see there already exists alert policies doctl monitoring alert and I am not sure if this would be confusing to a user with both doctl monitoring uptime alert and doctl monitoring alert.

Do you want the command doctl monitoring uptime alert or have another format in-mind?

@danaelhe
Copy link
Member Author

danaelhe commented Oct 5, 2023

@mikesmithgh Oh that's a very good design question, thank you for bringing this up.

We can see how that might be confusing, but doctl monitoring uptime alert is still our preferred way to go. It remains consistent with doctl pattern and also mirrors the control panel experience as well. I'm going to create a separate PR for expanding the doctl monitoring alert -h output a bit to differentiate the type of alerts.

@mikesmithgh
Copy link
Contributor

@mikesmithgh Oh that's a very good design question, thank you for bringing this up.

We can see how that might be confusing, but doctl monitoring uptime alert is still our preferred way to go. It remains consistent with doctl pattern and also mirrors the control panel experience as well. I'm going to create a separate PR for expanding the doctl monitoring alert -h output a bit to differentiate the type of alerts.

Sounds good, thanks!

@MeenuyD
Copy link

MeenuyD commented Oct 5, 2023

I would like to work on this issue can you please guide me?

@mikesmithgh
Copy link
Contributor

Hi @danaelhe I am working on this issue and noticed some inconsistencies in the APIs.

For the uptime alert comparison the values are either greater_than or less_than (see https://github.com/search?q=repo%3Adigitalocean%2Fopenapi%20greater_than&type=code).

But, the alert API is using compare with GreaterThan and LessThan (see https://github.com/search?q=repo%3Adigitalocean%2Fopenapi%20GreaterThan&type=code).

Should this be opened as a bug? The API spec is correct and I can hit the endpoints with the syntax, so I am assuming this would be in the actual API repo.

@danaelhe
Copy link
Member Author

danaelhe commented Oct 9, 2023

Oh yes, good catch. You are correct in that it is an inconsistency with the different types of alerts. It is more of an inconsistency from a user experience perspective, as you point out, since functionally it's still accurate. Though, trying to enforce a common standard now would cause a breaking change. Unfortunately, it is not a breaking change we can fix right now. We will pass the feedback on to the appropriate internal product teams who will decide what/when is the best course of action to mitigate inconsistencies in the past and in the future.

Thank you for sharing your feedback!

@mikesmithgh
Copy link
Contributor

@danaelhe Thanks! makes sense 👍

SergeAx added a commit to SergeAx/doctl that referenced this issue Oct 10, 2023
I've made it according to digitalocean#1419. Took e846085 as example
@danaelhe
Copy link
Member Author

addressed in #1431

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-parity Feature supported in the DigitalOcean API not yet implemented in doctl good first issue hacktoberfest suggestion
Projects
None yet
Development

No branches or pull requests

4 participants