anchor.diff:  quarkus.openshift.env.fields.foo=metadata.name
   ----
   
  -===== Using Deployment instead of DeploymentConfig
  +==== Using Deployment instead of DeploymentConfig
   Out of the box the extension will generate a `DeploymentConfig` resource. Often users, prefer to use `Deployment` as the main deployment resource, but still make use of Openshift specific resources like `Route`, `BuildConfig` etc.
   This feature is enabled by setting `quarkus.openshift.deployment-kind` to `Deployment`.
   
  
positive.code: * JDK 11+ installed with `JAVA_HOME` configured appropriately
  * Apache Maven {maven-version}
  * access to an OpenShift cluster (Minishift is a viable option)
  * OpenShift CLI (Optional. Only required for manually deploying)
  
  == Creating the Maven project
  
  First, we need a new project that contains the OpenShift extension. This can be done using the following command:
  
  
negative.code: For more information, see link:https://quarkus.io/guides/deploying-to-kubernetes#client-connection-configuration[deploying to kubernetes].
  ====
  
  Once the build is done we can create a new application from the relevant `ImageStream`.
  
  [source,bash,subs=attributes+]
  ----
  oc get is <1>
  oc new-app --name=greeting <project>/openshift-quickstart:1.0.0-SNAPSHOT <2>
  oc get svc
  oc expose svc/greeting <3>
  oc get routes <4>
  curl http://<route>/greeting <5>
  ----
  <1> Lists the image streams created. The image stream of our application should be tagged as <project>/openshift-quickstart:1.0.0-SNAPSHOT.
  <2> Create a new application from the image source.
  <3> Expose the service to the outside world.
  <4> Get the list of exposed routes.
  <5> Access your application.
  
  After this setup the next time the container image is built a deployment to OpenShift is triggered automatically.
  In other words, you don't need to repeat the above steps.
  
  === Non-S2I Builds
  
  Out of the box the OpenShift extension is configured to use link:container-image#s2i[container-image-s2i]. However, it's still possible to use other container image extensions like:
  
  - link:container-image#docker[container-image-docker]
  - link:container-image#jib[container-image-jib]
  
  When a non-s2i container image extension is used, an `ImageStream` is created that is pointing to an external `dockerImageRepository`. The image is built and pushed to the registry and the `ImageStream` populates the tags that are available in the `dockerImageRepository`. 
  
  To select which extension will be used for building the image:
  
  