This message was deleted.

I also originally installed opni with grafana disabled and then tried enabling it after I had the other components working. In this case, should a grafana ingress have been auto-created for me?

We don't have any immediate plans to upgrade to v5. We tend to tread cautiously with grafana related things due to licensing issues with grafana. AFAIK you should be able to create an ingress without problems.

apiVersion: <http://networking.k8s.io/v1|networking.k8s.io/v1>
kind: Ingress
metadata:
  name: grafana
  namespace: opni
  annotations:
    <http://cert-manager.io/cluster-issuer|cert-manager.io/cluster-issuer>: letsencrypt-issuer
    <http://nginx.ingress.kubernetes.io/proxy-body-size|nginx.ingress.kubernetes.io/proxy-body-size>: 500m
spec:
  ingressClassName: nginx
  rules:
  - host: <http://hostname.example.com|hostname.example.com>
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: grafana-service
            port:
              number: 3000
  tls:
  - hosts:
    - <http://hostname.example.com|hostname.example.com>
    secretName: grafana-ingress

Here's an example ingress I have used without any problems

According to the code here and farther down in the grafana reconciler https://github.com/grafana-operator/grafana-operator/blob/70a9b41f3778cca532c749448ac67c82664b0f2e/controllers/grafana/grafana_reconciler.go#L222, it seems the grafana-operator wants to crud the ingress itself. Does the opni code execution path somehow bypass this code? In my environment my ingress which is similar to yours is autodeleted within 10 seconds of its creation.

So digging into the code the grafana operator is explicitly reconciling an ingress called

grafana-ingress

. As long as you call your ingress something else it shouldn't get touched.

Why not generate the CR the operator knows how to reconcile instead of writing your own controller variant and risking these types of unexpected side affects? Most examples happen to use this problematic name. The proposed workaround does not seem ideal to me.

We've largely stayed away from owning and configuring methods of traffic ingress (whether ingresses or some other mechanism) because they're typically bespoke and there's generally quite a lot of variation depending on the environment, but this is something we can review after GA.

Understood. For now, you might either document the requirement to not use the

grafana-ingress

name or implement a simple validating admission webhook that errors if an invalidly-named ingress is created in the opni namespace. Should I open an issue to track this problem?