anchor.diff:  
   * Previous versions allowed the user to specify `*AWS_ACCESS_KEY_ID*` and `*AWS_SECRET_ACCESS_KEY*` in their *_/etc/sysconfig/_* files for {product-title} services. During upgrade, these files were updated according to a template, and if the user had not yet switched to using the new cloud provider framework their pre-existing AWS variables would be overwritten. The upgrade process has been modified to preserve these variables if they are present during upgrade, and a cloud provider is not configured. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1353354[*BZ#1353354*])
   
  -* Previously, a bug in a script which cleans out all pre-existing images and containers during a *docker* 1.10 upgrade would cause the script to miss some images with name and tag *none*, potentially resulting in a slower or failed *docker* upgrade. This script has been updated to use a more robust method of clean-up which also catches orphaned images. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1351406[*BZ#1351406*])
  +* Previously, a bug in a script that cleans out all pre-existing images and containers during a *docker* 1.10 upgrade would cause the script to miss some images with name and tag *none*, potentially resulting in a slower or failed *docker* upgrade. This script has been updated to use a more robust method of clean-up which also catches orphaned images. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1351406[*BZ#1351406*])
   
   * Previously, nodes had their schedulability state reset to the state defined in the inventory used during an upgrade. If the scheduling state had been modified since the inventory file was created, this would be a surprise to administrators. The upgrade process has been modified to preserve the current schedulability state during upgrade so that nodes do not change state after an upgrade. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1372594[*BZ#1372594*])
   
  
positive.code: 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.
  
  
negative.code: [[ocp-33-pipelines]]
  ==== Pipelines (Technology Preview)
  
  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) expose a true first class pipeline execution capability. OpenShift Pipelines are based on the link:https://jenkins.io/solutions/pipeline/[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.
  
  [NOTE]
  ====
  