Skip to content

v1.1.2
Compare
Choose a tag to compare
@smarterclayton smarterclayton released this 07 Feb 01:42
· 29032 commits to master since this release
v1.1.2
2711160

This is a feature release on the OpenShift Origin 1.1.x stream.

Compatibility with previous releases

API Changes

  • Due to a change in the upstream JSON serialization path used in Kubernetes, some fields that were previously accepted case-insensitively are no longer accepted. Please validate that your API objects have the correct case for all attributes
  • When creating a deployment config, omitting the spec.selector will default that value to the pod template labels

Features

Updated to Kubernetes 1.2.0-dev from late January

This release includes an update to be based on Kubernetes 1.2.0 dev openshift/kubernetes@9caf0a7 (thanks @deads2k, @liggitt, and @soltysh)

Highlighted features:

  • Addition of kubectl create namespace and kubectl create secrets, making it easier to create those resources directly. oc secrets will be replaced over time with additions to oc create secrets.
  • Secrets can now be injected as environment variables using the secretKeyRef field making consumption of secrets in applications easier.
  • DaemonSets are enabled in Origin now that the API has been stabilized.

We anticipate one more rebase prior to 1.2.0 Origin onto 1.2.0 Kube rc0.

Updated etcd to v2.2.2

Carries performance improvements.

Build secrets and image sources

  • Edit build configurations directly from the web console
    bc-edit
  • Builds can now be supplied with input files from unrelated images. Previously all input to a build had to come from the builder image itself, or a git repository. It is now possible to specify additional images and paths within those images to use as an input to a build for things like external dependencies.

Use the --source-image=IMAGE and --source-image-path=SRC:DST flags to oc new-build to specify images.

The example shown below will inject the /usr/lib/jenkins/jenkins.war file out of the image currently tagged with jenkins:latest into the installed-apps directory of the build input.

apiVersion: v1
kind: BuildConfig
metadata:
  name: imagedockerbuild
spec:
  source:
    images:
    - from:
        kind: ImageStreamTag
        name: jenkins:latest
      paths:
      - destinationDir: installed-apps/
        sourcePath: /usr/lib/jenkins/jenkins.war

Be sure to set an image change trigger for jenkins:latest if you want to rebuild every time that image is updated.

  • Builds can now be supplied with secrets for use during the build prcoess. Previously secrets could be used for git cloning but now secrets can also be made available to the build process itself so that build operations such as maven packaging can use a secret for credentials.
  • Builds now properly use Git submodules when checking out the source repository - thanks to @paralin
  • When a build configuration is deleted (via oc delete), all associated Builds are now deleted as well. To prevent this behavior, specify --cascade=false.
  • Custom build configurations can now specify the API version to use. This API version will determine the schema version used for the serialized build configuration supplied to the custom build pod in the BUILD environment variable.
  • Resource limits are now enforced on the container launched by S2I builds, and also on the operations performed within containers as part of a docker build of a Dockerfile. (Previously the resource limit only applied to the build pod itself and not the containers spawned by the build process)

Import images with authentication, schedule image import, and image pullthrough

  • You can now import images from Docker v2 registries that are authenticated via Basic or Token credentials. To import, create a secret in your project based on a .docker/config.json or .dockercfg file:
$ oc secrets new hub .dockerconfigjson=$HOME/.docker/config.json
Created secret/hub
$ oc import-image auth-protected/image-from-dockerhub
The import completed successfully.

Name:       image-from-dockerhub
Created:    Less than a second ago

Tag     Spec                                 Created
latest  default/image-from-dockerhub:latest  Less than a second ago ...

When importing, all secrets in your project of those types will be checked. To exclude a secret from being a candidate for importing, use the openshift.io/image.excludeSecret annotation set to true:

$ oc annotate secret/hub openshift.io/image.excludeSecret=true
  • Image stream tags can be set to be automatically imported from remote repositories when they change (public or private). OpenShift will periodically query the remote registry and check for updates depending on the configuration the administrator sets. By default, images will be checked every 15 minutes.

To set an image to be imported automatically, used the --scheduled flag with the oc tag command:

$ oc tag --source=docker redis:latest myredis:latest --scheduled
Tag myredis:latest set to import redis:latest periodically.

You can see which images are being scheduled using oc describe is myredis.

Administrators can control whether scheduling is enabled, the polling interval, and the rate at which images can be imported via the imagePolicyConfig section in the master configuration.

  • The integrated Docker registry now supports "image pullthrough", allowing you to tag a remote image into OpenShift and directly pull it from the integrated registry as if it were already pushed to the OpenShift registry. If the remote registry is configured to use content-offload (sending back a temporary redirect URL to the actual binary contents), that value will be passed through the OpenShift registry and down to the Docker daemon, avoiding the need to proxy the binary contents.

To try pullthrough, tag an image from the DockerHub and then pull it from the integrated registry:

$ oc tag --source=docker redis:latest redis:local
$ oc get is redis
NAME      DOCKER REPO                     TAGS     UPDATED
mysql     172.30.1.5:5000/default/redis   local    Less than a second ago

# log into your local docker registry
$ docker pull 127.30.1.5:5000/default/redis:local
Using default tag: local
Trying to pull repository 127.30.1.5:5000/default/redis ... latest: Pulling from 127.30.1.5:5000/default/redis
47d44cb6f252: Pull complete 
838c1c5c4f83: Pull complete 
5764f0a31317: Pull complete 
60e65a8e4030: Pull complete 
449f8db3c25a: Pull complete 
a6b6487c42f6: Pull complete 
Digest: sha256:c541c66a86b0715bfbb89c5515929268196b642551beccf8fbd452bb00170cde
Status: Downloaded newer image for 127.30.1.5:5000/default/redis:local

