Skip to content

KFLUXINFRA-3695 Install Kueue v1.3 on internal-production#341

Open
manish-jangra wants to merge 3 commits into
redhat-appstudio:mainfrom
manish-jangra:KFLUXINFRA-3695
Open

KFLUXINFRA-3695 Install Kueue v1.3 on internal-production#341
manish-jangra wants to merge 3 commits into
redhat-appstudio:mainfrom
manish-jangra:KFLUXINFRA-3695

Conversation

@manish-jangra

@manish-jangra manish-jangra commented May 8, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Install Kueue on the internal-production cluster using stable-v1.3 channel with v1beta2 CRD apiVersions
  • Fix tekton-kueue sync wave ordering (wave 10 → 12) for both internal-staging and internal-production

Context

Kueue has never been installed on the internal-production cluster. This PR introduces a fresh installation at v1.3.1, aligned with the staging deployment.

Related PRs

PR Description Status
#344 Remove Kueue staging resources (teardown for v1.3 upgrade) Merged
#342 Install Kueue v1.3 on internal-staging (fresh reinstall) Merged
#343 Add CI to validate tekton-kueue CEL expressions Open
#340 Simplify to FIFO scheduling for signing pipelines Merged
#337 Add signing-server resource quota and CEL resource request Merged

Changes

Production install (new files)

  • kueue/ — Namespace, CatalogSource (v4.18 index), OperatorGroup, Subscription (stable-v1.3), Kueue CR with Tekton PipelineRun framework
  • queue-config/ — ClusterQueue (cluster-pipeline-queue) with signing-server-request resource + WorkloadPriorityClass (v1beta2)
  • localqueues/ — LocalQueue (pipelines-queue) in internal-services namespace (v1beta2)
  • tekton-kueue/ — Controller (2 replicas) and webhook (3 replicas) with topology spread, resource limits, and leader election tuning

Sync wave fix (both environments)

tekton-kueue sync wave moved from 10 → 12 so it deploys after LocalQueue (wave 11), preventing a race where the webhook starts before pipelines-queue exists.

Sync wave ordering

Wave Component Purpose
-4 to -1 kueue/ Namespace, CatalogSource, OperatorGroup, Subscription
1 Kueue CR Operator instance
10 queue-config/ ClusterQueue, ResourceFlavor, WorkloadPriorityClass
11 localqueues/ LocalQueue in internal-services
12 tekton-kueue/ Controller + webhook (must deploy after LocalQueue)

Note

Both environments are kept independent (no shared base overlay) to allow independent tuning — per team agreement.

@openshift-ci

openshift-ci Bot commented May 8, 2026

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: manish-jangra

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci Bot added the approved label May 8, 2026
@qodo-code-review

Copy link
Copy Markdown

Review Summary by Qodo

Add Kueue configuration for internal-production cluster

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Deploy Kueue operator with CatalogSource, Subscription, and Kueue CR
• Configure ClusterQueue with BestEffortFIFO and resource quotas
• Set up tekton-kueue controller and webhook with HA configuration
• Add LocalQueue and WorkloadPriorityClass for queue-based scheduling
• Implement CEL expressions for priority assignment and rate-limiting
Diagram
flowchart LR
  A["Kueue Operator<br/>CatalogSource v4.18"] --> B["Kueue CR<br/>Managed State"]
  B --> C["ClusterQueue<br/>cluster-pipeline-queue"]
  C --> D["LocalQueue<br/>pipelines-queue"]
  D --> E["tekton-kueue<br/>Controller & Webhook"]
  C --> F["ResourceFlavor<br/>default-flavor"]
  E --> G["CEL Expressions<br/>Priority & Rate-limiting"]
Loading

Grey Divider

File Changes

1. components/kueue/internal-production/kueue/operator.yaml ⚙️ Configuration changes +47/-0

Kueue operator installation with CatalogSource and Subscription

components/kueue/internal-production/kueue/operator.yaml


2. components/kueue/internal-production/kueue/kueue.yaml ⚙️ Configuration changes +21/-0

