Release Notes

The OpenShift Container Platform provides a registry to manage container images. The most noticeable improvements to the registry in 3.3 are in the user interface and its deployment options. The registry can be deployed one of two ways: as an integrated registry in the OpenShift Container Platform web console or as a stand-alone registry.

Integrated Registry User Interface

The updated OpenShift Container Platform integrated registry provides details about the container images it manages and their tagged versions from within the OpenShift Container Platform web console. Each tag of an image stream, from the Builds → Images view, is now a hyperlink that leads to a multi-tabbed page with more information about the selected image.

Figure 2.1. Integrated Registry User Interface

The Details tab shows the image author, built-on date, digest hash ID, labels, annotations, and docker version for compatibility comparisons. The Config tab shows how the container image was built and its set of defined metadata labels. The Layers tab shows the size and digest ID for each layer of the image.

Figure 2.2. Integrated Registry User Interface: Details Tab

Stand-Alone Registry User Interface

The OpenShift Container Platform registry can alternatively be installed as a stand-alone container image registry to run on-premise or in the cloud, deployed as either an all-in-one cluster (running the master, node, etcd and registry components) or in a highly-available configuration (three hosts running all components on each, with the masters configured for native high-availability).

The web console of the stand-alone registry is based on the Cockpit project, with full API and CLI access. Traffic to/from the stand-alone registry is secured by default with TLS.

Figure 2.3. Stand-alone Registry User Interface: Details Tab

Figure 2.4. Stand-alone Registry User Interface: Image Metadata

This container image registry viewer provides a more "hub-like" direct access experience with registry images, and allows users to manage role-based access control (RBAC) to authorize image delivery on a per user and per project basis for oc policy and oc projects functionality right from within the user interface.

Figure 2.5. Stand-alone Registry User Interface: Project RBAC

It has its own built-in OAuth server for a single sign-on (SSO) user experience and is easily integrated with common enterprise and cloud identity providers. The stand-alone registry management interface also has flexible options for persistent storage of the images it manages and their metadata.

This new feature provides the ability to pull images from the OpenShift Container Platform integrated registry without a docker login, to facilitate automation and users who want the ability to simply pull an image.

To enable this, the project administrator (a user with the registry-admin role) can assign the registry-viewer role with the following command:

$ oc policy add-role-to-group registry-viewer system:unauthenticated

OpenShift Container Platform 3.3 adds a Google Cloud Storage (GCS) driver to enable its use as the storage back end for the registry’s container images. Prior to GCS driver initialization, the OpenShift Container Platform admin must set a bucket parameter to define the name of the GCS bucket to store objects in.

The OpenShift Container Platform 3.3 registry is based on Docker Distribution registry 2.4, and its features will be backported to OpenShift Container Platform 3.2. Version 2.4 of the registry includes a variety of performance and usability enhancements, notably:

Cross-repo Mounting When Pushing Images That Already Exist in the Registry

When a client wishes to push a blob to a target repository from a primary source, and knows that the blob already exists in a secondary source repository on the same server as the target, this feature gives the user the ability to optimize the push by requesting the server cross-mount the blob from the secondary source repository, speeding up push time.

Of course, the client must have proper authorizations (pull and push on the target repository, pull on the secondary source repository). If the client is not authorized to pull from the secondary source repository, the blob push will proceed, unoptimized, and the client will push the entire blob to the target repository from the primary source repository without assistance from the secondary source repository.

Support for the New schema 2 Storage Format for Images

The image manifest version 2, schema 2, introduces the ability to hash an image’s configuration and thus reduce manifest size, to create an ID for the image, and provide content-addressable information about the image.

Support for consuming schema 2 from external resources is enabled implicitly. However, images pushed to the internal registry will be converted to schema 1 for compatibility with older docker versions. For clusters not in need of compatibility preservation, accepting of schema 2 during pushes can be manually enabled:

$ oc login -u system:admin
$ oc set env dc/docker-registry -n default REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ACCEPTSCHEMA2=true

Manifest lists, introduced by schema 2 to provide support for multi-architecture images (e.g., amd64 versus ppc64le), are not yet supported in OpenShift Container Platform 3.3.

The OpenShift Container Platform integrated registry allows remote public and private images to be tagged into an image stream and "pulled-through" it, as if the image were already pushed to the OpenShift Container Platform registry. Authentication credentials required for private images to create the image stream are re-used by the integrated registry for subsequent pull-through requests to the remote registry.

