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

[SLO] HTTP2 support QA testing - SLO product #184834

Closed
5 of 6 tasks
jasonrhodes opened this issue Jun 5, 2024 · 3 comments
Closed
5 of 6 tasks

[SLO] HTTP2 support QA testing - SLO product #184834

jasonrhodes opened this issue Jun 5, 2024 · 3 comments
Assignees
Labels
Team:obs-ux-management Observability Management User Experience Team

Comments

@jasonrhodes
Copy link
Member

jasonrhodes commented Jun 5, 2024

Summary

With the addition of HTTP2 support in Kibana, the Kibana platform team is asking us to run Kibana with HTTP2 support turned on and verify that our areas of the product do not display any obvious errors or problems.

Acceptance criteria

  • Please run a local Kibana instance using the HTTP2 flag and test our SLO product, specifically:
    • Creating an SLO
    • Editing an SLO
    • Federated SLO flow
    • Auto-creation of the burn rate rule when creating an SLO
    • Deleting an SLO?
    • Anything else you can think of re: our SLO product and its interaction with HTTP calls from Kibana

Timebox: 2-3 hours, max

More details

From @pgayvallet's email:

HTTP2 is considered (and documented as) an experimental feature for now, and is disabled by default for obvious reasons.

In theory, having HTTP2 enabled should be an implementation detail for any feature that doesn't mess with things specific to HTTP/1.x (looking at you, bfetch), and our manual tests tend to confirm that.

The PR also adds integration tests and FTR smoke tests for the feature, however massively enabling HTTP2 for all FTR suites is a bit complicated (mostly due to the fact that we're using self-signed certificates, not really because of HTTP2 itself), so we can't be fully sure everything works as expected, given that, well, we did not ran all FTR suites.

Which is why we need you: if some of you could do just some surface / smoke tests of their Kibana apps, it would really be amazing and help us a lot.

HTTP2 can be enabled (for dev mode) simply by adding the --http2 flag when starting the server:

node scripts/kibana --dev --http2

If you prefer the long way, it can be done via the configuration file too

server.protocol: http2
server.ssl.enabled: true
server.ssl.certificate: {path-to-kibana}/packages/kbn-dev-utils/certs/kibana.crt
server.ssl.key: {path-to-kibana}/packages/kbn-dev-utils/certs/kibana.key

Please remember that enabling HTTP2 (one way or the other) enables HTTPS/TLS too. So to access your local instance, you need to use https instead of http, e.g. https://localhost:5601/base-path. (and also you need to discard the scary warning about self-signed certificates)

If you see anything that doesn't behave as expected when HTTP2 is enabled, or if you have any questions, please reach out to us on the #kibana-core channel.

Thanks a lot for your support

@jasonrhodes jasonrhodes added the Team:obs-ux-management Observability Management User Experience Team label Jun 5, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)

@dominiqueclarke dominiqueclarke self-assigned this Jun 6, 2024
@dominiqueclarke
Copy link
Contributor

Also checked filtering, sorting, and groups. Everything LGTM

@jasonrhodes
Copy link
Member Author

Thank you so much, @dominiqueclarke !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:obs-ux-management Observability Management User Experience Team
Projects
None yet
Development

No branches or pull requests

3 participants