Kueue CR with Tekton PipelineRun framework integration

components/kueue/internal-production/kueue/kueue.yaml


3. components/kueue/internal-production/kueue/kustomization.yaml ⚙️ Configuration changes +7/-0

Kustomization for Kueue operator namespace resources

components/kueue/internal-production/kueue/kustomization.yaml


View more (10)
4. components/kueue/internal-production/queue-config/cluster-queue.yaml ⚙️ Configuration changes +30/-0

ClusterQueue with BestEffortFIFO and resource quotas

components/kueue/internal-production/queue-config/cluster-queue.yaml


5. components/kueue/internal-production/queue-config/workload-priority-class.yaml ⚙️ Configuration changes +7/-0

WorkloadPriorityClass for default pipeline priority

components/kueue/internal-production/queue-config/workload-priority-class.yaml


6. components/kueue/internal-production/queue-config/kustomization.yaml ⚙️ Configuration changes +8/-0

Kustomization for queue configuration resources

components/kueue/internal-production/queue-config/kustomization.yaml


7. components/kueue/internal-production/localqueues/internal-services.yaml ⚙️ Configuration changes +10/-0

LocalQueue for internal-services namespace pipelines

components/kueue/internal-production/localqueues/internal-services.yaml


8. components/kueue/internal-production/localqueues/kustomization.yaml ⚙️ Configuration changes +9/-0

Kustomization for LocalQueue resources

components/kueue/internal-production/localqueues/kustomization.yaml


9. components/kueue/internal-production/tekton-kueue/config.yaml ⚙️ Configuration changes +13/-0

CEL expressions for priority and rate-limiting logic

components/kueue/internal-production/tekton-kueue/config.yaml


10. components/kueue/internal-production/tekton-kueue/controller-patch.yaml ⚙️ Configuration changes +49/-0

HA patches for tekton-kueue controller deployment

components/kueue/internal-production/tekton-kueue/controller-patch.yaml


11. components/kueue/internal-production/tekton-kueue/webhook-patch.yaml ⚙️ Configuration changes +41/-0

HA patches for tekton-kueue webhook deployment

components/kueue/internal-production/tekton-kueue/webhook-patch.yaml


12. components/kueue/internal-production/tekton-kueue/kustomization.yaml ⚙️ Configuration changes +46/-0

Kustomization for tekton-kueue with patches and config

components/kueue/internal-production/tekton-kueue/kustomization.yaml


13. components/kueue/internal-production/kustomization.yaml ⚙️ Configuration changes +11/-0

Root kustomization for internal-production Kueue overlay

components/kueue/internal-production/kustomization.yaml


Grey Divider

Qodo Logo

@qodo-code-review

qodo-code-review Bot commented May 8, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (2)

Context used

Grey Divider


Action required

1. config.yaml missing in base 📎 Requirement gap ⚙ Maintainability ⭐ New
Description
The PR adds config.yaml only within the environment-specific tekton-kueue directory rather than
providing the required placeholder within components/kueue/base/tekton-kueue/. This prevents the
base component from packaging the placeholder for future CEL rule configuration.
Code

components/kueue/internal-production/tekton-kueue/kustomization.yaml[R17-23]

+configMapGenerator:
+- name: tekton-kueue-config
+  namespace: tekton-kueue
+  behavior: replace
+  files:
+  - config.yaml
+
Evidence
PR Compliance ID 2 requires a config.yaml placeholder within the base tekton-kueue component and
that it be included via kustomize. The PR only generates tekton-kueue-config from config.yaml
inside the internal-production tekton-kueue directory, not the required base component path.

Provide config.yaml placeholder for future CEL rules
components/kueue/internal-production/tekton-kueue/kustomization.yaml[17-23]
components/kueue/internal-production/tekton-kueue/config.yaml[1-13]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`config.yaml` exists only in the environment-specific tekton-kueue directory, but compliance requires a placeholder `config.yaml` to live inside the base tekton-kueue component and be packaged by that component's kustomization.

