Merge branch '2024-02-15-case-studies-index-page' into add-styling-to…

…-ali-branch

OWNERS_ALIASES

@@ -78,16 +78,13 @@ aliases:
   - knative-prow-updater-robot
   - knative-test-reporter-robot
   - krsna-m
-  - mchmarny
   - nainaz
   - pierDipi
   - psschwei
   - puerco
   - salaboy
   - skonto
-  - smoser-ibm
   - upodroid
-  - xtreme-sameer-vohra
   knative-release-leads:
   - Cali0707
   - Leo6Leo
@@ -137,12 +134,11 @@ aliases:
   - psschwei
   - skonto
   serving-reviewers:
-  - KauzClay
-  - krsna-m
+  - izabelacg
   - retocode
   - skonto
   serving-triage:
-  - KauzClay
+  - izabelacg
   - retocode
   - skonto
   serving-wg-leads:
@@ -163,10 +159,6 @@ aliases:
   - dsimansk
   - krsna-m
   - psschwei
-  trademark-committee:
-  - mchmarny
-  - smoser-ibm
-  - xtreme-sameer-vohra
   ux-wg-leads:
   - cali0707
   - leo6leo

blog/config/nav.yml

@@ -71,6 +71,7 @@ nav:
           - articles/ko-fast-kubernetes-microservice-development-in-go.md
           - articles/build-deploy-manage-modern-serverless-workloads-using-knative-on-kubernetes.md
       - Steering Committee:
+          - steering/2024-02-14-trademark-committee-dissolved.md
           - steering/toc-2022-election-announcement.md
           - steering/2022-04-14-annual-report-2021.md
           - steering/knative-and-endusers.md

blog/docs/steering/2024-02-14-trademark-committee-dissolved.md

