[ML] Deprecate anomaly detection post data endpoint #66347
Conversation
There is little evidence of this endpoint being used and there is quite a lot of code complexity associated with the various formats that can be used to upload data and the different errors that can occur when direct data upload is open to end users. In a future release we can make this endpoint internal so that only datafeeds can use it, and remove all the options and formats that are not used by datafeeds. End users will have to store their input data for anomaly detection in Elasticsearch indices (which we believe all do today) and use a datafeed to feed it to anomaly detection jobs.
|
Pinging @elastic/ml-core (:ml) |
...high-level/src/test/java/org/elasticsearch/client/documentation/MlClientDocumentationIT.java
Outdated
Show resolved
Hide resolved
client/rest-high-level/src/test/java/org/elasticsearch/client/MachineLearningIT.java
Outdated
Show resolved
Hide resolved
|
Will the flush jobs API be deprecated as well? Per https://www.elastic.co/guide/en/elasticsearch/reference/master/ml-flush-job.html#ml-flush-job-desc "The flush jobs API is only applicable when sending data for analysis using the post data API". |
Not immediately. There are actually troubleshooting use cases where the flush jobs API can be used in conjunction with a datafeed, to skip or advance time in between opening the job and starting the datafeed. Potentially we could deprecate calling the flush jobs API without arguments, as that use case will be useless. But there isn't time to properly think this through for 7.11 so let's leave it for 7.12 or after. |
|
Jenkins run elasticsearch-ci/2 |
There is little evidence of this endpoint being used and there is quite a lot of code complexity associated with the various formats that can be used to upload data and the different errors that can occur when direct data upload is open to end users. In a future release we can make this endpoint internal so that only datafeeds can use it, and remove all the options and formats that are not used by datafeeds. End users will have to store their input data for anomaly detection in Elasticsearch indices (which we believe all do today) and use a datafeed to feed it to anomaly detection jobs. Backport of elastic#66347
There is little evidence of this endpoint being used and there is quite a lot of code complexity associated with the various formats that can be used to upload data and the different errors that can occur when direct data upload is open to end users. In a future release we can make this endpoint internal so that only datafeeds can use it, and remove all the options and formats that are not used by datafeeds. End users will have to store their input data for anomaly detection in Elasticsearch indices (which we believe all do today) and use a datafeed to feed it to anomaly detection jobs. Backport of #66347
There is little evidence of this endpoint being used
and there is quite a lot of code complexity associated
with the various formats that can be used to upload
data and the different errors that can occur when direct
data upload is open to end users.
In a future release we can make this endpoint internal
so that only datafeeds can use it, and remove all the
options and formats that are not used by datafeeds.
End users will have to store their input data for
anomaly detection in Elasticsearch indices (which we
believe all do today) and use a datafeed to feed it
to anomaly detection jobs.