Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta Adatta ai principianti
  • Qualcosa non va?
#1,350 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
75/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, kubernetes
Ambito
infrastructure

Direzione di ricerca

Il bug si trova in controllers/argocd/openshift/openshift.go, in updateSystemCATrustBuilding(), dove l'init container update-ca-certificates viene costruito senza un campo Resources. Confrontalo con il modo in cui l'init container copyutil riceve spec.repo.resources, e verifica getArgoRepoResources(cr) nel reconciler upstream. È completato quando il container update-ca-certificates ha gli stessi requests e limits di spec.repo.resources, cosa che puoi confermare con il comando jq del passaggio 3.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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-----..."

2. Deploy an ArgoCD instance with spec.repo.resources and spec.repo.systemCATrust
```yaml
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:
```json
{
  "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:        

```go
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).

Lingua principale
Go
Stelle
188
Fork
362
Merge medio
5g 4h
PR unite (30g)
27

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di redhat-developer/gitops-operator

Tutte le issue di redhat-developer/gitops-operator

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.