pulp / pulp/pulp-operator

ingress_annotations does not propagate from Pulp CR to created Ingress resource.

Open
#1,398 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Issue
Dominant language
Go
Stars
88
Forks
66
Avg merge
53m
Merged PRs (30d)
1

Description

Version
pulp-operator-0.1.0
1.0.1-beta.4 - installed using helm.

Describe the bug
ingress_annotations does not pass to ingress object.
I try to add some ingress annotations like enable_cors and other annotations.
According to the code it should be passed down to the ingress resource generated by pulp operator.
I do see the annotations i pass in the CR are passed to the spec.ingress_annotations, for example:

apiVersion: repo-manager.pulpproject.org/v1beta2
kind: Pulp
...
spec:
...
  ingress_annotations:
    cert-manager.io/cluster-issuer: letsencrypt-dynu-cluster-issuer-prod
    kubernetes.io/ingress.class: pulp04-access-nginx-ingress
    nginx.ingress.kubernetes.io/cors-allow-headers: Content-Type, Authorization
    nginx.ingress.kubernetes.io/cors-allow-methods: PUT, GET, POST, OPTIONS
    nginx.ingress.kubernetes.io/cors-allow-origin: http://localhost:8002
    nginx.ingress.kubernetes.io/enable-cors: "true"

But when i look at the created ingress i don't see the values i passed, for example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: 120s
    nginx.ingress.kubernetes.io/proxy-read-timeout: 120s
    nginx.ingress.kubernetes.io/proxy-send-timeout: 120s
    nginx.org/client-max-body-size: 4096m
    web: "false"
  labels:
    app.kubernetes.io/managed-by: pulp-operator
    app.kubernetes.io/part-of: pulp
    pulp_cr: pulp04
  name: pulp04
  namespace: pulp
  ownerReferences:
  - apiVersion: repo-manager.pulpproject.org/v1beta2
    blockOwnerDeletion: true
    controller: true
    kind: Pulp
    name: pulp04
    uid: 3cb2176f-cf72-460d-af69-d67169e96988
  resourceVersion: "249382"

from this part of the code

I see that the annotations assingment code is there but it is not working.

Additionally i can see that if i try to patch the ingress myself the operator will "fix" it and override my settings, for example:

kubectl patch -n pulp ingress pulp04 --type=merge -p '{"metadata": { "annotations": { "nginx.ingress.kubernetes.io/cors-allow-origin": "http://localhost:8002" } }}'
ingress.networking.k8s.io/pulp04 patched

kubectl get -n pulp ingress pulp04 -oyaml 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/cors-allow-origin: http://localhost:8002

In the operator log i can see that it detected the change and "fixed" it:

controllers/utils.go:651        The Metadata from pulp resource pulp04 has been modified! Reconciling ...

What i'm trying to do is adding CORS headers so i can connect from the pulp-ui to my pulp instance, but i have to enable these annotations to be able to connect.

To Reproduce
Try to add spec.ingress_annotations to pulp resource and see that it is passed to the created ingress instance.

Expected behavior
I expect all annotations defined on the pulp instance will be propagated to the Ingress instance created.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in controllers/repo_manager/ingress.go at the annotation assignment around lines 263-272, then reproduce the issue by setting spec.ingress_annotations on a Pulp resource and inspecting the created Ingress. Trace reconciliation after the Ingress is patched and verify that the configured annotations persist on the generated resource.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes, nginx
Domain
infrastructure, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.