@@ -0,0 +1,43 @@
+---
+title: "Knative Trademark Committee Dissolved"
+linkTitle: "Knative Trademark Committee Dissolved"
+date: 2024-02-14
+description: "Summary of governance changes that involve dissolving the trademark committee."
+type: "blog"
+
+---
+
+**_Author: [Ali Ok](https://github.com/aliok), on behalf of the [Knative Steering Committee](https://github.com/knative/community/blob/main/STEERING-COMMITTEE.md)_**
+
+Knative [joined CNCF](https://knative.dev/blog/steering/cncf/) in 2022, and the
+ownership of the branding and trademark has been transferred to the CNCF.
+As a result, the committee that was responsible for these matters, the Knative 
+Trademark Committee, was not really needed anymore. The Knative Trademark 
+Committee has decided to dissolve itself, and the Steering Committee 
+will handle any trademark matters.
+
+You may find the recording of the last meeting of the Knative Trademark Committee
+and the dissolution decision [here](https://github.com/knative/community/issues/1399).
+
+Branding, trademark usage, conformance and scope matters that were previously 
+handled by the Knative Trademark Committee will now be handled by the 
+Steering Committee. Knative Technical Oversight Committee (TOC) 
+will advise the Steering Committee on conformance and scope matters. 
+
+The Steering Committee will coordinate with the CNCF to ensure that the project's 
+trademarks are protected and used in a way that is consistent with the project's goals.
+
+You may find the record of the dissolved Knative Trademark Committee charter document  
+[here](https://github.com/knative/community/blob/fa4340e96c0eeb69151be0f512a8970083d99a05/TRADEMARK-COMMITTEE.md).
+
+We would like to thank the emeritus members of the Knative Trademark Committee for their
+service and dedication to the project.
+
+- Mark Chmarny ([@mchmarny](https://github.com/mchmarny))
+- Simon Moser  ([@smoser-ibm](https://github.com/smoser-ibm))
+- Sameer Vohra ([@xtreme-sameer-vohra](https://github.com/xtreme-sameer-vohra))
+- Evan Anderson ([@evankanderson](https://github.com/evankanderson))
+- Spencer Dillard ([@spencerdillard](https://github.com/spencerdillard))
+- Doug Davis ([@duglin](https://github.com/duglin))
+- Brenda Chan ([@bsnchan](https://github.com/bsnchan))
+- Ron Avnur ([@ronavn](https://github.com/ronavn))

config/nav.yml

@@ -192,10 +192,9 @@ nav:
             - Available Broker types: eventing/brokers/broker-types/README.md
             # add default IMC broker page, page explaining broker types
             - Channel based Broker: eventing/brokers/broker-types/channel-based-broker/README.md
-            - Apache Kafka: 
+            - Apache Kafka:
               - About Apache Kafka Broker: eventing/brokers/broker-types/kafka-broker/README.md
               - Configuring Kafka features: eventing/brokers/broker-types/kafka-broker/configuring-kafka-features.md
-            - 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
         - Triggers:
@@ -215,7 +214,6 @@ nav:
           - PingSource:
             - Creating a PingSource object: eventing/sources/ping-source/README.md
             - PingSource reference: eventing/sources/ping-source/reference.md
-          - RabbitMQSource: eventing/sources/rabbitmq-source/README.md
           - RedisStreamSource:
             - About RedisStreamSource: eventing/sources/redis/README.md
             - Creating a RedisStreamSource object: eventing/sources/redis/getting-started.md
@@ -311,10 +309,12 @@ nav:
     - About:
       - Testimonials: about/testimonials.md
       - Case studies:
+        - List of Case Studies: about/case-studies/README.md
         - deepc: about/case-studies/deepc.md
         - Outfit7: about/case-studies/outfit7.md
         - Puppet: about/case-studies/puppet.md
         - PNC Bank: about/case-studies/pnc.md
+        - SVA: about/case-studies/sva.md
     - Community:
       - How To Get Involved: community/README.md
       - Contribute to Knative: community/contributing.md

config/redirects.yml

@@ -6,7 +6,6 @@ plugins:
       eventing/broker/create-mtbroker.md: eventing/brokers/create-broker.md
       eventing/broker/example-mtbroker.md: eventing/brokers/broker-developer-config-options.md
       eventing/broker/kafka-broker/README.md: eventing/brokers/broker-types/kafka-broker/README.md
-      eventing/broker/rabbitmq-broker/README.md: eventing/brokers/broker-types/rabbitmq-broker/README.md
       eventing/broker/README.md: eventing/brokers/README.md
       concepts/resources/revisions.md: concepts/serving-resources/revisions.md
       serving/revision-gc.md: serving/revisions/revision-developer-config-options.md
@@ -210,6 +209,5 @@ plugins:
       serving/spec/knative-api-specification-1.0.md: https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md
       serving/using-an-ssl-cert/index.md: serving/encryption/using-certificates-in-networking-layer.md
       serving/using-subroutes.md: serving/traffic-management.md
-      about/case-studies/README.md: about/case-studies/deepc.md
       eventing/brokers/create-mtbroker.md: eventing/brokers/create-broker.md
       eventing/brokers/broker-admin-config-options.md: eventing/configuration/broker-configuration.md

docs/about/case-studies/sva.md

@@ -0,0 +1,39 @@
+---
+hide:
+  - toc
+---
+<h1 style="color:#0071c7;font-size: 3em;">SVA System Vertrieb Alexander GmbH Case Study</h1>
+<table style="border: 0;">
+<tr style="background-color: var(--md-default-bg-color);">
+<td style="border: 0;">
+<div style="min-width: 20mm;">
+      <img src="../../../images/case-studies/sva.png" alt="" draggable="false" />
+</div>
+<div>
+<em style="color:#0071c7;font-size: 1em;">“SVA built an HTTP-based, event-driven platform that was highly available and adhered to cloud native best practices. The solution was opt-in and provided a quality developer experience so that the developers would want to use it.”
+</em>
+</div>
+<div>
+</div>
+
+</td>
+
+<td style="border: 0;">
+<h2 style="font-weight: bold;">SVA uses Knative to kickstart cloud native adoption and patterns</h2>
+
+SVA System Vertrieb Alexander GmbH is a leading German company that specializes in Professional Services, server migrations, and managed services. Public sectors pose unique challenges due to their complex structure and regulated requirements. For example, one particular customer, a German government organisation, is divided into departments, groups, units, and application teams, each with specific functional responsibilities. Some applications have to adhere to specific laws, which limits innovation and makes the lifecycle of applications stale. With the gradual introduction of microservices and service-oriented architecture, the number of applications connecting to each other grew into a complicated mesh of applications which was quickly becoming unmanageable.
+
+<h2 style="color:#0071c7;">Please read the full case study at CNCF site</h2>
+<li><a href="https://www.cncf.io/case-studies/system-vertrieb-alexander-gmbh/">How SVA used Knative to kickstart cloud native adoption and patterns</a></li>
+
+<h2 style="color:#0071c7;">Find out more</h2>
+
+<ul>
+<li><a href="../../../getting-started/">Getting started with Knative</a></li>
+<li><a href="../../../serving/">Knative Serving</a></li>
+<li><a href="../../../eventing/">Knative Eventing</a></li>
+</ul>
+
+    </td>
+  </tr>
+</table>

docs/community/governance.md

@@ -38,9 +38,6 @@ describes our steering committee.
 - [Technical Oversight Committee (TOC)](https://github.com/knative/community/blob/main/TECH-OVERSIGHT-COMMITTEE.md):
 describes our technical oversight committee.
 
-- [Trademark Committee](https://github.com/knative/community/blob/main/TRADEMARK-COMMITTEE.md):
-describes our trademark committee.
-
 - [Annual reports](https://github.com/knative/community/tree/main/annual_reports):
 lists previous annual reports.
 

docs/eventing/brokers/broker-developer-config-options.md

@@ -33,6 +33,6 @@ spec:
 
 - You can specify any valid `name` for your broker. Using `default` will create a broker named `default`.
 - The `namespace` must be an existing namespace in your cluster. Using `default` will create the broker in the `default` namespace.
-- You can set the `eventing.knative.dev/broker.class` annotation to change the class of the broker. The default broker class is `MTChannelBasedBroker`, but Knative also supports use of the `Kafka` and `RabbitMQBroker` broker class. For more information see the [Apache Kafka Broker](../brokers/broker-types/kafka-broker/README.md) or [RabbitMQ Broker](../brokers/broker-types/rabbitmq-broker/README.md) documentation.
+- You can set the `eventing.knative.dev/broker.class` annotation to change the class of the broker. The default broker class is `MTChannelBasedBroker`, but Knative also supports use of the `Kafka`. For more information see the [Apache Kafka Broker](../brokers/broker-types/kafka-broker/README.md) documentation.
 - `spec.config` is used to specify the default backing channel configuration for Channel based Broker implementations. For more information on configuring the default channel type, see the documentation on [Configure Broker defaults](../configuration/broker-configuration.md).
 - `spec.delivery` is used to configure event delivery options. Event delivery options specify what happens to an event that fails to be delivered to an event sink. For more information, see the documentation on [Event delivery](../event-delivery.md).

docs/eventing/brokers/broker-types/README.md

@@ -17,8 +17,3 @@ The following is a list of Brokers provided by the community or vendors:
 ### Knative Broker for Apache Kafka
 
 This Broker implementation uses [Apache Kafka](https://kafka.apache.org/) as its backing technology. For more information, see the [Knative Broker for Apache Kafka](./kafka-broker/README.md) documentation.
-
-### RabbitMQ broker
-
-The RabbitMQ Broker uses [RabbitMQ](https://www.rabbitmq.com/) for its underlying implementation.
-For more information, see [RabbitMQ Broker](./rabbitmq-broker/README.md) or [the docs available on GitHub](https://github.com/knative-extensions/eventing-rabbitmq).

docs/eventing/brokers/broker-types/channel-based-broker/README.md

@@ -1,7 +1,7 @@
 # Channel based Broker
 
 The Channel based Broker (`MTChannelBasedBroker`) uses [Channels](../../../channels) for event routing. It is shipped by default with Knative Eventing.
-Users should prefer native Broker implementations (like [Knative Broker for Apache Kafka](../kafka-broker/README.md) or [RabbitMQ Broker](../rabbitmq-broker/README.md)) over the MTChannelBasedBroker and Channel combination because it is usually more efficient as they reduce network hops for example. 
+Users should prefer native Broker implementations (like [Knative Broker for Apache Kafka](../kafka-broker/README.md) over the MTChannelBasedBroker and Channel combination because it is usually more efficient as they reduce network hops for example. 
 ## Prerequisites
 
 * You have Knative Eventing installed.

docs/eventing/brokers/broker-types/kafka-broker/README.md

@@ -113,6 +113,26 @@ different `name` on your Kafka Broker's `spec.config` field.
 !!! note
     The `default.topic.replication.factor` value must be less than or equal to the number of Kafka broker instances in your cluster. For example, if you only have one Kafka broker, the `default.topic.replication.factor` value should not be more than `1`.
 
+Knative supports the [full set of topic config options that your version of Kafka supports](https://kafka.apache.org/documentation/#topicconfigs). To set any of these, you need to add a key to the configmap with the `default.topic.config.` prefix.
+For example, to set the `retention.ms` value you would modify the `ConfigMap` to look like the following:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: kafka-broker-config
+  namespace: knative-eventing
+data:
+  # Number of topic partitions
+  default.topic.partitions: "10"
+  # Replication factor of topic messages.
+  default.topic.replication.factor: "3"
+  # A comma separated list of bootstrap servers. (It can be in or out the k8s cluster)
+  bootstrap.servers: "my-cluster-kafka-bootstrap.kafka:9092"
+  # Here is our retention.ms config
+  default.topic.config.retention.ms: "3600"
+```
+
 ## Set as default broker implementation
 
 To set the Kafka broker as the default implementation for all brokers in the Knative deployment,

docs/eventing/sources/README.md

@@ -37,7 +37,6 @@ All Sources are part of the `sources` category.
 | [GitLab](https://github.com/knative/docs/tree/main/code-samples/eventing/gitlab-source) | Beta | Knative    | Registers for events of the specified types on the specified GitLab repository, and brings those events into Knative. The GitLabSource creates a webhooks for specified [event types](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#events), listens for incoming events, and passes them to a consumer. See the [GitLab Source](https://github.com/knative/docs/tree/main/code-samples/eventing/gitlab-source) example for more details.  |
 | [KogitoSource](https://github.com/knative-extensions/eventing-kogito) |  Alpha | Knative    | An implementation of the [Kogito Runtime](https://docs.jboss.org/kogito/release/latest/html_single/#proc-kogito-deploying-on-kubernetes_kogito-deploying-on-openshift) custom resource managed by the [Kogito Operator](https://github.com/kiegroup/kogito-operator). |
 | [PingSource](ping-source/README.md) | Stable | Knative    | Produces events with a fixed payload on a specified [Cron](https://en.wikipedia.org/wiki/Cron) schedule. See the [Ping Source](ping-source/README.md) example for more details. |
-| [RabbitMQ](https://github.com/knative-extensions/eventing-rabbitmq) | Stable | Knative | Brings [RabbitMQ](https://www.rabbitmq.com/) messages into Knative.
 [RedisSource](https://github.com/knative-extensions/eventing-redis/tree/{{version}}/source) | Alpha | Knative | Brings Redis Stream into Knative.
 | [SinkBinding](../custom-event-source/sinkbinding/README.md) | Stable | Knative    | The SinkBinding can be used to author new event sources using any of the familiar compute abstractions that Kubernetes makes available (e.g. Deployment, Job, DaemonSet, StatefulSet), or Knative abstractions (e.g. Service, Configuration). SinkBinding provides a framework for injecting `K_SINK` (destination address) and `K_CE_OVERRIDES` (JSON cloudevents attributes) environment variables into any Kubernetes resource which has a `spec.template` that looks like a Pod (aka PodSpecable). See the [SinkBinding](../custom-event-source/sinkbinding/README.md) example for more details. |