## Issue Context
The placeholder is required so future CEL rules can be added by updating the base component used by multiple overlays.

## Fix Focus Areas
- components/kueue/internal-production/tekton-kueue/kustomization.yaml[17-23]
- components/kueue/internal-production/tekton-kueue/config.yaml[1-13]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. tekton-kueue base component missing 📎 Requirement gap ⚙ Maintainability
Description
The PR adds tekton-kueue manifests only under the internal-production overlay (via a remote
upstream resource) but does not create the required reusable base at
components/kueue/base/tekton-kueue/. This fails the checklist requirement for a pinned, shared
base component derived from upstream config/default.
Code

components/kueue/internal-production/tekton-kueue/kustomization.yaml[R4-6]

+resources:
+- https://github.com/konflux-ci/tekton-kueue/config/default?ref=815dbf158b0e39df568eb901dcf05e759099991a
+
Evidence
PR Compliance ID 1 requires a new base component at components/kueue/base/tekton-kueue/, but the
PR introduces tekton-kueue configuration directly in the internal-production overlay by
referencing the upstream config/default URL instead of providing the required base
directory/component.

Create tekton-kueue base component from pinned upstream config
components/kueue/internal-production/tekton-kueue/kustomization.yaml[4-6]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR does not add the required base component at `components/kueue/base/tekton-kueue/` derived from the pinned upstream `config/default` manifests; it only adds an environment-specific overlay.

## Issue Context
Compliance requires a reusable base component (pinned to a specific ref) so that staging/production overlays can share the same upstream-derived manifests while allowing overlay-specific tuning.

## Fix Focus Areas
- components/kueue/internal-production/tekton-kueue/kustomization.yaml[4-6]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Webhook before LocalQueue ✓ Resolved 🐞 Bug ☼ Reliability
Description
tekton-kueue is synced at ArgoCD wave 10 while the LocalQueue it is configured to use
(pipelines-queue) is synced at wave 11, so the webhook/controller can become active before the queue
exists and reject/skip queueing PipelineRuns during rollout.
Code

components/kueue/internal-production/tekton-kueue/kustomization.yaml[R14-16]

+commonAnnotations:
+  argocd.argoproj.io/sync-wave: "10"
+
Evidence
tekton-kueue resources are annotated to sync at wave 10, but LocalQueues are annotated to sync at
wave 11. Since tekton-kueue is configured with queueName: pipelines-queue, there is a real
dependency on the LocalQueue existing before the webhook starts processing PipelineRuns.

components/kueue/internal-production/tekton-kueue/kustomization.yaml[14-16]
components/kueue/internal-production/localqueues/kustomization.yaml[6-9]
components/kueue/internal-production/tekton-kueue/config.yaml[1-13]
components/kueue/internal-production/localqueues/internal-services.yaml[1-10]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`tekton-kueue` can become ready (wave 10) before the `pipelines-queue` LocalQueue is created (wave 11). During that window the admission webhook/controller may not find the expected LocalQueue and can reject or fail to enqueue PipelineRuns.

### Issue Context
- tekton-kueue is configured to use `queueName: pipelines-queue`.
- LocalQueue creation currently happens in a later ArgoCD sync wave.

### Fix Focus Areas
- components/kueue/internal-production/tekton-kueue/kustomization.yaml[14-16]
- components/kueue/internal-production/localqueues/kustomization.yaml[6-9]

### Suggested change
Move tekton-kueue to a later sync-wave than LocalQueues (e.g., set tekton-kueue to wave 12), or move LocalQueues earlier so they are created before tekton-kueue starts intercepting PipelineRuns.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

4. Namespace ordering dependency 🐞 Bug ☼ Reliability
Description
The LocalQueue is created in the internal-services namespace, but the kueue ApplicationSet doesn’t
create namespaces; cluster bootstrap can leave this LocalQueue out-of-sync until the separate
internal-services ApplicationSet creates the namespace.
Code

components/kueue/internal-production/localqueues/internal-services.yaml[R4-9]

