docker compose examples refactor

[olegbespalov]

What?

These PRs refactor how the docker-compose example is structured. So instead of the being presented in a root folder, we move it under the examples (this aligns with the way how other Grafana projects do, e.g. tempo)

It also simplifies InfluxV1 example a bit.

And it moves the OpenTelemetry example from the https://github.com/grafana/xk6-output-opentelemetry repository, since soonish it's going to be archived.

Why?

docker-compose examples' is a nice way to quickly showcase our users the integration, so having and maintaining them we're more user friendly

Checklist

• I have performed a self-review of my code.
• I have commented on my code, particularly in hard-to-understand areas.
• I have added tests for my changes.
• I have run linter and tests locally (make check) and all pass.

Checklist: Documentation (only for k6 maintainers and if relevant)

Please do not merge this PR until the following items are filled out.

• I have added the correct milestone and labels to the PR.
• I have updated the k6-documentation: grafana/k6-docs#PR-NUMBER
• I have updated the TypeScript definitions: grafana/k6-DefinitelyTyped#PR-NUMBER
• I have updated the release notes: link

Related PR(s)/Issue(s)

[mstoykov]

LGTM in general. I have left comments to bump versions of projects up a bit.

I am not certain I really want us to have dashboards inside of k6. As I've pointed before this means that users come to us to make changse to them . So we have breaking changes all the time on a thing that users should likely customize on their own, but now potentially will be surprised that their dashboards keep changing.

If the idea is that we will NOT update them all that much and keep them as an example that is fine. But IMO that should be explicitly pointed out, that we do not really want any contributions, and that users should be copying those and customizing the copies.

[olegbespalov]

I am not certain I really want us to have dashboards inside of k6. As I've pointed before this means that users come to us to make changse to them . So we have breaking changes all the time on a thing that users should likely customize on their own, but now potentially will be surprised that their dashboards keep changing.

If the idea is that we will NOT update them all that much and keep them as an example that is fine. But IMO that should be explicitly pointed out, that we do not really want any contributions, and that users should be copying those and customizing the copies.

Like I said internally, but also posting my rational here

I believe the primary reason for having the these docker-compose (like any docker-compose in any project), dashboard examples for me is to provide a fast start to playing with technologies. They don't need to be production ready, so the simpler they are, the better they are. And having them should help our users adopt k6 better.

If the idea is that we will NOT update them all that much and keep them as an example that is fine. But IMO that should be explicitly pointed out, that we do not really want any contributions, and that users should be copying those and customizing the copies.

I believe it depends on the contribution, if the contribution is the fix because the latest k6 release introduced some breaking changes, but we forgot to update, to reflect the change,

[inancgumus]

Good idea 👍