Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update operator-sdk to v1.2.0 #516

Merged
merged 8 commits into from
Nov 11, 2020
Merged

Conversation

miguelsorianod
Copy link
Contributor

Changes:

  • Updated controller-runtime to v0.6.3
  • Fix metrics reader ClusterRole APIversion from rbac.authorization.k8s.io/v1beta1 to rbac.authorization.k8s.io/v1 (change also included in bundle)
  • Fix CRD directory path for controllers suite_test
  • Now operator-sdk automatically adds all generated elements in bundle. This makes include the metrics-reader Service as part of the bundle now

@@ -22,7 +22,7 @@ bases:
# [CERTMANAGER] To enable cert-manager, uncomment all sections with 'CERTMANAGER'. 'WEBHOOK' components are required.
#- ../certmanager
# [PROMETHEUS] To enable prometheus monitor, uncomment all sections with 'PROMETHEUS'.
- ../prometheus
#- ../prometheus
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's this last change I've made that is worth mentioning.

Due to the change:

Now operator-sdk automatically adds all generated elements in bundle. This makes include the metrics-reader Service as part of the bundle now

Now the ServiceMonitor object related to Prometheus was also automatically included in the bundle/manifests directory, changing the existing behavior we had using operator-sdk v1.1.0. I've commented that line to disable the automatic inclusion of the ServiceMonitorobject in bundle and automatic installation when running make deploy to keep our previous behavior where the responsability of installing the ServiceMonitor belonged to the users when installing it through OLM.

This is specially important on clusters where Prometheus is not installed (the case in our apicast-operator where K8s native is used and Prometheus CRDs might not be installed) as including the ServiceMonitor in the bundle would make the OLM installation fail due to Prometheus API types not existing.

@miguelsorianod miguelsorianod changed the title [WIP] Update operator-sdk to v1.2.0 Update operator-sdk to v1.2.0 Nov 11, 2020
@miguelsorianod miguelsorianod changed the title Update operator-sdk to v1.2.0 [WIP] Update operator-sdk to v1.2.0 Nov 11, 2020
Due to Service objects cannot start with a number.
@codeclimate
Copy link

codeclimate bot commented Nov 11, 2020

Code Climate has analyzed commit 6e93107 and detected 0 issues on this pull request.

View more on Code Climate.

@miguelsorianod
Copy link
Contributor Author

When working on this I've found a bug that already existed before this PR (although we did not hit it because it was not included in the bundle so it was not deployed):

The generated service name (on the bundle or when executing make deploy) is:
3scale-operator-controller-manager-metrics-service

Services cannot begin with a number so the deployment fails with the following error:

The Service "3scale-operator-controller-manager-metrics-service" is invalid: metadata.name: Invalid value: "3scale-operator-controller-manager-metrics-service": a DNS-1035 label must consist of lower case alphanumeric characters or '-', start with an alphabetic character, and end with an alphanumeric character (e.g. 'my-name',  or 'abc-123', regex used for validation is '[a-z]([-a-z0-9]*[a-z0-9])?')

This name is generated from the namePrefix value in config/default/kustomization.yaml which had the value 3scale-operator.
This prefix controls the prefix that is added to several objects when generating them. That prefix is not used on all of them though. For example the generated CSV does not make use of this name, the 3scale-operator ServiceAccount that we created neither.

To solve this issue I've changed the namePrefix to threescale-operator. This has changed the name of the Service to threescale-operator-controller-manager-metrics-service. But it also has changed names of lots of other objects. For example, the metrics reader ClusterRole (also included on the bundle) name and also the operator Deployment name. Also lots of other objects. The content of the bundle/manifests directory is now (notice how some file names changed too):
msoriano@localhost:~/go/src/github.com/3scale/3scale-operator (update-operator-sdk-to-120)$ find bundle/manifests/

bundle/manifests/
bundle/manifests/threescale-operator-controller-manager-metrics-service_v1_service.yaml
bundle/manifests/capabilities.3scale.net_openapis.yaml
bundle/manifests/capabilities.3scale.net_backends.yaml
bundle/manifests/3scale-operator.clusterserviceversion.yaml
bundle/manifests/capabilities.3scale.net_tenants.yaml
bundle/manifests/capabilities.3scale.net_products.yaml
bundle/manifests/apps.3scale.net_apimanagers.yaml
bundle/manifests/apps.3scale.net_apimanagerbackups.yaml
bundle/manifests/apps.3scale.net_apimanagerrestores.yaml
bundle/manifests/threescale-operator-metrics-reader_rbac.authorization.k8s.io_v1_clusterrole.yaml

The whole list of objects with the names changed can be seen if you execute kustomize build config/default. You'll see their new names (for example the Namespace name has also another name, but also the operator Role, RoleBinding, ...).

@miguelsorianod miguelsorianod changed the title [WIP] Update operator-sdk to v1.2.0 Update operator-sdk to v1.2.0 Nov 11, 2020
@miguelsorianod miguelsorianod merged commit 20b5863 into master Nov 11, 2020
@miguelsorianod miguelsorianod deleted the update-operator-sdk-to-120 branch November 11, 2020 16:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants