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

monitor_search is not yet supported #358

Merged
merged 9 commits into from
Dec 12, 2019
Merged

monitor_search is not yet supported #358

merged 9 commits into from
Dec 12, 2019

Conversation

unclebconnor
Copy link
Contributor

removing monitor_search flag while unsupported

Copy link
Member

@armcburney armcburney left a comment

Choose a reason for hiding this comment

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

LGTM! 💯

}
```

* `monitor` type SLOs:
* `monitor_ids` - (Optional) A list of numeric monitor IDs for which to use as SLIs. Their tags will be auto-imported into `monitor_tags` field in the API resource. At least 1 of `monitor_ids` or `monitor_search` must be provided.
* `monitor_search` - (Optional) The monitor query search used on the monitor search API to add monitor_ids by searching. Their tags will be auto-imported into `monitor_tags` field in the API resource. At least 1 of `monitor_ids` or `monitor_search` must be provided.
* `monitor_ids` - (Optional) A list of numeric monitor IDs for which to use as SLIs. Their tags will be auto-imported into `monitor_tags` field in the API resource.
Copy link
Contributor

Choose a reason for hiding this comment

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

If one of monitor_ids and monitor_search must be provided and we are hiding monitor_search, shouldn't we then also make monitor_ids required for now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bkabrda that makes sense to me. I haven't actually updated any code here...should we just document that monitor_ids is required for now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adjusted so monitor_ids is required

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bkabrda this should be ready for another review when you can

@platinummonkey
Copy link
Contributor

can you remove this from the schema as well?

Copy link
Member

@armcburney armcburney left a comment

Choose a reason for hiding this comment

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

This LGTM! 💯

@bkabrda
Copy link
Contributor

bkabrda commented Nov 22, 2019

Hmm, I'm honestly unsure about this. The Terraform deprecation policy [1] prevents us from just removing an attribute like this. OTOH this attribute never worked anyway, so I guess this should be fine...

I think after all I'm 👍 for doing this change, but would like to hear more opinions. @nmuesch thoughts?

[1] https://www.terraform.io/docs/extend/best-practices/deprecations.html#provider-attribute-removal

@platinummonkey
Copy link
Contributor

since it's not in use, I think it's safe to just drop.

@unclebconnor
Copy link
Contributor Author

@bkabrda @nmuesch any additional thoughts here? ok to merge/drop the setting since it's not in use? Other changes?

@bkabrda
Copy link
Contributor

bkabrda commented Nov 26, 2019

One last question that I have here is if there's a specific timeframe on where monitor_search will be actually supported. IOW, is it worth removing it?

Edit: to be more specific, if it's going to be supported soon(ish), maybe we should just document this but leave the field there.

@unclebconnor
Copy link
Contributor Author

@bkabrda that option is currently not production ready and there is a good bit of design and dev work that needs to be done and hasn't been scheduled. We've already had a support case where someone was trying to use it and getting errors so we'd prefer to remove it.

@bkabrda
Copy link
Contributor

bkabrda commented Nov 28, 2019

@unclebconnor ok, that's fair, let's remove the field for now.

I was going through the terraform docs for removal of attribute [1]. The "right" way to do this seems to be to leave the field there, but add a Removed attribute to it, e.g. Removed: "We identified problems with usage of this field and thus we're marking it as 'removed' until these are fixed" or something similar. This will make sure that our users who tried to define this field will get a proper error message when running terraform and will know what's going on.

[1] https://www.terraform.io/docs/extend/best-practices/deprecations.html#provider-attribute-removal

@ghost ghost added size/S and removed size/XS labels Dec 4, 2019
@unclebconnor
Copy link
Contributor Author

@bkabrda Ok I've made that update. I'm pretty sure this is the format that is described in the docs but let me know if you have other feedback

@unclebconnor
Copy link
Contributor Author

@bkabrda not sure of process for this repo but I'm assuming you want to do the final merge. Let me know if there's anything else you need from me here.

@bkabrda
Copy link
Contributor

bkabrda commented Dec 12, 2019

LGTM now, merging. 👍 thanks for your patience :)

@bkabrda bkabrda merged commit e21480b into DataDog:master Dec 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants