Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン 初心者向け
  • 何か問題がありますか？
#1,350 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
75/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go, kubernetes
領域
infrastructure

調査の方向性

バグは controllers/argocd/openshift/openshift.go の updateSystemCATrustBuilding() にあります。ここでは update-ca-certificates の init container が Resources フィールドなしで作成されています。copyutil の init container が 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-----..."

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

主要言語
Go
スター
188
フォーク
362
平均マージ
5日 4時間
マージ済み PR（30日）
27

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

redhat-developer/gitops-operator のほかの issue

redhat-developer/gitops-operator の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。