The content-offload optimization configuration is still honored by pull-through requests. If the pull-through request points to a remote registry configured with both a storage back end (for example, GCS, S3, or Swift storage) and content-offload enabled, a redirect URL that points directly to the blobs on the remote back end storage will be passed through the local registry to the local docker daemon, creating a direct connection to the remote storage for the blobs.

To optimize image and blob lookups for pull-through requests, a small cache is kept in the registry to track which image streams have the manifest for the requested blobs, avoiding a potentially costly multi-server search.

Previously with CI/CD, it was possible to define small pipeline-like workflows, such as triggering deployments after a new image was built or building an image when upstream source code changed. OpenShift Pipelines (currently in Technology Preview) now expose a true first class pipeline execution capability. OpenShift Pipelines are based on the Jenkins Pipeline plug-in. By integrating Jenkins Pipelines into OpenShift, you can now leverage the full power and flexibility of the Jenkins ecosystem while managing your workflow from within OpenShift.

Pipelines are defined as a new build strategy within OpenShift Container Platform, meaning you can start, cancel, and view your pipelines in the same way as any other build. Because your pipeline is executed by Jenkins, you can also use the Jenkins console to view and manage your pipeline.

Finally, your pipelines can utilize the OpenShift Pipeline plug-in to easily perform first class actions in your OpenShift Container Platform cluster, such as triggering builds and deployments, tagging images, or verifying application status.

To keep the system fully integrated, the Jenkins server executing your pipeline can run within your cluster, launch Jenkins slaves on that same cluster, and OpenShift Container Platform can even automatically deploy a Jenkins server if one does not already exist when you first declare a new pipeline build configuration.

See the following for more on pipelines:

The Jenkins plug-in now provides full integration with the Jenkins Pipeline, exposing the same OpenShift Container Platform build steps available in the classic, "freestyle" jobs as Jenkins Pipeline DSL methods (replacing the Java language invocations previously available from the Jenkins Pipeline Groovy scripts).

Several user requested features have also been introduced, including:

Often a developer will want to have a stand-alone OpenShift Container Platform instance running on their desktop to enable evaluation of various features or developer and testing locally of their containerized applications containers. Launching a local instance of OpenShift Container Platform for application development is now as easy as downloading the latest client tools and running:

$ oc cluster up

This provides a running cluster using your local docker daemon or Docker Machine. All the basic infrastructure of the cluster is automatically configured for you: a registry, router, image streams for standard images, and sample templates.

It also creates a normal user and system administrator accounts for managing the cluster.

Prior to OpenShift Container Platform 3.3, if multiple builds were created for a given build configuration, they all ran in parallel. This resulted in a race to the finish, with the last build to push an application image to the registry winning. This also lead to higher resource utilization peaks when multiple builds ran at the same time.

Now with OpenShift Container Platform 3.3, builds run serially by default. It is still possible to revert to the parallel build policy if desired. In addition, the new SerialLatestOnly policy runs builds in serial, but skips intermediary builds. In other words, if build 1 is running and builds 2, 3, 4, and 5 are in the queue, when build 1 completes the system will cancel builds 2 through 4 and immediately run build 5. This allows you to optimize your build system around building the latest code and not waste time building intermediate commits.

For more information, see Build Run Policy.

The oc rsync command was added previously, allowing synchronizing of a local file system to a running container. This is a very useful tool for copying files into a container in general, but in particular it can be used to synchronize local source code into a running application framework. For frameworks that support hot deployment when files change, this enables an extremely responsive "code, save, debug" workflow with source on the developer’s machine using the their IDE of choice, while the application runs in the cloud with access to any service it depends on, such as databases.

This sync flow is made even easier with this release by coupling it with a file system watch. Instead of manually syncing changes, developers can now run oc rsync --watch, which launches a long running process that monitors the local file system for changes and continuously syncs them to the target container. Assuming the target container is running a framework that supports hot reload of source code, the development workflow is now: "save file in IDE, reload application page in browser, see changes."

For more information, see Continuous Syncing on File Change.

While OpenShift Container Platform has always automatically run a build of your application when source changes or an upstream image that your application is built on top of has been updated, prior to OpenShift Container Platform 3.3 it was not easy to know why your application had been rebuilt. With OpenShift Container Platform 3.3, builds now include information explaining what triggered the build (manual, image change, webhook, etc.) as well as details about the change, such as the image or commit ID associated with the change.

