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

Feature flag outside XPack plugins boundaries #52328

Closed
astefan opened this issue Feb 13, 2020 · 6 comments
Closed

Feature flag outside XPack plugins boundaries #52328

astefan opened this issue Feb 13, 2020 · 6 comments
Labels

Comments

@astefan
Copy link
Contributor

astefan commented Feb 13, 2020

Inside EQL's telemetry code (and actually any XPack plugin that needs to expose usage data and summarized info), there is a pair of actions that need to be registered on the plugin side, but also two that need to be registered on the xpack core side.

XPack core actions:

EQL actions registration (draft PR): https://github.com/elastic/elasticsearch/pull/52248/files#diff-65a84ede375062e6ddafed077d89e530R109-R123

If the EQL side Usage and Info actions are hidden behind the enabled flag then PingAndInfoIT.testXPackInfo fails and, also, MiscellaneousDocumentationIT.testXPackUsage fails.
Ideally, the same feature flag value should be able to allow/forbid the action registration on the XPack code side, but it doesn't look like something easily doable.

The current approach is the one from the draft PR where Info and Usage actions are always registered which means eql will appear as available but disabled

    "eql" : {
      "available" : true,
      "enabled" : false
    }

when /_xpack or /_xpack/usage is called on the rest layer.

Opening this issue for discussion about any other approach than the current one for eql, as shown in the links above.
@jasontedor @henningandersen @colings86

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search (:Search/EQL)

@jasontedor
Copy link
Member

@astefan I think always registering the info/usage endpoints independently of EQL being enabled is fine.

@henningandersen
Copy link
Contributor

@astefan, this looks fine, though I would prefer the available flag to switch to false when the feature flag is not set to true. Looks like this can be easily handled in EqlInfoTransportAction.available()

@jasontedor
Copy link
Member

@henningandersen Availability is about whether or not the license level permits the feature (e.g., machine learning would be marked as not available with a basic license, but available with a platinum license, independently of whether or not it's enabled).

@henningandersen
Copy link
Contributor

Thanks @jasontedor , @astefan, that approach looks good 😃 .

@astefan
Copy link
Contributor Author

astefan commented Feb 18, 2020

Thank you for the feedback @jasontedor and @henningandersen.

@astefan astefan closed this as completed Feb 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants