More Goodness is Here!
The team continues to process feedback and turn it into improvements to the experience of OpenShift, the 3.5 release is no different. There are too many to list in this single blog post, so we’ll highlight a few here such as: “create from URL”, improved feedback messages, more kubernetes resources support and pipeline samples.
Create from URL
If you want a way to streamline how an end-user adds new applications or services to their project, you can now direct them using a flow you can control. This works in coordination with customizations on the OpenShift instance you target, to ensure you have appreciate templates (with no hidden surprises) and images.
You can define custom buttons
That leverage a defined URL pattern, with appropriate query string, such as:
Which would prompt the user to select the project and then the "Create from URL" flow continues
To get the full details on the feature and the URL query string parameters available, be sure to check out the documentation.
Additional Kubernetes Service Data
We sure do love our services in Kubernetes and OpenShift. To match that importance, we spent time redesigning and updating the service details page to provide streamlined information on a single page and not hidden in different tabs. Now you can easily see the routes associated with this service and some details about those routes, as well as all the associated pods and more!
ConfigMaps have been a very useful addition to Kubernetes (what am I saying, what feature isn’t useful in Kubernetes?), now the OpenShift web console provides specialized support for them. You can view details, edit or create new from a specialized editor.
You can even easily use ConfigMaps from other resources such as using a ConfigMap from Volumes in Deployments:
Kubernetes StatefulSets provide a way to define deployment requirements for clustered applications. In 3.5 we have provided a technology preview of this feature in OpenShift, including a dedicated experience for StatefulSets like resembles that of ReplicaSets.
Getting more help when things go wrong
Sometimes builds fail. Oh...ok, it happens a fair amount, especially in early stabilization phases. We’ve made it easier to understand what these issues are by surfaces the specific build errors.
In the web console we have surfaced up the message in the status field, such as the following shows where a build failed since it couldn’t fetch the source code:
Similarly the command line output for builds has been updated with a more detailed status:
CI/CD Pipelines Samples
We’ve expanded on our Jenkins pipeline samples to highlight a few key real world usages, such as:
- OpenShift Client Plugin sample showcases the fluent Jenkins pipeline syntax.
- Orchestration with sample mapsapp contains a pipeline that instantiates other pipelines and runs them. It shows how more than one pipeline can be launched in parallel and how a single Jenkins pipeline can work with multiple source code repositories.
- Maven slave sample contains a pipeline that uses a maven node to build and package a WAR.
- Blue Green deployment sample contains a pipeline that demonstrates alternating blue/green deployments with a manual approval step.
new-app & new-build pipeline aware
These commands have been updated to be pipeline aware. What that means is that it will now inspect the contents of the associated source code repository and determine if there is a Jenkinsfile, if so, it will create a BuildConfig of type JenkinsPipeline. There is also a way to force it, using the --strategy=pipeline flag.
Promoting Applications Across Environments Guide
A fair amount of work was done to investigate and document some of the alternatives that have been used at various customer engagements.
Application promotion means moving an application through various runtime environments, typically with an increasing level of maturity. For example, an application might start out in a development environment, then be promoted to a stage environment for further testing, before finally being promoted into a production environment. As changes are introduced in the application, again the changes will start in development and be promoted through stage and production. This guide, which is part of the OpenShift product documentation, articulates the concept of application and its boundaries, as well as strategies for promotion.
OpenShift developer experience continues to evolve to meet more and more enterprise needs for transforming application source code and binaries to a containerized application. Here are just some of the highlights of what is included in 3.5:
- Pulling in artifacts via `oc start-build --from-file=<some URL>`
- Provide SHA256 of produced image in build status
- Supply new-app/process/new-build parameters and env vars via a file
- Setting env vars on the objects created from a template
- Ability to use installer for configuring the build defaulter/override behavior
- Annotate secrets to clone source, so you don't need to manually add the secret to the build config after creating it
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.