A build triggered by an image change

Output provided by CLI command oc describe build:

$ oc describe build ruby-sample-build-2
Name: ruby-sample-build-2
…………….
Status: Running
Started: Fri, 09 Sep 2016 16:39:46 EDT
Duration: running for 10s
Build Config: ruby-sample-build
Build Pod: ruby-sample-build-2-build

Strategy: Source
URL: https://github.com/openshift/ruby-hello-world.git
From Image: DockerImage centos/ruby-23-centos7@sha256:940584acbbfb0347272112d2eb95574625c0c60b4e2fdadb139de5859cf754bf
Output to: ImageStreamTag origin-ruby-sample:latest
Post Commit Hook: ["", "bundle", "exec", "rake", "test"]
Push Secret: builder-dockercfg-awr0v

Build trigger cause:Image change
Image ID:centos/ruby-23-centos7@sha256:940584acbbfb0347272112d2eb95574625c0c60b4e2fdadb139de5859cf754bf
Image Name/Kind: ruby:latest / ImageStreamTag

Then, within the web console:

Figure 2.6. Build Triggered by Image Change

A build triggered by a webhook

Output provided by CLI command oc describe build:

$ oc describe build mynodejs-4
Name: mynodejs-4
…………...
Status: Complete
Started: Mon, 12 Sep 2016 04:57:44 EDT
Duration: 20s
Build Config: mynodejs
Build Pod: mynodejs-4-build

Strategy: Source
URL: https://github.com/bparees/nodejs-ex.git
Ref: master
Commit: 7fe8ad9 (update welcome page text)
Author/Committer: Ben Parees
From Image: DockerImage centos/nodejs-4-centos7@sha256:f525982280a22eb35c48bac38ee5dc65d545ac0431ce152e351d7efa0a34a82d
Output to: ImageStreamTag mynodejs:latest
Push Secret: builder-dockercfg-nt9xq

Build trigger cause:GitHub WebHook
Commit:7fe8ad9 (update welcome page text)
Author/Committer:Ben Parees
Secret: 34c64fd2***

Then, within the web console:

Figure 2.7. Build Triggered by Webhook

It is now possible to provide additional inputs to webhook triggered builds. Previously, the generic webhook simply started a new build with all the default values inherited from the build configuration. It is now possible to provide a payload to the webhook API.

The payload can provide Git information so that a specific commit or branch can be built. Environment variables can also be provided in the payload. Those environment variables are made available to the build in the same way as environment variables defined in the build configuration.

For examples of how to define a payload and invoke the webhook, see Generic Webhooks.

OpenShift Container Platform provides a number of framework images for working with Java, Ruby, PHP, Python, NodeJS, and Perl code. It also provides a few database images (MySQL, MongoDB, PostgreSQL) out of the box. For OpenShift Container Platform 3.3, these images are improved by making them self-tuning.

Based on the container memory limits specified when the images are deployed, these images will automatically configure parameters like heap sizes, cache sizes, number of worker threads, and more. All these automatically-tuned values can easily be overridden by environment variables, as well.

The web console’s Overview is the landing page for your project. At a glance, you should be able to see what is running in your project, how things are related, and what state they are in. To that end, the re-designed overview now includes the following:

Figure 2.8. New Project Overview

Previously, most of the concepts in OpenShift Container Platform were hidden underneath a generic Browse menu. An exercise to define the information architecture resulted in the new left sidebar project navigation.

A new set of pages have been added dedicated to the new OpenShift Pipelines feature (currently in Technology Preview) that allow you to visualize your pipeline’s stages, edit the configuration, and manually kick off a build. Pipelines paused waiting for manual user intervention provide a link to the Jenkins pipeline interface.

Figure 2.9. OpenShift Pipelines Details

Running or recently completed pipeline builds also show up on the new Overview page if they are related to a deployment configuration.

Figure 2.10. Project Overview with Pipelines

Because OpenShift Pipelines are currently in Technology Preview, you must enable pipelines in the primary navigation of the web console to use this feature. See Enabling Features in Technology Preview for instructions.

In OpenShift Container Platform 3.3, routes can now point to multiple back end services, commonly called A/B deployments. Routes configured in this way will automatically group the related services and visualize the percentage of traffic configured to go to each one.