+metadata:
+  name: pipelines-queue
+  namespace: internal-services
+  annotations:
+    argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true
+spec:
Evidence
The LocalQueue manifest targets namespace: internal-services, but the kueue ApplicationSet does
not use CreateNamespace=true. Namespace creation for internal-services is handled by a different
ApplicationSet, and there is no explicit ordering between these ApplicationSets, so on
fresh/bootstrap syncs the LocalQueue can fail to apply until the namespace exists.

components/kueue/internal-production/localqueues/internal-services.yaml[4-10]
argo-cd-apps/base/internal/kueue/appset.yaml[1-33]
argo-cd-apps/base/internal/internal-services/appset.yaml[13-33]
argo-cd-apps/base/internal/kustomization.yaml[1-16]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`LocalQueue/pipelines-queue` is applied into `internal-services`, but the kueue ArgoCD ApplicationSet doesn’t create namespaces. On cluster bootstrap, this can cause sync failures until the internal-services ApplicationSet has created the namespace.

### Issue Context
Namespace creation for `internal-services` is owned by the internal-services ApplicationSet (it sets `CreateNamespace=true`). The kueue ApplicationSet does not, and there is no explicit ordering guarantee between the two ApplicationSets.

### Fix Focus Areas
- components/kueue/internal-production/localqueues/internal-services.yaml[4-10]
- argo-cd-apps/base/internal/kueue/appset.yaml[20-33]
- argo-cd-apps/base/internal/internal-services/appset.yaml[21-30]

### Suggested change
Choose one:
1) Move/manage the LocalQueue manifest under the internal-services component so it’s applied by the same app that creates the namespace, or
2) Add an `internal-services` Namespace manifest in the kueue component (only if ownership won’t conflict), or
3) Add explicit ArgoCD app/appset ordering (e.g., sync-wave annotations at the Application/ApplicationSet level) so internal-services creates the namespace before kueue applies the LocalQueue.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Previous review results

Review updated until commit 6811469

Results up to commit 71ff9dd


🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (1)


Action required
1. tekton-kueue base component missing 📎 Requirement gap ⚙ Maintainability
Description
The PR adds tekton-kueue manifests only under the internal-production overlay (via a remote
upstream resource) but does not create the required reusable base at
components/kueue/base/tekton-kueue/. This fails the checklist requirement for a pinned, shared
base component derived from upstream config/default.
Code

components/kueue/internal-production/tekton-kueue/kustomization.yaml[R4-6]

+resources:
+- https://github.com/konflux-ci/tekton-kueue/config/default?ref=815dbf158b0e39df568eb901dcf05e759099991a
+
Evidence
PR Compliance ID 1 requires a new base component at components/kueue/base/tekton-kueue/, but the
PR introduces tekton-kueue configuration directly in the internal-production overlay by
referencing the upstream config/default URL instead of providing the required base
directory/component.

Create tekton-kueue base component from pinned upstream config
components/kueue/internal-production/tekton-kueue/kustomization.yaml[4-6]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR does not add the required base component at `components/kueue/base/tekton-kueue/` derived from the pinned upstream `config/default` manifests; it only adds an environment-specific overlay.

## Issue Context
Compliance requires a reusable base component (pinned to a specific ref) so that staging/production overlays can share the same upstream-derived manifests while allowing overlay-specific tuning.

## Fix Focus Areas
- components/kueue/internal-production/tekton-kueue/kustomization.yaml[4-6]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Webhook before LocalQueue ✓ Resolved 🐞 Bug ☼ Reliability
Description
tekton-kueue is synced at ArgoCD wave 10 while the LocalQueue it is configured to use
(pipelines-queue) is synced at wave 11, so the webhook/controller can become active before the queue
exists and reject/skip queueing PipelineRuns during rollout.
Code

components/kueue/internal-production/tekton-kueue/kustomization.yaml[R14-16]

+commonAnnotations:
+  argocd.argoproj.io/sync-wave: "10"
+
Evidence
tekton-kueue resources are annotated to sync at wave 10, but LocalQueues are annotated to sync at
wave 11. Since tekton-kueue is configured with queueName: pipelines-queue, there is a real
dependency on the LocalQueue existing before the webhook starts processing PipelineRuns.

