Make Quarkus more Platform Engineer / Backstage friendly

[iocanel]

Currently a team can make use of Backstage templates in order to generate a Quarkus application along with additional manifests for:

• Backstage
  • Components
  • APIs
  • Documentation
• Kubernetes / Openshift
  • Manifests
  • Helm Charts
  • Tekton Pipelines
• ArgoCD
  • Application

The problem of keeping project files up to date

As discussed in the context of #41352 arbitrary files and metadata should be easily (re)generated externally or else they will most likely get out of date / require manual maintenance.

How can these files get out of date

• A version change (app or quarkus)
• An new API provided (rest, grpc, graphql)
• A new API consumed (rest, grpc)
• A change in the VCS application info.
• Anything that can influence Kubernetes manifest generation
  • Extensions added / removed / upgraded
    • Metrics
    • Health
    • Kubernetes (plain or config)
    • Liquibase / Flyway
  • Configuration changes
  • Port changes
    ... and more

Challenges

In most cases such changes are performed by developers, while the manifests are maintained by DevOps or Platform Engineers and is often not obvious to those groups that a change on one side of the requires changes on the other.

The problem of bringing in existing application into the software catalog

The problem described above focused on the maintainance aspect, but how are these manifest get created in the first place:

• Manually
• Using Backstage Templates

The challenge of creating Backstage templates

Creating templates for Backstage can be a tedious process, especially when they also include configuration and manifests for:

• argocd
• kubernetes / helm

The biggest challenge is that the feedback loop takes too long, which means that each iteration takes a lot of time.
Having tools that could generated those files and place them in the project in such a way that everything integrates seamlessly would save Platform Engineers a lot of time and frustration. Furthermore, it would provide them with a a golden path for setting up their own templates.

Suggested solution

1. Create a set of extensions that would be able to generate all the required manifests:
   • Backstage (Create a backstage extension #42398)
   • ArgoCD (Create a Quarkus extension for ArgoCD #42399)
   • Helm
   • Tekton (maybe repurpose quarkus-tekton-cli?)
2. Create an umbrella extension that will coordinate all of the extensions above (like Make Quarkus Kubernetes gitops friendly. #26928 but extension driven):
   • Generate and add files under version control
   • Generate idempotent files

Extension structure

These extensions should possibly have the following structure

• spi (build items for intra extension integration)
• model (classes the model the output entities)
• deployement (buildsteps producing GeneratedFileSystemResourceBuildItem)
• runtime (no runtime code needed so metadata mostly)
• cli (command line interface for generating / regenerating those manifests `e.g. quarkus generate backsteage).