1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

Merge pull request #54339 from MirzWeiss/TELCODOCS-767

TELCODOCS:767 - Add existing osc release notes to 4.12 branch. New content to follow in separate branch.
This commit is contained in:
Michael Burke
2023-01-09 09:52:13 -05:00
committed by GitHub
3 changed files with 158 additions and 44 deletions

View File

@@ -2247,7 +2247,7 @@ Dir: sandboxed_containers
Distros: openshift-enterprise
Topics:
- Name: OpenShift sandboxed containers release notes
File: sandboxed-containers-4.11-release-notes
File: sandboxed-containers-1.3-release-notes
- Name: Understanding OpenShift sandboxed containers
File: understanding-sandboxed-containers
- Name: Deploying OpenShift sandboxed containers workloads

View File

@@ -0,0 +1,157 @@
:_content-type: ASSEMBLY
[id="sandboxed-containers-1-3-release-notes"]
= {sandboxed-containers-first} {sandboxed-containers-version} release notes
include::_attributes/common-attributes.adoc[]
:context: sandboxed-containers-release-notes
toc::[]
[id="sandboxed-containers-1-3-about-this-release"]
== About this release
These release notes track the development of {sandboxed-containers-first} {sandboxed-containers-version} alongside Red Hat {product-title} {product-version}.
This product is fully supported and enabled by default as of {product-title} 4.10.
[id="sandboxed-containers-1-3-new-features-and-enhancements"]
== New features and enhancements
[id="refined-kata-metrics"]
=== Container ID in metrics list
The `sandbox_id` with the ID of the relevant sandboxed container now appears in the metrics list on the *Metrics* page in the web console.
In addition, the `kata-monitor` process now adds three new labels to kata-specific metrics: `cri_uid`, `cri_name`, and `cri_namespace`. These labels enable kata-specific metrics to relate to corresponding kubernetes workloads.
For more information about kata-specific metrics, see xref:../sandboxed_containers/monitoring-sandboxed-containers.adoc#sandboxed-containers-metrics-list_monitoring-sandboxed-containers[About {sandboxed-containers-first} metrics].
[id="osc-baremetal-fully-supported-on-aws"]
=== {sandboxed-containers-first} availability on AWS bare metal
Previously, {sandboxed-containers-first} availability on AWS bare metal was in Technology Preview. With this release, installing {sandboxed-containers-first} on AWS bare-metal clusters is fully supported.
[id="osc-with-sno-topology"]
=== Support for {sandboxed-containers-first} on {sno}
{sandboxed-containers-first} now work on {sno} clusters when the {sandboxed-containers-operator} is installed by {rh-rhacm-first}.
[id="sandboxed-containers-1-3-bug-fixes"]
== Bug fixes
* Previously, when creating the `KataConfig` CR and observing the pod status under the `openshift-sandboxed-containers-operator` namespace, a huge number of restarts for monitor pods was shown. The monitor pods use a specific SELinux policy that was installed as part of the `sandboxed-containers` extension installation. The monitor pod was created immediately. However, the SELinux policy was not yet available, which resulted in a pod creation error, followed by a pod restart.
+
With this release, the SELinux policy is available when the monitor pod is created, and the monitor pod transitions to a `Running` state immediately. (https://issues.redhat.com/browse/KATA-1338[*KATA-1338*])
* Previously, {sandboxed-containers-first} deployed a security context constraint (SCC) on startup which enforced a custom SELinux policy that was not available on Machine Config Operator (MCO) pods. This caused the MCO pod to change to a `CrashLoopBackOff` state and cluster upgrades to fail. With this release, {sandboxed-containers-first} deploys the SCC when creating the `KataConfig` CR and no longer enforces using the custom SELinux policy. (https://issues.redhat.com/browse/KATA-1373[*KATA-1373*])
* Previously, when uninstalling the {sandboxed-containers-operator}, the `sandboxed-containers-operator-scc` custom resource was not deleted. With this release, the `sandboxed-containers-operator-scc` custom resource is deleted when uninstalling the {sandboxed-containers-operator}. (https://issues.redhat.com/browse/KATA-1569[*KATA-1569*])
[id="sandboxed-containers-1-3-known-issues"]
== Known issues
* If you are using {sandboxed-containers-first}, you might receive SELinux denials when accessing files or directories mounted from the `hostPath` volume in an {product-title} cluster. These denials can occur even when running privileged sandboxed containers because privileged sandboxed containers do not disable SELinux checks.
+
Following SELinux policy on the host guarantees full isolation of the host file system from the sandboxed workload by default. This also provides stronger protection against potential security flaws in the `virtiofsd` daemon or QEMU.
+
If the mounted files or directories do not have specific SELinux requirements on the host, you can use local persistent volumes as an alternative. Files are automatically relabeled to `container_file_t`, following SELinux policy for container runtimes. See xref:../storage/persistent_storage/persistent-storage-local.adoc#persistent-storage-local[Persistent storage using local volumes] for more information.
+
Automatic relabeling is not an option when mounted files or directories are expected to have specific SELinux labels on the host. Instead, you can set custom SELinux rules on the host to allow the `virtiofsd` daemon to access these specific labels. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1904609[*BZ#1904609*])
* Some {sandboxed-containers-operator} pods use container CPU resource limits to increase the number of available CPUs for the pod. These pods might receive fewer CPUs than requested. If the functionality is available inside the container, you can diagnose CPU resource issues by using `oc rsh <pod>` to access a pod and running the `lscpu` command:
+
[source,terminal]
----
$ lscpu
----
+
.Example output
+
[source,terminal]
----
CPU(s):                          16
On-line CPU(s) list:             0-12,14,15
Off-line CPU(s) list:            13
----
+
The list of offline CPUs will likely change unpredictably from run to run.
+
As a workaround, you can use a pod annotation to request additional CPUs rather than setting a CPU limit. CPU requests that use pod annotation are not affected by this issue, because the processor allocation method is different. Rather than setting a CPU limit, the following `annotation` must be added to the metadata of the pod:
+
[source,yaml]
----
metadata:
  annotations:
    io.katacontainers.config.hypervisor.default_vcpus: "16"
----
+
(link:https://issues.redhat.com/browse/KATA-1376[*KATA-1376*])
* The progress of the runtime installation is shown in the `status` section of the `kataConfig` custom resource (CR). However, the progress is not shown if all of the following conditions are true:
** There are no worker nodes defined. You can run `oc get machineconfigpool` to check the number of worker nodes in the machine config pool.
** No `kataConfigPoolSelector` is specified to select nodes for installation.
+
In this case, the installation starts on the control plane nodes because the Operator assumes it is a converged cluster where nodes have both control plane and worker roles. The `status` section of the `kataConfig` CR is not updated during the installation. (link:https://issues.redhat.com/browse/KATA-1017[*KATA-1017*])
* When using older versions of the Buildah tool in {sandboxed-containers-first}, the build fails with the following error:
+
[source,text]
----
process exited with error: fork/exec /bin/sh: no such file or directory
subprocess exited with status 1
----
+
You must use the latest version of Buildah, available at link:https://quay.io/buildah/stable:latest[quay.io].
+
(link:https://issues.redhat.com/browse/KATA-1278[*KATA-1278*])
* In the *KataConfig* tab in the web console, if you click *Create KataConfig* while in the *YAML view*, the `KataConfig` YAML is missing the `spec` fields. Toggling to the *Form view* and then back to the *YAML view* fixes this issue and displays the full YAML. (link:https://issues.redhat.com/browse/KATA-1372[*KATA-1372*])
* In the *KataConfig* tab in the web console, a `404: Not found` error message appears whether a `KataConfig` CR already exists or not. To access an existing `KataConfig` CR, go to *Home* > *Search*. From the *Resources* list, select *KataConfig*. (link:https://issues.redhat.com/browse/KATA-1605[*KATA-1605*])
* Upgrading {sandboxed-containers-first} does not automatically update the existing `KataConfig` CR. As a result, monitor pods from previous deployments are not restarted and continue to run with an outdated `kataMonitor` image.
+
Upgrade the `kataMonitor` image with the following command:
+
[source,terminal]
----
$ oc patch kataconfig example-kataconfig --type merge --patch '{"spec":{"kataMonitorImage":"registry.redhat.io/openshift-sandboxed-containers/osc-monitor-rhel8:1.3.0"}}'
----
+
You can also upgrade the `kataMonitor` image by editing the `KataConfig` YAML in the web console.
+
(link:https://issues.redhat.com/browse/KATA-1650[*KATA-1650*])
[id="sandboxed-containers-1-3-asynchronous-errata-updates"]
== Asynchronous errata updates
Security, bug fix, and enhancement updates for {sandboxed-containers-first} {product-version} are released as asynchronous errata through the Red Hat Network. All {product-title} {product-version} errata are available on the https://access.redhat.com/downloads/content/290/[Red Hat Customer Portal]. For more information about asynchronous errata, see the https://access.redhat.com/support/policy/updates/openshift[{product-title} Life Cycle].
Red Hat Customer Portal users can enable errata notifications in the account settings for Red Hat Subscription Management (RHSM). When errata notifications are enabled, users are notified by email whenever new errata relevant to their registered systems are released.
[NOTE]
====
Red Hat Customer Portal user accounts must have systems registered and consuming {product-title} entitlements for {product-title} errata notification emails to generate.
====
This section will continue to be updated over time to provide notes on enhancements and bug fixes for future asynchronous errata releases of {sandboxed-containers-first} {sandboxed-containers-version}.
[id="sandboxed-containers-1-3-0"]
=== RHSA-2022:6072 - {sandboxed-containers-first} {sandboxed-containers-version}.0 image release, bug fix, and enhancement advisory.
Issued: 2022-08-17
{sandboxed-containers-first} release {sandboxed-containers-version}.0 is now available. This advisory contains an update for {sandboxed-containers-first} with enhancements and bug fixes.
The list of bug fixes included in the update is documented in the link:https://access.redhat.com/errata/RHBA-2022:6072[RHSA-2022:6072] advisory.
[id="sandboxed-containers-1-3-1"]
=== RHSA-2022:7058 - {sandboxed-containers-first} {sandboxed-containers-version}.1 security fix and bug fix advisory.
Issued: 2022-10-19
{sandboxed-containers-first} release {sandboxed-containers-version}.1 is now available. This advisory contains an update for {sandboxed-containers-first} with security fixes and a bug fix.
The list of bug fixes included in the update is documented in the link:https://access.redhat.com/errata/RHSA-2022:7058[RHSA-2022:7058] advisory.

View File

@@ -1,43 +0,0 @@
:_content-type: ASSEMBLY
[id="sandboxed-containers-1-3-release-notes"]
= {sandboxed-containers-first} {sandboxed-containers-version} release notes
include::_attributes/common-attributes.adoc[]
:context: sandboxed-containers-release-notes
toc::[]
[id="sandboxed-containers-1-3-about-this-release"]
== About this release
These release notes track the development of {sandboxed-containers-first} {sandboxed-containers-version} alongside Red Hat {product-title} {product-version}.
This product is fully supported and enabled by default as of {product-title} 4.10.
[id="sandboxed-containers-1-3-new-features-and-enhancements"]
== New features and enhancements
[id="sandboxed-containers-1-3-bug-fixes"]
== Bug fixes
[id="sandboxed-containers-1-3-known-issues"]
== Known issues
[id="sandboxed-containers-1-3-asynchronous-errata-updates"]
== Asynchronous errata updates
Security, bug fix, and enhancement updates for {sandboxed-containers-first} {product-version} are released as asynchronous errata through the Red Hat Network. All {product-title} {product-version} errata are available on the https://access.redhat.com/downloads/content/290/[Red Hat Customer Portal]. For more information about asynchronous errata, see the https://access.redhat.com/support/policy/updates/openshift[{product-title} Life Cycle].
Red Hat Customer Portal users can enable errata notifications in the account settings for Red Hat Subscription Management (RHSM). When errata notifications are enabled, users are notified by email whenever new errata relevant to their registered systems are released.
[NOTE]
====
Red Hat Customer Portal user accounts must have systems registered and consuming {product-title} entitlements for {product-title} errata notification emails to generate.
====
This section will continue to be updated over time to provide notes on enhancements and bug fixes for future asynchronous errata releases of {sandboxed-containers-first} {sandboxed-containers-version}.