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

[ML] add new flag exclude_generated that removes generated fields in GET config APIs #63899

Merged

Conversation

benwtrent
Copy link
Member

@benwtrent benwtrent commented Oct 19, 2020

When exporting and cloning ml configurations in a cluster it can be
frustrating to remove all the fields that were generated by
the plugin. Especially as the number of these fields change
from version to version.

This flag, exclude_generated, allows the GET config APIs to return
configurations with these generated fields removed.

APIs supporting this flag:

  • GET _ml/anomaly_detection/<job_id>
  • GET _ml/datafeeds/<datafeed_id>
  • GET _ml/data_frame/analytics/<analytics_id>

The following fields are not returned in the objects:

  • any field that is not user settable (e.g. version, create_time)
  • any field that is a calculated default value (e.g. datafeed chunking_config)
  • any field that is automatically set via another Elastic stack process (e.g. anomaly job custom_settings.created_by)

relates to #63055

When exporting and cloning ml configurations in a cluster it can be
frustrating to remove all the fields that were generated by
the plugin. Especially as the number of these fields change
from version to version.

This flag, remove_generated, allows the GET config APIs to return
configurations with these generated fields removed.

relates to elastic#63055
@elasticmachine
Copy link
Collaborator

Pinging @elastic/ml-core (:ml)

Copy link
Member

@davidkyle davidkyle left a comment

Choose a reason for hiding this comment

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

Looks good, left a question

@@ -67,7 +67,9 @@ Specifies whether the included model definition should be returned as a JSON map

`for_export`::
(Optional, boolean)
include::{es-repo-dir}/ml/ml-shared.asciidoc[tag=for-export]
Indicates if certain fields should be removed from the model configuration on
Copy link
Member

Choose a reason for hiding this comment

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

Same comment as #63093 (comment)

Copy link
Member

Choose a reason for hiding this comment

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

Can the ml-shared.asciidoc snippit be written in a general enough way to be used here too?

Shouldn't for_export be deprecated for trained models and switch to the exclude_generated flag? Or it that for another PR

Copy link
Member Author

Choose a reason for hiding this comment

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

@davidkyle I think keeping it for_export makes sense for now as its use case is really only for export (no clone makes sense for trained models)

Copy link
Member

Choose a reason for hiding this comment

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

I'd much prefer the same flag was used for the same purpose in all the APIs. Trained models will look like an oddity when transforms, AD jobs and DFA all use exclude_generated

The use case shouldn't define the parameter name, in future there may be another reason to get the model without the generated fields e.g. copy and update the model with further training. I like exclude_generated as it describes the action that takes place rather than one possible use case.

Copy link
Member

@davidkyle davidkyle left a comment

Choose a reason for hiding this comment

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

LGTM

@benwtrent
Copy link
Member Author

run elasticsearch-ci/1

@benwtrent benwtrent merged commit c1de07f into elastic:master Oct 20, 2020
@benwtrent benwtrent deleted the feature/ml-add-flag-for-clone-export branch October 20, 2020 15:28
benwtrent added a commit to benwtrent/elasticsearch that referenced this pull request Oct 20, 2020
…in GET config APIs (elastic#63899)

When exporting and cloning ml configurations in a cluster it can be
frustrating to remove all the fields that were generated by
the plugin. Especially as the number of these fields change
from version to version.

This flag, exclude_generated, allows the GET config APIs to return
configurations with these generated fields removed.

APIs supporting this flag:
- GET _ml/anomaly_detection/<job_id>
- GET _ml/datafeeds/<datafeed_id>
- GET _ml/data_frame/analytics/<analytics_id>

The following fields are not returned in the objects:

- any field that is not user settable (e.g. version, create_time)
- any field that is a calculated default value (e.g. datafeed chunking_config)
- any field that is automatically set via another Elastic stack process (e.g. anomaly job custom_settings.created_by)

relates to elastic#63055
benwtrent added a commit that referenced this pull request Oct 20, 2020
…ields in GET config APIs (#63899)(#63092) (#63177)

* [ML] adding for_export flag for ml plugin GET resource APIs (#63092)

This adds the new `for_export` flag to the following APIs:

- GET _ml/anomaly_detection/<job_id>
- GET _ml/datafeeds/<datafeed_id>
- GET _ml/data_frame/analytics/<analytics_id>

The flag is designed for cloning or exporting configuration objects to later be put into the same cluster or a separate cluster.

The following fields are not returned in the objects:

- any field that is not user settable (e.g. version, create_time)
- any field that is a calculated default value (e.g. datafeed chunking_config)
- any field that would effectively require changing to be of use (e.g. datafeed job_id)
- any field that is automatically set via another Elastic stack process (e.g. anomaly job custom_settings.created_by)

closes #63055

* [ML] adding new flag exclude_generated that removes generated fields in GET config APIs (#63899)

When exporting and cloning ml configurations in a cluster it can be
frustrating to remove all the fields that were generated by
the plugin. Especially as the number of these fields change
from version to version.

This flag, exclude_generated, allows the GET config APIs to return
configurations with these generated fields removed.

APIs supporting this flag:
- GET _ml/anomaly_detection/<job_id>
- GET _ml/datafeeds/<datafeed_id>
- GET _ml/data_frame/analytics/<analytics_id>

The following fields are not returned in the objects:

- any field that is not user settable (e.g. version, create_time)
- any field that is a calculated default value (e.g. datafeed chunking_config)
- any field that is automatically set via another Elastic stack process (e.g. anomaly job custom_settings.created_by)

relates to #63055
pugnascotia pushed a commit to pugnascotia/elasticsearch that referenced this pull request Oct 21, 2020
…in GET config APIs (elastic#63899)

When exporting and cloning ml configurations in a cluster it can be
frustrating to remove all the fields that were generated by
the plugin. Especially as the number of these fields change
from version to version.

This flag, exclude_generated, allows the GET config APIs to return
configurations with these generated fields removed.

APIs supporting this flag: 
- GET _ml/anomaly_detection/<job_id>
- GET _ml/datafeeds/<datafeed_id>
- GET _ml/data_frame/analytics/<analytics_id>

The following fields are not returned in the objects:

- any field that is not user settable (e.g. version, create_time)
- any field that is a calculated default value (e.g. datafeed chunking_config)
- any field that is automatically set via another Elastic stack process (e.g. anomaly job custom_settings.created_by)

relates to elastic#63055
@pugnascotia pugnascotia changed the title [ML] adding new flag exclude_generated that removes generated fields in GET config APIs [ML] add new flag exclude_generated that removes generated fields in GET config APIs Dec 16, 2020
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