Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

Local uri input monitor support #369

Open
wants to merge 14 commits into
base: local-uri-input-monitor-support
Choose a base branch
from

Conversation

AWSHurneyt
Copy link

@AWSHurneyt AWSHurneyt commented Apr 2, 2021

*Issue #, if available: #347

*Description of changes:

  1. Renamed assets from #347 from HttpInput to LocalUriInput
  2. Implemented data class, LocalUriInput, to support creation of local cluster monitors using URI input.
  3. Implemented logic for a map of supported API and their supported JSON payloads. Local cluster monitors for unsupported API will fail to execute.
  4. Implemented logic to support creation of local cluster monitors for cluster health, and cluster stats using a LocalUriInput.

Implementing unit tests as a separate task.

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

…r creating ClusterHealth and ClusterStats monitors.
…yt/alerting into local-uri-input-monitor-support

� Conflicts:
�	alerting/src/main/kotlin/com/amazon/opendistroforelasticsearch/alerting/settings/SupportedApiSettings.kt
*/
// TODO: Currently set to TRUE for testing purposes.
// Should likely be set to FALSE by default.
private var supportedApiListEnabled = true

Choose a reason for hiding this comment

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

just curious: why do we need this?

Copy link
Author

Choose a reason for hiding this comment

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

This is essentially an on/off switch that I implemented at the beginning of the project. If a user did not want to check the API called by the monitor against the allow list, this value could be set to FALSE. That would allow users to create monitors for any API that this feature support. At the moment, it doesn't serve much of a purpose; but it could be more valuable as more API become supported.

We could remove this value if we feel it's extraneous.

Choose a reason for hiding this comment

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

If I understand this correctly this is something intended to be specified by the user and if this is set to false then they cannot use the LocalUrlInput feature.

I am not sure I understand how this is configurable by the end user at the moment. Do you think this can be defined as a cluster setting so user can turn it on off as it seems fit for them? or if this is not configurable at the moment suggest going with removing this as it serves no purpose and in future when needed to add the customization we can introduce the cluster setting

Copy link
Author

Choose a reason for hiding this comment

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

If configured to false, users could still use the LocalUriInput feature; but the allow list wouldn't be checked for the requested API before creating and executing the monitor. At the moment, the allow list exposes both of the supported API; but as support for more API is added, a cluster owner could essentially configure this setting to false to allow access to any supported API, regardless of whether they are on the allow list.

Your comment about configuring via settings makes sense though. This will be easy enough to reimplement if there's a need in the future.

Removed this value.