Figure 2.11. A/B Routes

Modifying the route’s back end services can be done in the new GUI editor, which also lets you change the route’s target ports, path, and TLS settings.

The Add to Project page now a Deploy Image option. The behavior is similar to the oc run command, allowing you to pick any existing image or tag from an image stream, or to look for an image using a docker pull spec. After you have picked an image, it generates the service, deployment configuration, and an image stream if it is from a pull spec.

Figure 2.12. Deploy Image

You can also take advantage of the new and improved key value editor for environment variables and labels.

The Add to Project page now has an Import YAML / JSON option, which behaves like the oc create -f command. You can paste, upload, or drag and drop your file, and even edit the YAML or JSON before submitting it. If your file contained a template resource, you can choose whether you want to create and/or process the template resource.

Figure 2.13. Import YAML / JSON

Processing a template goes to the existing experience for creating from a template, and now supports showing a message to the user on the next steps page. This message can be defined by the template author and can include generated parameters like passwords and other keys.

The Other Resources page gives you access to all the other content that exists in your project that do not have dedicated pages yet. You can select the type of resource you want to list and get actions to Edit YAML (similar to oc edit) and Delete. Due to a new feature that has been applied to the whole web console, only the resource types you have permission to list are shown, and only actions that you can actually perform.

Figure 2.14. Other Resources

While the Overview provides some simple metrics and pod status, the new Monitoring page provides a deeper dive into the logs, metrics, and events happening in your project.

Figure 2.15. Monitoring

Metrics and logs both received some minor improvements including:

When a pod’s containers are not starting cleanly, a link is now shown on the pod details page to debug it in a terminal. This starts a pod with identical settings, but changes the container’s entrypoint to /bin/sh instead, giving you access to the runtime environment of the container.

Figure 2.16. Debugging

A number of small improvements to the container terminal have also been added that create a smoother experience, including:

Figure 2.17. Terminal

Before OpenShift Container Platform 3.3, there was no information in the web console about the images in your image streams, aside from the SHAs. This made it difficult to know the specifics of how your image was defined unless you used the CLI. Now, for any image stream tag you can see the metadata, cofiguration, and layers.

Figure 2.18. Image Stream Tag Details

Figure 2.19. Image Stream Tag Configuration

Platform administrators can now identify a node in the cluster and allocate a number of static IP addresses to the node at the host level. If a developer needs an unchanging source IP for their application service, they can request access to one during the process they use to ask for firewall access. Platform administrators can then deploy an egress router from the developer’s project, leveraging a nodeSelector in the deployment configuration to ensure the pod lands on the host with the pre-allocated static IP address.

The egress pod’s deployment declares one of the source IPs, the destination IP of the protected service, and a gateway IP to reach the destination. After the pod is deployed, the platform administrator can create a service to access the egress router pod. They then add that source IP to the corporate firewall and close out the ticket. The developer then has access information to the egress router service that was created in their project (e.g., service.project.cluster.domainname.com).

When the developer would like to reach the external, firewalled service, they can call out to the ergress router pod’s service (e.g., service.project.cluster.domainname.com) in their application (e.g., the JDBC connection information) rather than the actual protected service url.

See Controlling Egress Traffic for more details.

OpenShift Container Platform offers a multi-tenant, docker-compliant platform. Thousands of tenants can be placed on the platform, some of which may be subsidiary corporations or have drastically different affiliations. With such diversity, often times business rules and regulatory requirements will dictate that tenants not flow through the same routing tier.

To solve this issue, OpenShift Container Platform 3.3 introduces router sharding. With router sharding, a platform administrator can group specific routes or namespaces into shards and then assign those shards to routers that may be up and running on the platform or be external to the platform. This allows tenants to have separation of egress traffic at the routing tiers.

OpenShift Container Platform has always been able to support non-standard TCP ports via SNI routing with SSL. As the internet of things (IoT) has exploded, so to has the need to speak to dumb devices or aggregation points without SNI routing. At the same time, with more and more people running data sources (such as databases) on OpenShift Container Platform, many more people want to expose ports other than 80 or 433 for their applications so that people outside of the platform can leverage their service.

Previously, the solution for this in Kubernetes was to leverage NodePorts or External IPs. The problem with NodePorts is that only one developer can have the port on all the nodes in the cluster. The problem with External IPs is that duplications can be common if the administrator is not carefully assigning them out.

