Remove dynakube CR generation from helm chart

[mjgrzybek]

Description

Currently, user is expected to install CRD manually. Once it's done, helm charts can be used to instantiate dynakube object containing configuration.

It's about to change:

• helm chart is responsible only for CRD deployment
• user must create CR manually
• user must create token secrets manually

This PR is the first step - helm charts won't create dynakube object.

csi section renamed to csidriver.
Added csi.enabled field.

Added securityContextConstraints section.

How can this be tested?

1. Install latest stable release:

k create ns dynatrace
kubectl apply -f https://github.com/Dynatrace/dynatrace-operator/releases/latest/download/dynatrace.com_dynakubes.yaml
helm install --namespace dynatrace dynatrace-operator dynatrace/dynatrace-operator -f values-old.yaml --atomic

2. Upgrade to new helm chart:
   helm upgrade dynatrace-operator config/helm/chart/default/ -f values-new.yaml --atomic --namespace dynatrace

Example input

values-old.yaml

# may be set to "kubernetes", "openshift", "google"
platform: "kubernetes"

### base properties

name: "dynakube"
apiUrl: "..."
image: quay.io/dynatrace/dynatrace-operator:0.5.2

operator:
  requests:
    cpu: 50m
    memory: 64Mi
  limits:
    cpu: 100m
    memory: 128Mi

webhook:
  requests:
    cpu: 300m
    memory: 128Mi
  limits:
    cpu: 300m
    memory: 128Mi
  highAvailability: false

csi:
  requests:
    cpu: 300m
    memory: 100Mi
  limits:
    cpu: 300m
    memory: 100Mi

cloudNativeFullStack:
  enabled: true

values-new.yaml:

platform: "kubernetes"

image: quay.io/dynatrace/dynatrace-operator:snapshot

operator:
  requests:
    cpu: 50m
    memory: 64Mi
  limits:
    cpu: 100m
    memory: 128Mi

webhook:
  requests:
    cpu: 300m
    memory: 128Mi
  limits:
    cpu: 300m
    memory: 128Mi
  highAvailability: false

csi:
  requests:
    cpu: 300m
    memory: 100Mi
  limits:
    cpu: 300m
    memory: 100Mi

csidriver:
  enabled: true

Checklist

• Unit tests have been updated/added
• PR is labeled accordingly

[chrismuellner]

Don't forget to update the NOTES.txt file!

[meik99]

while testing i noticed that the CREATE operation is not applied to the validation webhook, because the .manifests property is missing. I'd suggest removing that check entirely and adding CREATE to the operations rule permanently. Otherwise the creation of invalid custom resources would be allowed

[mjgrzybek]

while testing i noticed that the CREATE operation is not applied to the validation webhook, because the .manifests property is missing. I'd suggest removing that check entirely and adding CREATE to the operations rule permanently. Otherwise the creation of invalid custom resources would be allowed

@meik99 Good point 👍 but it changes webhook behavior which is out of scope of this PR. Let's create another PR with this change separated so we can track results with better granularity.

[meik99]

while testing i noticed that the CREATE operation is not applied to the validation webhook, because the .manifests property is missing. I'd suggest removing that check entirely and adding CREATE to the operations rule permanently. Otherwise the creation of invalid custom resources would be allowed

@meik99 Good point +1 but it changes webhook behavior which is out of scope of this PR. Let's create another PR with this change separated so we can track results with better granularity.

It changes webhook behaviour as it is now, because previously the validation webhook caught invalid CRs on creation

[0sewa0]

Values.manifests is definitely no longer needed
probably Values.partial is also no longer necessary

[0sewa0]

I take it back for Values.partial, that is still kinda needed (unfortunately 😭 )

[mjgrzybek]

Values.manifests is definitely no longer needed probably Values.partial is also no longer necessary

@0sewa0 .partial is used to determine if csi is needed src
but I'll gladly change it's name and values ("false" and "csi" :D) to more descriptive.

[0sewa0]

@mjgrzybek I would leave it as is for now,
as the main idea for not using a bool for the partial thingy is that then it could be used for different things in the future

we should probably move the csi-driver into a sub-chart so it could be easily and neatly generated without these hacky ifs :D (but that is a problem for another time)

[meik99]

when autoCreateSecret is true, the upgrade is not possible, as the secret.yaml looks for .Values.name which has now been removed.
I'd suggest either:

• Re-adding that property in the values file
• Changing the secret.yaml to use .Release.Name
• Removing the ability to automatically create the secret

[meik99]

The upgrade fails since the operator's readiness and liveness probes fail:

Warning  Unhealthy  2m10s (x6 over 3m10s)  kubelet            Readiness probe failed: HTTP probe failed with statuscode: 404
Warning  Unhealthy  2m10s (x6 over 3m10s)  kubelet            Liveness probe failed: HTTP probe failed with statuscode: 404

[meik99]

The upgrade fails since the operator's readiness and liveness probes fail:

Warning  Unhealthy  2m10s (x6 over 3m10s)  kubelet            Readiness probe failed: HTTP probe failed with statuscode: 404
Warning  Unhealthy  2m10s (x6 over 3m10s)  kubelet            Liveness probe failed: HTTP probe failed with statuscode: 404

nevermind, works with the newer images

was fixed

[0sewa0]

@mjgrzybek run make manifests than it can go in 😄