Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭 适合新手
  • 哪里不对？
#1,350 0 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@olivergondza 已经在做这个了。

开始于 2026年10月13日。

  • #1397 来自 @olivergondza —— 未关闭

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
75/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
go, kubernetes
领域
infrastructure

调研方向

问题位于 controllers/argocd/openshift/openshift.go 的 updateSystemCATrustBuilding() 中，其中构建 update-ca-certificates 初始化容器时没有设置 Resources 字段。请将它与 copyutil 初始化容器获取 spec.repo.resources 的方式进行比较，并检查上游 reconciler 中的 getArgoRepoResources(cr)。当 update-ca-certificates 容器具有与 spec.repo.resources 相同的 requests 和 limits 时即完成，可以使用第 3 步中的 jq 命令进行确认。

由索引模型根据 Issue 内容生成。

描述

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

主要语言
Go
星标
189
派生
365
平均合并
6 天 5 小时
30 天内合并 PR
44

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

redhat-developer/gitops-operator 的其他 Issue

查看 redhat-developer/gitops-operator 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。