WIP: feat: proposal for CEL expression placement plugin by prb112 · Pull Request #737 · outrigger-project/multiarch-tuning-operator

prb112 · 2026-03-31T19:30:45Z

No description provided.

Signed-off-by: Paul Bastide <pbastide@us.ibm.com>

openshift-ci · 2026-03-31T19:31:02Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: prb112
Once this PR has been reviewed and has the lgtm label, please assign aleskandro for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

OWNERS

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

lwan-wanglin · 2026-04-01T08:16:00Z

+
+The current Multiarch Tuning Operator automatically determines Pod image architecture compatibility by inspecting container images. While this works well for most scenarios, there are cases where administrators need more control at the namespace level:
+
+1. **Workload-specific architecture preferences** Some workloads may benefit from specific architectures based on their component affinnity (e.g., database pods on ppc64le, web servers on amd64)


a typo

Suggested change

1. **Workload-specific architecture preferences** Some workloads may benefit from specific architectures based on their component affinnity (e.g., database pods on ppc64le, web servers on amd64)

1. **Workload-specific architecture preferences** Some workloads may benefit from specific architectures based on their component affinity (e.g., database pods on ppc64le, web servers on amd64)

lwan-wanglin · 2026-04-01T09:01:26Z

+   - Filters configs whose `labelSelector` matches the pod
+   - For matching configs with `celArchitecturePlacement` enabled, evaluates CEL expressions in priority order
+   - If a rule matches (CEL expression returns `true`):
+     - **Removes any existing architecture constraints** from the pod's `spec.nodeSelector` (removes `kubernetes.io/arch` key if present)


If a user creates a namespaced PPC and enables celArchitecturePlacement, it can override all of spec.nodeSelector and spec.affinity.nodeAffinity, including user-defined settings, not just those added by MTO？

Ah, I see the answer in the following section

lwan-wanglin · 2026-04-01T09:29:59Z

+
+1. **Limits Rule Explosion and Configuration Burden** Without a default, administrators would need to create rules for every possible pod pattern, leading to complex and hard-to-maintain configurations. The plugin supports _exceptional_ cases in the same namespace.
+
+2. **Provides Fallback Behavior** When no rules match, the system needs a sensible default rather than failing or using arbitrary behavior


we now have a field named fallbackArchitecture in Cluster scope ppc https://github.com/outrigger-project/multiarch-tuning-operator/blob/main/api/v1beta1/clusterpodplacementconfig_types.go#L58, If both fallbackArchitecture and defaultArchitectures are set, does defaultArchitectures take precedence?

AnnaZivkovic · 2026-04-08T19:49:14Z

+metadata:
+  name: database-rules
+  namespace: production
+spec:


This is missing the Priority field which will default to 0 if left empty.

AnnaZivkovic · 2026-04-08T19:54:33Z

+
+#### Priority and Conflict Resolution
+
+Only a single `PodPlacementConfig` resource in the same namespace is allowed.


I feel like this disregards the purpose of the Priority field. We would want multiple PPC with different priories. If several configs match the pod via labelSelector, is the winner only by priority, or is there a tie-breaker (name, creation time)?

AnnaZivkovic · 2026-04-08T19:57:09Z

+1. **CEL Compilation** Expressions are compiled once at configuration time
+2. **Expression Caching** Compiled expressions are cached to avoid repeated compilation
+3. **Evaluation Overhead** CEL evaluation is fast (microseconds per expression)
+4. **Rule Limit** Maximum of 500 rules per configuration to prevent excessive evaluation time. This limit will be reviewed after use.


There are conflicting numbers for the rule limit. Is it 50, 500. or 1000+?

AnnaZivkovic · 2026-04-08T20:00:07Z

+| Misconfigured rules assign pods to incompatible architectures | Pods fail to start with ENOEXEC errors | Document best practices; recommend testing rules in non-production environments; existing ENOEXEC monitoring will detect issues |
+| Too many rules impact performance | Increased pod scheduling latency | Limit maximum rules per configuration (500); compile and cache expressions; provide performance guidelines |
+| Conflicting rules between multiple PodPlacementConfigs | Unpredictable behavior | Clear precedence rules based on priority field; document evaluation order |
+| CEL expressions access sensitive pod data | Potential information disclosure | CEL expressions only have access to pod metadata (labels, annotations, name, namespace); no access to secrets or container specs |


The risk table says CEL only sees pod metadata and not container specs. Elsewhere the design is “evaluate against a Pod resource” with self. If the real CEL type is a full Pod, expressions could reference images, env, volumes, etc., unless the implementation uses a restricted type or field mask.

