Implement Kibana/OpenSearch Dashboards dev services

[Javatar81]

This change will add dashboard services to the dev services for extensions/elasticsearch-rest-client and extensions/elasticsearch-java-client. If the distribution is elasticsearch, it will start Kibana as the dashboard. If the distribution is opensearch, it will start OpenSearch-dashboards as the dashboard.

• Fixes Kibana/OpenSearch Dashboards dev services #39582

[quarkus-bot]

/cc @gsmet (elasticsearch), @loicmathieu (elasticsearch), @marko-bekhta (elasticsearch)

[andreaTP]

cc. @yrodiere @holly-cummins

[marko-bekhta]

Hey 👋🏻

thanks for the PR! 🙂

Could you please use rebase instead of adding merge commits? Something like:

git checkout main
git fetch upstream
git rebase upstream/main

where upstream points to this repo (git remote add upstream https://github.com/quarkusio/quarkus.git that is if you haven't set up the upstream yet) usually should do it for your current branch (main from which you've opened this PR) 🙂

I think it would be better if you just create another processor for the dashboards (i.e. DevServicesElasticsearchDashboardsProcessor), that way you'd easiely spot if you are not missing any stop/restart actions + the processor for the Elasticsearch services is about to change to work with multiple services at the same time.

You've made good progress here already 👍🏻
Have you had a chance to look into this part about dev ui as well:

it would be a great start if we provided either an option to launch Kibana in the Elasticsearch dev services (and include a link to it in the Dev UI),

it can go as a follow up if not 🙂

[Javatar81]

Thanks for all your comments. So I would move all my changes into a separate class DevServicesDashboardProcessor with its own properties files and address your proposed changes.

Regarding the Dev Ui. Yes I had that in mind but I planned it as a follow up.

[gsmet]

Thanks for this work, I see we are making good progress. I added a small question.

[Javatar81]

I am in the refactoring to move everything related to dashboards into a new processor class named DevServicesElasticsearchDashboardsProcessor. Since both are running in parallel I must make sure that the elasticsearch dev service is already running (but only if the hosts variable is not set). One obvious solution would be to repeat locating the elasticsearch container with a backoff. Is there a more elegant way to wait for the other devservice to be started?

[marko-bekhta]

I am in the refactoring to move everything related to dashboards into a new processor class named DevServicesElasticsearchDashboardsProcessor. Since both are running in parallel I must make sure that the elasticsearch dev service is already running (but only if the hosts variable is not set). One obvious solution would be to repeat locating the elasticsearch container with a backoff. Is there a more elegant way to wait for the other devservice to be started?

oh yes, you could make the ES services produce a build item(s) for you (it would contain a list of hosts) and then you'd use that build items as an input to your dashboards step:

...
startElasticsearchDevService(
    ...
    BuildProducer<ElasticsearchHostBuildItem> elasticsearchHosts
    .. .) {
        ... 

        elasticsearchHosts.produce(...)

    }

and then in the dashboards:

startElasticsearchDashboardsDevService(
    ...
    List<ElasticsearchHostBuildItem> elasticsearchHosts
    .. .) {
        ...
        List<String> eshosts = getAllEsHosts(elasticsearchHosts);
        ..
    }

(maybe you could come up with a better name for ElasticsearchHostBuildItem as well 🙂)

[Javatar81]

All points addressed so far. Please review again.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit b461825.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[github-actions]

🎊 PR Preview f8ca654 has been successfully built and deployed to https://quarkus-pr-main-51164-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit b461825.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ MicroProfile TCKs Tests

📦 tcks/microprofile-lra

❌ org.eclipse.microprofile.lra.tck.TckRecoveryTests.testCancelWhenParticipantIsUnavailable - History

• Expecting the metric Compensated callback was called Expected: a value equal to or greater than <1> but: <0> was less than <1> - java.lang.AssertionError

java.lang.AssertionError: 
Expecting the metric Compensated callback was called
Expected: a value equal to or greater than <1>
     but: <0> was less than <1>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.eclipse.microprofile.lra.tck.TckRecoveryTests.assertMetricCallbackCalled(TckRecoveryTests.java:210)
	at org.eclipse.microprofile.lra.tck.TckRecoveryTests.testCancelWhenParticipantIsUnavailable(TckRecoveryTests.java:195)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)