OpenShift Container Platform 3.3 solves this problem through the clever use of edge routers. Platform administrators can either select one or more of the nodes (more than one for high availability) in the cluster to become edge routers or they can just run additional pods on the HAProxy nodes.

For example, a platform administrator can run additional pods that are ipfailover pods. A pool of available Ingress IPs are specified that are routable to the nodes in the cluster and resolvable externally via the corporate DNS. This pool of IP addresses are served out to developers who want to use a port other than 80 and 433. In these use cases, there are services outside of the cluster trying to connect to services inside the cluster that are running on ports other than 80 or 433. This means they are coming into the cluster (ingress) as opposed to leaving the cluster (egress). By resolving through the edge routers, the cluster can ensure each developers gets their desired port by pairing it with a Ingress IP from the available pool rather than giving them a random port.

In order to trigger this allocation of an Ingress IP, the developer declares a LoadBalancer type in their service definition for their application. Afterwards, they can use the oc get <service_name> command to see what Ingress IP was assigned to them. See Getting Traffic into the Cluster for details.

OpenShift Container Platform 3.3 adds service lists to routes, making it easier to perform A/B testing. Each route can now have multiple services assigned to it, and those services can come from different applications or pods.

New automation enables HAProxy to be able to read weight annotations on the route for the services. This enables developers to declare traffic flow (for example, 70% to application A and 30% to application B) using the CLI or web console.

See Load Balancing for A/B Testing for more details.

The seccomp feature in Red Hat Enterprise Linux (RHEL) has been enabled for docker 1.10 or higher. This feature allows containers to define interactions with the kernel using syscall filtering. This reduces the risk of a malicious container exploiting a kernel vulnerability, thereby reducing the guest attack surface.

OpenShift Container Platform adds the ability to create seccomp policies with security context constraints (SCCs). This allows platform administrators to set SCC policies on developers that imposes a filter on their containers for Linux-level system calls.

See the Authorization concept for more details.

The oc client on Linux can now recognize and handle the kinit process of generating a Kerberos ticket during developer interactions with the CLI. For example:

$ kinit <user>@<domain>
$ oc login <openshift_master>

OpenShift Container Platform leverages TLS encryption and token-based authentication between its framework components. In order to accelerate and ease the installation of the product, certificates are self-signed during automated installation.

OpenShift Container Platform 3.3 adds the ability to update and change those certificates that govern the communication between framework components. This allows platform administrators to more easily maintain the life cycles of their OpenShift Container Platform installations.

See Redeploying Certificates for more details.

OpenShift Container Platform 3.3 allows platform administrators more control over what happens over the lifecycle of the workload on the cluster after the process (container) is started. By leveraging limits and request setting at deployment time, the cluster can determine automatically how the developer wants their workload handled in terms of resources. Three positions can be taken:

The decision to evict is a configurable setting. Platform administrators can turn on the ability to hand a pod (container) back to the scheduler for re-deployment on a different node should out of memory errors start to occur.

1000 nodes per cluster at 250 pods per node (with a recommendation of 10 pods per hyper-threaded core) are now supported. See Sizing Considerations for more details.

OpenShift Container Platform 3.3 adds an API to idle an application’s pods (containers). This allows for monitoring solutions to call the API when a threshold to a metric of interest is crossed. At the routing tier, the HAProxy holds the declared route URL that is connected to the service open and the pods are shut down. Should someone hit this application URL, the pods are re-launched on available resources in the cluster and connected to the existing route.

OpenShift Container Platform already included the ability to offer remote persistence block and file based storage, and this release adds the ability for developers to select a storage provider on the cluster in a more granular manner using storage labels. Storage labels help developers call out to a specific provider in a simple manner by adding a label request to their persistent volume claim (PVC).

See Binding Persistent Volumes by Labels for example usage.

A new log curator utility helps platform administrators deal with the storage requirements of storing tenant logs over time.

Integration with existing ELK stacks you might already own or be invested in has also been enhanced by allowing logs to more easily be sent to multiple locations.

This release adds network usage attributes to the core metrics tracked for tenants. Metrics deployment is also now a core installation feature instead of a post-installation activity. The OpenShift Container Platform installer now guides you through the Ansible playbooks required to successfully deploy metrics, thus driving more usage of the feature in the user interface and Red Hat CloudForms.

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

