Devin Bost

After I swapped out the brokerClient auth to use token auth instead of TLS auth in the broker-configmap.yaml and proxy-configmap.yaml files, the cluster started just fine. So, it seems that...

I added TLS debugging. (I forgot to tag this issue in the commit.)

It appears (from the debug logs) that the TLS session is established. The exception "Client unable to authenticate with TLS certificate" is thrown in AuthenticationProviderTls from this block: @Override public...

Just before the exception is thrown, it appears that the broker is successfully able to establish a TLS session with Zookeeper, but then it gives this odd message: ``` Inaccessible...

I tried changing all the certs to use CNs that match roles specified as superAdmin roles, but I can't get beyond the exception: ``` 20:26:40.155 [AsyncHttpClient-64-1] WARN org.apache.pulsar.client.admin.internal.BaseResource - [http://pulsar-ci-broker-0.pulsar-ci-broker.pulsar.svc.cluster.local:8080/admin/v2/persistent/public/functions/assignments]...

Here's a complete broker log. [brokerlogs.txt](https://github.com/apache/pulsar-helm-chart/files/5585412/brokerlogs.txt)

@gubespam I ended up putting this on the shelf to work on higher priority items, but I suspect it's a configuration issue.

@frankjkelly Doesn't that command wipe the bookie?

I found some change logs between draft-07 and 2020-12 that make it easier to see what has changed: [Draft-07 to Draft 2019-09](https://json-schema.org/draft/2019-09/release-notes.html) [Draft 2019-09 to Draft 2020-12](https://json-schema.org/draft/2020-12/release-notes.html)

What is the intent behind the `dataschema` field of CloudEvents? Is it just to validate the payload? I'm interested in a mechanism to distinguish between (1) validation of the payload,...