Chart needs a new Service in order to support calls

[Xnyle]

I patched this but obv. this could be done more elegantly

apiVersion: v1
kind: Service
metadata:
  name: mattermost-udp-service
  namespace: {{.Release.Namespace}}
spec:
  ports:
  - protocol: UDP
    name: udp-calls
    port: 8443
    targetPort: 8443
  type: LoadBalancer
  selector:
    app.kubernetes.io/instance: mattermost

[stafot]

Could you please elaborate more your proposal?

[baznikin]

@stafot Calls plugin required UDP port 8443 to be exposed - https://docs.mattermost.com/configure/calls-deployment.html
Separate mattermost-rtcd chart seems to do the job, but integrated processing with plugin not supported.
There is no way to expose mattermost UDP/8443 with mattermost-operator - nether operator create needed ports nor CRD for installation.mattermost.com support for additional ports declaration to expose it manually.

[Xnyle]

Operator (to me) seems like overkill. In my (simple) scenario I just needed to add the mentioned service.
Would be nice if that template just gets included and one could enable it via values.yaml.

[stafot]

Yes an additional service with a related flag to enable it on demand seems as reasonable proposal. Feel free to propose it in a pull request if you are in a rush.

[onpaws]

+1 would be great to add to the chart. Presumably since the Calls plugin is still in beta it should live behind a flag.

In my case I went with NodePort which is why I specified port 30001 in my manifest:

apiVersion: v1
kind: Service
metadata:
  name: mattermost-rtc-service
spec:
  ports:
  - nodePort: 30001
    port: 30001
    protocol: UDP
  selector:
    app.kubernetes.io/instance: mattermost ## should match the Helm name of your Mattermost deployment

Why 30001? It could be any port # so long as it complies with the rules of NodePorts.

In my view the main pro of NodePorts is that they are cloud provider agnostic and should be generally available; the con is running on a 'weird' port. Pro of LoadBalancer is that it works on default port 8443, but con is LoadBalancers are 1) not supported at every cloud provider and 2) where they are supported, they may not be free.

In testing I noticed that Mattermost clients appear to automatically load custom RTC port config from the server anyway, so a 'weird' port like 3000whatever may not matter anyway b/c it's not a user-facing detail.

[baznikin]

Actually RTC works for me by some magic; I see UTC traffic between my and node addresses and have no idea how it reach pod - there is no services and pod do not use host address. My best idea is 1) my machine send udp packet towards server, priecing my firewall and NAT and at same time 2) pod send UDP packet towards me, piercing nodes iptables (i.e. creating firewall state to pass traffic, so both sides create states in firewalls to pass traffic. For some network configurations such 'magic' isn't possible and some service needed. пт, 2 дек. 2022 г., 0:10 Pat ***@***.***>:

…

+1 would be great to add to the chart. Presumably since the Calls plugin is still in beta it should live behind a flag. In my case I went with NodePort <https://kubernetes.io/docs/concepts/services-networking/service/#nodeport-custom-port> which is why I specified port 30001 in my manifest: apiVersion: v1kind: Servicemetadata: name: mattermost-rtc-servicespec: ports: - nodePort: 30001 port: 30001 protocol: UDP selector: app.kubernetes.io/instance: mattermost ## should match the Helm name of your Mattermost deployment Why 30001? Because those are the rules <https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport> for NodePorts. In my view the main pro of NodePorts is that they are cloud provider agnostic and should be generally available; the con is running on a 'weird' port. Pro of LoadBalancer is that it works on default port 8443, but con is LoadBalancers are 1) not supported at every cloud provider and 2) where they are supported, they may not be free. In testing I noticed that Mattermost clients appear to automatically load custom RTC port config from the server anyway, so a 'weird' port like 3000whatever may not matter anyway b/c it's not a user-facing detail. — Reply to this email directly, view it on GitHub <#384 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHROZVCB2CUNU542NZLZDTWLEA4TANCNFSM6AAAAAASJ753W4> . You are receiving this because you commented.Message ID: ***@***.***>