Revert "Merge pull request openshift#41809 from Srivaralakshmi/Refact…

…orGettingStartedSBO"

This reverts commit 1816807, reversing
changes made to 08d83aa.

applications/connecting_applications_to_services/binding-workloads-using-sbo.adoc

@@ -7,27 +7,29 @@ include::modules/servicebinding-document-attributes.adoc[]
 
 toc::[]
 
-[role="_abstract"]
 Application developers must bind a workload to one or more backing services by using a binding secret. This secret is generated for the purpose of storing information to be consumed by the workload.
 
 As an example, consider that the service you want to connect to is already exposing the binding data. In this case, you would also need a workload to be used along with the `ServiceBinding` custom resource (CR). By using this `ServiceBinding` CR, the workload sends a binding request with the details of the services to bind with.
 
 .Example of `ServiceBinding` CR
-[source,yaml]
 ----
 apiVersion: binding.operators.coreos.com/v1alpha1
 kind: ServiceBinding
 metadata:
-    name: spring-petclinic-pgcluster
-    namespace: my-petclinic
+    name: spring-petclinic-rest
+    namespace: my-postgresql
 spec:
     services: <1>
     - group: postgres-operator.crunchydata.com
       version: v1beta1
       kind: PostgresCluster
       name: hippo
+    - group: ""
+      version: v1
+      kind: Secret
+      name: hippo-pguser-hippo
     application: <2>
-      name: spring-petclinic
+      name: spring-petclinic-rest
       group: apps
       version: v1
       resource: deployments

applications/connecting_applications_to_services/exposing-binding-data-from-a-service.adoc

@@ -7,7 +7,6 @@ include::modules/servicebinding-document-attributes.adoc[]
 
 toc::[]
 
-[role="_abstract"]
 Application developers need access to backing services to build and connect workloads. Connecting workloads to backing services is always a challenge because each service provider requires a different way to access their secrets and consume them in a workload.
 
 The {servicebinding-title} enables application developers to easily bind workloads together with operator-managed backing services, without any manual procedures to configure the binding connection. For the {servicebinding-title} to provide the binding data, as an Operator provider or user who creates backing services, you must expose the binding data to be automatically detected by the {servicebinding-title}. Then, the {servicebinding-title} automatically collects the binding data from the backing service and shares it with a workload to provide a consistent and predictable experience.

applications/connecting_applications_to_services/getting-started-with-service-binding.adoc

@@ -7,7 +7,6 @@ include::modules/servicebinding-document-attributes.adoc[]
 
 toc::[]
 
-[role="_abstract"]
 {servicebinding-title} manages the data plane for workloads and backing services. This guide provides instructions with examples to help you create a database instance, deploy an application, and use {servicebinding-title} to create a binding connection between the application and the database service.
 
 // Prerequisites for getting started with Service Binding Operator
@@ -16,13 +15,9 @@ toc::[]
 
 * You have access to an {product-title} cluster using an account with `cluster-admin` permissions.
 * You have installed the `oc` CLI.
+* You have installed PostgreSQL `psql` CLI.
 * You have installed {servicebinding-title} from OperatorHub.
-* You have installed the Crunchy Postgres for Kubernetes Operator from OperatorHub using the *v5* Update channel. The installed Operator is available in an appropriate namespace, such as the `my-petclinic` namespace.
-+
-[NOTE]
-====
-You can create the namespace using the `oc create namespace my-petclinic` command.
-====
+* You have installed the Crunchy Postgres for Kubernetes Operator from OperatorHub using the *v5* Update channel. The installed Operator is available in an appropriate namespace, such as the `my-postgresql` namespace.
 
 //Creating a PostgreSQL database instance
 include::modules/sbo-creating-a-postgresql-database-instance.adoc[leveloffset=+1]

applications/connecting_applications_to_services/installing-sbo.adoc

@@ -7,7 +7,6 @@ include::modules/servicebinding-document-attributes.adoc[]
 
 toc::[]
 
-[role="_abstract"]
 This guide walks cluster administrators through the process of installing the {servicebinding-title} to an {product-title} cluster.
 
 You can install {servicebinding-title} on {product-title} 4.7 and later.

