Closed codyhoag closed 3 years ago
Scheduler Policy API has been marked deprecated in favor of upcoming profiles - https://github.com/openshift/api/pull/787
oc's --config
option, OC_EDITOR
env and oc convert
subcommand dropped: https://github.com/openshift/oc/pull/648
i18n for Metrics and Dashboards pages was added (CONSOLE-2391). Specific dashboard content in the web console will not be translated, as that is defined in config maps contributed by the Monitoring Operator and are out of scope for the initial i18n work. More context can be found in https://github.com/openshift/console/pull/7266.
Descheduler strategies API has been deprecated in favor of profiles - https://github.com/openshift/cluster-kube-descheduler-operator/pull/156
With oc image mirror
flags, the command will now fail if/when --keep-manifest-list=true
is passed with --filter-by-os
for any value other than --filter-by-os=.*
(wildcard). This is because it is not possible to preserve the manifest list digest while also filtering manifests from the list. https://github.com/openshift/oc/pull/642
Kubernetes 1.19 should be replaced with Kubernetes 1.20.
@ingvagabund should we as well add Non-preempting option for priority classes in the TechnologyPreview table list ? As of now that has not been added.
For RHCOS Complex Root Devices (GRPA-1431) is probably worth mentioning. OCP docs link here: https://github.com/openshift/openshift-docs/pull/27661
The fix to BZ#1901517 is a slight change. Here is the text of an email I sent recently as an FYI about the change:
TL;DR if you don't muck with default networking configs, nothing should change
In the past RHCOS has propagated initramfs networking configuration into the real
root of RHCOS if no other networking configuration was provided. This meant a single
default_connection.nmconnection file would get created and that connection profile
would match any interface on the machine. Every interface would get DHCP.
However, if you boot NetworkManager with no configuration at all (i.e. no
default_connection.nmconnection) it still defaults to DHCP on every interface and
will use dynamically generated profiles for each interface (written into /run/).
Using the single connection profile for multiple interfaces was a bit confusing to
some users (https://bugzilla.redhat.com/show_bug.cgi?id=1901517) so we made a slight
change to no longer propagate initramfs networking configuration if the defaults
were used. This means by default if you don't provide any other networking config
there won't be files in /etc/NetworkManager/system-connections/ on boot. If you rely
on tweaking the file that existed there previously then you might need to make a change.
In 4.7, RHCOS is using RHEL 8.3 packages (4.6 and below will stay with RHEL 8.2 packages). This is relevant for hardware support, new NetworkManager features, etc.
Please mention initial kdump support in RHCOS: https://github.com/openshift/openshift-docs/pull/28164
Ignition changes:
gs://
URLss3://
resources from the same partitionFor the Complex Root Devices epic (https://github.com/openshift/openshift-docs/issues/26801#issuecomment-745521970), we should call out:
/etc/clevis.json
is specified in the Ignition configThe fix to BZ#1901517 is a slight change. Here is the text of an email I sent recently as an FYI about the change: Left a comment in the BZ, I'm wondering if this should be included in the bug fixes list instead of in general release notes for 4.7? Cc: @jeana-redhat
Edit: This BZ now has bug fix text, so it should not be necessary to add to general 4.7 release notes.
oc
silently fixes apiVersion
in your resource files (yaml
or json
) for all OpenShift related objects (such as DeploymentConfig, Route, BuildConfig, etc) from v1
to proper name. For example apps.openshift.io/v1
for DeploymentConfig
. https://github.com/openshift/oc/pull/693 adds a warning which will print what the correct apiVersion
should be when it's missing and was fixed by oc
. The message, for Deployment Config will look like this:
Using non-groupfied API resources is deprecated and will be removed in a future release, update apiVersion to "apps.openshift.io/v1" for your resource
When you notice this message you should update your resource file because we are planning to remove this mechanism in a future release.
The web console is now localized and provides language support for global users. English, Japanese, Simplified Chinese, and Korean are currently supported
Korean language support may ship in a z-stream release, we didn't add support for it yet
From the Admin drop-down menu, select Language preferences to update your language setting. Localized date and time is now also supported
It would be better if we update it to From the User drop-down menu..
Enable Google customer managed keys for disk encryption at install
supported in 4.7 - https://issues.redhat.com/browse/CORS-1504
For visibility, here are the WIP release notes for Monitoring - https://github.com/openshift/openshift-docs/pull/28149. Please let me know if anything is missing for Monitoring and I can add it to the PR.
@gpei GCP custom-managed keys for disk encryption is covered here in the RNs: https://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-release-notes.html#ocp-4-7-gcp-disk-encryption. Let me know if there's anything additional to add.
deprecating a flag in oc adm catalog mirror
: https://github.com/openshift/oc/pull/710/files
@gpei GCP custom-managed keys for disk encryption is covered here in the RNs: https://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-release-notes.html#ocp-4-7-gcp-disk-encryption. Let me know if there's anything additional to add.
I also have a release note going into the Machine API section for customer-managed keys for OCPCLOUD-980. PR-28473.
Not sure if it is worth mentioning, there is a bug that was deferred from 4.6 and it is still failing in 4.7: https://bugzilla.redhat.com/show_bug.cgi?id=1887007 In short, realtime kernel is only supported for worker nodes.
Under Networking, we need to introduce feature "IPSEC support on OVNKubernetes". Ref: https://issues.redhat.com/browse/SDN-717. Docs PR in progress: https://github.com/openshift/openshift-docs/pull/27911
Under Networking, we need to introduce feature "IPSEC support on OVNKubernetes". Ref: https://issues.redhat.com/browse/SDN-717. Docs PR in progress: #27911
It's here: https://github.com/openshift/openshift-docs/pull/27907
oc rsh
removes support for --timeout
flag which was deprecated in 4.4 (https://github.com/openshift/oc/pull/260), users should be using --request-timeout
instead - https://github.com/openshift/oc/pull/631.oc adm must-gather
deprecates --timeout
's value passed in seconds and allows users to use duration like 5s
, 2m
, or 3h
, instead - https://github.com/openshift/oc/pull/631.Please add release notes for : CIS Kubernetes benchmark. These work for both OCP 4.7 and OCP 4.6 (For 4.6, apply RHSA-2021:0190) The OpenShift 4 Hardening Guide is available from Red Hat now until the CIS OpenShift Benchmark is published. Red Hat Advanced Cluster Manager 2.2 integrates with the OpenShift Compliance Operator
RHEL 7.9 node currently have communication issues with RHCOS nodes on IPSEC clusters https://bugzilla.redhat.com/show_bug.cgi?id=1925925#c2
QE lgtm for Build bug fixs part and Removed images part
QE lgtm for Build bug fixs part and Removed images part
@codyhoag QE ack is for https://github.com/openshift/openshift-docs/pull/29270
should we as well add Non-preempting option for priority classes in the TechnologyPreview table list ? As of now that has not been added.
@kasturinarra Scheduler profiles and Non-preempting priority classes were added to the TP table in this PR: https://github.com/openshift/openshift-docs/pull/29403.
should we as well add Non-preempting option for priority classes in the TechnologyPreview table list ? As of now that has not been added.
@kasturinarra Scheduler profiles and Non-preempting priority classes were added to the TP table in this PR: #29403.
@bergerhoffer thanks, looks good to me.
In the post installation steps, there is a line "For an installation with FCP, additional steps are required to enable multipathing." that needs to have the added caveat: "When enabling multipath root via a machine-config, all nodes in the pool must have multipath disks"
Please add docs for https://issues.redhat.com/browse/GRPA-2715 - "Machine configurations updates in select cases no longer reboot the nodes for SSH keys, pull secrets and ICSP changes."
there are some restrictions while installing a cluster on C2S region, need to be added to release note, please @staebler @joelddiaz confirm, thanks.
Restriction:
@yunjiang29 Unfortunately, I know very little about C2S. I didn't want you to think I was ignoring your request for conformation, but I also don't want to give the impression that I can speak authoritatively about C2S.
@yunjiang29 @staebler I can add those to the release notes once confirmed.
Questions:
STS is not supported in OCP 4.7 on C2S region.
Since STS (to my knowledge) is Tech Preview, isn't it understood that we do not support STS when deploying to a C2S region, since this really isn't "supported" for any deployment?
UPI is not supported in OCP 4.7 on C2S region.
Would this be considered a known issue that is planned to be fixed in the 4.7.z time frame? Or should we document just a strict "we don't support this for 4.7"?
I am hesitant to say that UPI is not supported. UPI certainly should be supported. Our reference implementation using CloudFormations may not work, but there is no reason why a UPI install in general should not work.
@codyhoag re: STS on C2S - yes, STS is TP in 4.7, so not supported in any case. Is there another way we might put it though since we do know it's an issue? "STS does not work in OCP 4.7 on C2S region" but more official-sounding?
In the post installation steps, there is a line "For an installation with FCP, additional steps are required to enable multipathing." that needs to have the added caveat: "When enabling multipath root via a machine-config, all nodes in the pool must have multipath disks"
@darkmuggle this would not really be a Release Notes item, but can you open it as a docs bug so it gets addressed post-GA?
OCI images are supported after Epic IR-115 cc @dmage @ricardomaraschini
OCI images are supported after Epic IR-115 cc @dmage @ricardomaraschini
@wzheng1 we have this RN: https://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-release-notes.html#ocp-4-7-registry-oci-support. Should anything be added? Thanks!
With
oc image mirror
flags, the command will now fail if/when--keep-manifest-list=true
is passed with--filter-by-os
for any value other than--filter-by-os=.*
(wildcard). This is because it is not possible to preserve the manifest list digest while also filtering manifests from the list. openshift/oc#642
@sallyom Doing a little detective work, this is actually covered in the bug fix section as BZ1908565. The doc text field for that BZ will go into the 4.7 RNs.
@yunjiang29 Unfortunately, I know very little about C2S. I didn't want you to think I was ignoring your request for conformation, but I also don't want to give the impression that I can speak authoritatively about C2S.
@joelddiaz not a problem, it make sense to me.
For the Docker Registry v1 API
in the ocp-4-7-deprecated-removed-features, it should be DEP
I guess.
OCP image registry has a known bug on C2S cluster Bug 1924568 - [aws-c2s] Failed to push images to openshift registry with "MethodNotAllowed: The specified method is not allowed against this resource" error.
OCP 4.7 docs are now live. Thanks all!
OCP 4.8 release notes tracker is here: #29652
Please leave comments here for anything that should be highlighted in the 4.7 release notes. Thank you!