OCP 4.8 Release Notes Tracker

[soltysh]

Please leave comments here for anything that should be highlighted in the 4.8 release notes. Thank you!

[soltysh]

oc newapp might not work on RHEL7 for clients using older Docker versions. openshift/oc#745 removes support for docker v1 API.

[vikram-redhat]

descheduler is not supported on SNO cluster - https://bugzilla.redhat.com/show_bug.cgi?id=1959321

[jianzhangbjz]

• OLM is not supported on SNO cluster - https://issues.redhat.com/browse/OLM-2017, besides, there is bug: https://bugzilla.redhat.com/show_bug.cgi?id=1953977
• The build subcommand had been removed from the oc adm catalog.

[root@preserve-olm-env debug-manifests]# oc adm catalog --help
This tool is used to extract and mirror the contents of catalogs for Operator Lifecycle Manager.

 The subcommands allow you to mirror catalog content across registries.

Usage:
  oc adm catalog [flags]

Available Commands:
  mirror      Mirror an operator-registry catalog

[pamoedom]

Not sure if we should include the experimental AWS tagging feature as tech preview, I've asked the developer within OSDOCS-1959 to confirm/discard.

[tsze-redhat]

GCP installation:
Change to subnets created during installation to increase number of IP available
https://issues.redhat.com/browse/CORS-1660

[miabbott]

RHCOS will be based on RHEL 8.4; this brings in new kernel features, hardware enablements, etc

[travier]

In RHCOS, we longer set the PEERNTP=no option in the chrony configuration (/etc/chrony.conf) by default on cloud platforms (AWS, GCP, Azure) if (and only if) the administrator has already set a custom chrony.conf configuration. All other cases are unchanged (i.e. this option is set by default on those platforms). See coreos/fedora-coreos-config#845 for reference.

[dmesser]

OLM has better installation/update error handling and reporting: https://issues.redhat.com/browse/OLM-2048

• missing or invalid OperatorGroups will now be reported at the InstallPlan level
• missing or wrong package, catalog and channel names will now be reported at the Subscription level
• InstallPlans are now automatically retried to overcome transient errors

[dulek]

In deployments on OSP with Kuryr-Kubernetes, the API LB for the default/kubernetes Service is no longer managed by CNO, but by kuryr-controller itself. This means that:

• On upgrade it's expected this service will have some downtime (more in deployments where no ovn-octavia is available).
• The default/kubernetes LB was previously forced to be using Amphora Octavia provider. This is not true anymore, if ovn-octavia is available in the OSP cloud, it will be used to implement that service.

Please note that I added the same to the bug [1] doc text.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1949509

[tsze-redhat]

@pamoedom I suggest also includes CORS-1600:

Installer now attempts to automatically collect and analyze when installation fails.
Potential causes for installation failures will be displayed if the terminal running the installer has the proper ssh key configured and user specifies a ssh key during install process.
It differentiates failures between bootstrap failure vs API failure and also reports registry access failures.

What do you think?

[pamoedom]

@pamoedom I suggest also includes CORS-1600:

Installer now attempts to automatically collect and analyze when installation fails.
Potential causes for installation failures will be displayed if the terminal running the installer has the proper ssh key configured and user specifies a ssh key during install process.

What do you think?

That's a good point @tsze-redhat but I recall @codyhoag telling we don't have any customer facing documentation for this in CORS-1627, so not sure if we could refer it in the official release notes.

[tsze-redhat]

Based on feedback from @staebler I also added CORS-1533 (registry accessing causing bootstrap).
Maybe we can consider the output from installer is self-explanatory enough to not require user doc.

I shall leave it to you to decide whether we include or not include bootstrap improvements. @pamoedom

Thanks.

[adduarte]

OpenStack platform: SSH port is explicitly CLOSED on cluster deployment.
having ssh port to the cluster exposed (open) is a security risk.
Also, ssh to nodes is not the suggested way to connect to the cluster nodes. Instead the user should use the "oc debug" command when possible.
If the user wants to ssh to the nodes, they must explicitly open port 22 in the security rules for the cluster, as pointed out in https://docs.openshift.com/container-platform/4.7/virt/virtual_machines/virt-accessing-vm-consoles.html#virt-accessing-vmi-ssh_virt-accessing-vm-consoles

Bug 1873079 - SSH to api and console route is possible when the clsuter is hosted on Openstack (https://bugzilla.redhat.com/show_bug.cgi?id=1873079)

[adambkaplan]

Builds: Image change triggers will not start a build based on changes to the lastImageChangeTriggeredID field in the BuildConfig spec. The image IDs that trigger a build will be recorded in the BuildConfig's status, which cannot be changed by most users.

Epic link: https://issues.redhat.com/browse/BUILD-213