Layered operator #272
Layered operator #272
Conversation
# Conflicts: # .gitignore # controllers/backstage_controller.go # controllers/backstage_controller_test.go # controllers/backstage_deployment.go # controllers/backstage_service.go # controllers/local_db_deployment.go # controllers/local_db_storage.go
# Conflicts: # api/v1alpha1/backstage_types.go # config/crd/bases/janus-idp.io_backstages.yaml # controllers/backstage_backend_auth.go # controllers/backstage_controller.go # controllers/backstage_controller_test.go # controllers/local_db_statefulset.go
# Conflicts: # go.mod
Co-authored-by: gazarenkov <gazarenkov@users.noreply.github.com>
|
|
| @@ -98,7 +111,7 @@ type Application struct { | |||
|
|
|||
| // Image Pull Secrets to use in all containers (including Init Containers) | |||
| // +optional | |||
| ImagePullSecrets *[]string `json:"imagePullSecrets,omitempty"` | |||
| ImagePullSecrets []string `json:"imagePullSecrets,omitempty"` | |||
There was a problem hiding this comment.
If ImagePullSecrets []string is not defined it contains nil pointer If ImagePullSecrets []string is initialized with empty array it contains pointer to empty slice with len:0 and cap:0
So, yes we can distinguish just checking ImagePullSecrets == nil Is it what you're asking about?
It is just that, as it is, the way it is iterated upon in this PR (https://github.com/gazarenkov/janus-idp-operator/blob/e6c56cecebf4f76748e8c80903059593e7fd78a8/pkg/model/deployment.go#L188-L191) will never allow CR users to explicitly set this list to an empty list.
This used to work previously (see
operator/controllers/backstage_deployment.go
Lines 219 to 224 in 496da58
imagePullSecrets: [] in my CR, the resulting Deployment won't have any pull secrets defined, and if I don't set imagePullSecrets in the CR, it will inherit those coming from the operator/raw config.
But this can be tackled in a separate issue.
Co-authored-by: Armel Soro <armel@rm3l.org>
Co-authored-by: Armel Soro <armel@rm3l.org>
|
There was a problem hiding this comment.
Approving to unblock other work items, but besides what's already in the review comments, there are a couple of things that have an impact on the current downstream documentation. We need to make sure those are handled later in the product documentation:
- the way the backend auth secret is handled
- to see changes from a custom CM already referenced in CR, either doing
oc rollout restartof the Deployment or updating thespec.application.replicasfield in the CR to 0 then back to what it was, so that the operator can recreate the Deployment with the new changes - changes to the default naming pattern of the route URL: changed from
https://backstage-<CUSTOM_RESOURCE_NAME>-<NAMESPACE_NAME>.<OPENSHIFT_INGRESS_DOMAIN>tohttps://<CUSTOM_RESOURCE_NAME>-backstage-<NAMESPACE_NAME>.<OPENSHIFT_INGRESS_DOMAIN>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rm3l The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Description
Operator was redesigned in order to:
Which issue(s) does this PR fix or relate to
#69
PR acceptance criteria
How to test changes / Special notes to the reviewer
make test