Allow customizing ingress type and pathType directly in the mattermost spec

[finda-yeongjo]

Original issue title: The server was deployed in a Kubernetes using an mattermost-operator and installation, but a 404 error is occurring.

Summary

The server was deployed in a Kubernetes using an mattermost-operator and installation, but a 404 error is occurring.

Steps to reproduce

1. Deploy mattermost-operator in AWS EKS (1.29)
2. deploy mattermost-installation with gitops(app of apps), argocd

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: mattermost-operator
  namespace: test
spec:
  project: test

  destination:
    server: https://kubernetes.default.svc
    namespace: mattermost-operator

  source:
    repoURL: https://helm.mattermost.com
    targetRevision: 1.0.1
    chart: mattermost-operator
    helm:
      values: |
        mattermostOperator:
          enabled: true
          replicas: 1
          rbac:
            create: true
          serviceAccount:
            create: true
          env:
            maxReconcilingInstallations: 20
            maxReconcilingConcurrency: 10
            requeuOnLimitDelay: 20s
          image:
            repository: mattermost/mattermost-operator
            tag: v1.21.0
            pullPolicy: IfNotPresent
          args:
            - --enable-leader-election
            - --metrics-addr=0.0.0.0:8383

          ## Specify image pull secret for private repository
          privateRegistry:
            enabled: false

apiVersion: installation.mattermost.com/v1beta1
kind: Mattermost
metadata:
  name: finda-mattermost 
  namespace: mattermost
spec:
  image: mattermost/mattermost-team-edition 
  imagePullPolicy: Always
  version: latest
  size: 1000users
  awsLoadBalancerController:
    enabled: true
    hosts: 
      - hostName: 'SOMETHING_YOUR_HOSTNAME'
    annotations:
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
      alb.ingress.kubernetes.io/ssl-redirect: '443'
      alb.ingress.kubernetes.io/load-balancer-name: SOMETHING_YOURS
      alb.ingress.kubernetes.io/group.name: SOMETHING_YOURS
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/scheme: internal
      alb.ingress.kubernetes.io/backend-protocol: HTTP
    certificateARN: SOMETHING_YOURS
    internetFacing: false
    ingressClassName: 'alb'
  mattermostEnv: 
    - name: MM_FILESETTINGS_AMAZONS3SSE
      value: "true"
    - name: MM_FILESETTINGS_AMAZONS3SSL
      value: "true"
  # licenseSecret: ""
  database:
    external:
      secret: db-secret
  fileStore:
    external:
      url: s3.amazonaws.com
      bucket: SOMETHING_YOUR_BUCKET
      secret: bucket-secret
  # elasticSearch:
  #   host: "" 
  #   username: ""
  #   password: "" 
#  volumeMounts: {}
#  volumes: {}
#  replicas: 1 according to it.
  # scheduling:
  #   resources: {} 
  #   nodeSelector: {}
  #   affinity: {}

Expected behavior

Deploy successful

Observed behavior (that appears unintentional)

1. Pod deploy success and health check success

2. There is no error logs

3.When accessing via the URL, a 404 error occurs.

Possible fixes

Since we are using the Mattermost container image, it is difficult to identify the issue at the code level.

[0arko]

i think i may have also ran into this issue. What do your listener rules look like? I had to manually edit the listener rule condition to accept '/*' as opposed to '/'. As this ingress is deployed via the Mattermost operator, after some time or a redeploy the listener rule reverts back and we see the 404 again. I still haven't worked out a way to specify the wildcard in the path via the Mattermost installation manifest file though...

[0arko]

is there a way to edit the path that the aws ingress controller uses via the mattermost installation?

[fmartingr]

is there a way to edit the path that the aws ingress controller uses via the mattermost installation?

Not at the moment, the path is static in the code.

[0arko]

thanks @fmartingr is there any chance this will be configurable any time soon? or at least made static to /* for instance

[finda-yeongjo]

If what @0arko said is correct, I request that @fmartingr modify the "pathType" of the Mattermost ingress to "Prefix."
Here are my ingress desire manifests that are working correctly and a capture of the current problematic Mattermost ingress. You will easily understand what I mean.

[fmartingr]

I'm not currently aware of the roadmap, but ideally we could allow customising the ingress in the Mattermost spec by adding the path and pathType fields. I'm going to update the issue title to reflect the actual issue. And of course pull requests are welcome.

[itaizelther]

@finda-yeongjo I'm facing this exact problem on the same stack. Have you found a fitting solution yet?

[itaizelther]

There is a workaround for anyone who tries to deploy the operator on AWS.
Disabling the operator self deployed ingress in the installation yaml:

ingress:
      enabled: false

and then applying a custom made ingress yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'
    alb.ingress.kubernetes.io/load-balancer-name: SOMETHING_YOURS
    alb.ingress.kubernetes.io/group.name: SOMETHING_YOURS
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/scheme: internal
    alb.ingress.kubernetes.io/backend-protocol: HTTP
  name: mattermost-ingress
  namespace: SOMETHING_YOUR_NAMESPACE
spec:
  ingressClassName: alb
  rules:
  - host: SOMETHING_YOUR_HOSTNAME
    http:
      paths:
      - backend:
          service:
            name: MATTERMOST_INSTALLATION
            port:
              number: 8065
        path: /
        pathType: Prefix

[finda-yeongjo]

@itaizelther

I used the same method as you.

I disabled the ingress activated in the operator,
and separately created and connected the ingress.

However, I think this way clearly does not meet the expectation of unified centralized management using the operator.