Merge pull request #40418 from abrennan89/reorg

SRVCOM-1580: move conceptual info to Discover section

Author: abrennan89

_topic_maps/_topic_map.yml

@@ -3138,10 +3138,12 @@ Topics:
   Topics:
   - Name: About OpenShift Serverless
     File: about-serverless
-  - Name: Understanding Knative Eventing
-    File: serverless-understanding-eventing
-  - Name: Understanding Knative Serving
-    File: serverless-understanding-serving
+  - Name: About OpenShift Serverless Functions
+    File: serverless-functions-about
+  - Name: Knative Serving components
+    File: serverless-serving-components
+  - Name: Knative Eventing components
+    File: serverless-eventing-components
 - Name: Install
   Dir: install
   Topics:
@@ -3283,8 +3285,6 @@ Topics:
 - Name: Functions
   Dir: functions
   Topics:
-  - Name: About OpenShift Serverless Functions
-    File: serverless-functions-about
   - Name: Setting up OpenShift Serverless Functions
     File: serverless-functions-setup
   - Name: Getting started with functions

modules/security-build-knative.adoc

@@ -4,10 +4,8 @@
 
 [id="security-build-knative_{context}"]
 = Building Knative serverless applications
-Relying on Kubernetes and Kourier, you can build, deploy
-and manage serverless applications using
-link:https://knative.dev/[Knative] in {product-title}.
-As with other builds, you can use S2I images to build your containers,
-then serve them using Knative services.
-View Knative application builds through the
+
+Relying on Kubernetes and Kourier, you can build, deploy, and manage serverless applications by using OpenShift Serverless in {product-title}.
+
+As with other builds, you can use S2I images to build your containers, then serve them using Knative services. View Knative application builds through the
 *Topology* view of the {product-title} web console.

security/container_security/security-build.adoc

@@ -33,6 +33,6 @@ include::modules/security-build-knative.adoc[leveloffset=+1]
 * xref:../../cicd/builds/creating-build-inputs.adoc#builds-input-secrets-configmaps_creating-build-inputs[Input secrets and config maps]
 ifndef::openshift-origin[]
 // **This section is being moved, update the link once content is in.* add link here[The CI/CD methodology and practice]
-* xref:../../serverless/discover/serverless-understanding-serving.adoc#serverless-understanding-serving[Understanding Knative Serving]
+* xref:../../serverless/discover/about-serverless.adoc#about-serverless[About OpenShift Serverless]
 endif::[]
 * xref:../../applications/odc-viewing-application-composition-using-topology-view.adoc#odc-viewing-application-composition-using-topology-view[Viewing application composition using the Topology view]

serverless/discover/about-serverless.adoc

@@ -6,15 +6,47 @@ include::modules/common-attributes.adoc[]
 
 toc::[]
 
-Serverless is a cloud computing model where application developers do not need to provision servers or manage scaling for their applications. These routine tasks are abstracted away by the platform, allowing developers to push code to production more quickly than in traditional models.
-
 {ServerlessProductName} simplifies the process of delivering code from development into production by reducing the need for infrastructure set up or back-end development by developers.
 
-Developers on {ServerlessProductName} can use the provided Kubernetes native APIs, as well as familiar languages and frameworks, to deploy applications and container workloads.
+Developers on {ServerlessProductName} can use the provided Kubernetes native APIs (Knative Serving and Eventing), as well as familiar languages and frameworks, to deploy applications and container workloads.
 
 {ServerlessProductName} is based on the open source link:https://knative.dev/docs/[Knative project], which provides portability and consistency for hybrid and multi-cloud environments by enabling an enterprise-grade serverless platform.
 
 [id="about-serverless-supported-configs"]
 == Supported configurations
 
 The set of supported features, configurations, and integrations for {ServerlessProductName}, current and past versions, are available at the link:https://access.redhat.com/articles/4912821[Supported Configurations page].
