Allow rest tests with Serverless API protections#98250
Allow rest tests with Serverless API protections#98250elasticsearchmachine merged 2 commits intoelastic:mainfrom
Conversation
This commit changes the `ESRestTestCase` in 3 ways - Refactor the "hasXYZ" flags into a single `EnumSet` of `ProductFeature` flags - Detect serverless distributions, and in those cases treat certain features as unavailable (even if the plugin is installed) - Add a few more feature checks for features that can now be disabled
|
Pinging @elastic/es-delivery (Team:Delivery) |
| if (serverless) { | ||
| availableFeatures.removeAll( | ||
| List.of( | ||
| ProductFeature.ILM, | ||
| ProductFeature.SLM, | ||
| ProductFeature.ROLLUPS, | ||
| ProductFeature.CCR, | ||
| ProductFeature.LEGACY_TEMPLATES | ||
| ) | ||
| ); | ||
| } |
There was a problem hiding this comment.
I don't love what I had to do here.
- Detecting serverless via the module names is ugly
- It means this test case knows which APIs are available in serverless, which it shouldn't.
However, I couldn't find a better option that wouldn't require a huge rewrite of the test cases.
- There's no single test hierarchy for serverless tests, so it's hard to find somewhere to put in a shared "disable X, Y, Z" piece of code
- This method is static, so even if there was a hierarchy there isn't a great way to plug in a "disable features" piece of code.
There was a problem hiding this comment.
Is it really necessary to do this though? Should we just remove those module from serverless and then the generic code here will just "work"? Those features won't be available by virtue of the modules being uninstalled. I don't see a scenario in which we are running "serverless" and have those modules installed.
There was a problem hiding this comment.
Oh how I would love that ... but alas...
- We can't remove legacy templates because it's not a module, it's part of server
- We can't remove SLM because we're using it to run operational backups, but there's no user facing API for it - everything is configured via file based config
- We can't remove ILM because SLM is part of ILM and because we support templates that configure ILM even if ILM itself cannot run
We might be able to remove CCR and Rollups, but I haven't tried since it wouldn't make a big difference.
There was a problem hiding this comment.
Understood. Where did we land on response codes here then? Could we try to hit some of these endpoints to see what they return instead. Probably more trouble than it's worth just to eliminate this small hack but just thinking out loud.
There was a problem hiding this comment.
They return 404 (but perhaps 410 in the future, per #97397) so I think we could do it with endpoint detection, but I agree that it's not worth it (at least right now).
Either we'd do a preflight request (which requires finding a good detection API for each feature) or we'd just catch-and-ignore 404/410 when trying to do cleanups, which might be simpler, but could end up masking real failures.
|
@elasticmachine update branch |
tvernum
added
the
auto-merge-without-approval
Modifies `ESClientYamlSuiteTestCase` to ship loading the global template if legacy templates are not supported. Relates: elastic#98250
…)" This reverts commit 2ba7b79.
This reverts commit 53e9792. See: elastic#98250, elastic#98373
This commit changes the `ESRestTestCase` in 3 ways - Refactor the "hasXYZ" flags into a single `EnumSet` of `ProductFeature` flags - Detect serverless distributions, and in those cases treat certain features as unavailable (even if the plugin is installed) - Add a few more feature checks for features that can now be disabled It also changes `ESClientYamlSuiteTestCase` to register a composable global template if legacy templates are unavailable Relates: elastic#98250, elastic#98373
This commit changes the `ESRestTestCase` in 3 ways - Refactor the "hasXYZ" flags into a single `EnumSet` of `ProductFeature` flags - Detect serverless distributions, and in those cases treat certain features as unavailable (even if the plugin is installed) - Add a few more feature checks for features that can now be disabled
…)" (elastic#98373) This reverts commit 2ba7b79. Temporarily reverting because it breaks downstream projects
This commit changes the `ESRestTestCase` in 3 ways - Refactor the "hasXYZ" flags into a single `EnumSet` of `ProductFeature` flags - Detect serverless distributions, and in those cases treat certain features as unavailable (even if the plugin is installed) - Add a few more feature checks for features that can now be disabled It also changes `ESClientYamlSuiteTestCase` to register a composable global template if legacy templates are unavailable Relates: #98250, #98373
4 participants
This commit changes the
ESRestTestCasein 3 waysEnumSetofProductFeatureflags