You can use pullthrough with private images - the integrated registry will use the same secret you imported the image with to fetch content from the remote registry.

  • Imported images now contain the size of the image as well as the individual layers and size of each layer and report that in describe
  • When importing an entire remote repository, only the first 5 tags will be imported by default. OpenShift will preferentially import the latest tag and the highest semantically versioned tag (tags in the form v5, 5.0, or 5.0.1). You can import the remaining tags directly. Lists of tags will be sorted with the latest tag on top, followed by the highest major semantic tag, in descending order.

Integrated Docker registry

  • The integrated registry now supports Azure Blob Storage, OpenStack Swift, and Amazon CloudFront as storage backends
  • A readiness and health check have been added to the integrated registry to ensure new instances do not serve traffic until they are fully initialized.

Test deployments and improvements to the Recreate strategy

  • It is now possible to create a "test" deployment that will scale itself down to zero when a deployment is complete. This deployment can be used to verify that an image will be correctly rolled out without requiring the pods to be running all the time. To create a test deployment, use the --as-test flag on oc new-app or set the spec.test field of a deployment config to true via oc edit.

The deployment will trigger like any other deployment config, scaling up to the current spec.replicas value when triggered, and then once the deployment has completed (success or failure) it will be scaled down to zero. You can use deployment hooks to test or verify the deployment - since hooks run as part of the deployment process, a test suite running in your hook can ensure your application is correct and pass or fail the deployment. You can add a local database or other test container to the deployment pod template, and have your application code verify itself before passing to the next step.

Scaling a test deployment will only affect the next deployment.

  • The Recreate strategy now supports mid hooks which run while all old pods have been scaled down and before any new pods are scaled up - use it to run migrations or config changes that can only happen while the application is completely shut down.
  • The Recreate strategy now has the same behavior as the Rolling strategy - requiring the pod to be "ready" before continuing with the deployment. A new field timeoutSeconds was added to the strategy that is the maximum allowed interval between pods becoming ready - it defaults to 120s.

Web console

  • The console theme has been updated and refined.
    overview
  • Display limits and quota information in the web console for all resources, including fine grained control on each containerresource-limits
  • Templates containing Jobs, DaemonSets, HorizontalPodAutoscalers, and other non-core Kubernetes resources can now be instantiated in the web console
  • Allow users to hit a customized branded page before continuing on to a login identity provider. This allows users to see your branding up front instead of immediately redirecting to identity providers like Github and Google.
  • Project names and descriptions can be edited from the settings page
  • Pod, replication controller, and deployment configuration environment variables are editable
  • A new "About" page allows administrators to show download client links and provides information about the server.about

Command line

  • Display more information about the application being created in oc new-app, including any display name or description set on the image as a label, or whether the image may require running as root.
  • If you have set up the latest tag in an image stream to point to another tag in the same image stream, the oc new-app command will follow that reference and create the application using the referenced tag, not latest. This allows administrators to ensure applications are created on stable tags (like php:5.6). The default image streams created in the openshift project follow this pattern.
  • Administrators can pass the --all-namespaces flag to oc status to see status information across all namespaces (WARNING: this will generate a lot of output!)
  • You can view the logs of the oldest pod in a deployment or build config with oc logs dc/NAME
  • The oc env and oc volume commands have been moved to oc set env and oc set volume, and future commands that modify aspects of existing resources will be located under this command.
  • Improve the help output of the oadm policy command.

Storage

  • The NoDiskConflicts scheduling predicate can be added to the scheduler configuration to ensure that pods using the same Ceph RBD device are not placed on the same node. See the help topic on customizing the scheduler for more information.

Security

  • When a pod is crashlooping, display an error in oc status and provide more information about possible causes.
  • By default, the restricted and anyuid security context constraints drop Linux capabilities that could be used to escalate container privileges. Administrators can change the list of default or enforced capabilities.
  • Use a constant-time string comparison on web-hooks - thanks @elyscape
  • Only users authenticated via OAuth can request projects
  • A GitLab server can be used as an identity provider - thanks @fh1ch

Routes

  • Create routes directly via oc create route edge|passthrough|reencrypt, allowing you to specify the secret values to be used for the route.
  • You can limit the frequency of router reloads using the --interval=DURATION flag or RELOAD_INTERVAL environment variable to the router. This can minimize the memory and CPU used by the router while reloading, at the cost of delaying when the route is exposed via the router.

Configuration and Administration

  • The set of admission controllers in use may be configured by an administrator in the master configuration.
  • openshift ex diagnostics can now launch a diagnostic pod that reports on more potential issues with pod networking, DNS configuration, and registry authentication
  • The amount of projects an individual user can create can be limited via the ProjectRequestQuota admission controller
  • A build defaults admission controller can be used to set default environment variables on all builds created, including proxy settings.

Bugs fixed

  • Passthrough routes may not be specified with paths - since passthrough does not decode the route there is no way for the router to check the path without decoding the request. oc status will now warn you if you have any such routes.
  • oc new-app now returns more information about errors encountered while searching for matches to user input
  • When using images from registries that are not the DockerHub, don't insert the library prefix.
  • The image ID returned from the ImageStreamImage API was not the correct value.
  • The router health check was not correct on all systems when using host networking - it now defaults to using localhost
  • OAuth client secrets are not reset in HA master configurations
Assets 7
Loading