Closed NickLarsenNZ closed 1 week ago
On the first run of trino-operator getting_started it timed-out. ~I'll treat it as a transient error, but recording it here in case we see it more often in future.~
waiting for ephemeral volume controller to create the persistentvolumeclaim "simple-trino-coordinator-default-0-server-tls-mount". preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.
While the pods are still waiting for a volume, I can see the PVC has been created and is bound to a PV.
The two in red are waiting on volume provisioning, ~so I think this is the usual KinD takes a while to provision volumes issue~.
(ignore the Age values, the screenshot was taken on a separate run, and the pods were still waiting)
Edit: Works for other people, so it seems to be a local issue.
As we are now using the listener, port 9093 is exposed instead of 9092. The broker reports:
Failed authentication with /127.0.0.1 (channelId=127.0.0.1:9093-127.0.0.1:32822-112) (SSL handshake failed)
(Although the kafka.yaml does not enforce client-server TLS).
I have tested the HBase getting-started without https://github.com/stackabletech/hbase-operator/issues/508 as it seems it won't make the release.
If https://github.com/stackabletech/hbase-operator/issues/508 is merged, the getting_started test needs doing.
Pre-Release Getting Started Script Updates
Part of https://github.com/stackabletech/issues/issues/647
In each operator repository, run the following commands. If any updates are required, open a PR using the applicable link below.
Replace the items in the task lists below with the applicable Pull Requests (if any).