I am trying to deploy v2.0-rc that was released last week. I am reusing my cluster setup on which I could successfully run v2.0-beta before.
The component nifi currently is a show-stopper for me. I either run into case 1 or case 2 as described in the following.
Case 1: Enable nifi (default)
When trying to leave it enabled, I run into the following issue:
In civitas-core-deployment/components/nifi/values/nifi/base-values.yaml.gotmpl, line 69 an init container tries to curl a postgresql archive:
curl -fsSL -o /opt/nifi/drivers/postgresql.jar https://jdbc.postgresql.org/download/postgresql-42.7.4.jar
This is the culprit.
Problem 1
It does not respect my local HTTPS proxy settings. I had to add HTTPS_PROXY manually.
Problem 2
When initializing the pod, the init container simply fails with:
curl: (35) TLS connect error: error:00000000:lib(0)::reason(0)
Running curl in a debug pod with -v reports „unexpected eof while reading“
* Uses proxy env variable HTTPS_PROXY == '<http proxy>'
* Host <http proxy> was resolved.
* IPv6: (none)
* IPv4: <http proxy>
* Trying <http proxy>...
* CONNECT: no ALPN negotiated
* allocate connect buffer
* Establish HTTP proxy tunnel to jdbc.postgresql.org:443
> CONNECT jdbc.postgresql.org:443 HTTP/1.1
> Host: jdbc.postgresql.org:443
> User-Agent: curl/8.17.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.0 200 Connection Established
< date: Tue, 14 Jul 2026 07:18:00 GMT
<
* CONNECT phase completed
* CONNECT tunnel established, response 200
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [1565 bytes data]
* SSL Trust: peer verification disabled
} [5 bytes data]
* Send failure: Broken pipe
* TLSv1.3 (OUT), TLS alert, decode error (562):
} [2 bytes data]
* TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
* closing connection #0
curl: (35) Send failure: Broken pipe
and linkerd-proxy shows
WARN ThreadId(01) outbound:proxy{addr=<http proxy>}:forward{addr=<http proxy>}: linkerd_proxy_http::h1: A successful response to a CONNECT request had an incorrect HTTP version (expected HTTP/1.1, got HTTP/1.0)
In a fresh namespace without linkerd-annotation, the same curl command succeeds. As far as I can see my corporate HTTP(s) proxy anwers with HTTP/1.0 but I have to suspect linkerd-proxy is configured to only allow tunnels using HTTP/1.1?
Do you have any ideas how to explain this behaviour? Anything I could do to further investigate?
Some context (parts of deployment/environvments/local/global.yaml.gotmpl)
serviceMesh:
enable: true
type: linkerd
patchNamespaces: true
defaultInboundPolicy: audit
allowUnauthenticatedIngress: true
[...]
runtimePolicies:
enabled: true
failureAction: Audit
I disabled everything new in comparison to v2.0-beta.
Case 2: Disable nifi
Disabling nifi does not seem to be work at the moment either. In this case helmfile sync failes with
Building dependency release=config-adapters-adapters, chart=charts/config-adapter
in deployment/helmfile.yaml:
in .helmfiles[0]:
in ../helmfile-root.yaml.gotmpl:
in .helmfiles[0]:
in ./helmfile-components.yaml.gotmpl:
in .helmfiles[11]:
in components/config-adapters/helmfile.yaml.gotmpl:
failed processing release config-adapters-adapters:
failed to render values files "values/adapters/base-values.yaml.gotmpl":
failed to render [values/adapters/base-values.yaml.gotmpl], because of template:
stringTemplate:138:72: executing "stringTemplate" at <.Values.nifi.nifi.namespace>:
map has no entry for key "nifi"
Any help to get v2.0-rc up and running would be appreciated.