Add support for v1 clusters for users, roles, topics, and schemas

acceptance/clusters/v1/roles/cluster.yaml

@@ -0,0 +1,27 @@
+apiVersion: redpanda.vectorized.io/v1alpha1
+kind: Cluster
+metadata:
+  name: roles
+spec:
+  image: "redpandadata/redpanda"
+  version: "v25.2.1"
+  replicas: 1
+  enableSasl: true
+  resources:
+    requests:
+      cpu: "100m"
+      memory: 256Mi
+    limits:
+      cpu: "100m"
+      memory: 256Mi
+  configuration:
+    rpcServer:
+      port: 33145
+    kafkaApi:
+      - port: 9092
+    adminApi:
+      - port: 9644
+    developerMode: true
+    additionalCommandlineArguments:
+      dump-memory-diagnostics-on-alloc-failure-kind: all
+      abort-on-seastar-bad-alloc: ''

acceptance/features/migration.feature

@@ -30,7 +30,7 @@ Feature: Helm chart to Redpanda Operator migration
             fullnameOverride: name-override
     # end::redpanda-custom-resource-manifest[]
         """
-        Then cluster "redpanda-migration-example" is available
+        Then v2 cluster "redpanda-migration-example" is available
         And the Kubernetes object of type "StatefulSet.v1.apps" with name "name-override" has an OwnerReference pointing to the cluster "redpanda-migration-example"
         And the helm release for "redpanda-migration-example" can be deleted by removing its stored secret
         And the cluster "redpanda-migration-example" is healthy

acceptance/features/operator-upgrades.feature

@@ -28,7 +28,7 @@ Feature: Upgrading the operator
     """
     # use just a Ready status check here since that's all the
     # old operator supports
-    And cluster "operator-upgrade" is available
+    And v2 cluster "operator-upgrade" is available
     Then I can upgrade to the latest operator with the values:
     """
     image:
@@ -67,7 +67,7 @@ Feature: Upgrading the operator
     """
     # use just a Ready status check here since that's all the
     # old operator supports
-    And cluster "operator-upgrade" is available
+    And v2 cluster "operator-upgrade" is available
     Then I can upgrade to the latest operator with the values:
     """
     image:

acceptance/features/role-crds.feature

@@ -1,12 +1,12 @@
 @cluster:roles
 Feature: Role CRDs
   Background: Cluster available
-    Given cluster "roles" is available
+    Given v2 cluster "roles" is available
 
   @skip:gke @skip:aks @skip:eks
   Scenario: Manage roles
-    Given there is no role "admin-role" in cluster "roles"
-    And there are the following pre-existing users in cluster "roles"
+    Given there is no role "admin-role" in v2 cluster "roles"
+    And there are the following pre-existing users in v2 cluster "roles"
       | name    | password | mechanism     |
       | alice   | password | SCRAM-SHA-256 |
       | bob     | password | SCRAM-SHA-256 |
@@ -30,16 +30,16 @@ Feature: Role CRDs
 # end::manage-roles-with-principals[]
     """
     And role "admin-role" is successfully synced
-    Then role "admin-role" should exist in cluster "roles"
-    And role "admin-role" should have members "alice and bob" in cluster "roles"
+    Then role "admin-role" should exist in v2 cluster "roles"
+    And role "admin-role" should have members "alice and bob" in v2 cluster "roles"
 
   @skip:gke @skip:aks @skip:eks
   Scenario: Manage roles with authorization
-    Given there is no role "read-only-role" in cluster "roles"
-    And there are the following pre-existing users in cluster "roles"
+    Given there is no role "read-only-role" in v2 cluster "roles"
+    And there are the following pre-existing users in v2 cluster "roles"
       | name    | password | mechanism     |
       | charlie | password | SCRAM-SHA-256 |
-    When I create topic "public-test" in cluster "roles"
+    When I create topic "public-test" in v2 cluster "roles"
     And I apply Kubernetes manifest:
     """
 # tag::manage-roles-with-authorization[]
@@ -67,16 +67,16 @@ Feature: Role CRDs
 # end::manage-roles-with-authorization[]
     """
     And role "read-only-role" is successfully synced
-    Then role "read-only-role" should exist in cluster "roles"
-    And role "read-only-role" should have ACLs for topic pattern "public-" in cluster "roles"
-    And "charlie" should be able to read from topic "public-test" in cluster "roles"
+    Then role "read-only-role" should exist in v2 cluster "roles"
+    And role "read-only-role" should have ACLs for topic pattern "public-" in v2 cluster "roles"
+    And "charlie" should be able to read from topic "public-test" in v2 cluster "roles"
 
   @skip:gke @skip:aks @skip:eks
   Scenario: Manage authorization-only roles
-    Given there are the following pre-existing users in cluster "roles"
+    Given there are the following pre-existing users in v2 cluster "roles"
       | name    | password | mechanism     |
       | travis  | password | SCRAM-SHA-256 |