OpenShift Container Platform whitelists a subset of namespaced sysctls for use in pods:

These whitelisted sysctls are considered safe and supported because they cannot be misused to influence other containers, for example by blocking resources like memory outside of the pods' defined memory limits. If a namespaced sysctl is not whitelisted, it is considered unsafe.

See Sysctls for more details and usage information.

As a result, users can bypass the certificate error and log in with --insecure-skip-tls-verify.

To apply this update, run the following on all hosts where you intend to initiate Ansible-based installation or upgrade procedures:

# yum update atomic-openshift-utils

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

To apply this update, run the following on all hosts where you intend to initiate Ansible-based installation or upgrade procedures:

# yum update atomic-openshift-utils

This release fixes bugs for the following components:

Installer

Upgrades

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

This release fixes bugs for the following components:

Metrics

Storage

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

This release updates the Red Hat Container Registry (registry.access.redhat.com) with the following images:

openshift3/ose-pod:v3.3.1.35-2
rhel7/pod-infrastructure:v3.3.1.35-2
openshift3/ose:v3.3.1.35-2
openshift3/ose-docker-registry:v3.3.1.35-2
openshift3/ose-egress-router:v3.3.1.35-2
openshift3/ose-keepalived-ipfailover:v3.3.1.35-2
openshift3/ose-f5-router:v3.3.1.35-2
openshift3/ose-deployer:v3.3.1.35-2
openshift3/ose-haproxy-router:v3.3.1.35-2
openshift3/node:v3.3.1.35-2
openshift3/ose-recycler:v3.3.1.35-2
openshift3/ose-sti-builder:v3.3.1.35-2
openshift3/ose-docker-builder:v3.3.1.35-2
openshift3/logging-deployer:v3.3.1.35-2
openshift3/metrics-deployer:v3.3.1.35-2
openshift3/openvswitch:v3.3.1.35-2
openshift3/logging-auth-proxy:3.3.1-16
openshift3/logging-curator:3.3.1-16
openshift3/logging-elasticsearch:3.3.1-16
openshift3/logging-fluentd:3.3.1-17
openshift3/logging-kibana:3.3.1-16
openshift3/metrics-cassandra:3.3.1-17
openshift3/metrics-hawkular-metrics:3.3.1-17
openshift3/metrics-heapster:3.3.1-18
openshift3/registry-console:3.3-20

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

To apply this update, run the following on all hosts where you intend to initiate Ansible-based installation or upgrade procedures:

# yum update atomic-openshift-utils

This release updates the Red Hat Container Registry (registry.access.redhat.com) with the following images:

openshift3/ose-pod:v3.3.1.46.11-3
rhel7/pod-infrastructure:v3.3.1.46.11-3
openshift3/ose-ansible:v3.3.1.46.11-3
openshift3/ose:v3.3.1.46.11-3
openshift3/ose-docker-registry:v3.3.1.46.11-3
openshift3/ose-egress-router:v3.3.1.46.11-3
openshift3/ose-keepalived-ipfailover:v3.3.1.46.11-3
openshift3/ose-f5-router:v3.3.1.46.11-3
openshift3/ose-deployer:v3.3.1.46.11-3
openshift3/ose-haproxy-router:v3.3.1.46.11-3
openshift3/node:v3.3.1.46.11-3
openshift3/ose-recycler:v3.3.1.46.11-3
openshift3/ose-sti-builder:v3.3.1.46.11-3
openshift3/ose-docker-builder:v3.3.1.46.11-3
openshift3/logging-deployer:v3.3.1.46.11-3
openshift3/logging-curator:v3.3.1.46.13-3
openshift3/metrics-deployer:v3.3.1.46.11-3
openshift3/openvswitch:v3.3.1.46.11-3
openshift3/logging-auth-proxy:3.3.1-22
openshift3/logging-elasticsearch:3.3.1-22
openshift3/logging-fluentd:3.3.1-23
openshift3/logging-kibana:3.3.1-22
openshift3/metrics-cassandra:3.3.1-25
openshift3/metrics-hawkular-metrics:3.3.1-25
openshift3/metrics-heapster:3.3.1-24
openshift3/registry-console:3.3-28

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.

To upgrade an existing OpenShift Container Platform 3.2 or 3.3 cluster to this latest release, use the automated upgrade playbook. See Performing Automated In-place Cluster Upgrades for instructions.