quarkusio / quarkus-super-heroes Goto Github PK

It would be nice if there was a local cache of hero and villain fighters available to the fights service. This cache could be used to demonstrate the resiliency patterns if the hero or villain service was not available. In that case, the fight service could first look into the cache for a random fighter before going to its fallback.

Currently the event-statistics service stores data in-memory. The service itself can handle upwards of 1,000,000 events/second, but wWe should add Infinispan so that data is persisted.

ATM OpenTelemetry is still not supported in ACA.

• microsoft/azure-container-apps#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
• microsoft/azure-container-apps#290
• https://docs.microsoft.com/en-us/azure/azure-monitor/app/java-in-process-agent#point-the-jvm-to-the-jar-file
• microsoft/azure-container-apps#208 (comment)

With the announcement of Quinoa, I was wondering if we could use it for the Angular app

https://quarkus.io/blog/quinoa-modern-ui-with-no-hassle/

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.

I have noticed there are no examples of Redis Cache integrated into Quarkus.
Can we request the best practice sample within this project where we use
Redisson and Jedis clients
And even perhaps showcase how we would connect to AWS Elasticache redis

After the Quarkus 2.16 upgrade, the CORS support has changed.

See https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.16#no-wildcard-origin-support-by-default-for-cors-filter

Add some Grafana dashboards and infrastructure for standing up Grafana.

Add Pact provider verification tests to rest-fights.

It looks like the models for the UI were auto-generated using Swagger CodeGen. It would be nice to have this step documented in the UI's readme.

The k8s KNative yamls for the UI app don't have the CALCULATE_API_BASE_URL environment variable set properly.

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.

When creating the Azure container registry, we should use the TAG_SYSTEM variable: --tags system="$TAG_SYSTEM" instead of --tags system=quarkus-super-heroes

az acr create \
  --resource-group "$RESOURCE_GROUP" \
  --location "$LOCATION" \
  --name "$CONTAINER_REGISTRY_NAME" \
  --sku Standard \
  --tags system=quarkus-super-heroes

Investigate using the Quarkus Helm Quarkiverse Extension to generate Helm charts along with all the current k8s resources.

In the README file we need to document how to use Jaeger

see #115

When I tried to run the project using 'podman-compose' on the provided YAML files the execution returns a 'KeyError'. I attached the erros below.

I would like to run the project with podman-compose. I'm no expert in docker/podman but I thought that it should be possible to run the 'podman-compose' tool.

I'm a newbie but if someone is able to provide some directions I can try to address this issue.

Introduce a schema registry for events produced to/consumed from Kafka.

The immediate fix for #154 was to revert back to a previous bitnami image. After some conversation on bitnami/containers#9143 we need to figure out a different way to pull in the Hero/Villain data which will allow us to not have to be pinned to this PostgreSQL image.

Some possible solutions:

1. Maybe use an initContainer on the db pods for pulling the data to a shared volume?
2. Switch away from the bitnami images to something else?

Cleanup the workaround for the missing app.openshift.io/runtime label.

Waiting on quarkusio/quarkus#26516

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.

Or maybe we keep prometheus, but instead of scraping each individual app, it gets the metrics from the Otel collector?

Should we use any Kotlin anywhere?

Create multi-arch native images for the Quarkus services. This is left over from #70.

While requesting random fights is great, what if we introduced a "fairness" setting in the UI. Sometimes we get fights that don't seem fair, where one fighter is a level 10 and the other is 10,000,000.

We could have a dropdown/radio button/whatever that, when selected in the UI, gave a choice to the user. Something like

• Weaklings
• Average
• Super strong
• Super-duper strong

We can certainly come up with better names/categories, but whatever we come up with we'd assign ranges of fighter levels to each term. The weakling would be anything <= some number and the Super-duper strong would be anything >= some number.

We'd pass that on the getRandomFighters call to rest-fights, which would in turn pass to the rest-heroes & rest-villains. rest-heroes & rest-villains would guarantee that only a fighter between those levels would be returned.

We could use this scenario to really showcase consumer-driven contract testing where making sure rules within the contract between consumers & producers stipulates the requirement in the contract.

So for example, in the rest-fights consumer contract you'd have something in the contract that said

