In every OpenShift release, we make it a priority to implement work that directly relates to customer feedback. For OpenShift 4.10, we focused on notification enhancements to user preferences, enabling non-admin users to view cluster-scoped quota, and running pods in debug mode (a carry-over feature supported in OpenShift 3).
We designed and improved OpenShift 4.10 based on feedback from OpenShift users just like you. Your feedback helps improve user experiences and influence the future of Red Hat products. To play a part in future OpenShift releases, sign up to become a participant in future research opportunities.
Let’s take a closer look at the requests for enhancements (RFEs) we made for 4.10.
Add notification drawer settings to User Preferences
What we heard: We often hear that notifications are overwhelming and it is hard to filter the noise from what the user cares about the most. Specifically, hiding user alerts from the admin console and only surfacing platform alerts. Whereas user alerts should be visible from the developer's console.
How we responded: Enable users to customize what notifications appear in the drawer. Users can now filter workload notifications from all user projects in user preferences.
Select User preferences from the dropdown.
Navigate to the new Notifications tab.
On the Notifications tab, users now have the ability to hide user workload notifications.
Support AppliedClusterResourceQuota for project admins
What we heard: Project administrators need the ability to view AppliedClusterResourceQuota to know which ClusterResourceQuotas are applied to their project (namespace) and its associated usage in the console UI. Today AppliedClusterResourceQuota is only supported via the CLI.
How we responded: Project administrators now have the ability to view the AppliedClusterResourceQuota in the web console for their namespace.
We have added a new ResourceQuotas card to the project dashboard page that surfaces graphs for CPU request, CPU limit, Memory request and Memory limit.
In addition to the project dashboard, we have also added an AppliedClusterResourceQuota details page that surfaces more information regarding capacity per resource type.
Run Pod in Debug mode
What we heard: OpenShift 3 supported the ability to debug pods, and customers requested for OpenShift 4 to do the same to help with troubleshooting, particularly crash loop back-off statuses.
How we responded: We added the ability to debug pods in OpenShift 4.10.
In general, wherever a crash loop back-off status surfaces, a user can click the link to prompt a popover to view logs, view events, and debug (container-name) in terminal.
The crash loop back-off status surfaces in many places across the console like the Pods list and details pages, among others. For the example below we will use the Pods list.
Clicking on the Crash loop-back off status opens a popover with a description of what that means as well as links to view logs, view events, and debug (container-name) in terminal.
Clicking on any of the links to Debug (container-name) in terminal will direct users to the debug terminal page for the container-name.
Clicking on the link to View logs navigates users to the pod log page where we have added the Debug in terminal action to the log toolbar.
The Debug in terminal link is enabled when the selected container is crash-looping. Clicking on Debug in terminal will direct users to the debug terminal page corresponding to the selected container (as shown above).
Connect with us
We are always growing and evolving our improvements to OpenShift with a customer-first mindset. Be on the lookout for more enhancements in future releases, and don’t forget to sign up to participate in future research opportunities to share your OpenShift experiences.
Let us know your thoughts. We would love to connect with users like you. Stay up to speed with the OpenShift design team on our OpenShift Design site, and be sure to catch us on the OpenShift Twitch channel.