Adding SmallRye Stork service discovery for both the hero & villain services.

The VillainClient, is implemented by directly using the JAX-RS client API with the RESTEasy Reactive client. Therefore, the Stork API is used directly in order to get the same functionality available in the HeroRestClient.

Fixes #40

@holly-cummins & I had a talk at Devoxx Belgium about Pact contract testing:

• VIdeo replay: https://youtu.be/vYwkDPrzqV8
• Slides: https://speakerdeck.com/hollycummins/how-to-avoid-common-pitfalls-with-modern-microservices-testing-c2a33ee0-ca9d-413e-b01e-cbd25853132a

We used the Quarkus superheroes app as the foundation for our demos. Currently all the code resides in my own personal fork. We need to get this into the main repo.

The code, as-is, will not break anything, but it also will not be executed during any CI/CD process, or dev mode/continuous testing.

There are a few caveats that need to be sorted out.

1. The Pact tests use the free tier within Pactflow broker - https://quarkus-super-heroes.pactflow.io.
   • There is a CI/CD robot user that has credentials we can store as GitHub secrets, but the larger problem is that the account we currently use is tied to my (@edeandrea's) redhat.com email address. Ideally we should have a more "generic" user to own the account.
   • Under an account you can assign individual users with permissions. @holly-cummins and I are currently in there as admin users.
   • @cescoffier / @maxandersen how do you want to handle this? I can add you both as users in the current Pactflow and you can explore, or I can demo it for you so you get an understanding of it. Let me know your thoughts.
     • You need to authenticate with the broker even to perform read actions
2. The Pact tests as they currently are written will not run by default - they have to have flags to enable them
   • This is because, in its current state, Pact does not work in dev mode/continuous testing. There are some issues on the Pact side and some work on the Quarkus side
   • This way we can safely merge in the code without breaking any of the existing CI/CD workflows and/or dev mode/continuous testing within any of the apps
   • @holly-cummins has already started work on that. In our Devoxx demo we showed it working in continuous testing on the provider side. That was done with a local patch to Pact and the beginnings of a Quarkus extension which @holly-cummins is building
3. From a CI perspective we should hook in, at a minimum, the provider verification tests into the simple build/test workflow AND the nightly CI process that tests against Quarkus main
   • The simple build/test workflow runs against all PRs as well as the first workflow against any pushes to main.

@holly-cummins did I miss anything?

All three Villain, Hero and Fight microservices use a Postgres database. What about having a different database type for each microservice?

We could use Postgres, MySQL and MariaDB, for example.

Describe the bug When building projects and changing the generated deployment resource by setting quarkus.openshift.deployment-kind=Deployment property for Maven build, the generated YAML for the Deployment resource doesn't contain .spec.template.metadata and its child elements.

To Reproduce Steps to reproduce the behavior:

1. Run maven build with quarkus.openshift.deployment-kind=Deployment property setting.

./mvnw clean package \ 
 -Dquarkus.profile=openshift-17 \
 -Dquarkus.kubernetes.deploy=true \
 -Dquarkus.openshift.deployment-kind=Deployment

2. Open the target/kubernetes/openshift.yml file and look for YAML for the Deployment resource.

3. .spec.template.metadata and child elements didn't get generated.

Expected behavior .spec.template.metadata and its child elements e.g. labels, and annotations should be generated.

Desktop (please complete the following information):

• OS: macOS Ventura
• JDK: Java SE build 17.0.5+9-LTS-191
• Maven: mvnw comes with the project

Additional context Sample generated YAML of Deployment resource.

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    app.openshift.io/vcs-url: <<unknown>>
    app.openshift.io/connects-to: "fights-db,fights-kafka,apicurio,rest-villains,rest-heroes,otel-collector"
    app.quarkus.io/commit-id: 58303663091232da528a9eecfcd74f0c592f558d
    app.quarkus.io/build-timestamp: 2022-11-28 - 14:42:55 +0000
    prometheus.io/scrape: "true"
    prometheus.io/path: /q/metrics
    prometheus.io/port: "8082"
    prometheus.io/scheme: http
  labels:
    app.kubernetes.io/name: rest-fights
    app.kubernetes.io/part-of: fights-service
    app.kubernetes.io/version: "1.0"
    app: rest-fights
    application: fights-service
    system: quarkus-super-heroes
    app.openshift.io/runtime: quarkus
  name: rest-fights
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: rest-fights
      app.kubernetes.io/part-of: fights-service
      app.kubernetes.io/version: "1.0"
  template:
    spec:
      containers:
        - env:
            - name: JAVA_APP_JAR
              value: /deployments/quarkus-run.jar
          envFrom:
            - secretRef:
                name: rest-fights-config-creds
            - configMapRef:
                name: rest-fights-config
          image: quay.io/quarkus-super-heroes/rest-fights:1.0
          imagePullPolicy: Always
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /q/health/live
              port: 8082
              scheme: HTTP
            initialDelaySeconds: 0
            periodSeconds: 30
            successThreshold: 1
            timeoutSeconds: 10
          name: rest-fights
          ports:
            - containerPort: 8082
              name: http
              protocol: TCP
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /q/health/ready
              port: 8082
              scheme: HTTP
            initialDelaySeconds: 0
            periodSeconds: 30
            successThreshold: 1
            timeoutSeconds: 10

The imports.sql had an import issue. The superpowers are missing some spaces. For example: WillInvisibilityLongevityMaster. It should be "Will Invisibility Longevity Master"

In production, both Heroes and Villains microservices are not be visible from the outside world, just from the Fight microservice. For that, invoking the hello endpoints on Heroes and Villains becomes impossible.

I've added two endpoints on Fights (@Path("/hello/heroes") and @Path("/hello/villains")) so we can "ping" Heroes and Villains from Fights:

curl http://localhost:8082/api/fights/hello
curl http://localhost:8082/api/fights/hello/heroes
curl http://localhost:8082/api/fights/hello/villains

I've also added some debug logging

Bumps surefire-plugin.version from 3.0.0-M5 to 3.0.0-M7. Updates maven-surefire-plugin from 3.0.0-M5 to 3.0.0-M7

Updates maven-failsafe-plugin from 3.0.0-M5 to 3.0.0-M7

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Adding SmallRye Stork service discovery for both the hero & villain services.

The VillainClient, is implemented by directly using the JAX-RS client API with the RESTEasy Reactive client. Therefore, the Stork API is used directly in order to get the same functionality available in the HeroRestClient.

Fixes #40

Bumps quarkus.platform.version from 2.6.3.Final to 2.7.0.Final. Updates quarkus-bom from 2.6.3.Final to 2.7.0.Final

Updates quarkus-maven-plugin from 2.6.3.Final to 2.7.0.Final

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Run cd ui-super-heroes && docker build . and the build fails with the following error. Adding /'s fixes it.

Sending build context to Docker daemon  658.9kB
Step 1/10 : FROM registry.access.redhat.com/ubi8/nodejs-16:1 as builder
 ---> 0ffebd6de0e2
Step 2/10 : COPY --chown=1001:1001 package*.json $HOME
When using COPY with more than one source file, the destination must be a directory and end with a /

Output of docker version:

Client: Docker Engine - Community
 Version:           20.10.18
 API version:       1.41
 Go version:        go1.18.6
 Git commit:        b40c2f6
 Built:             Thu Sep  8 23:12:30 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.18
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.6
  Git commit:       e42327a
  Built:            Thu Sep  8 23:10:10 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.8
  GitCommit:        9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

I deployed a few weeks ago and everything spun up healthy. Today, I tried to spin up in OpenShift and am seeing errors with the heroes & villains db pods with this:

postgresql 16:14:10.52
postgresql 16:14:10.52 Welcome to the Bitnami postgresql container
postgresql 16:14:10.52 Subscribe to project updates by watching https://github.com/bitnami/containers
postgresql 16:14:10.52 Submit issues and feature requests at https://github.com/bitnami/containers/issues
postgresql 16:14:10.52
postgresql 16:14:10.53 INFO ==> ** Starting PostgreSQL setup **
postgresql 16:14:10.54 INFO ==> Validating settings in POSTGRESQL_* env vars..
postgresql 16:14:10.54 INFO ==> Loading custom pre-init scripts...
postgresql 16:14:10.55 INFO ==> Loading user's custom files from /docker-entrypoint-preinitdb.d ...
/docker-entrypoint-preinitdb.d/..2022_10_06_15_42_44.4190271301/get-data.sh: line 3: curl: command not found

I love this demo, I hope this can be fixed soon! I use this to test OpenTelemetry things. Thank you! Here is how I deployed:

oc apply -f https://raw.githubusercontent.com/quarkusio/quarkus-super-heroes/main/deploy/k8s/java17-openshift.yml
oc apply -f https://raw.githubusercontent.com/quarkusio/quarkus-super-heroes/main/deploy/k8s/monitoring-openshift.yml

The fight service shouldn't use Stork's client-side load balancing when deployed in KNative. This breaks because if the heroes/villains services scale to 0, then the client side load balancing in the fights service won't have any downstream clients.

ATM OpenTelemetry is still not supported in ACA.

• https://github.com/microsoft/azure-container-apps/issues/289
• https://github.com/ezYakaEagle442/aca-java-petclinic-mic-srv/blob/main/iac/bicep/aca/aca.bicep#L223
• https://github.com/ezYakaEagle442/aca-java-petclinic-mic-srv/blob/main/docker/petclinic-customers-service/Dockerfile#L17
• https://github.com/microsoft/azure-container-apps/issues/290
• https://docs.microsoft.com/en-us/azure/azure-monitor/app/java-in-process-agent#point-the-jvm-to-the-jar-file
• https://github.com/microsoft/azure-container-apps/issues/208#issuecomment-1231697920

Follow-up to #93 where profiles were added to make local deployment to kubernetes easier.

quarkusio/quarkus#26781 (coming in Quarkus 2.12) allows for hierarchical profile configuration. Once this is in place, some of the current profile configurations can be cleaned up a bit so things aren't duplicated.

Now that the OpenTelemetry Collector is part of the architecture and collecting metrics, investigate whether it can process/handle metrics as well, potentially removing Prometheus from the architecture.

Currently the websockets in the event stats service don't implement ping/pong, so after a while the browser drops the websocket connection. When this happens the user needs to refresh the page.

This would need to be implemented on the server side (TeamStatsWebSocket & TopWinnerWebSocket) as well as on the client (index.html).