You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: post_installation_configuration/configuring-multi-arch-compute-machines/multi-arch-tuning-operator-release-notes.adoc
+26-2Lines changed: 26 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,30 @@ These release notes track the development of the Multiarch Tuning Operator.
12
12
13
13
For more information, see xref:../../post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc#multiarch-tuning-operator[Managing workloads on multi-architecture clusters by using the Multiarch Tuning Operator].
* With this release, you can enable the *exec format error monitor* plugin for the Multiarch Tuning Operator. This plugin detects `ENOEXEC` errors, which occur when a pod attempts to execute a binary incompatible with the node's architecture. You enable this plugin by setting the `plugins.execFormatErrorMonitor.enabled` parameter to `true` in the `ClusterPodPlacementConfig` object. For more information, see xref:../../post_installation_configuration/configuring-multi-arch-compute-machines/multiarch-tuning-operator.adoc#multi-architecture-creating-podplacement-config_multiarch-tuning-operator[Creating the ClusterPodPlacementConfig object].
* Previously, the Multiarch Tuning Operator incorrectly handled the Operator bundle image inspector, restricting it to a single architecture, which could cause OLM to fail when installing Operators. With this update, MTO now sets the bundle image to support all architectures, allowing Operators to be successfully installed on single-architecture clusters when the Multiarch Tuning Operator is deployed. (link:https://issues.redhat.com/browse/MULTIARCH-5546[*MULTIARCH-5546*])
29
+
30
+
* Previously, when a cluster global pull secret was changed, stale authentication information could remain in the Multiarch Tuning Operator cache. With this update, the cache is cleared whenever a cluster global pull secret is changed. (link:https://issues.redhat.com/browse/MULTIARCH-5538[*MULTIARCH-5538*])
31
+
32
+
* Previously, the Multiarch Tuning Operator failed to process pods if an image reference contained both a tag and a digest. With this update, the image inspector prioritizes the digest if both are present. (link:https://issues.redhat.com/browse/MULTIARCH-5584[*MULTIARCH-5584*])
33
+
34
+
* Previously, the Multiarch Tuning Operator did not respect the `.spec.registrySources.containerRuntimeSearchRegistries` field in the `config.openshift.io/Image` custom resource when a workload image did not specify a registry URL. With this update, the Operator can now handle this case, allowing workload images without an explicit registry URL to be pulled successfully. (link:https://issues.redhat.com/browse/MULTIARCH-5611[*MULTIARCH-5611*])
35
+
36
+
* Previously, if the `ClusterPodPlacementConfig` object was deleted less than 1 second after its creation, some finalizers were not removed in time, causing certain resources to remain. With this update, all finalizers are properly deleted when the `ClusterPodPlacementConfig` object is deleted. (link:https://issues.redhat.com/browse/MULTIARCH-5372[*MULTIARCH-5372*])
== Release notes for the Multiarch Tuning Operator 1.1.1
17
41
@@ -22,11 +46,11 @@ Issued: 27 May 2025
22
46
23
47
* Previously, the pod placement operand did not support authenticating registries using wildcard entries in the hostname of their pull secret. This caused inconsistent behavior with Kubelet when pulling images, because Kubelet supported wildcard entries while the operand required exact hostname matches. As a result, image pulls could fail unexpectedly when registries used wildcard hostnames.
24
48
+
25
-
With this release, the pod placement operand supports pull secrets that include wildcard hostnames, ensuring consistent and reliable image authentication and pulling.
49
+
With this release, the pod placement operand supports pull secrets that include wildcard hostnames, ensuring consistent and reliable image authentication and pulling.
26
50
27
51
* Previously, when image inspection failed after all retries and the `nodeAffinityScoring` plugin was enabled, the pod placement operand applied incorrect `nodeAffinityScoring` labels.
28
52
+
29
-
With this release, the operand sets `nodeAffinityScoring` labels correctly, even when image inspection fails. It now applies these labels independently of the required affinity process to ensure accurate and consistent scheduling.
53
+
With this release, the operand sets `nodeAffinityScoring` labels correctly, even when image inspection fails. It now applies these labels independently of the required affinity process to ensure accurate and consistent scheduling.
0 commit comments