anchor.diff:  ----
   ====
   
  -After adding the above configuration properties inside your `application.properties`, the `quarkus-kubernetes`, in combination with the `quarkus-kubernetes-service-binding` extension, automatically generates the `ServiceBinding` resource.
  -
  -The above mentioned `db-demo` property-configuration identifier now has  a double role  and also completes the following actions: :
  +After adding the earlier configuration properties inside your `application.properties`, the `quarkus-kubernetes`, in combination with the `quarkus-kubernetes-service-binding` extension, automatically generates the `ServiceBinding` resource.
  +
  +The earlier mentioned `db-demo` property-configuration identifier now has a double role and also completes the following actions:
   
   * Correlates and groups `api-version` and `kind` properties together
  -* Defines the `name` property for the custom resource with a possibility for a later edit:
  +* Defines the `name` property for the custom resource with a possibility for a later edit. For example:
   +
   [source,properties]
   ----
  
positive.code: 
  === Workload Projection
  
  Workload Projection is a process of obtaining a configuration for services from the Kubernetes cluster. Configuration has the form of a directory structure that follows certain conventions and is attached to an application or a service as volume mounts. The `kubernetes-service-binding` extension uses this directory structure to create configuration sources, which allows you to configure additional modules, such as databases or message brokers.
  
  During application development, users can use workload projection to connect their application to a dev-database, or other locally-run services, without changing the actual application code or configuration. 
  
  For an an example of a workload projection where the directory structure is included in the test resources and passed to integration test, see link:https://github.com/quarkusio/quarkus/tree/e7efe6b3efba91b9c4ae26f9318f8397e23e7505/integration-tests/kubernetes-service-binding-jdbc/src/test/resources/k8s-sb[here].
  
  [NOTE]
  ====
  * The `k8s-sb` directory is the root of all service bindings. In this example, only one database called `fruit-db` is intended to be bound. This binding database has the `type` file, that indicates `postgresql` as the database type, while the other files in the directory provide the necessary information to establish the connection. 
  
  * After your Quarkus project obtains information from `SERVICE_BINDING_ROOT` environment variables that are set by OpenShift, you  can locate generated configuration files that are present in the file system and use them to map the configuration-file values to properties of certain extensions.
  ====
  
  
  == Introduction to the Service Binding Operator
  
  The link:https://github.com/redhat-developer/service-binding-operator[Service Binding Operator] is an Operator that implements link:https://github.com/k8s-service-bindings/spec[Service Binding Specification for Kubernetes] and is meant to simplify the binding of services to an application. As mentioned above, containerized applications that support link:https://github.com/k8s-service-bindings/spec#workload-projection[Workload Projection] obtain service binding information in the form of volume mounts. The Service Binding Operator reads binding service information and mounts it to the application containers that need it.
  
  The correlation between application and bound services is expressed through the `ServiceBinding` resources, which declares the intent of what services are meant to be bound to what application.
  
  The Service Binding Operator watches for `ServiceBinding` resources, which inform the Operator what applications are meant to be bound with what services. When a listed application is deployed, the Service Binding Operator collects all the binding information that needs to be passed to the application, then upgrades the application container by attaching a volume mount with the binding information.
  
  The Service Binding Operator completes the following actions:
  
  * Observes `ServiceBinding` resources for workloads intended to be bound to a particular service
  * Applies the binding information to the workload using volume mounts
  
  The following chapter describes the automatic and semi-automatic service binding approaches and their use cases. With either approach,  the `kubernetes-service-binding` extension generates a  `ServiceBinding` resource. With the semi-automatic approach, users have to provide a configuration for target services manually. With the automatic approach, for a limited set of services generating the `ServiceBinding` resource, no additional configuration is needed.
  
  
  === Semi-automatic service binding
  
  To initiate a service binding process, a user needs to specify what services need to be bound to a certain application. This expression is summarized in the `ServiceBinding` resource that is generated by the `kubernetes-service-binding` extension. The use of the `kubernetes-service-binding` extensions helps users to generate `ServiceBinding` resources with minimal configuration, therefore simplifying the process overall.
  
  The Service Binding Operator responsible for the binding process then reads the information from the `ServiceBinding` resource and mounts the required files to a container accordingly.
  
  * An example of the `ServiceBinding` resource:
  +
  [source,yaml]
  ----
  apiVersion: binding.operators.coreos.com/v1alpha1
  kind: ServiceBinding
  metadata:
   name: binding-request
  
negative.code: 
  === Automatic service binding
  
  The `quarkus-kubernetes-service-binding` extension can generate the `ServiceBinding` resource automatically after detecting that an application requires access to the external services that are provided by available bindable Operators.
  
  NOTE: Automatic service binding can be generated for a limited number of service types. To be consistent with established terminology for Kubernetes and Quarkus services, this chapter refers to these service types as kinds.
  
  .Operators that support the service auto-binding
  [%autowidth,%noheader,stripes=even]
  