applications/connecting_applications_to_services/odc-connecting-an-application-to-a-service-using-the-developer-perspective.adoc

@@ -5,7 +5,6 @@ include::modules/common-attributes.adoc[]
 include::modules/servicebinding-document-attributes.adoc[]
 :context: odc-connecting-an-application-to-a-service-using-the-developer-perspective
 
-[role="_abstract"]
 In addition to grouping multiple components within an application, you can also use the *Topology* view to connect components with each other. You can either use a binding connector or a visual one to connect components.
 
 A binding connection between the components can be established only if the target node is an Operator-backed service. This is indicated by the *Create a binding connector* tool-tip which appears when you drag an arrow to such a target node. When an application is connected to a service using a binding connector a `ServiceBinding` resource is created. Then, the Service Binding Operator controller projects the necessary binding data into the application deployment. After the request is successful, the application is redeployed establishing an interaction between the connected components.
@@ -19,8 +18,8 @@ This procedure walks you through an example of creating a visual connection betw
 
 .Prerequisites
 
-* You have created and deployed a Spring PetClinic sample application using the *Developer* perspective.
-* You have created and deployed a Crunchy PostgreSQL database instance using the *Developer* perspective. This instance has the following four components: `hippo-backup`, `hippo-instance`, `hippo-repo-host`, and  `hippo-pgbouncer`.
+* Ensure that you have created and deployed a Spring PetClinic sample application using the *Developer* perspective.
+* Ensure that you have created and deployed a Crunchy PostgreSQL database instance using the *Developer* perspective. This instance has the following three components: `hippo-backup`, `hippo-instance`, and  `hippo-pgbouncer`.
 
 .Procedure
 
@@ -29,7 +28,7 @@ This procedure walks you through an example of creating a visual connection betw
 .Visual connector
 image::odc_connector.png[]
 . Click and drag the arrow towards the `hippo-pgbouncer` deployment to connect the Spring PetClinic sample application with it.
-. Click the `spring-petclinic` deployment to see the *Overview* panel. Under the *Details* tab, click the edit icon in the *Annotations* section to see the *Key = `app.openshift.io/connects-to`* and *Value = `[{"apiVersion":"apps/v1","kind":"Deployment","name":"hippo-pgbouncer"}]`* annotation added to the deployment.
+. Click on the `spring-petclinic-rest` deployment to see the *Overview* panel. Under the *Details* tab, click the edit icon in the *Annotations* section to see the *Key = `app.openshift.io/connects-to`* and *Value = `[{"apiVersion":"apps/v1","kind":"Deployment","name":"hippo-pgbouncer"}]`* annotation added to the deployment.
 
 Similarly you can create other applications and components and establish visual connections between them.
 
@@ -43,13 +42,13 @@ This procedure walks through an example of creating a binding connection between
 The PostreSQL Database Operator then creates and manages the `Database` resource, which exposes the binding information in secrets, config maps, status, and spec attributes.
 
 .Prerequisites
-* You have created and deployed a Spring PetClinic sample application using the *Developer* perspective.
-* You have installed the {servicebinding-title} from the OperatorHub.
-* You have installed the *Crunchy Postgres for Kubernetes* Operator from the OperatorHub using `v5` *Update* channel.
-* You have created and deployed a Crunchy PostgreSQL database instance using the *Developer* perspective. This instance has the following four components: `hippo-backup`, `hippo-instance`, `hippo-repo-host`, and `hippo-pgbouncer`.
+* Ensure that you have created and deployed a Spring PetClinic sample application using the *Developer* perspective.
+* Ensure that you have installed the {servicebinding-title} from the OperatorHub.
+* Ensure that you have installed the *Crunchy Postgres for Kubernetes* Operator from the OperatorHub using `v5` *Update* channel.
+* Ensure that you have created and deployed a Crunchy PostgreSQL database instance using the *Developer* perspective. This instance has the following three components: `hippo-backup`, `hippo-instance`, and  `hippo-pgbouncer`.
 
 .Procedure
