michaeljmarshall commented on issue #110:
URL:
https://github.com/apache/pulsar-helm-chart/issues/110#issuecomment-845501809
@sijie and @lhotari - what are your thoughts here? It'd be good to solve
this soon so that it doesn't affect end users when we release 2.8.0 soon.
I see a couple options.
1. We could add a value for the `targetPort` on the pulsar proxy service
where the `targetPort` defaults to `8080`. In this case, we could update the
template for the proxy service with a block like this:
```yaml
spec:
type: {{ .Values.proxy.service.type }}
ports:
{{- if or (not .Values.tls.enabled) (not .Values.tls.proxy.enabled)
}}
- name: http
port: {{ .Values.proxy.ports.http }}
targetPort: {{ .Values.proxy.ports.targetHttp }}
protocol: TCP
```
Then, we would open up the `targetHttp` port on the proxy container and
pod definition. This would be helpful because it'd be a seamless transition for
end users targeting the service. Technically, any users hitting the pods
directly would be affected by this breaking change. Although, I believe that
kind of direct interations is an anti-pattern within kubernetes, so I think we
could safely ignore that case. Further, the proxy's `PodMonitor` config is set
to hit the named port `http`, which would mean that it'd make the transition to
an arbitrary `targetPort` seamlessly. (I technically still need to double check
that this whole solution works. I'm pretty confident it will, but I'll need to
test before pushing up the PR.)
A major benefit to this solution is that it lets us support rootless
containers by default for our end users.
1. As I suggested in my earlier comment, we could default the Pulsar Proxy
container to run as the root user, and then let end users manage the upgrade
themselves. This solution seems more complicated to me, and it doesn't result
in a great experience for end users.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