-    And there is a pre-existing role "travis-role" in cluster "roles"
+    And there is a pre-existing role "travis-role" in v2 cluster "roles"
     When I apply Kubernetes manifest:
     """
 # tag::manage-authz-only-roles[]
@@ -106,5 +106,5 @@ Feature: Role CRDs
     """
     And role "travis-role" is successfully synced
     And I delete the CRD role "travis-role"
-    Then there should still be role "travis-role" in cluster "roles"
-    And there should be no ACLs for role "travis-role" in cluster "roles"
+    Then there should still be role "travis-role" in v2 cluster "roles"
+    And there should be no ACLs for role "travis-role" in v2 cluster "roles"

acceptance/features/schema-crds.feature

@@ -1,7 +1,7 @@
 @cluster:basic
 Feature: Schema CRDs
   Background: Cluster available
-    Given cluster "basic" is available
+    Given v2 cluster "basic" is available
 
   @skip:gke @skip:aks @skip:eks
   Scenario: Manage customer profile schema (Avro)

acceptance/features/topic-crds.feature

@@ -1,7 +1,7 @@
 @cluster:basic
 Feature: Topic CRDs
   Background: Cluster available
-    Given cluster "basic" is available
+    Given v2 cluster "basic" is available
 
   @skip:gke @skip:aks @skip:eks
   Scenario: Manage topics

acceptance/features/user-crds.feature

@@ -1,7 +1,7 @@
 @cluster:sasl
 Feature: User CRDs
   Background: Cluster available
-    Given cluster "sasl" is available
+    Given v2 cluster "sasl" is available
 
   @skip:gke @skip:aks @skip:eks
   Scenario: Manage users
@@ -53,7 +53,7 @@ Feature: User CRDs
 
   @skip:gke @skip:aks @skip:eks
   Scenario: Manage authorization-only users
-    Given there are the following pre-existing users in cluster "sasl"
+    Given there are the following pre-existing users in v2 cluster "sasl"
       | name    | password | mechanism     |
       | travis  | password | SCRAM-SHA-256 |
     When I apply Kubernetes manifest:

acceptance/features/v1-role-crds.feature

@@ -0,0 +1,103 @@
+@cluster:v1/roles
+Feature: V1 Role CRDs
+  Background: Cluster available
+    Given v1 cluster "roles" is available
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Manage v1 roles
+    Given there is no role "admin-role" in v1 cluster "roles"
+    And there are the following pre-existing users in v1 cluster "roles"
+      | name    | password | mechanism     |
+      | alice   | password | SCRAM-SHA-256 |
+      | bob     | password | SCRAM-SHA-256 |
+    When I apply Kubernetes manifest:
+    """
+    ---
+    apiVersion: cluster.redpanda.com/v1alpha2
+    kind: Role
+    metadata:
+      name: admin-role
+    spec:
+      cluster:
+        clusterRef:
+          group: redpanda.vectorized.io
+          kind: Cluster
+          name: roles
+      principals:
+        - User:alice
+        - User:bob
+    """
+    And role "admin-role" is successfully synced
+    Then role "admin-role" should exist in v1 cluster "roles"
+    And role "admin-role" should have members "alice and bob" in v1 cluster "roles"
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Manage v1 roles with authorization
+    Given there is no role "read-only-role" in v1 cluster "roles"
+    And there are the following pre-existing users in v1 cluster "roles"
+      | name    | password | mechanism     |
+      | charlie | password | SCRAM-SHA-256 |
+    When I create topic "public-test" in v1 cluster "roles"
+    And I apply Kubernetes manifest:
+    """
+    ---
+    apiVersion: cluster.redpanda.com/v1alpha2
+    kind: Role
+    metadata:
+      name: read-only-role
+    spec:
+      cluster:
+        clusterRef:
+          group: redpanda.vectorized.io
+          kind: Cluster
+          name: roles
+      principals:
+        - User:charlie
+      authorization:
+        acls:
+          - type: allow
+            resource:
+              type: topic
+              name: public-
+              patternType: prefixed
+            operations: [Read, Describe]
+    """
+    And role "read-only-role" is successfully synced
+    Then role "read-only-role" should exist in v1 cluster "roles"
+    And role "read-only-role" should have ACLs for topic pattern "public-" in v1 cluster "roles"
+    And "charlie" should be able to read from topic "public-test" in v1 cluster "roles"
+
+  @skip:gke @skip:aks @skip:eks
+  Scenario: Manage v1 authorization-only roles
+    Given there are the following pre-existing users in v1 cluster "roles"
+      | name    | password | mechanism     |
+      | travis  | password | SCRAM-SHA-256 |
+    And there is a pre-existing role "travis-role" in v1 cluster "roles"
+    When I apply Kubernetes manifest:
+    """
+    ---
+    apiVersion: cluster.redpanda.com/v1alpha2
+    kind: Role
+    metadata:
+      name: travis-role
+    spec:
+      cluster:
+        clusterRef:
+          group: redpanda.vectorized.io
+          kind: Cluster
+          name: roles
+      principals:
+        - User:travis
+      authorization:
+        acls:
+          - type: allow
+            resource:
+              type: topic
+              name: some-topic
+              patternType: prefixed
+            operations: [Read]
+    """
+    And role "travis-role" is successfully synced
+    And I delete the CRD role "travis-role"
+    Then there should still be role "travis-role" in v1 cluster "roles"
+    And there should be no ACLs for role "travis-role" in v1 cluster "roles"