components/kueue/internal-production/tekton-kueue/kustomization.yaml[14-16]
components/kueue/internal-production/localqueues/kustomization.yaml[6-9]
components/kueue/internal-production/tekton-kueue/config.yaml[1-13]
components/kueue/internal-production/localqueues/internal-services.yaml[1-10]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`tekton-kueue` can become ready (wave 10) before the `pipelines-queue` LocalQueue is created (wave 11). During that window the admission webhook/controller may not find the expected LocalQueue and can reject or fail to enqueue PipelineRuns.

### Issue Context
- tekton-kueue is configured to use `queueName: pipelines-queue`.
- LocalQueue creation currently happens in a later ArgoCD sync wave.

### Fix Focus Areas
- components/kueue/internal-production/tekton-kueue/kustomization.yaml[14-16]
- components/kueue/internal-production/localqueues/kustomization.yaml[6-9]

### Suggested change
Move tekton-kueue to a later sync-wave than LocalQueues (e.g., set tekton-kueue to wave 12), or move LocalQueues earlier so they are created before tekton-kueue starts intercepting PipelineRuns.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended
3. Namespace ordering dependency 🐞 Bug ☼ Reliability
Description
The LocalQueue is created in the internal-services namespace, but the kueue ApplicationSet doesn’t
create namespaces; cluster bootstrap can leave this LocalQueue out-of-sync until the separate
internal-services ApplicationSet creates the namespace.
Code

components/kueue/internal-production/localqueues/internal-services.yaml[R4-9]

+metadata:
+  name: pipelines-queue
+  namespace: internal-services
+  annotations:
+    argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true
+spec:
Evidence
The LocalQueue manifest targets namespace: internal-services, but the kueue ApplicationSet does
not use CreateNamespace=true. Namespace creation for internal-services is handled by a different
ApplicationSet, and there is no explicit ordering between these ApplicationSets, so on
fresh/bootstrap syncs the LocalQueue can fail to apply until the namespace exists.

components/kueue/internal-production/localqueues/internal-services.yaml[4-10]
argo-cd-apps/base/internal/kueue/appset.yaml[1-33]
argo-cd-apps/base/internal/internal-services/appset.yaml[13-33]
argo-cd-apps/base/internal/kustomization.yaml[1-16]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`LocalQueue/pipelines-queue` is applied into `internal-services`, but the kueue ArgoCD ApplicationSet doesn’t create namespaces. On cluster bootstrap, this can cause sync failures until the internal-services ApplicationSet has created the namespace.

### Issue Context
Namespace creation for `internal-services` is owned by the internal-services ApplicationSet (it sets `CreateNamespace=true`). The kueue ApplicationSet does not, and there is no explicit ordering guarantee between the two ApplicationSets.

### Fix Focus Areas
- components/kueue/internal-production/localqueues/internal-services.yaml[4-10]
- argo-cd-apps/base/internal/kueue/appset.yaml[20-33]
- argo-cd-apps/base/internal/internal-services/appset.yaml[21-30]

### Suggested change
Choose one:
1) Move/manage the LocalQueue manifest under the internal-services component so it’s applied by the same app that creates the namespace, or
2) Add an `internal-services` Namespace manifest in the kueue component (only if ownership won’t conflict), or
3) Add explicit ArgoCD app/appset ordering (e.g., sync-wave annotations at the Application/ApplicationSet level) so internal-services creates the namespace before kueue applies the LocalQueue.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Qodo Logo

Comment on lines +4 to +6
resources:
- https://github.com/konflux-ci/tekton-kueue/config/default?ref=815dbf158b0e39df568eb901dcf05e759099991a

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Tekton-kueue base component missing 📎 Requirement gap ⚙ Maintainability