* @param localUriInput The [LocalUriInput] to validate.
* @return The path that was validated.
*/
fun validateLocalUriInput(localUriInput: LocalUriInput): String {
Copy link

@thalurur thalurur Apr 13, 2021

Choose a reason for hiding this comment

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

Do you think it makes sense to rename this to something like resolveToUriPath` as this method seems to be doing more than just validation, its also seems to be converting LocalUriInput`` to a path.

Also do we really need to convert to a uri path? Looks the entity being used later on is transport action request do you think it makes sense to just build and return ActionRequest from this method instead, so callers don't need to worry about building the action request with all the correct attributes?

fun resolveToActionRequest(localUriInput: LocalUriInput): ActionRequest? {
  ....
} 

Copy link
Author

Choose a reason for hiding this comment

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

That makes sense. I'll refactor this method to resolveToActionRequest and return the ActionRequest. Thank you for the feedback! I've also made the validatePath method public for use in the Monitor class.

Comment on lines 16 to 22
if (path == SupportedApiSettings.CLUSTER_HEALTH_PATH) {
return client.admin().cluster().health(ClusterHealthRequest()).get()
}
if (path == SupportedApiSettings.CLUSTER_STATS_PATH) {
return client.admin().cluster().clusterStats(ClusterStatsRequest()).get()
}
throw IllegalArgumentException("Unsupported API: $path")

Choose a reason for hiding this comment

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

minor:
you can use when statement instead

when (path) {
   is SupportedApiSettings.CLUSTER_HEALTH_PATH -> return ..
   is SupportedApiSettings.CLUSTER_STATS_PATH -> return ...
   else -> throw IllegalArgumentException
}

Copy link
Author

Choose a reason for hiding this comment

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

Thank you for the tip! The syntax is a little different from your example due to some compiler warnings, but I refactored this to when.

Comment on lines 26 to 32
if (this is ClusterHealthResponse) {
return this.convertToMap()
}
if (this is ClusterStatsResponse) {
return this.convertToMap()
}
throw IllegalArgumentException("Unsupported ActionResponse type: ${this.javaClass.name}")
Copy link

@thalurur thalurur Apr 13, 2021

Choose a reason for hiding this comment

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

minor: using when

when (this) {
    is ClusterHealthResponse, is ClusterStatsResponse -> return this.convertToMap()
    else -> throw IllegalArgumentException
}

Copy link
Author

Choose a reason for hiding this comment

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

Thank you for the tip! The syntax is a little different from your example due to some compiler warnings, but I refactored this to when.

}

/**
* Helper function to confirm at least [url], or [scheme]+[host]+[port]+[path]+[query_params] is defined.
Copy link

@thalurur thalurur Apr 14, 2021

Choose a reason for hiding this comment

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

is it either or alteast?

if its atleast then I'd think we need to check that either url or [scheme]+[host]+[port]+[path]+[query_params] is not empty and if they are both not empty then check they both are creating same URI?

if it either then just check either url or [scheme]+[host]+[port]+[path]+[query_params] is not empty but never both are empty

Looking at the code I am thinking either is what we are trying to do, but it seem to miss the validation for case that both are empty. We are only checking both are not not empty.

Copy link
Author

Choose a reason for hiding this comment

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

Ah, thank you for pointing that out. Yes, we want either the url or the other fields to be provided, not both so we don't need to worry about a user providing two different URLs in one request. I've refactored this method to include that check.

…yt/alerting into local-uri-input-monitor-support

� Conflicts:
�	alerting/src/test/kotlin/com/amazon/opendistroforelasticsearch/alerting/MonitorRunnerIT.kt
�	alerting/src/test/kotlin/com/amazon/opendistroforelasticsearch/alerting/TestHelpers.kt
�	core/src/main/kotlin/com/amazon/opendistroforelasticsearch/alerting/core/model/LocalUriInput.kt
�	core/src/test/kotlin/com/amazon/opendistroforelasticsearch/alerting/core/model/LocalUriInputTests.kt
…nd added unit test. Implemented method to redact fields from a response, and added unit tests
Comment on lines +46 to +50
val supportedJsonPayloads = SupportedApiSettings::class.java.getResource(RESOURCE_FILE)
@Suppress("UNCHECKED_CAST")
if (supportedJsonPayloads != null) supportedApiList =
XContentHelper.convertToMap(
JsonXContent.jsonXContent, supportedJsonPayloads.readText(), false) as HashMap<String, Map<String, ArrayList<String>>>
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we not want to make this a configurable setting for the customers? What is in the supported_json_payloads.json can be the default values.

Copy link
Author

Choose a reason for hiding this comment

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

For P0, the supportedApiList is configured using the JSON; users will need to make changes to the resource file in order to update that list. As the plan was to only support ClusterHealth and ClusterStats for P0, an API to configure the list was not a high priority for P0.

Comment on lines 73 to 78
validatePath(path)
return when (path) {
CLUSTER_HEALTH_PATH -> ClusterHealthRequest()
CLUSTER_STATS_PATH -> ClusterStatsRequest()
else -> throw IllegalArgumentException("Unsupported API: $path")
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a need to have validatePath() if we have the when validation?

Copy link
Author

Choose a reason for hiding this comment

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

Ah, that's a really good point. Thank you for pointing that out! I removed the call to validatePath.

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

Successfully merging this pull request may close these issues.

None yet

3 participants