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.

Sign up for GitHub

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

Jump to bottom

Deprecate X-Pack centric REST endpoints #35958

Closed
11 tasks done
jasontedor opened this issue Nov 27, 2018 · 10 comments
Closed
11 tasks done

Deprecate X-Pack centric REST endpoints #35958

jasontedor opened this issue Nov 27, 2018 · 10 comments
Assignees
@hub-cap @jakelandis @gwbrown @jasontedor @droberts195 @jkakavas
Labels
blocker :Core/Infra/REST API REST infrastructure and utilities >deprecation Meta v7.0.0-beta1

Comments

@jasontedor
Copy link
Member

jasontedor commented Nov 27, 2018 •
edited
Loading

We want to remove _xpack from our REST endpoints that currently have this as part of their path. We will deprecate these endpoints in 7.0.0 and remove them in 8.0.0. This is a meta-issue to track progress on deprecating these endpoints:
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

@jasontedor jasontedor mentioned this issue Nov 27, 2018
Merged
@jasontedor jasontedor added the help wanted adoptme label Nov 27, 2018
This was referenced Nov 27, 2018
Merged
Merged
@jasontedor jasontedor removed the help wanted adoptme label Nov 27, 2018
@gwbrown gwbrown mentioned this issue Nov 28, 2018
Merged
@jasontedor jasontedor mentioned this issue Nov 28, 2018
Merged
jakelandis added a commit to jakelandis/elasticsearch that referenced this issue Nov 29, 2018
@jakelandis
Support content type application/x-ndjson in DeprecationRestHandler
6f25b17 
org.elasticsearch.rest.RestController#hasContentType checks to see if the
RestHandler supports the `application/x-ndjson` Content-Type. DeprecationRestHandler
is a wrapper around the real RestHandler, and prior to this change
would always return `false` due to the interface's default supportsContentStream().
This prevents API's that use multi-line JSON from properly being deprecated
resulting in an HTTP 406 error.

This change ensures that the DeprecationRestHandler honors the
supportsContentStream() of the wrapped RestHandler.