AnnaZivkovic · 2026-04-08T20:12:28Z

+            - key: kubernetes.io/arch
+                operator: In
+                values:
+                - ppc64le
+                - amd64


Suggested change

- key: kubernetes.io/arch

operator: In

values:

- ppc64le

- amd64

- key: kubernetes.io/arch

operator: In

values:

- ppc64le

- amd64

AnnaZivkovic · 2026-04-08T20:34:13Z

+   - If no rules match, uses the default architecture list specified in the plugin configuration (also removing existing constraints)
+   - The scheduling gate is removed
+
+#### Architecture Constraint Removal


The proposal states that celArchitecturePlacement removes existing arch constraints and sets required affinity, that image-based detection can still apply elsewhere, and that NodeAffinityScoring can coexist and “prefer among eligible architectures.” Could you document an explicit ordering (and which component runs in which stage) for a single reconcile pass? Without that, it is ambiguous whether image-based logic might run before or after CEL and whether scoring sees the final required arch set or an intermediate state, which makes behavior hard to predict and tests hard to specify.

AnnaZivkovic · 2026-04-08T20:52:04Z

+
+| Risk | Impact | Mitigation |
+|------|--------|------------|
+| Complex CEL expressions cause evaluation errors | Pods may not be scheduled correctly | Validate expressions at admission time; provide clear error messages; treat evaluation errors as non-matches |


Implementation notes say evaluation errors are logged and treated as false. How do we handle validation on PodPlacementConfig create/update (reject bad CEL), and whether any pod-level admission failure is possible, or failures are always soft (fall through to default / next rule)?

Signed-off-by: Paul Bastide <pbastide@us.ibm.com>

feat: proposal for CEL expression placement plugin

a78bc4b

Signed-off-by: Paul Bastide <pbastide@us.ibm.com>

openshift-ci Bot requested review from AnnaZivkovic and aleskandro March 31, 2026 19:30

prb112 changed the title ~~feat: proposal for CEL expression placement plugin~~ WIP: feat: proposal for CEL expression placement plugin Mar 31, 2026

openshift-ci Bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 31, 2026

lwan-wanglin reviewed Apr 1, 2026

View reviewed changes

AnnaZivkovic reviewed Apr 8, 2026

View reviewed changes

prb112 added 2 commits April 15, 2026 13:03

fix: spelling changed to the correct placement

d6a6129

Signed-off-by: Paul Bastide <pbastide@us.ibm.com>

fix: convert to fallbackArchitecture, and explain the use

0fd19b3

Signed-off-by: Paul Bastide <pbastide@us.ibm.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: feat: proposal for CEL expression placement plugin#737

WIP: feat: proposal for CEL expression placement plugin#737
prb112 wants to merge 3 commits intooutrigger-project:mainfrom
prb112:feat-cel-plugin

prb112 commented Mar 31, 2026

Uh oh!

openshift-ci Bot commented Mar 31, 2026

Uh oh!

lwan-wanglin Apr 1, 2026

Uh oh!

lwan-wanglin Apr 1, 2026

Uh oh!

lwan-wanglin Apr 1, 2026

Uh oh!

lwan-wanglin Apr 1, 2026

Uh oh!

AnnaZivkovic Apr 8, 2026

Uh oh!

AnnaZivkovic Apr 8, 2026 •

edited

Loading

Uh oh!

AnnaZivkovic Apr 8, 2026

Uh oh!

AnnaZivkovic Apr 8, 2026

Uh oh!

AnnaZivkovic Apr 8, 2026

Uh oh!

AnnaZivkovic Apr 8, 2026

Uh oh!

AnnaZivkovic Apr 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants


		The current Multiarch Tuning Operator automatically determines Pod image architecture compatibility by inspecting container images. While this works well for most scenarios, there are cases where administrators need more control at the namespace level:

		1. Workload-specific architecture preferences Some workloads may benefit from specific architectures based on their component affinnity (e.g., database pods on ppc64le, web servers on amd64)


		1. Limits Rule Explosion and Configuration Burden Without a default, administrators would need to create rules for every possible pod pattern, leading to complex and hard-to-maintain configurations. The plugin supports _exceptional_ cases in the same namespace.

		2. Provides Fallback Behavior When no rules match, the system needs a sensible default rather than failing or using arbitrary behavior


		#### Priority and Conflict Resolution

		Only a single `PodPlacementConfig` resource in the same namespace is allowed.

Conversation

prb112 commented Mar 31, 2026

Uh oh!

openshift-ci Bot commented Mar 31, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnnaZivkovic Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

AnnaZivkovic Apr 8, 2026 •

edited

Loading