DOC-511 Schema CRD

modules/ROOT/nav.adoc

@@ -167,8 +167,11 @@
 *** xref:manage:topic-recovery.adoc[Topic Recovery]
 *** xref:manage:whole-cluster-restore.adoc[Whole Cluster Restore]
 ** xref:manage:schema-reg/index.adoc[Schema Registry]
-*** xref:manage:schema-reg/schema-reg-overview.adoc[]
-*** xref:manage:schema-reg/schema-reg-api.adoc[]
+*** xref:manage:schema-reg/schema-reg-overview.adoc[Overview]
+*** xref:manage:schema-reg/manage-schema-reg.adoc[]
+**** xref:manage:schema-reg/schema-reg-api.adoc[API]
+**** xref:console:ui/schema-reg.adoc[Redpanda Console]
+**** xref:manage:kubernetes/k-schema-controller.adoc[Kubernetes]
 *** xref:manage:schema-reg/schema-id-validation.adoc[]
 *** xref:console:ui/schema-reg.adoc[Manage in Redpanda Console]
 ** xref:manage:console/index.adoc[Redpanda Console]

modules/manage/examples/kubernetes/schema-crds.feature

@@ -0,0 +1,106 @@
+@cluster:basic
+Feature: Schema CRDs
+  Background: Cluster available
+    Given cluster "basic" is available
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Manage customer profile schema (Avro)
+    Given there is no schema "customer-profile" in cluster "basic"
+    When I apply Kubernetes manifest:
+    """
+# tag::customer-profile-avro-schema-manifest[]
+    # This manifest creates an Avro schema named "customer-profile" in the "basic" cluster.
+    # The schema defines a record with fields for customer ID, name, and age.
+    ---
+    apiVersion: cluster.redpanda.com/v1alpha2
+    kind: Schema
+    metadata:
+      name: customer-profile
+    spec:
+      cluster:
+        clusterRef:
+          name: basic
+      schemaType: avro
+      compatibilityLevel: Backward
+      text: |
+        {
+          "type": "record",
+          "name": "CustomerProfile",
+          "fields": [
+            { "type": "string", "name": "customer_id" },
+            { "type": "string", "name": "name" },
+            { "type": "int", "name": "age" }
+          ]
+        }
+# end::customer-profile-avro-schema-manifest[]
+    """
+    And schema "customer-profile" is successfully synced
+    Then I should be able to check compatibility against "customer-profile" in cluster "basic"
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Manage product catalog schema (Protobuf)
+    Given there is no schema "product-catalog" in cluster "basic"
+    When I apply Kubernetes manifest:
+    """
+# tag::product-catalog-protobuf-schema-manifest[]
+    # This manifest creates a Protobuf schema named "product-catalog" in the "basic" cluster.
+    # The schema defines a message "Product" with fields for product ID, name, price, and category.
+    ---
+    apiVersion: cluster.redpanda.com/v1alpha2
+    kind: Schema
+    metadata:
+      name: product-catalog
+    spec:
+      cluster:
+        clusterRef:
+          name: basic
+      schemaType: protobuf
+      compatibilityLevel: Backward
+      text: |
+        syntax = "proto3";
+
+        message Product {
+          int32 product_id = 1;
+          string product_name = 2;
+          double price = 3;
+          string category = 4;
+        }
+# end::product-catalog-protobuf-schema-manifest[]
+    """
+    And schema "product-catalog" is successfully synced
+    Then I should be able to check compatibility against "product-catalog" in cluster "basic"
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Manage order event schema (JSON)
+    Given there is no schema "order-event" in cluster "basic"
+    When I apply Kubernetes manifest:
+    """
+# tag::order-event-json-schema-manifest[]
+    # This manifest creates a JSON schema named "order-event" in the "basic" cluster.
+    # The schema requires an "order_id" (string) and a "total" (number) field, with no additional properties allowed.
+    ---
+    apiVersion: cluster.redpanda.com/v1alpha2
+    kind: Schema
+    metadata:
+      name: order-event
+    spec:
+      cluster:
+        clusterRef:
+          name: basic
+      schemaType: json
+      compatibilityLevel: None
+      text: |
+        {
+          "$schema": "http://json-schema.org/draft-07/schema#",
+          "type": "object",
+          "properties": {
+            "order_id": { "type": "string" },
+            "total": { "type": "number" }
+          },
+          "required": ["order_id", "total"],
+          "additionalProperties": false
+        }
+# end::order-event-json-schema-manifest[]
+    """
+    And schema "order-event" is successfully synced
+    Then I should be able to check compatibility against "order-event" in cluster "basic"

modules/manage/examples/kubernetes/topic-crds.feature

@@ -0,0 +1,27 @@
+@cluster:basic
+Feature: Topic CRDs
+  Background: Cluster available
+    Given cluster "basic" is available
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Manage topics
+    Given there is no topic "topic1" in cluster "basic"
+    When I apply Kubernetes manifest:
+    """
+# tag::basic-topic-example[]
+    # In this example manifest, a topic called "topic1" is created in a cluster called "basic". It has a replication factor of 1 and is distributed across a single partition.
+    ---
+    apiVersion: cluster.redpanda.com/v1alpha2
+    kind: Topic
+    metadata:
+      name: topic1
+    spec:
+      cluster:
+        clusterRef:
+          name: basic
+      partitions: 1
+      replicationFactor: 1
+# end::basic-topic-example[]
+    """
+    And topic "topic1" is successfully synced
+    Then I should be able to produce and consume from "topic1" in cluster "basic"

modules/manage/examples/kubernetes/user-crds.feature

@@ -25,7 +25,7 @@ Feature: User CRDs
       | jason  | [{"type":"allow","resource":{"type":"cluster"},"operations":["Read"]}] |
     When I apply Kubernetes manifest:
     """
-    # tag::manage-authn-only-manifest[]
+# tag::manage-authn-only-manifest[]
     # In this example manifest, a user called "jason" is created in a cluster called "sasl".
     # The user's password is defined in a Secret called "jason-password".
     # This example assumes that you will create ACLs for this user separately.
@@ -45,7 +45,7 @@ Feature: User CRDs
             secretKeyRef:
               name: jason-password
               key: password
-    # end::manage-authn-only-manifest[]
+# end::manage-authn-only-manifest[]
     """
     And user "jason" is successfully synced
     And I delete the CRD user "jason"
@@ -58,7 +58,7 @@ Feature: User CRDs
       | travis  | password | SCRAM-SHA-256 |
     When I apply Kubernetes manifest:
     """
-    # tag::manage-authz-only-manifest[]
+# tag::manage-authz-only-manifest[]
     # In this example manifest, an ACL called "travis" is created in a cluster called "sasl".
     # The ACL give an existing user called "travis" permissions to read from all topics whose names start with some-topic.
     # This example assumes that you already have a user called "travis" in your cluster.
@@ -79,8 +79,8 @@ Feature: User CRDs
             name: some-topic
             patternType: prefixed
           operations: [Read]
-    # end::manage-authz-only-manifest[]
+# end::manage-authz-only-manifest[]
     """
     And user "travis" is successfully synced
     And I delete the CRD user "travis"
-    Then "travis" should be able to authenticate to the "sasl" cluster with password "password" and mechanism "SCRAM-SHA-256"
+    Then "travis" should be able to authenticate to the "sasl" cluster with password "password" and mechanism "SCRAM-SHA-256"