[Epic] Operator based on the Operator SDK

[jasperchui]

Goal

This epic aims to provide an operator based on Operator SDK that is releaseable and usable state where it offers a comparable stable experience as installing via helm chart.

Acceptance criteria

• Operator is able to deploy Backstage
• Operator can reconcile changes
• Operator can enforce Janus IDP image
• Operator can enforce proper routing

Requirements

• Test plan
• Documentation

Roadmap

https://github.com/orgs/janus-idp/projects/5/views/1

Notes

Additional context
Add any other context or screenshots about the epic here.

[kadel]

• Operator is able to deploy Backstage

Should operator also handle PostgreSQL instance? Or the assumption is that users will use separate PostgreSQL operator?

• Operator can reconcile changes

How is Backstage configuration going to be stored?
Doe the full app-config.yaml config going to be represented as CR or users will manage configuration in a separate ConfigMap?

• Operator can enforce Janus IDP image

what does it mean enforce IDP Image?

• Operator can enforce proper routing

What does it mean enforce proper routing?

[gazarenkov]

In order to make it more focused, can we:

• retitle the issue as Initial implementation/MVP of ...
• remove "Operator can reconcile changes" , it is a bit confusing since it's Oparator's nature to reconcile but this makes me think we want to react on changes with changing runtime objects (Deployments, Services etc...) but, as discussed we hardly can cover it in initial implementation (it requires more analysis and dicussion)
  WDYT?

[gazarenkov]

Should operator also handle PostgreSQL instance? Or the assumption is that users will use separate PostgreSQL operator?

In my proposal user can:

• install default db (PostgreSQL) deployment
• replace it with own manifest (using ConfigMap) and install
• avoid installation any db and configure Backstage to use external DB OR use embedded SQLite instead (not tested)

How is Backstage configuration going to be stored? Doe the full app-config.yaml config going to be represented as CR or users will manage configuration in a separate ConfigMap?

• Operator can enforce Janus IDP image

what does it mean enforce IDP Image?

I guess it is about to make Janus "bundle" as default option installing backstage instance (can be image or app-config)?

What does it mean enforce proper routing?

I guess it is about to be able to properly configure "networking" (Service, Route, Ingress...) to access Backstage service.
I think, Ideally controller should put a URL somewhere to the CR.status to make it simpler for user to get this endpoint

[rm3l]

In order to make it more focused, can we:

• retitle the issue as Initial implementation/MVP of ...
• remove "Operator can reconcile changes" , it is a bit confusing since it's Oparator's nature to reconcile but this makes me think we want to react on changes with changing runtime objects (Deployments, Services etc...) but, as discussed we hardly can cover it in initial implementation (it requires more analysis and dicussion)
  WDYT?

I'd suggest keeping this epic as it is to keep track of everything needed to achieve the end goal (to aim for something production-ready). We can indeed create a sub-task about the initial implementation/MVP + any other issues we think should be addressed after this MVP (like reacting to changes, ...).
I can create those issues, and we can add any other relevant tasks we can think of.

[gazarenkov]

In order to make it more focused, can we:

• retitle the issue as Initial implementation/MVP of ...
• remove "Operator can reconcile changes" , it is a bit confusing since it's Oparator's nature to reconcile but this makes me think we want to react on changes with changing runtime objects (Deployments, Services etc...) but, as discussed we hardly can cover it in initial implementation (it requires more analysis and dicussion)
  WDYT?

I'd suggest keeping this epic as it is to keep track of everything needed to achieve the end goal (to aim for something production-ready). We can indeed create a sub-task about the initial implementation/MVP + any other issues we think should be addressed after this MVP (like reacting to changes, ...). I can create those issues, and we can add any other relevant tasks we can think of.

Well, it can be any reasonable scope, it just has to be well-defined.
"initial implementation", "MVP", "something production-ready" it's just names, details matter.
We can create as many epics as we need, it's free :)

For the issues - I would probably starting creating them after code moving.

[rm3l]

/close

Closing as done.

[openshift-ci]

@rm3l: Closing this issue.

In response to this:

/close

Closing as done.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.