You asked for it – we listened!
We get a lot of feedback from a lot of people, and when we compile that feedback oftentimes we see trends. Many times the things on that list are features we just haven’t been able to get to yet. So for 3.4 we picked a few of the most asked for features and usability improvements.
Filtering and Sorting the Project List
We have a class of users for OpenShift that manage many projects on behalf of a larger set of developers. To make things easier for people with a large number of projects, the project list now has a text filter on name, display name, description, and project creator. It also allows sorting on several of these attributes.
Organization of Add to Project Catalog / Customizable Categories
Our existing “Add to Project” catalog could become quite cluttered when dealing with builder images with many versions, or lots of templates with slight differences. In the past we focused on minimizing the number of clicks to getting an application running, but now we’ve focused on helping you find what you are actually looking for. The main catalog page now only contains high level categories “Languages” and “Technologies” and underneath those are sub-categories, such as “Java” or “Data Stores”. Diving into one of those you’ll find re-designed tiles for builder images and templates. Different versions of the same builder image now all roll-up to the same tile with the semantically latest version automatically selected. We have also taken a hard look at all of our out of the box images and templates and focused on providing better display names, descriptions, and categorization.
Don’t like our categories? That’s OK too! We heard your requests and now you can customize the categories and subcategories as much as you want.
Creating and Adding Secrets for Build and Deployment Configurations
We chose this feature because it was very difficult to set up a build against a private git repository from the web console. Previously you had to Import YAML/JSON to create your secret and then edit your build’s YAML to make it use that secret. Not exactly easy and definitely not obvious.
Now you can expand the advanced build options, create a user/password or SSH key based secret and tell the build to use that when cloning your source. Already have your secret created in that project? You can pick any of your existing ones too.
While we were making private git repository connections easier to set up, we figured we should improve setting up push and pull against private image registries as well. The build configuration editor lets you set up a push or pull secret in case the image you are building from, or the image stream you are pushing to, is on a secure registry. Similarly the new deployment configuration editor allows you to specify a pull secret.
Editor for deployment configuration strategy, hooks, and secrets
We’ve had a GUI editor for build configurations for a few releases, and now we’ve added one for deployment configurations too. From the new editor you can:
- Switch your deployment strategy
- Tweak advanced deployment settings like the maximum number of pods that can be unavailable during the deployment
- Add, edit, or remove deployment lifecycle hooks
- Change the image being deployed
- Set a pull secret for the registry your image is being pulled from
- Add, edit, or remove environment variables for the pods that will be deployed
Many of the existing editing actions we supported still exist as separate actions, such as editing health checks, or configuring different resource limits. If you want to make a number of changes without triggering a deployment for each change, you can now Pause your deployment, make all the changes you want, and then Resume it. Pausing will prevent any deployment from happening, no matter whether it was automatically or manually triggered.
Quota Warnings
Users working within quota constraints had a hard time knowing when they had run out of quota, unless they went to check the Quota page. We wanted to add some checks for the most common scenarios where people have problems with quota. You’ll now get quota warnings:
- On the overview – this is a generic warning if anything in your quota is at its limit
- On the overview pod count visualizations – when we think you are unable to reach your scale target due to quota
- If you try to create something and we know you are out of quota for that resource
- If you try to create something and we think it will cause you to exceed quota for a resource
Managing project membership
An important feature for people that want to collaborate within the same projects, the new membership management interface lets you add and remove roles to users, groups, and service accounts within your project.
Project administrators have access to view and modify the project’s membership. Membership management is the only difference between an admin and an editor in the default OpenShift roles. Cluster administrators can add a description to any role to provide extra information for end users about what that role actually allows.
Bookmarkable Page States
Sometimes the little things can make all the difference. Have you been annoyed that you couldn’t send someone straight to the log tab for a pod? Now you can! Tab selection, label filters, and several other options that change page state are now persisted to the URL throughout the console. You can bookmark and share with others.
Keeping up with Kubernetes
As an Enterprise Kubernetes distribution, we want to allow our users to use new features without it negatively impacting their experience in the console. To that end we’ve been working on a number of new features from Kubernetes.
- Create storage using storage classes
- If your cluster admin sets up storage classes, then they will be available for you to pick from in the “Create Storage” page.
- Deployments and ReplicaSets
- Will fit in seamlessly on the overview alongside your existing Deployment Configurations
- Will appear on the Applications -> Deployments page
- Support many of the actions we already supported for Deployment Configurations (excluding the new editor)
- Roll-up of PetSet pods on the Overview – Note: PetSets are now StatefulSets in Kubernetes 1.5
- A PetSet’s pods will roll up into a single card with a pod count visualization like the other controllers
- You’ll be able to see metrics on the overview for the pods in the petset
Command Line Interface (CLI) Improvements
We can’t talk about usability improvements without mentioning all the efforts that went into the CLI to help those who interface directly with OpenShift through the CLI or need to use it to script a number of tasks.
A number of improvements that have been made in the user experience for the CLI include:
- Tab completion for commands (in both zsh and bash)
- Improved flow for many `oc` commands.
For example when a user logs in, or attempts to execute a command with the wrong arguments, the command’s output will help the user by suggesting the next steps they should take. - Global timeout flag across almost all `oc` commands
This helps when running various automated scripts, so there aren’t long timeouts when things are working as expected. - Better output format support / consistency for `oc` commands.
For example, making sure that all `oc set …` subcommands support `yaml`, `json`, and all other printer output formats. Also grouping multiple resources into a single list, so that they can be piped to other `oc` commands. - Help text overhaul, improving command descriptions, suggesting the contexts where commands can run (which types of resources apply to each command, etc), and adding responsiveness to terminal window resizing.
- Better feedback for users on secondary workflows.
For example, ‘oc get’ now prints “No resources found” when returning an empty list and ‘oc get all’ now features much improved readability. - Improved support for ‘oc’ when interacting with a raw Kubernetes server. Many of the basic ‘oc’ commands (like ‘get’, ‘describe’, ‘run’, and so on) now work properly against a Kubernetes REST API server.
- …and many more!
Keep the Feedback Coming
Is there a feature you really wish we would add, or some existing behavior that’s been bothering you? Get involved in the feedback loop! Development for the OpenShift management console happens in the openshift/origin-web-console GitHub repository, and we track our user stories in Trello.