When I (the rest-fights consumer requests a random hero/villain between a certain level, the level attribute in the response from the rest-heroes/rest-villains service should be between the values passed in the request.

Thats the kind of thing that can't be done using straight OpenAPI.

@edeandrea What about having a JMeter load test that gets new fighters and just fights? This way we could add some load (and Azure Load Testing is compatible with JMeter load scripts ;o)

WDYT ?

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

Offshoot from #37.

Update the event-statistics service to remove the custom KafkaProducerResource class and InjectKafkaProducer annotation. The WebSocketsIT tests should use the new KafkaCompanion.

The JMeter script uses properties that are not taken into account in Azure. We need to have the properties in a separate file

Add SmallRye Stork Service Discovery & load balancing to the rest-fights service.

NOTE: Only calls to the rest-heroes service will use it since calls to the rest-villains service do not use the jax-rs client (calls to the rest-villains service use the JAX-RS client API directly - just to illustrate how it would be done).

The Kubernetes descriptors would configure stork to use the Kubernetes service discovery. We can discuss on here what the right load balancing strategy should be.

Add distributed tracing within and between each of the services. This would also need to add Jaeger to the infra which gets deployed.

The single script version for super heroes is broken on https://github.com/quarkusio/quarkus-super-heroes/blob/main/docs/deploying-to-azure-containerapps.md - there was a change for the protocol for postgres to include open telemetry and now the villains app cant connect to the database

Exception:
error 11:12:08 ERROR traceId=, parentId=, spanId=, sampled= [or.hi.en.jd.sp.SqlExceptionHelper] (JPA Startup Thread: ) Driver does not support the provided URL: jdbc:postgresql://villains-db-codespace.postgres.database.azure.com:5432/villains?ssl=true&sslmode=require

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

Currently there isn't any AuthZ/AuthN in any of the apps. It would be nice if there was some.

In the super heroes UI, introduce the ability to pick a specific hero and/or villain for a battle, rather than selecting random ones.

Maybe a pop-up that hits the heroes & villains services directly? This would also be a good thing where in the future we could introduce an API management layer so that the UI only talks to that and not the individual services directly.

There would probably need to be some discussion on the UI and the flow. That discussion can happen here in this issue.

Additionally - the same way the UI handles the URL to the fight service would have to work here as well for the UI to talk to both the heroes & villains services.

@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?

In the event stats UI

in addition to just the bar going between heroes & villains, show the number of wins for each in paraentheses beside each label as well as the total number of fights.

Something like this:

Coming in Quarkus 2.8 is the new KafkaCompanion. This will allow the rest-fights app to remove the custom KafkaConsumerResource class and InjectKafkaConsumer annotation. The FightResourceIT tests can just use the new KafkaCompanion.

See #58 for a similar enhancement on the event-statistics service.

We need to create multi-arch images supporting both amd64 and arm64 for both JVM & native for the event-statistics, rest-fights, rest-heroes, & rest-villains services, as well as both an amd64 and arm64 image for the ui-super-heroes.

Currently we are only building amd64 images for JVM & native for the Quarkus services and an amd64 image for the ui-super-heroes service.

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

In the README file we need to document how to use Prometheus

see #116

To be able to run the script easily in both local and Cloud environment, we should introduce variables for the protocol (either HTTP or HTTPs), URL of the Fight API and port number

Add a simple read-only UI in the heroes service that shows all the heroes and is searchable by name. This will be done using Quarkus Qute. There would need to be tests as well.

This could be expanded on in the future, but for now, just read-only.

Essentially the same as #41 just for the heroes service.

Add a simple read-only UI in the villains service that shows all the villains and is searchable by name. This will be done using Quarkus Qute. There would need to be tests as well.

This could be expanded on in the future, but for now, just read-only.

Essentially the same as #42 just for the villains service.

Currently we build java11-native and java17-native images for native image. Native image is native image and the Java version should not matter.

Therefore we should just produce a single native image for each application.

As part of this we will also want to switch back to using quay.io/quarkus/ubi-quarkus-mandrel-builder-image for building the native images. #177 switched to quay.io/quarkus/ubi-quarkus-graalvmce-builder-image for the short term.

That will essentially mean reverting b2693a9 and 302ff69

In rest-fights & event-statistics, remove the need for overriding to a custom version of io.apicurio:apicurio-common-rest-client-vertx

Waiting on quarkusio/quarkus#25378 which will be released in Quarkus 2.11.0

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).

As Quarkus 3 nears we want to be ready to upgrade once it hits.

It doesn't really make sense to scale the fights service & the UI app to 0, so keep a min of 1 replica for each

It would be nice to have a parent pom. It's not mandatory, but for some IDEs it's much easier to open the project and have all the modules setup.

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.

Currently, to add custom "stuff" for the Quarkus kubernetes/openshift extensions, you have to duplicate those resource definitions in each of the files (src/main/kubernetes/kubernetes.yml, src/main/kubernetes/minishift.yml, src/main/kubernetes/knative.yml, & src/main/kubernetes/openshift.yml).

See the guide for more details on this.

Once dekorateio/dekorate#942 makes it into a Quarkus version (via quarkusio/quarkus#22290), we will want to update the super heroes (rest-heroes, rest-villains, rest-fights, & event-statistics) to take advantage of this feature.