Part of elastic#35958
@jakelandis jakelandis mentioned this issue Nov 29, 2018
Merged
jakelandis added a commit that referenced this issue Nov 29, 2018
@jakelandis
Support content type application/x-ndjson in DeprecationRestHandler (…
f8636e5 
…#36025)

org.elasticsearch.rest.RestController#hasContentType checks to see if the
RestHandler supports the `application/x-ndjson` Content-Type. DeprecationRestHandler
is a wrapper around the real RestHandler, and prior to this change
would always return `false` due to the interface's default supportsContentStream().
This prevents API's that use multi-line JSON from properly being deprecated
resulting in an HTTP 406 error.

This change ensures that the DeprecationRestHandler honors the
supportsContentStream() of the wrapped RestHandler.

Relates to #35958
jakelandis added a commit that referenced this issue Nov 29, 2018
@jakelandis
Support content type application/x-ndjson in DeprecationRestHandler (…
a2b78e0 
…#36025)

org.elasticsearch.rest.RestController#hasContentType checks to see if the
RestHandler supports the `application/x-ndjson` Content-Type. DeprecationRestHandler
is a wrapper around the real RestHandler, and prior to this change
would always return `false` due to the interface's default supportsContentStream().
This prevents API's that use multi-line JSON from properly being deprecated
resulting in an HTTP 406 error.

This change ensures that the DeprecationRestHandler honors the
supportsContentStream() of the wrapped RestHandler.

Relates to #35958
jakelandis added a commit to jakelandis/elasticsearch that referenced this issue Nov 30, 2018
@jakelandis
Deprecate /_xpack/monitoring/* in favor of /monitoring/*
5f115e1 
This commit is part of our plan to deprecate and ultimately remove the
use of _xpack in the REST APIs.

* Add deprecation for /_xpack/monitoring/* in favor of /monitoring/*
* Removed xpack from the rest-api-spec and tests
* Removed xpack from the Action name
* Removed MonitoringRestHandler as an unnecessary abstraction
* Minor corrections to comments

Relates elastic#35958
@jakelandis jakelandis mentioned this issue Nov 30, 2018
Merged
jakelandis added a commit that referenced this issue Dec 3, 2018
@jakelandis
Deprecate /_xpack/monitoring/* in favor of /_monitoring/* (#36130)
f8f521b 
This commit is part of our plan to deprecate and ultimately remove the
use of _xpack in the REST APIs.

* Add deprecation for /_xpack/monitoring/_bulk in favor of /_monitoring/bulk
* Removed xpack from the rest-api-spec and tests
* Removed xpack from the Action name
* Removed MonitoringRestHandler as an unnecessary abstraction
* Minor corrections to comments

Relates #35958
spinscale pushed a commit that referenced this issue Dec 4, 2018
@jakelandis @spinscale
Deprecate /_xpack/monitoring/* in favor of /_monitoring/* (#36130)
34fc485 
This commit is part of our plan to deprecate and ultimately remove the
use of _xpack in the REST APIs.

* Add deprecation for /_xpack/monitoring/_bulk in favor of /_monitoring/bulk
* Removed xpack from the rest-api-spec and tests
* Removed xpack from the Action name
* Removed MonitoringRestHandler as an unnecessary abstraction
* Minor corrections to comments

Relates #35958
@hub-cap hub-cap mentioned this issue Dec 4, 2018
Merged
jkakavas added a commit to jkakavas/elasticsearch that referenced this issue Dec 6, 2018
@jkakavas
This commit is part of our plan to deprecate and ultimately remove th…
8fba077 
…e use of _xpack in the REST APIs.

- REST api docs
- HLRC docs and doc tests
- Handle REST actions with deprecation warnings
- Changed endpoints in rest-api-spec and relevant file names

Relates elastic#35958
@jkakavas jkakavas mentioned this issue Dec 6, 2018
Merged
@droberts195
Copy link
Contributor

droberts195 commented Jan 3, 2019 •
edited
Loading

Given that, we can't replace the deprecated X-Pack endpoints in Beats code in 7.0.0 unless those endpoints are deprecated in ES 6.7.0 as well

Did you mean available in ES 6.7.0 rather than deprecated in ES 6.7.0?

I think for most components the new endpoints are available in 6.7, albeit undocumented. For example, #36373 for ML, #36379 for security, #36269 for watcher. Do you need any others?

@ycombinator
Copy link
Contributor

ycombinator commented Jan 3, 2019 •
edited
Loading

You are right indeed. The new APIs being available in 6.7.0 is sufficient. I checked the Beats codebase for which X-Pack APIs we're using and all of their new cousins exist in 6.7.0 already. So nothing to do here. Thanks!

@peteharverson peteharverson mentioned this issue Jan 4, 2019
Merged
1 task
@ycombinator
Copy link
Contributor

@droberts195 In my previous comment I said:

I checked the Beats codebase for which X-Pack APIs we're using and all of their new cousins exist in 6.7.0 already

However, it appears I missed one newer API endpoint. Evidently the POST _license/start_trial API isn't available in 6.7.0. Any chance we could make this available?

@jkakavas
Copy link
Member

jkakavas commented Jan 4, 2019

It would most probably make sense to add support for all license related endpoints. I can take this up for 6.7.0 if you can can open an issue about it @ycombinator (so that I don't forget :) )

@ycombinator ycombinator mentioned this issue Jan 4, 2019
Closed
@ycombinator
Copy link
Contributor

ycombinator commented Jan 4, 2019 •
edited
Loading

@jkakavas Thanks! Here's the issue: #37139.

This was referenced Jan 28, 2019
Closed
Merged
Merged
ycombinator added a commit to elastic/beats that referenced this issue Feb 5, 2019
@ycombinator
Replace deprecated _xpack endpoints (#9656)
fd98c11 
In 7.0.0, Elasticsearch is deprecating most `_xpack/*` endpoints. See elastic/elasticsearch#35958.

This PR updates the Beats codebase, except test fixtures, with the appropriate replacements for the deprecated endpoints.
@jpountz jpountz mentioned this issue Feb 8, 2019
Closed
jakelandis added a commit to jakelandis/logstash that referenced this issue Mar 10, 2019
@jakelandis
Update monitoring HTTP end point
7647b38 
This commit changes /_xpack/monitoring/_bulk to /_monitoring/bulk.
The former is deprecrated as 7.0.0.

Relates elastic/elasticsearch#36130
Relates elastic/elasticsearch#35958
@jakelandis jakelandis mentioned this issue Mar 10, 2019
Closed
jakelandis added a commit to jakelandis/logstash that referenced this issue Mar 11, 2019
@jakelandis
Update monitoring HTTP end point
78dae9f 
This commit changes /_xpack/monitoring/_bulk to /_monitoring/bulk.
The former is deprecrated as 7.0.0.

Relates elastic/elasticsearch#36130
Relates elastic/elasticsearch#35958
elasticsearch-bot pushed a commit to elastic/logstash that referenced this issue Mar 12, 2019
@jakelandis @jsvd
Update monitoring HTTP end point
dcde7e3 
This commit changes /_xpack/monitoring/_bulk to /_monitoring/bulk.
The former is deprecrated as 7.0.0.

Relates elastic/elasticsearch#36130
Relates elastic/elasticsearch#35958

Fixes #10528
elasticsearch-bot pushed a commit to elastic/logstash that referenced this issue Mar 12, 2019
@jakelandis @jsvd
Update monitoring HTTP end point
4867674 
This commit changes /_xpack/monitoring/_bulk to /_monitoring/bulk.
The former is deprecrated as 7.0.0.

Relates elastic/elasticsearch#36130
Relates elastic/elasticsearch#35958

Fixes #10528
elasticsearch-bot pushed a commit to elastic/logstash that referenced this issue Mar 12, 2019
@jakelandis @jsvd
Update monitoring HTTP end point
3c3e769 
This commit changes /_xpack/monitoring/_bulk to /_monitoring/bulk.
The former is deprecrated as 7.0.0.

Relates elastic/elasticsearch#36130
Relates elastic/elasticsearch#35958

Fixes #10528
@estolfo estolfo mentioned this issue Apr 9, 2019
Closed
@bizybot bizybot mentioned this issue Apr 25, 2019
Closed
@danielmitterdorfer danielmitterdorfer mentioned this issue Oct 9, 2019
Closed
2 tasks
@jtibshirani jtibshirani mentioned this issue Oct 17, 2019
Merged
This was referenced Oct 21, 2019
Closed
Merged
@edsavage edsavage mentioned this issue Jul 20, 2020
Merged
@jakelandis jakelandis mentioned this issue Oct 20, 2021
Merged
jakelandis added a commit that referenced this issue Oct 25, 2021
@jakelandis
[REST API compatibility] Move _xpack prefix compat tests to their own…
bfd8e15 
… qa module (#79501)

This commit moves where we the _xpack/* REST compatible tests are executed.
The _xpack/* prefix was deprecated in 7x and removed in 8.x via #35958.
However, when deprecated the paths were also removed from the API spec in 7x.
This means that these paths are not available to test with the YAML test framework.

As part of the work to support REST API compatibility for 8.x these _xpack prefix paths
were re-introduced when using compatibility. These paths were tested via the primary
x-pack YAML rest tests using custom specs and transformations. These custom specs are
needed to allow the testing framing work to use the _xpack/* paths and the transformations
tell the tests to use the _xpack prefix. To avoid re-introducing these prefix paths in the 7.x spec,
custom specs for the tests are used.

This worked well for testing on the server, but after introducing the compatibility
tests via the rest-resources-zip (#78534) the transformed tests in that zip
requires those custom specs to execute properly. Since these are re-introduced just
for testing we do not want to add these to the zip file of specs.

To allow the xpack prefix to continue to be tested AND allow the tests to execute
as-is via the specs/tests in the rest-resource-zip BUT do not expose the need for
custom specs in the zip file ; these tests have been moved to their own qa module.

As an implementation detail, the tests in the new qa module are transformed twice. Once
as determined by the main x-pack transforms for things like compatible type support, and
then once again solely for the purpose for testing the xpack prefix.
lockewritesdocs pushed a commit to lockewritesdocs/elasticsearch that referenced this issue Oct 28, 2021
@jakelandis
[REST API compatibility] Move _xpack prefix compat tests to their own…
0c3806d 
… qa module (elastic#79501)

This commit moves where we the _xpack/* REST compatible tests are executed.
The _xpack/* prefix was deprecated in 7x and removed in 8.x via elastic#35958.
However, when deprecated the paths were also removed from the API spec in 7x.
This means that these paths are not available to test with the YAML test framework.

As part of the work to support REST API compatibility for 8.x these _xpack prefix paths
were re-introduced when using compatibility. These paths were tested via the primary
x-pack YAML rest tests using custom specs and transformations. These custom specs are
needed to allow the testing framing work to use the _xpack/* paths and the transformations
tell the tests to use the _xpack prefix. To avoid re-introducing these prefix paths in the 7.x spec,
custom specs for the tests are used.

This worked well for testing on the server, but after introducing the compatibility
tests via the rest-resources-zip (elastic#78534) the transformed tests in that zip
requires those custom specs to execute properly. Since these are re-introduced just
for testing we do not want to add these to the zip file of specs.

To allow the xpack prefix to continue to be tested AND allow the tests to execute
as-is via the specs/tests in the rest-resource-zip BUT do not expose the need for
custom specs in the zip file ; these tests have been moved to their own qa module.

As an implementation detail, the tests in the new qa module are transformed twice. Once
as determined by the main x-pack transforms for things like compatible type support, and
then once again solely for the purpose for testing the xpack prefix.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hub-cap hub-cap

@jakelandis jakelandis

@gwbrown gwbrown

@jasontedor jasontedor

@droberts195 droberts195

@jkakavas jkakavas

Labels
blocker :Core/Infra/REST API REST infrastructure and utilities >deprecation Meta v7.0.0-beta1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
10 participants
@ycombinator @colings86 @hub-cap @jakelandis @gwbrown @jasontedor @droberts195 @jkakavas @elasticmachine @lcawl