3 improvements to the OpenShift 4.12 developer experience

February 1, 2023
Serena Chechile Nichols
Related topics:
Containers
Related products:
Red Hat OpenShift ServerlessRed Hat OpenShift Container Platform

Red Hat OpenShift Container Platform 4.12 provides several enhancements based on customer requests and usability improvements to the Red Hat OpenShift console.

The improvements include the following:

  • The Helm page now has a dedicated Repositories tab allowing users to manage Helm chart repositories.
  • When using OpenShift Serverless, workloads created by Import from Git and Deploy image default to serverless.
  • When using OpenShift Pipelines:
    • Users now have quick access to the parameter values used during a Pipeline Run in the Parameters tab of the PipelineRun details page.
    • Users can now choose to either Cancel or Stop a running PipelineRun, providing more granular control of the running tasks of the PipelineRun.
  • Cluster Administrators now have a form-based experience to customize areas of the OpenShift console from Cluster Settings. Although developers cannot use this feature, it provides the ability for admins to provide an improved developer experience. Be on the lookout for an in-depth article about console customization coming soon.

This article will dive into what’s new for developers.

3 improvements to OpenShift 4.12

Let’s go into more detail about the improvements in three key areas.

1. User preferences updates

The Applications tab of User Preferences provides default settings that are used in the import from Git and deploy image flows (Figure 1). In addition to security defaults, developers can now set the default workload type in the Resource type section.  When using OpenShift Serverless, this default is set to serverless. Otherwise, it is set to deployment.

Screenshot of the applications tab of user preferences page.
Figure 1: The applications tab of the user preferences page.

Now let’s look at how this affects the Import from Git and Deploy Image flows. Previously, resource type section was prominent in those user flows. We learned from users that resource type was not something that is typically changed. So once their default was set properly, they didn’t update it frequently. Because of this, we have added the ability to set the default in User Preferences and also moved the Resource type section of our Import from Git and Deploy Image forms to the Advanced options section (see Figure 2).

Screenshot of the previous and new advanced options page with the Resource type section.
Figure 2: The Resource type section moved to the Advanced option section.

2. Improved display of limits and quotas issues

To improve awareness of project limits and quota issues, developers will see a warning label on the top of the Add and Topology page when any project limits and quotas are detected. Figure 3 shows an example of the label on the Topology page, which indicates the number of quotas that have been reached. Developers can click the label to get additional data to detect the issue.

A screenshot of the quota issues label on the topology page.
Figure 3: The quota issues label on the Topology page indicating the number of quotas reached.

When multiple quotas have been reached, the user is brought to the list page of Resource Quotas (see Figure 4). Otherwise, users will be redirected to the details page of that specific resource quota.

The Resource Quotas page showing resources reached quotas.
Figure 4: The Resource Quotas page showing resources reached quotas.

Taking this a step further, additional visual indicators are shown in Topology on resources that have surpassed limits or quotas. Figure 5 illustrates an example of how developers can identify these issues at different zoom levels. Developers can gain additional information about the detected problem by clicking on the node and viewing the information in the side panel. An in-context link is provided, allowing the developer to navigate to the specific flow to fix the issue. In this case, it would allow them to edit the resource limits of the deployment.

A screenshot of issues at different zoom levels.
Figure 5: You can view issues at different zoom levels.

This is one of my favorite features of the release. Currently, when limits and quotas are reached, developers have to go to the Project Details page to get information. We now inform the user as soon as the issue is detected. Additionally, we provide them with one-click access to either get more information or resolve the issue (Figure 6).

One-click access to resolve the issue.
Figure 6: One-click access to learn how to resolve the issue.

3. End-to-end KafkaSink support

Receive and store CloudEvents from Source/Subscription/Trigger on a Kafka topic without writing custom code as follows:

When the CR for knativeKafka is created with sink enabled, developers can create a KafkaSink from the Event Sink Catalog. Users will have a form-based experience to create a KafkaSink (Figure 7). Once created, a KafkaSink can be added as subscriber, trigger, and event-source sink targets. Developers can accomplish by using drag-and-drop or the action buttons.

The form-based creation flow for KafkaSink.
Figure 7: The form-based creation flow for KafkaSink.

How to get started with OpenShift 4.12

Ready to try these new features for yourself? Get started with OpenShift 4.12 today on the Developer Sandbox.

Check out the following resources to learn more about the new OpenShift 4.12 release:

If you have questions, feel free to comment below or reach out to us. Community feedback helps us to continually improve the OpenShift developer experience. Tweet me @serenamarie125 or join the OpenShift Developer Experience Google group to share your feedback.

Last updated: September 19, 2023