The naming seems to be inconsitent and confusing, as we there are multiple different names to refer to the same thing.

For example for gitops alone we have:

• argocd-operator
• gitops-operator
• openshift-gitops-operator
• assemble-argocd

We need to somehow narrow down the list as it get's pretty confusing.

Here are some ideas of conventions that could possibly help us:

• The easiest thing to get rid of is the assemble variant.
• Another option is to adopt the upstream folder name, when possible.
• Aligning folder name, with namespace

Create a helm chart which provisions the Assemble backend services components including application, and database.

As an Assemble contributor or demo'er
I want an Tekton software template
So that I can spin a Tekton instance to use for continuous integration

Acceptance:

Automatically provision operator
Automatically provision instance
Automatically provision service accounts / RBAC

ArgoCD application that includes all platform components so that they can be managed via GitOps.

Create a procedure for deploying Openshift GitOps and ApplicationSet to then sync all platform services & configurations so that the IDP is ready to use in a single cluster.

Update status on new Janus IDP board Here: https://github.com/orgs/janus-idp/projects/1/views/2

depends on #21 in assemble-platforms

As an Assemble Platform Engineer
I want to be able to store sensitive credentials in a secure vault in order to protect the credentials.

Acceptance:

• An instance of the hashicorp vault is running in the cluster as an HA deployment
• An argo application to maintain the state of the vault deployment.

Update main README to provide clearer description of Janus IDP Demo project

Ideally, the provided charts should be usable in vanilla kubernetes too.
Especially, for local development or things like integration testing (see #27) being able to spin something like: kind, k3s, microk8s and trying things out would be great.

User should have instructions for populating secret data into Vault to support the platform installation process.

As an Assemble contributor or demo'er
I want a Keycloak software template
So that I can spin a Keycloak instance to use for Backstage authentication

Acceptance:

Automatically provision operator
Automatically provision instance
Automatically provision service accounts / RBAC

To validate incoming pull requests, we need to put together some integration tests that at least verify that charts are installable to the target environment.

Adding a pull request workflow on github actions should be fine.

Documentation of GitHub configuration

• Oauth apps
• Permissions

Tekton plugin for Backstage is still WIP

As a Developer
I want to authenticate using my [GitHub] credentials
In order to access Backstage

Acceptance:

• Deploy an instance of Keycloak to [namespace?] using OLM
• Configure a realm for OpenShift integration
• OAuth client for the integration
• Backstage configuration?

As an Assemble contributor or demo'er
I want an Backstage software template
So that I can spin a Backstage instance to use for DevEx UI

Acceptance:

• Helm chart
• Uses the shared Backstage image
• Provisions Postgres and configures database connection
• Allows user to point to external DB

As an Assemble contributor or demo'er
I want an ArgoCD software template
So that I can spin a ArgoCD instance to use for continuous delivery

Acceptance:

• Automatically provision operator
• Automatically provision instance
• Automatically provision service accounts / RBAC

We need to Identify all the secrets that Vault and Argo will need to manage for MVP and ensure the credentials so we can remove them from individual configs, and store them in a secure way for initial provisioning.

Also need to identify how the installation instructions will need to be updated to incorporate passwords into Vault.

Namespace configuration operator is likely useful here.

Main capabilities to target:

• Quotas based on selected "size"
• RBAC for image pulls
• RBAC for team access to the namespace (depends on Authorization design)

As a Platform Operator
I want to authenticate using my [GitHub] credentials
In order to access [OpenShift] environments

Acceptance:

• Deploy an instance of Keycloak to [namespace?] using OLM
• Configure a realm for cluster integration
• OAuth client for the integration
• Personal Account Token setup in GitHub for integration
• Identity provider configuration for OpenShift

Document instuctions for users to set up the platform on an OpenShift cluster.

Acceptance:

• Backstage
• Argo
• Tekton
• Postgres
• Keycloak

OpenShift ingress routing will not be available to some users on k8s. Support non-OpenShift users with k8s native ingress config.

Some users may not have OLM installed in their k8s cluster. Support users with a manifest for provisioning OLM on plain k8s. This should include appropriate catalog configuration.