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

NP Licensing service #50931

Closed
2 of 12 tasks
mshustov opened this issue Nov 18, 2019 · 2 comments
Closed
2 of 12 tasks

NP Licensing service #50931

mshustov opened this issue Nov 18, 2019 · 2 comments
Labels
blocker Feature:New Platform Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@mshustov
Copy link
Contributor

mshustov commented Nov 18, 2019

Actions

// The decision to convert kebab-case/snake-case keys to camel-case keys stemmed from an old
// convention of using kebabe-case/snake-case in API response bodies but camel-case in JS
// objects. See pull #29304 for more info.

for me it sounds like a Kibana-wide problem and something that we must be mentioned in the convention docs.

  • cover service with functional/integration tests.
  • switch license fetching from deprecated /_xpack to /_license endpoint. /_license returns license status only. we need to investigate what is a substitution for a set of features.
  • document migration path.
  • decide how to provide observables via contract. provide observables {license$} or a getter get() => license$. The latter can simplify mocking. Unify approach for the all platform API.
  • should support enterprise license type for parity with the LP Support 'enterprise' license type #49474
  • fix issue reported by @pgayvallet
I see a lot of `│ERROR browser[SEVERE] http://localhost:6171/api/licensing/info - Failed to load resource: the server responded with a status of 401 (Unauthorized)` in the test logs. 
This is caused by the fact that plugins initialize even on login page, where user is non authenticated, and the /api/licensing/info route requires authentication

The main changes

state

LP: The plugin allows consumers to calculate state on license change event and store this
The signature calculation is based on this state + license content
NP: We decided that license service doesn't keep plugins state #49345 (comment). Plugins have to react on license change and calculate license state on every license change. If another plugin needs that information, it should be exposed via a plugin contract.
This change makes NP & LP licensing service not compatible. We have to keep both until all plugins migrate to the new platform service.

Network request failures

LP: The licensing plugin didn’t emit a license in case of network errors.
NP: Emits the license even if the request failed.

clusterSource

LP: Allows specifying cluster source to perform polling. Monitoring uses this functionality plugin
NP: The plugin always uses data client. If we want to support the case for monitoring we can expose already existing functionality by team request.

Initial value on the client

LP: Passed on the page via inlined xpackInitialInfo
NP: Should be fetched

Config

LP: xpack.xpack_main.xpack_api_polling_frequency_millis
NP: xpack.licensing.pollingFrequency

License

NP: mode field not provided anymore

sessionStorage

LP: License and signature were stored under different keys in session storage
NP: License and signature were stored under one key xpack.licensing

@mshustov mshustov added blocker Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Feature:New Platform labels Nov 18, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform (Team:Platform)

@mshustov
Copy link
Contributor Author

closed as a duplicate of #18356

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocker Feature:New Platform Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

No branches or pull requests

2 participants