Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto Apto para principiantes
#1,350 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@olivergondza ya está trabajando en esto.

Desde el 13/10/2026.

  • #1397 de @olivergondza — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
75/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go, kubernetes

Línea de trabajo

El error está en controllers/argocd/openshift/openshift.go, en updateSystemCATrustBuilding(), donde el init container update-ca-certificates se construye sin un campo Resources. Compáralo con la forma en que el init container copyutil recibe spec.repo.resources, y revisa getArgoRepoResources(cr) en el reconciler upstream. Está terminado cuando el contenedor update-ca-certificates tenga los mismos requests y limits que spec.repo.resources, lo que puedes confirmar con el comando jq del paso 3.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Go
Estrellas
188
Forks
362
Merge medio
6 d 5 h
PR fusionados (30 d)
44

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de redhat-developer/gitops-operator

Todos los issues de redhat-developer/gitops-operator

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.