cnoe-io/backstage-app#29

Once this is merged, we need to:

1. update the backstage image id.
2. ensure app config is updated for https://backstage.io/docs/releases/v1.28.0/#breaking-oauth-scope-updates

Have you searched for this feature request?

• I searched but did not find similar requests

Problem Statement

As a newcomer (or a regular committer) it would be great to have contribution guidelines. A set of guidelines for how to structure the new stacks and maybe some example anti-patterns to stay away from would be great.

Possible Solution

Create a CONTRIBUTING.md with some guidance

Alternatives Considered

No response

Similar to how it's set up in https://github.com/cnoe-io/idpbuilder/tree/main/.devcontainer, we should have one for this repository. I think in this repository, we can have cloud provider integration stuff in the config to allow for producers and consumers to experiment with cloud integrations.

What is your environment, configuration, and command?

Currently ref implementation disables TLS validation in Backstage. This was done because we did not generate our certificate previously. We now generate one so we should import it.

What did you do and What did you see instead?

NA

Additional Information. Logs.

No response

Have you searched for this feature request?

• I searched but did not find similar requests

Problem Statement

idpbuilder right now setups tools that help teams to get started with creating cloud resources but it doesn't help development team to connect to these resources. Adding tools like Dapr will help platform teams to enable developers to build complex application that can connect to infrastructure components by using APIs.

Possible Solution

Deploy and configure Dapr as part of the stack

Alternatives Considered

There are not many other projects providing the features that Dapr provides.

similar to the fix we did in cnoe-io/idpbuilder#326 we should also update the backstage scaffolder actions in this repo to also use the right gitea url. An example is here.

We need e2e tests for things we put here. I don't think we have to confine ourselves to Go but all stacks should use the same language and a chosen format.

Tests should:

• Verify functionalities of things that was deployed by stacks. For example, if it deploys Argo Workflows, it should test argo workflows functionalities that are enabled by the stack.
• Verify user workflows. If you instruct users to do things in readme, we should test as much as we can. e.g. Can you login with Keycloak? Can you login to Backstage?

Tests should not:

• Test the core functionalities of things that deploy the stacks. eg. No point in testing idpbuilder's --kind-confgi or --port flags.

Maybe we can mess with https://github.com/microsoft/playwright to start.

Have you searched for this feature request?

• I searched but did not find similar requests

Problem Statement

Currently, we do not have any observability components to check on metrics, logs, cost. We also have no ability to visualize or alert on them.

Possible Solution

I propose we add a stack that includes:

• Prometheus
• Loki
• Grafana
• Alertmanager
• OpenCost

These components will set the foundation for observability across CNOE components. They'll be able to monitor the core ones as well as any others added to the environment, including non-CNOE components.

We can have Grafana leverage keycloak and use the credentials there. If/when a service mesh becomes available, we can add Tempo to the stack for tracing observability.

Alternatives Considered

No response