Thoughts and feedback

[ddieruf]

Config as json

I know most components have quite a list of possible configurations. I see the "config" option of each component in the API spec is formatted as json. So, my assumption is that all defaults for the given component follow Puslar documentation - this operator is not changing anything. And to override a value, one would follow Pulsar's spec.

If I wanted to turn off non-persistent topic creation

PulsarCluster:
  spec:
    broker:
      config: "{\"enableNonPersistentTopics\":false}"

Or I could change the broker service port (which would break things)

PulsarCluster:
  spec:
    broker:
      config: "{\"enableNonPersistentTopics\":false,\"brokerServicePort\":3333}"

It seems that there are quite a few configuration values that you would want the operator to explicitly control and not give someone the ability to change (like the brokerServicePort). Would it be better to declare all possible config values individually? Then the operator can be more obvious about what it supports and possibly override Pulsar's default values in a documentable way. Also, because there are so many config values, declaring them as one json string is error-prone and very hard to read.

There are many cases in pulsar components where K8s has external provisions (like Service ports and Ingress). Leaving config as a json string will put the operator in a place where it either A)is forced to silently overwrite values without telling anyone or B)hope that the person deploying doesn't decide to provide a bad value for certain things.

Logging

How/where would I set log4j values? Say I wanted to turn up logging on my bookies, where would I provide log4j.appender.CONSOLE.Threshold=DEBUG ?

Values decision tree

I am assuming that the operator assigns values in the following order:

1. individual component param
2. global param
3. pulsar default

Cert issuer

I'd like to offer a different way of thinking about a certificate issuer. Currently, there are provisions for self-signed using cert-manager or passwords to "Override the default secret name from where to load the certificates". But what if I wanted to use a different issuer (enterprise or letsencrypt or cloud-based)? Instead of being so explicit why not accept any Issuer or ClusterIssuer object in the operator? The the stack chart can have provisions for setting up a self-signed issuer and provide the object to the operator. That way the limiting factor is the use of cert-manager but the Issuer and its configuration is left to the person deploying this.

Consolidate TLS values

PulsarCluster.spec. PulsarCluster.spec.global.tls. PulsarCluster.spec.global.tls.certProvisioner.selfSigned.

Could there be some consolidation of values? Maybe each component has PulsarCluster.spec.<component>.tls and then there is a global PulsarCluster.spec.global.tls.

Helm charts

Having a helm chart for the operator and the stack seems redundant. How about removing the operator helm chart? So your options are to create a cluster using the operator resources directly kubectl apply PulsarCluster.yaml or create a cluster (with optional add-ons) with stack chart helm install my-cluster datastax/pulsar-stack -y values.yaml.

Documentation

Descriptions in the CRD are essential. There are so many different tools one can use to manage K8s objects, the CRD is the only common thread to guarantee a good experience. From there one would look to the operator repo which should have the API reference and some simple getting started commands/yaml. OperatorHub and ArtifactHub can point back to the repo. Then in Luna Streaming docs, we can provide deep knowledge about the operator, how it works, its benefits, and many examples/guides.