Fix reorganization issues 6306

config/redirects.yml

@@ -226,3 +226,4 @@ plugins:
       versioned/serving/using-subroutes.md: versioned/serving/traffic-management.md
       versioned/eventing/brokers/create-mtbroker.md: versioned/eventing/brokers/create-broker.md
       versioned/eventing/brokers/broker-admin-config-options.md: versioned/eventing/configuration/broker-configuration.md
+      versioned/eventing/event-mesh.md: versioned/eventing/concepts/event-mesh.md

docs/versioned/.nav.yml

@@ -7,7 +7,7 @@ nav:
     # Getting started
 ###############################################################################
     - Tutorials:
-        - Overview: getting-started/tutorial.md
+        - Explore Knative: getting-started/tutorial.md
         - Quickstart:
           - Tutorial introduction: getting-started/README.md
           - Install Knative using quickstart: getting-started/quickstart-install.md
@@ -119,7 +119,6 @@ nav:
 ###############################################################################
     - Eventing:
       - Knative Eventing overview: eventing/README.md
-      - Event Mesh: eventing/event-mesh.md
       - Concepts:
         - Brokers:
           - About Brokers: eventing/brokers/README.md
@@ -132,6 +131,7 @@ nav:
             - RabbitMQ Broker: eventing/brokers/broker-types/rabbitmq-broker/README.md
           - Creating a Broker: eventing/brokers/create-broker.md
           - Developer configuration options: eventing/brokers/broker-developer-config-options.md
+        - Event Mesh: eventing/concepts/event-mesh.md
         - Triggers:
           - Using Triggers: eventing/triggers/README.md
         - Duck types: eventing/concepts/duck-typing.md

docs/versioned/eventing/brokers/README.md

@@ -7,7 +7,7 @@ function: explanation
 
 # Brokers
 
-Brokers are Kubernetes custom resources that define an [event mesh](../event-mesh.md) for collecting a pool of events. Brokers provide a discoverable endpoint for event ingress, and use Triggers for event delivery. Event producers can send events to a broker by POSTing the event.
+Brokers are Kubernetes custom resources that define an [event mesh](../concepts/event-mesh.md) for collecting a pool of events. Brokers provide a discoverable endpoint for event ingress, and use Triggers for event delivery. Event producers can send events to a broker by POSTing the event.
 
 ![Source 1 and Source 2 are transmitting some data -- ones and twos -- to the Broker, which then gets filtered by Triggers to the desired Sink.](https://user-images.githubusercontent.com/16281246/116248768-1fe56080-a73a-11eb-9a85-8bdccb82d16c.png){draggable=false}
 

docs/versioned/eventing/event-mesh.md → docs/versioned/eventing/concepts/event-mesh.md

@@ -13,13 +13,13 @@ In an Event Mesh, both producing and consuming applications do not need to imple
 
 ## Knative Event Mesh
 
-The above mentioned _event brokers_ map directly to a core API in Knative Eventing: the [`Broker` API](../brokers) offers a discoverable endpoint for event ingress and the [`Trigger` API](../triggers) completes the offering with its event filtering and delivery capabilities.  With these APIs Knative Eventing offers an Event Mesh as defined above:
+The above mentioned _event brokers_ map directly to a core API in Knative Eventing: the [`Broker` API](../brokers) offers a discoverable endpoint for event ingress and the [`Trigger` API](../triggers/) completes the offering with its event filtering and delivery capabilities.  With these APIs Knative Eventing offers an Event Mesh as defined above:
 
-![Raw Trace](images/mesh.png)
+![Raw Trace](../images/mesh.png)
 
-As visible in the above diagram, the Event Mesh is defined with the `Broker` and `Trigger` APIs for the ingress and the egress of events.  Knative Eventing enables multiple resources to participate in the Event Mesh with a partial schema pattern called "duck typing".  Duck typing allows multiple resource types to advertise common capabilities, such as "can receive events at a URL" or "can deliver events to a destination".  Knative Eventing uses these capabilities to offer [a pool of interoperable sources](../sources) for sending events to the `Broker` and [as destinations for `Trigger`-routed events](../triggers).  The Knative Eventing APIs contain three categories of APIs:
+As visible in the above diagram, the Event Mesh is defined with the `Broker` and `Trigger` APIs for the ingress and the egress of events.  Knative Eventing enables multiple resources to participate in the Event Mesh with a partial schema pattern called "duck typing".  Duck typing allows multiple resource types to advertise common capabilities, such as "can receive events at a URL" or "can deliver events to a destination".  Knative Eventing uses these capabilities to offer [a pool of interoperable sources](../sources/) for sending events to the `Broker` and [as destinations for `Trigger`-routed events](../triggers/README.md).  The Knative Eventing APIs contain three categories of APIs:
 
-* **Events Ingress**: Support for connecting event senders: Source duck type and [SinkBinding](../custom-event-source/sinkbinding) to support easily configuring applications to deliver events to a `Broker`.  Applications can submit events and use Eventing even without any sources installed.
+* **Events Ingress**: Support for connecting event senders: Source duck type and [SinkBinding](../custom-event-source/sinkbinding/) to support easily configuring applications to deliver events to a `Broker`.  Applications can submit events and use Eventing even without any sources installed.
 * **Event routing**: `Broker` and `Trigger` objects support defining the mesh and event routing.  Note that `Broker` matches the definition of an Addressable event destination, so it is possible to relay events from a Broker in one cluster to a Broker in another cluster.  Similarly, `Trigger` uses the same Deliverable duck type as many sources, so it is easy to substitute an event mesh for direct delivery of events.
 * **Event egress** : The Deliverable contract supports specifying either a bare URL or referencing a Kubernetes object which implements the Addressable interface (has a `status.address.url`) as a destination.  All event destinations ("sinks") must implement the CloudEvents delivery specification, but do not necessarily need to implement any Kubernetes behavior -- a bare VM referenced by URL is an acceptable event egress.