Skip to content
This repository has been archived by the owner on Aug 19, 2024. It is now read-only.

Improve Backstage CRD to simplify k8s runtime customization #352

Closed
gazarenkov opened this issue May 2, 2024 · 2 comments
Closed

Improve Backstage CRD to simplify k8s runtime customization #352

gazarenkov opened this issue May 2, 2024 · 2 comments
Labels
jira Issue will be sync'ed to Red Hat JIRA kind/feature

Comments

@gazarenkov
Copy link
Member

We have very flexible layered mechanism of Backstage runtime configuration:

  • Operator default config
  • CustomResource raw config
  • CR configuration

Raw config is powerful but not always convenient to use as required rewriting the whole resource, which in most of the cases is quite big Backstage Deployment.yaml.
So, to simplify a way to configure some parts of configuration and reach “features parity” with Helm Chart (following user’s feedback) we need to extend CR configuration

For the time being we clearly need to have options (at least) for:

@github-actions github-actions bot added the jira Issue will be sync'ed to Red Hat JIRA label May 2, 2024
@gazarenkov
Copy link
Member Author

gazarenkov commented Jun 20, 2024

As documented in #388

This PR includes new way to configure Backstage deployment, now (in contrary to raw config) it is possible to add the changes as a and valid "fragment" of appsv1.deployment object inside Backstage CR and those fields will be merged with default (+raw) configuration, like:

apiVersion: rhdh.redhat.com/v1alpha2
kind: Backstage
metadata:
  name: my-backstage
spec:
  deployment:
    spec:
      template:
        metadata:
           labels:
              label1: value1
        spec:
          containers:
            - name: backstage-backend
               resources:
                  requests:
                      cpu: 250m
                      memory: 256Mi
           - name: my-sidecar
              image: my-sidecar
          volumes:
            - ephemeral:
                volumeClaimTemplate:
                  spec:
                    storageClassName: "my-special-class"
              name: dynamic-plugins-root

Also, since this addition causes changes in the API, new API version v1alpha2 was added. So, as for Operator versions 0.3.x and 0.4.x (if we consider 3 months release cadency and 6 months API maintain) it will support as minimum both v1alpha1 and v1alpha2 (which become a storage version). After upgrading Operator to 0.3.x the following behaviour expected:

  • existed v1alpha1 CRs are working and shown as v1alpha2
  • both v1alpha1 and v1alpha2 CRs can be added/updated, all shown as v1alpha2

NOTE: v1alpha2 is backward compatible with v1alpha1 w/o data conversion

Openshift NOTE: deployment.patch field won't show up in the "Form view" when creating a CR from the OCP Web. To be able to edit it with ODC use "YAML view".

@nickboldt
Copy link
Member

As part of the migration from janus-idp to redhat-developer in https://issues.redhat.com/browse/RHIDP-1021, this will be tracked in https://issues.redhat.com/browse/RHIDP-2232

See also https://issues.redhat.com/browse/RHIDP-1138

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
jira Issue will be sync'ed to Red Hat JIRA kind/feature
Projects
None yet
Development

No branches or pull requests

2 participants