acceptance/main_test.go

@@ -25,6 +25,7 @@ import (
 	"github.com/redpanda-data/redpanda-operator/harpoon/providers"
 	redpandav1alpha1 "github.com/redpanda-data/redpanda-operator/operator/api/redpanda/v1alpha1"
 	redpandav1alpha2 "github.com/redpanda-data/redpanda-operator/operator/api/redpanda/v1alpha2"
+	vectorizedv1alpha1 "github.com/redpanda-data/redpanda-operator/operator/api/vectorized/v1alpha1"
 	operatorchart "github.com/redpanda-data/redpanda-operator/operator/chart"
 	"github.com/redpanda-data/redpanda-operator/pkg/helm"
 	"github.com/redpanda-data/redpanda-operator/pkg/otelutil"
@@ -60,7 +61,7 @@ var setupSuite = sync.OnceValues(func() (*framework.Suite, error) {
 			"quay.io/jetstack/cert-manager-startupapicheck:v1.14.2",
 			"quay.io/jetstack/cert-manager-webhook:v1.14.2",
 		}...).
-		WithSchemeFunctions(redpandav1alpha1.Install, redpandav1alpha2.Install).
+		WithSchemeFunctions(vectorizedv1alpha1.Install, redpandav1alpha1.Install, redpandav1alpha2.Install).
 		WithHelmChart("https://charts.jetstack.io", "jetstack", "cert-manager", helm.InstallOptions{
 			Name:            "cert-manager",
 			Namespace:       "cert-manager",
@@ -88,9 +89,16 @@ var setupSuite = sync.OnceValues(func() (*framework.Suite, error) {
 						Repository: ptr.To(imageRepo),
 					},
 					CRDs: &operatorchart.PartialCRDs{
+						Enabled:      ptr.To(true),
+						Experimental: ptr.To(true),
+					},
+					VectorizedControllers: &operatorchart.PartialVectorizedControllers{
 						Enabled: ptr.To(true),
 					},
 					AdditionalCmdFlags: []string{
+						// For the v1 controllers since otherwise we'll attempt to always
+						// pull the locally built operator which will result in errors
+						"--configurator-image-pull-policy=IfNotPresent",
 						// These are needed for running decommissioning tests.
 						"--additional-controllers=nodeWatcher,decommission",
 						"--unbind-pvcs-after=5s",

acceptance/steps/cluster.go

@@ -24,9 +24,50 @@ import (
 
 	framework "github.com/redpanda-data/redpanda-operator/harpoon"
 	redpandav1alpha2 "github.com/redpanda-data/redpanda-operator/operator/api/redpanda/v1alpha2"
+	vectorizedv1alpha1 "github.com/redpanda-data/redpanda-operator/operator/api/vectorized/v1alpha1"
 )
 
-func checkClusterAvailability(ctx context.Context, t framework.TestingT, clusterName string) {
+func checkClusterAvailability(ctx context.Context, t framework.TestingT, version, clusterName string) {
+	if version == "v1" {
+		checkV1ClusterAvailability(ctx, t, clusterName)
+		return
+	}
+	checkV2ClusterAvailability(ctx, t, clusterName)
+}
+
+func checkV1ClusterAvailability(ctx context.Context, t framework.TestingT, clusterName string) {
+	var cluster vectorizedv1alpha1.Cluster
+
+	key := t.ResourceKey(clusterName)
+
+	t.Logf("Checking cluster %q is ready", clusterName)
+	require.Eventually(t, func() bool {
+		require.NoError(t, t.Get(ctx, key, &cluster))
+		hasConditionQuiescent := hasV1Condition(vectorizedv1alpha1.ClusterCondition{
+			Type:   vectorizedv1alpha1.OperatorQuiescentConditionType,
+			Status: corev1.ConditionTrue,
+		}, cluster.Status.Conditions)
+
+		hasCondition := hasConditionQuiescent
+
+		t.Logf(`Checking cluster resource conditions contains "OperatorQuiescent"? %v`, hasCondition)
+		return hasCondition
+	}, 5*time.Minute, 5*time.Second, "%s", delayLog(func() string {
+		return fmt.Sprintf(`Cluster %q never contained the condition reason "OperatorQuiescent", final Conditions: %+v`, key.String(), cluster.Status.Conditions)
+	}))
+	t.Logf("Cluster %q is ready!", clusterName)
+}
+
+func hasV1Condition(expected vectorizedv1alpha1.ClusterCondition, conditions []vectorizedv1alpha1.ClusterCondition) bool {
+	for _, condition := range conditions {
+		if expected.Type == condition.Type && expected.Status == condition.Status {
+			return true
+		}
+	}
+	return false
+}
+
+func checkV2ClusterAvailability(ctx context.Context, t framework.TestingT, clusterName string) {
 	var cluster redpandav1alpha2.Redpanda
 
 	key := t.ResourceKey(clusterName)