Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

bug(repo-server): update-ca-certificates init container does not inherit spec.repo.resources

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#1,350 0 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@olivergondza arbeitet bereits daran.

Seit 13.10.2026.

  • #1397 von @olivergondza — offen

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
75/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
go, kubernetes
Bereich
infrastructure

Rechercherichtung

Der Fehler steckt in controllers/argocd/openshift/openshift.go, in updateSystemCATrustBuilding(), wo der Init-Container update-ca-certificates ohne ein Resources-Feld erstellt wird. Vergleiche ihn damit, wie der Init-Container copyutil spec.repo.resources übernimmt, und prüfe getArgoRepoResources(cr) im Upstream-Reconciler. Fertig ist es, wenn der Container update-ca-certificates dieselben requests und limits wie spec.repo.resources trägt, was du mit dem jq-Befehl aus Schritt 3 bestätigen kannst.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Describe the bug
When configuring custom CA trust via spec.repo.systemCATrust on an ArgoCD resource, the operator injects an init container named update-ca-certificates into the argocd-repo-server pod. However, this init container is created with empty compute resources (resources: {}), even when spec.repo.resources (requests and limits) is explicitly defined in the CR.

This causes pod admission failures in namespaces governed by strict ResourceQuota policies requiring explicit CPU/memory requests and limits.

To Reproduce
Steps to reproduce the behavior:

  1. Create a namespace and a ConfigMap containing a custom CA certificate:
oc create configmap custom-ca --from-literal=ca.crt="-----BEGIN CERTIFICATE-----..."
  1. Deploy an ArgoCD instance with spec.repo.resources and spec.repo.systemCATrust
apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd-sample
spec:
  repo:
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 512Mi
    systemCATrust:
      configMaps:
        - name: custom-ca
  1. inspect the resulting repo-server deployment's init containers
oc get deployment argocd-sample-repo-server -o json | jq '.spec.template.spec.initContainers[] | {name: .name, resources: .resources}'

4, See error/output:

{
  "name": "copyutil",
  "resources": {
    "limits": { "cpu": "500m", "memory": "512Mi" },
    "requests": { "cpu": "100m", "memory": "128Mi" }
  }
}
{
  "name": "update-ca-certificates",
  "resources": {}
}

Expected behavior The update-ca-certificates init container should inherit spec.repo.resources (requests and limits) identically to how copyutil inherits them and how upstream argocd-operator implements it via getArgoRepoResources(cr).

Screenshots N/A

Additional context

Root cause: In PR #987 (controllers/argocd/openshift/openshift.go), the downstream reconciler hook updateSystemCATrustBuilding() drops the upstream update-ca-certificates container to replace it with a RHEL-native container, but omits setting Resources on the new corev1.Container definition:

initContainer := corev1.Container{
    Name:            "update-ca-certificates",
    Image:           prodImage,
    SecurityContext: argoutil.DefaultSecurityContext(),
    VolumeMounts:    ...,
    Command:         ...,
    Args:            ...,
    // Missing: Resources field
}

Impact:
In environments with a ResourceQuota requiring resource limits/requests, the API server rejects pod creation with: failed quota: ...: must specify limits.cpu,limits.memory,requests.cpu,requests.memory for: update-ca-certificates.

Environment: Reproduced on OpenShift GitOps Operator v1.22.1 (introduced in v1.20.0 with PR #987).

Vorherrschende Sprache
Go
Sterne
188
Forks
362
Ø Merge
6 T. 5 Std.
Gemergte PRs (30 T.)
44

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus redhat-developer/gitops-operator

Alle Issues in redhat-developer/gitops-operator

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.