The PR adds tekton-kueue manifests only under the internal-production overlay (via a remote
upstream resource) but does not create the required reusable base at
components/kueue/base/tekton-kueue/. This fails the checklist requirement for a pinned, shared
base component derived from upstream config/default.
Agent Prompt
## Issue description
The PR does not add the required base component at `components/kueue/base/tekton-kueue/` derived from the pinned upstream `config/default` manifests; it only adds an environment-specific overlay.

## Issue Context
Compliance requires a reusable base component (pinned to a specific ref) so that staging/production overlays can share the same upstream-derived manifests while allowing overlay-specific tuning.

## Fix Focus Areas
- components/kueue/internal-production/tekton-kueue/kustomization.yaml[4-6]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The agreement within team is not to use shared overlay like base due to some past experiences.

Comment thread components/kueue/internal-production/kueue/operator.yaml Outdated
@manish-jangra

Copy link
Copy Markdown
Contributor Author

/review

@qodo-code-review

qodo-code-review Bot commented May 11, 2026

Copy link
Copy Markdown

PR Reviewer Guide 🔍

Warning

/review is deprecated. Use /agentic_review instead (removed after 2026-05-31).

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶

KFLUXINFRA-3695 - Partially compliant

Compliant requirements:

  • Deploy to tekton-kueue namespace.
  • Include in both staging and production overlays.

Non-compliant requirements:

  • Create components/kueue/base/tekton-kueue/ deploying from https://github.com/konflux-ci/tekton-kueue/tree/main/config/default (pinned ref).
  • Add config.yaml placeholder for CEL rules (to be configured later).

Requires further human verification:

  • tekton-kueue webhook is deployed and healthy on internal-staging.
  • tekton-kueue webhook is deployed and healthy on internal-production.
  • kustomize build passes for both overlays.
  • Deploy the tekton-kueue webhook on internal common clusters (staging and production) to intercept PipelineRun creation and integrate with Kueue for admission control.
⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

CEL Logic

Validate the CEL expressions behavior: the first expression sets a priority unconditionally, while the second conditionally requests signing-server-request. Confirm the CEL environment supports priority('konflux-default') as written and that the label checks match the exact labels applied to production PipelineRuns; otherwise admissions may not request resources as intended.

queueName: pipelines-queue
cel:
  expressions:
    - |
        priority('konflux-default')

    - |
        has(pipelineRun.metadata.labels) &&
        'internal-services.appstudio.openshift.io/rate-limited' in pipelineRun.metadata.labels &&
        pipelineRun.metadata.labels['internal-services.appstudio.openshift.io/rate-limited'] == 'true' &&
        'internal-services.appstudio.openshift.io/rate-limiting-group' in pipelineRun.metadata.labels &&
        pipelineRun.metadata.labels['internal-services.appstudio.openshift.io/rate-limiting-group'] == 'signing-server' ?
        [resource('signing-server-request', 1)] : []
Queue Semantics

Confirm the ClusterQueue resource model is correct: coveredResources includes tekton.dev/pipelineruns and signing-server-request with nominal quotas of 500 each. Ensure signing-server-request is a valid resource recognized by Kueue in this cluster and that namespaceSelector: {} is intended (it effectively allows all namespaces to use the queue unless restricted elsewhere).

---
apiVersion: kueue.x-k8s.io/v1beta2
kind: ResourceFlavor
metadata:
  name: default-flavor
---
apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
  name: cluster-pipeline-queue
spec:
  namespaceSelector: {}
  queueingStrategy: BestEffortFIFO
  preemption:
    borrowWithinCohort:
      policy: Never
    reclaimWithinCohort: Never
    withinClusterQueue: Never
  resourceGroups:
  - coveredResources:
    - tekton.dev/pipelineruns
    - signing-server-request
    flavors:
    - name: default-flavor
      resources:
      - name: tekton.dev/pipelineruns
        nominalQuota: '500'
      - name: signing-server-request
        nominalQuota: '500'
  stopPolicy: None
OLM Source