-. Switch to the *Developer* perspective and ensure that you are in the appropriate project, for example, `my-petclinic`. In the *Topology* view, hover over the Spring PetClinic sample application to see a dangling arrow on the node.
+. Switch to the *Developer* perspective and ensure that you are in the appropriate project, for example, `my-postgresql`. In the *Topology* view, hover over the Spring PetClinic sample application to see a dangling arrow on the node.
 . Click and drag the arrow towards the *hippo* database Postgres Cluster to make a binding connection with the Spring PetClinic sample application.
 +
 Alternatively, in the *+Add* view, click the *YAML* option to see the *Import YAML* screen. Use the YAML editor and add the `ServiceBinding` resource:
@@ -60,16 +59,16 @@ Alternatively, in the *+Add* view, click the *YAML* option to see the *Import YA
 apiVersion: binding.operators.coreos.com/v1alpha1
 kind: ServiceBinding
 metadata:
-    name: spring-petclinic-pgcluster
-    namespace: my-petclinic
+    name: spring-petclinic-rest
+    namespace: my-postgresql
 spec:
     services:
     - group: postgres-operator.crunchydata.com
       version: v1beta1
       kind: PostgresCluster
       name: hippo
     application:
-      name: spring-petclinic
+      name: spring-petclinic-rest
       group: apps
       version: v1
       resource: deployments

applications/connecting_applications_to_services/projecting-binding-data.adoc

@@ -7,7 +7,6 @@ include::modules/servicebinding-document-attributes.adoc[]
 
 toc::[]
 
-[role="_abstract"]
 This section provides information on how you can consume the binding data.
 
 == Consumption of binding data

applications/connecting_applications_to_services/understanding-service-binding-operator.adoc

@@ -8,7 +8,6 @@ include::modules/servicebinding-document-attributes.adoc[]
 toc::[]
 
 
-[role="_abstract"]
 Application developers need access to backing services to build and connect workloads. Connecting workloads to backing services is always a challenge because each service provider suggests a different way to access their secrets and consume them in a workload. In addition, manual configuration and maintenance of this binding together of workloads and backing services make the process tedious, inefficient, and error-prone.
 
 The {servicebinding-title} enables application developers to easily bind workloads together with Operator-managed backing services, without any manual procedures to configure the binding connection.

modules/sbo-advanced-binding-options.adoc

@@ -2,11 +2,9 @@
 //
 // * /applications/connecting_applications_to_services/binding-workloads-using-sbo.adoc
 
-:_content-type: CONCEPT
 [id="sbo-advanced-binding-options_{context}"]
 = Advanced binding options
 
-[role="_abstract"]
 Advanced binding options are available only for the `binding.operators.coreos.com` API group.
 
 == Changing the binding names before projecting them into the workload
@@ -17,7 +15,7 @@ You can specify the rules to change the binding names in the .spec.namingStrateg
 ----
 ...
     application:
-      name: spring-petclinic
+      name: spring-petclinic-rest
       group: apps
       version: v1
       resource: deployments
@@ -39,7 +37,6 @@ You can specify the rules to change the binding names in the .spec.namingStrateg
 If `namingStrategy` is not defined and the binding names are projected as environment variables, then the `host: hippo-pgbouncer` value in the backing service and the projected environment variable would appear as shown in the following example:
 
 .Example
-[source,yaml]
 ----
 DATABASE_HOST: hippo-pgbouncer
 ----
@@ -51,7 +48,6 @@ where:
 After applying the `POSTGRESQL_{{ .service.kind | upper }}_{{ .name | upper }}_ENV` naming strategy, the  list of custom binding names prepared by the service binding request appears as shown in the following example:
 
 .Example
-[source,yaml]
 ----
 POSTGRESQL_DATABASE_HOST_ENV: hippo-pgbouncer
 POSTGRESQL_DATABASE_PORT_ENV: 5432
@@ -77,13 +73,12 @@ For example, consider a case where the backing service CR exposes the host, port
 You can compose custom binding data using attributes in the Kubernetes resource representing the backing service.
 
 .Example
-[source,yaml]
 ----
 apiVersion: binding.operators.coreos.com/v1alpha1
 kind: ServiceBinding
 metadata:
-    name: spring-petclinic-pgcluster
-    namespace: my-petclinic
+    name: spring-petclinic-rest
+    namespace: my-postgresql
 spec:
     services:
     - group: postgres-operator.crunchydata.com
@@ -97,7 +92,7 @@ spec:
       name: hippo-pguser-hippo
       id: postgresSecret
     application:
-      name: spring-petclinic
+      name: spring-petclinic-rest
       group: apps
       version: v1
       resource: deployments

modules/sbo-binding-workloads-that-are-not-compliant-with-PodSpec.adoc

@@ -2,14 +2,12 @@
 //
 // * /applications/connecting_applications_to_services/binding-workloads-using-sbo.adoc
 
-:_content-type: PROCEDURE
 [id="sbo-binding-workloads-that-are-not-compliant-with-PodSpec_{context}"]
 = Binding secondary workloads that are not compliant with PodSpec
 
-[role="_abstract"]
 A typical scenario in service binding involves configuring the backing service, the workload (Deployment), and {servicebinding-title}. Consider a scenario that involves a secondary workload (which can also be an application Operator) that is not compliant with PodSpec and is between the primary workload (Deployment) and {servicebinding-title}.
 
-For such secondary workload resources, the location of the container path is arbitrary. For service binding, if the secondary workload in a CR is not compliant with the PodSpec, you must specify the location of the container path. Doing so projects the binding data into the container path specified in the secondary workload of the `ServiceBinding` custom resource (CR), for example, when you do not want the binding data inside a pod.
+For such secondary workload resources, the location of the container path is arbitrary. For service binding, if the secondary workload in a CR is not compliant with the PodSpec, you must specify the location of the container path. Doing so projects the binding data into the container path specified in the secondary workload of the `ServiceBinding` CR, for example, when you do not want the binding data inside a pod.
 
 {servicebinding-title} provides an option to configure the value of where the container path or secret path is and bind these paths at a custom location. This option is available only for the `binding.operators.coreos.com` API group when the binding data is projected as environment variables.
 
@@ -28,20 +26,18 @@ spec:
     - name: hello-world
       image: quay.io/baijum/secondary-workload:latest
       ports:
-      - containerPort: 8080
+      - containerPort: 9966
 ----
 
-[discrete]
-.Procedure
-* Configure the `spec.containers` path by specifying a value in the `ServiceBinding` CR and bind this path to a `spec.application.bindingPath.containersPath` custom location:
-+
+The following example shows how to configure the `spec.containers` path by specifying a value in the `ServiceBinding` CR and to bind this path to a `spec.application.bindingPath.containersPath` custom location:
+
 .Example: `ServiceBinding` CR with the `spec.containers` path in a custom location
 [source,yaml]
 ----
 apiVersion: binding.operators.coreos.com/v1alpha1
 kind: ServiceBinding
 metadata:
-    name: spring-petclinic-pgcluster
+    name: spring-petclinic-rest
 spec:
     services:
     - group: postgres-operator.crunchydata.com
@@ -55,7 +51,7 @@ spec:
       name: hippo-pguser-hippo
       id: postgresSecret
     application: <1>
-      name: spring-petclinic
+      name: spring-petclinic-rest
       group: apps
       version: v1
       resource: deployments
@@ -93,7 +89,7 @@ spec:
       image: quay.io/baijum/secondary-workload:latest
       name: hello-world
       ports:
-      - containerPort: 8080
+      - containerPort: 9966
       resources: {}
 ----
 <1> Unique array of containers with values generated by the {servicebinding-title}. These values are based on the backing service CR.
@@ -113,17 +109,15 @@ spec:
     secret: ""
 ----
 
-[discrete]
-.Procedure
-* Configure the `spec.secret` path by specifying a value in the `ServiceBinding` CR and bind this path at a `spec.application.bindingPath.secretPath` custom location:
-+
+The following example shows how to configure the `spec.secret` path by specifying a value in the `ServiceBinding` CR and to bind this path at a `spec.application.bindingPath.secretPath` custom location:
+
 .Example: `ServiceBinding` CR with the `spec.secret` path in a custom location
 [source,yaml]
 ----
 apiVersion: binding.operators.coreos.com/v1alpha1
 kind: ServiceBinding
 metadata:
-    name: spring-petclinic-pgcluster
+    name: spring-petclinic-rest
 spec:
 ...
     application: <1>