+
+[id="about-serverless-serving"]
+== Knative Serving
+
+Knative Serving on {product-title} enables developers to write link:https://www.redhat.com/en/topics/cloud-native-apps[cloud-native applications] using link:https://www.redhat.com/en/topics/cloud-native-apps/what-is-serverless[serverless architecture].
+
+Knative Serving supports deploying and managing cloud-native applications. It provides a set of objects as Kubernetes custom resource definitions (CRDs) that define and control the behavior of serverless workloads on an {product-title} cluster.
+
+Developers use these CRDs to create custom resource (CR) instances that can be used as building blocks to address complex use cases. For example:
+
+* Rapidly deploying serverless containers.
+* Automatically scaling pods.
+
+[id="about-serverless-eventing"]
+== Knative Eventing
+
+Knative Eventing on {product-title} enables developers to use an link:https://www.redhat.com/en/topics/integration/what-is-event-driven-architecture[event-driven architecture] with serverless applications.
+
+An event-driven architecture is based on the concept of decoupled relationships between event producers and event consumers. Event producers create events, and event  xref:../../serverless/knative_eventing/serverless-event-sinks.adoc#serverless-event-sinks[_sinks_], or consumers, receive events.
+
+Knative Eventing uses standard HTTP POST requests to send and receive events between event producers and sinks. These events conform to the link:https://cloudevents.io[CloudEvents specifications], which enables creating, parsing, sending, and receiving events in any programming language.
+
+Knative Eventing supports the following use cases:
+
+Publish an event without creating a consumer:: You can send events to a broker as an HTTP POST, and use binding to decouple the destination configuration from your application that produces events.
+
+Consume an event without creating a publisher:: You can use a trigger to consume events from a broker based on event attributes. The application receives events as an HTTP POST.
+
+[id="additional-resources_about-serverless"]
+== Additional resources
+
+* For more information about CRDs, see xref:../../operators/understanding/crds/crd-extending-api-with-crds.adoc#crd-extending-api-with-crds[Extending the Kubernetes API with custom resource definitions].
+
+* For more information about CRs, see xref:../../operators/understanding/crds/crd-managing-resources-from-crds.adoc#crd-managing-resources-from-crds[Managing resources from custom resource definitions].

serverless/discover/images

@@ -0,0 +1 @@
+../images

serverless/discover/modules

@@ -0,0 +1 @@
+../modules

serverless/discover/serverless-eventing-components.adoc

@@ -0,0 +1,18 @@
+include::modules/serverless-document-attributes.adoc[]
+[id="serverless-eventing-components"]
+= Knative Eventing components
+include::modules/common-attributes.adoc[]
+:context: serverless-eventing-components
+
+toc::[]
+
+To enable delivery to multiple types of sinks, Knative Eventing defines the following generic interfaces that can be implemented by multiple Kubernetes resources:
+
+Addressable resources:: Able to receive and acknowledge an event delivered over HTTP to an address defined in the `status.address.url` field of the event. The Kubernetes `Service` resource also satisfies the addressable interface.
+
+Callable resources:: Able to receive an event delivered over HTTP and transform it, returning `0` or `1` new events in the HTTP response payload. These returned events may be further processed in the same way that events from an external event source are processed.
+
+You can propagate an event from an xref:../../serverless/event_sources/knative-event-sources.adoc#knative-event-sources[event source] to multiple event sinks by using:
+
+* xref:../../serverless/channels/serverless-channels.adoc#serverless-channels[channels] and subscriptions, or
+* xref:../../serverless/knative_eventing/serverless-using-brokers.adoc#serverless-using-brokers[brokers] and xref:../../serverless/knative_eventing/serverless-triggers.adoc#serverless-triggers[triggers].

serverless/functions/serverless-functions-about.adoc renamed to serverless/discover/serverless-functions-about.adoc

@@ -0,0 +1,15 @@
+include::modules/serverless-document-attributes.adoc[]
+[id="serverless-serving-components"]
+= Knative Serving components
+:context: serverless-serving-components
+include::modules/common-attributes.adoc[]
+
+toc::[]
+
+Service:: The `service.serving.knative.dev` CRD automatically manages the life cycle of your workload to ensure that the application is deployed and reachable through the network. It creates a route, a configuration, and a new revision for each change to a user created service, or custom resource. Most developer interactions in Knative are carried out by modifying services.
+
+Revision:: The `revision.serving.knative.dev` CRD is a point-in-time snapshot of the code and configuration for each modification made to the workload. Revisions are immutable objects and can be retained for as long as necessary.
+
+Route:: The `route.serving.knative.dev` CRD maps a network endpoint to one or more revisions. You can manage the traffic in several ways, including fractional traffic and named routes.
+
+Configuration:: The `configuration.serving.knative.dev` CRD maintains the desired state for your deployment. It provides a clean separation between code and configuration. Modifying a configuration creates a new revision.