The CatalogSource uses registry.redhat.io/redhat/redhat-operator-index:v4.18 and is named redhat-operators-1-18. Verify this is the desired catalog for the target OpenShift version and that mirroring/connected-registry requirements are satisfied; otherwise the Subscription may not resolve or may resolve unexpected bundle versions.

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-kueue-operator
  labels:
    openshift.io/cluster-monitoring: "true"
  annotations:
    argocd.argoproj.io/sync-wave: "-4"
---
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  annotations:
    argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true
    argocd.argoproj.io/sync-wave: "-3"
  name: redhat-operators-1-18
  namespace: openshift-kueue-operator
spec:
  displayName: redhat-operators-1-18
  image: registry.redhat.io/redhat/redhat-operator-index:v4.18
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 30m
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-kueue-operatorgroup
  annotations:
    argocd.argoproj.io/sync-wave: "-2"
spec: {}
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-kueue-operator
  namespace: openshift-kueue-operator
  annotations:
    argocd.argoproj.io/sync-wave: "-1"
spec:
  channel: stable-v1.3
  installPlanApproval: Automatic
  name: kueue-operator
  source: redhat-operators-1-18
  sourceNamespace: openshift-kueue-operator

@manish-jangra manish-jangra changed the title KFLUXINFRA-3695 Add kueue configuration for internal-production KFLUXINFRA-3695 Install Kueue v1.3 on internal-production May 11, 2026
manish-jangra and others added 3 commits May 11, 2026 15:27
Add the kueue component overlay for the internal-production cluster,
enabling queue-based scheduling for signing PipelineRuns. Configuration
mirrors staging as the baseline and will be tuned independently based on
production observations.

Includes:
- Kueue operator (CatalogSource, Subscription, Kueue CR)
- ClusterQueue with BestEffortFIFO and signing-server-request resource
- LocalQueue in internal-services namespace
- tekton-kueue controller and webhook with HA patches
- CEL expressions for priority assignment and rate-limiting

Co-authored-by: Cursor <cursoragent@cursor.com>
Upgrade the Kueue operator subscription channel from stable-v1.2 to
stable-v1.3 and bump all Kueue CRD apiVersions from v1beta1 to v1beta2
(ResourceFlavor, ClusterQueue, WorkloadPriorityClass, LocalQueue) to
match the new API surface shipped with v1.3. Mirrors the staging
upgrade in PR redhat-appstudio#342.

Co-authored-by: Cursor <cursoragent@cursor.com>
…alQueue

Move tekton-kueue sync wave from 10 to 12 so it deploys after the
LocalQueue (wave 11). This prevents a race where the tekton-kueue
webhook becomes active before the pipelines-queue LocalQueue exists,
which could cause PipelineRuns to be rejected during rollout.

Fixes both internal-staging and internal-production overlays.

Co-authored-by: Cursor <cursoragent@cursor.com>
@manish-jangra

Copy link
Copy Markdown
Contributor Author

/agentic_review

@qodo-code-review

qodo-code-review Bot commented May 11, 2026

Copy link
Copy Markdown

Persistent review updated to latest commit 6811469

Comment on lines +17 to +23
configMapGenerator:
- name: tekton-kueue-config
namespace: tekton-kueue
behavior: replace
files:
- config.yaml

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. config.yaml missing in base 📎 Requirement gap ⚙ Maintainability

The PR adds config.yaml only within the environment-specific tekton-kueue directory rather than
providing the required placeholder within components/kueue/base/tekton-kueue/. This prevents the
base component from packaging the placeholder for future CEL rule configuration.
Agent Prompt
## Issue description
`config.yaml` exists only in the environment-specific tekton-kueue directory, but compliance requires a placeholder `config.yaml` to live inside the base tekton-kueue component and be packaged by that component's kustomization.

## Issue Context
The placeholder is required so future CEL rules can be added by updating the base component used by multiple overlays.

## Fix Focus Areas
- components/kueue/internal-production/tekton-kueue/kustomization.yaml[17-23]
- components/kueue/internal-production/tekton-kueue/config.yaml[1-13]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@openshift-ci

openshift-ci Bot commented May 31, 2026

Copy link
Copy Markdown

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants