docs: use v1beta1 API version (#553)

odubajDT · StackScribe · toddbaert · web-flow · commit ccc0471c15cb · 2023-11-20T15:45:22.000+01:00
Signed-off-by: odubajDT &lt;ondrej.dubaj@dynatrace.com&gt;
Signed-off-by: odubajDT &lt;93584209+odubajDT@users.noreply.github.com&gt;
Co-authored-by: Meg McRoberts &lt;meg.mcroberts@dynatrace.com&gt;
Co-authored-by: Todd Baert &lt;toddbaert@gmail.com&gt;
Co-authored-by: Todd Baert &lt;todd.baert@dynatrace.com&gt;
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -7,16 +7,16 @@ There are a few things to consider before contributing to open-feature-operator.
 Firstly, there's [a code of conduct](https://github.com/open-feature/.github/blob/main/CODE_OF_CONDUCT.md).
 TLDR: be respectful.
 
-Any contributions are expected to include tests. These can be validated with `make test` or the automated github workflow will run them on PR creation.
+Any contributions are expected to include tests. These can be validated with `make unit-test` or the automated github workflow will run them on PR creation.
 
 The go version in the `go.mod` is the currently supported version of go.
 
 Thanks! Issues and pull requests following these guidelines are welcome.
 
 ## Development
 
-### FeatureFlagConfiguration custom resource definition versioning
-Custom resource definitions support multiple versions. The kubebuilder framework exposes a system to seamlessly convert between versions (using a "hub and spoke" model) maintaining backwards compatibility. It does this by injecting conversion webhooks that call our defined convert functions. The hub version of the `FeatureFlagConfiguration` custom resource definition (the version to which all other versions are converted) is `v1alpha1`.
+### FeatureFlag custom resource definition versioning
+Custom resource definitions support multiple versions. The kubebuilder framework exposes a system to seamlessly convert between versions (using a "hub and spoke" model) maintaining backwards compatibility. It does this by injecting conversion webhooks that call our defined convert functions. The hub version of the `FeatureFlag` custom resource definition (the version to which all other versions are converted) is `v1beta1`.
 Follow [this tutorial](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html) to implement a new version of the custom resource definition.
 
 ### Local build
diff --git a/docs/README.md b/docs/README.md
@@ -12,14 +12,14 @@ Follow the detailed installation guide to deploy open feature operator to your l
 
 ## Configuration
 
-Configuration of the deployed sidecars is handled through the `FlagSourceConfiguration` custom resources defined at`openfeature.dev/flagsourceconfiguration` annotation of the deployed `PodSpec`.
+Configuration of the deployed sidecars is handled through the `FeatureFlagSource` custom resources referenced via `openfeature.dev/featureflagsource` annotations of the deployed `PodSpec`.
 
 The relationship between the deployment and custom resources is highlighted in the diagram below,
 
 ```mermaid
 flowchart TD
-    A[Pod]-->|Annotation: openfeature.dev/flagsourceconfiguration| B[FlagSourceConfiguration CR]
-    B--> |Flag source| C[FeatureFlagConfiguration CR]
+    A[Pod]-->|Annotation: openfeature.dev/featureflagsource| B[FeatureFlagSource CR]
+    B--> |Flag source| C[FeatureFlag CR]
     B--> |Flag source| D[HTTP sync]
     B--> |Flag source| E[Filepath sync]
     B--> |Flag source| F[GRPC sync]
@@ -29,8 +29,8 @@ flowchart TD
 To configure and understand more,
 
 - Deployment configurations: [Annotations](./annotations.md)
-- Define flag sources for the deployment: [FlagSourceConfiguration](./flag_source_configuration.md)
-- Define feature flags as custom resource: [FeatureFlagConfigurations](./feature_flag_configuration.md)
+- Define flag sources for the deployment: [FeatureFlagSource](./feature_flag_source.md)
+- Define feature flags as custom resource: [FeatureFlags](./feature_flag.md)
 
 ## Other Resources
 - [Permissions](./permissions.md)
diff --git a/docs/annotations.md b/docs/annotations.md
@@ -13,9 +13,9 @@ Example:
       openfeature.dev/enabled: "true"
 ```
 
-### `openfeature.dev/flagsourceconfiguration`
+### `openfeature.dev/featureflagsource`
 
-This annotation specifies the names of the `FlagSourceConfigurations` used to configure the injected flagd sidecar.
+This annotation specifies the names of the `FeatureFlagSources` used to configure the injected flagd sidecar.
 The annotation value is a comma separated list of values following one of 2 patterns: {NAME} or {NAMESPACE}/{NAME}. 
 
 If no namespace is provided, it is assumed that the custom resource is within the **same namespace** as the annotated pod.
@@ -28,7 +28,7 @@ Example:
   metadata:
     annotations:
       openfeature.dev/enabled: "true"
-      openfeature.dev/flagsourceconfiguration: "config-A, config-B"
+      openfeature.dev/featureflagsource: "config-A, config-B"
 ```
 
 ### `openfeature.dev/allowkubernetessync`
@@ -40,28 +40,3 @@ When the OFO manager pod is started, all `Service Accounts` of any `Pods` with t
 ## Deprecated annotations
 
 Given below are references to **deprecated** annotations used by previous versions of the operator.
-
-### `openfeature.dev/featureflagconfiguration`
-*This annotation is DEPRECATED in favour of the `openfeature.dev/flagsourceconfiguration` annotation and should no longer be used.* 
-
-This annotation specifies the names of the FeatureFlagConfigurations used to configure the injected flagd sidecar.
-The annotation value is a comma separated list of values following one of 2 patterns: {NAME} or {NAMESPACE}/{NAME}. 
-If no namespace is provided it is assumed that the CR is within the same namespace as the deployed pod.
-Example:
-```yaml
-    metadata:
-    annotations:
-      openfeature.dev/enabled: "true"
-      openfeature.dev/featureflagconfiguration: "demo, test/demo-2"
-```
-
-### `openfeature.dev`
-*This annotation is DEPRECATED in favour of the `openfeature.dev/enabled` annotation and should no longer be used.* 
-
-When a value of `"enabled"` is provided, the operator will inject a flagd sidecar into the annotated pods.  
-Example: 
-```yaml
-    metadata:
-    annotations:
-      openfeature.dev: "enabled"
-```
diff --git a/docs/concepts.md b/docs/concepts.md
@@ -13,11 +13,11 @@ The high level architecture of the operator is as follows:
 
 ## Modes of flag syncs
 
-- Kubernetes:  sync configuration which configures injected flagd sidecar instances to monitor the Kubernetes API 
-  for changes in flag configuration custom resources (`FeatureFlagConfiguration`).
-- filepath:  sync configuration which creates and mounts ConfigMap files from flag configuration custom  resources
-  (`FeatureFlagConfiguration`) and configures injected flagd sidecar instances to monitor them.
-- grpc: sync configuration which listen for flagd compatible grpc stream
+- Kubernetes:  sync configuration that configures injected flagd sidecar instances to monitor the Kubernetes API 
+  for changes in flag definition custom resources (`FeatureFlag`).
+- filepath:  sync configuration that creates and mounts ConfigMap files from flag configuration custom  resources
+  (`FeatureFlag`) and configures injected flagd sidecar instances to monitor them.
+- grpc: sync configuration that listens for flagd compatible grpc stream
 - http: sync configuration which watch and periodically poll flagd compatible http endpoint
 - [flagd-proxy](./flagd_proxy.md)
 
diff --git a/docs/feature_flag.md b/docs/feature_flag.md
@@ -1,14 +1,14 @@
-# Feature Flag Configuration
+# Feature Flag
 
-The `FeatureFlagConfiguration` version `v1alpha2` CRD defines a CR with the following example structure:
+The `FeatureFlag` version `v1beta1` CRD defines a CR with the following example structure:
 
 ```yaml
-apiVersion: core.openfeature.dev/v1alpha2
-kind: FeatureFlagConfiguration
+apiVersion: core.openfeature.dev/v1beta1
+kind: FeatureFlag
 metadata:
-  name: featureflagconfiguration-sample
+  name: featureflag-sample
 spec:
-  featureFlagSpec:
+  flagSpec:
     flags:
       foo:
         state: "ENABLED"
@@ -22,7 +22,7 @@ In the example above, we have defined a `String` type feature flag named `foo` a
 It has variants of `bar` and `baz`, referring to respected values of `BAR` and `BAZ`.
 The default variant is set to`bar`.
 
-## featureFlagSpec
+## flagSpec
 
-The `featureFlagSpec` is an object representing the flag configurations themselves.
+The `flagSpec` is an object representing the flag definitions themselves.
 The documentation for this object can be found [here](https://github.com/open-feature/flagd/blob/main/docs/configuration/flag_configuration.md).
diff --git a/docs/feature_flag_source.md b/docs/feature_flag_source.md
@@ -1,44 +1,45 @@
 # Flag Source configuration
 
-The injected sidecar is configured using the `FlagSourceConfiguration` custom resource definition. 
-The `openfeature.dev/flagsourceconfiguration` annotation is used to assign Pods with their respective`FlagSourceConfiguration` custom resources.
+The injected sidecar is configured using the `FeatureFlagSource` custom resource definition. 
+The `openfeature.dev/featureflagsource` annotation is used to assign Pods with their respective `FeatureFlagSource` custom resources.
 
-A minimal example of a `FlagSourceConfiguration` is given below,
+A minimal example of a `FeatureFlagSource` is given below,
 
 ```yaml
-apiVersion: core.openfeature.dev/v1alpha3
-kind: FlagSourceConfiguration
+apiVersion: core.openfeature.dev/v1beta1
+kind: FeatureFlagSource
 metadata:
-  name: flag-source-configuration
+  name: feature-flag-source
 spec:
   sources:                        # flag sources for the injected flagd
-    - source: flags/sample-flags  # FlagSourceConfiguration - namespace/name
-      provider: kubernetes        # kubernetes flag source backed by FlagSourceConfiguration custom resource
+    - source: flags/sample-flags  # FeatureFlag - namespace/name
+      provider: kubernetes        # kubernetes flag source backed by FeatureFlag custom resource
   port: 8080                      # port of the flagd sidecar
 ```
 
 ## Feature flag sources
 
 This section explains how to configure feature flag sources to injected flag sidecar.
 
-`FlagSourceConfiguration` support multiple flag sources. Sources are configured as a list and given below are supported sources and their configurations,
+`FeatureFlagSource` support multiple flag sources. Sources are configured as a list.
+Supported sources and their configurations are listed below.
 
-### kubernetes aka `FeatureFlagConfiguration`
+### kubernetes aka `FeatureFlag`
 
-This is `FeatureFlagConfiguration` custom resource backed flagd feature flag definition.
-Read more on the custom resource at the dedicated documentation of [FeatureFlagConfiguration](./feature_flag_configuration.md)
+This is `FeatureFlag` custom resource backed flagd feature flag definition.
+Read more about the custom resource at the dedicated documentation of [FeatureFlag](./feature_flag.md)
 
-To refer this custom resource in `FlagSourceConfiguration`, provider type `kubernetes` is used as below example,
+The following example of a `FeatureFlagSource` uses `kubernetes` as the `provider` type:
 
 ```yaml
 sources:                        
-  - source: flags/sample-flags  # FeatureFlagConfiguration - namespace/custom_resource_name
-    provider: kubernetes        # kubernetes flag source backed by FeatureFlagConfiguration custom resource
+  - source: flags/sample-flags  # FeatureFlag - namespace/custom_resource_name
+    provider: kubernetes        # kubernetes flag source backed by FeatureFlag custom resource
 ```
 
 ### flagd-proxy
 
-`flagd-proxy` is an alternative to direct resource access on `FeatureFlagConfiguration` custom resources.
+`flagd-proxy` is an alternative to direct resource access on `FeatureFlag` custom resources.
 This source type is useful when there is a need for restricting workload permissions and/or to reduce k8s API load.
 
 Read more about proxy approach to access kubernetes resources: [flagd-proxy](./flagd_proxy.md)
@@ -81,7 +82,7 @@ sources:
 
 ## Sidecar configurations
 
-`FlagSourceConfiguration` further allows to provide configurations to the injected flagd sidecar.
+`FeatureFlagSource` provides configurations to the injected flagd sidecar.
 Table given below is non-exhaustive list of overriding options,
 
 | Configuration    | Explanation                   | Default                                        |
@@ -105,18 +106,20 @@ If no namespace is provided, it is assumed that the CR is within the same namesp
         namespace: test-ns
         annotations:
             openfeature.dev/enabled: "true"
-            openfeature.dev/flagsourceconfiguration: "config-A, test-ns-2/config-B"
+            openfeature.dev/featureflagsource: "config-A, test-ns-2/config-B"
 ```
 
 In this example, 2 CRs are being used to configure the injected container (by default the operator uses the `flagd:main` image), `config-A` (which is assumed to be in the namespace `test-ns`) and `config-B` from the `test-ns-2` namespace, with `config-B` taking precedence in the configuration merge.
 
-The `FlagSourceConfiguration` version `v1alpha3` CRD defines a CR with the following example structure, the documentation for this CRD can be found [here](crds.md#flagsourceconfiguration):
+The `FeatureFlagSource` version `v1beta1` CRD defines a CR with the following example structure.
+The documentation for this CRD can be found
+[here](crds.md#featureflagsource):
 
 ```yaml
-apiVersion: core.openfeature.dev/v1alpha3
-kind: FlagSourceConfiguration
+apiVersion: core.openfeature.dev/v1beta1
+kind: FeatureFlagSource
 metadata:
-    name: flag-source-sample
+    name: feature-flag-source-sample
 spec:
     metricsPort: 8080
     port: 80
@@ -145,16 +148,16 @@ spec:
         memory: 256Mi
 ```
 
-The relevant `FlagSourceConfigurations` are passed to the operator by setting the `openfeature.dev/flagsourceconfiguration` annotation, and is responsible for providing the full configuration of the injected sidecar.
+The relevant `FeatureFlagSources` are passed to the operator by setting the `openfeature.dev/featureflagsource` annotation, which provides the full configuration of the injected sidecar.
 
 ## Configuration Merging
 
-When multiple `FlagSourceConfigurations` are provided, the configurations are merged. The last `CR` takes precedence over the first, with any configuration from the deprecated `FlagDSpec` field of the `FeatureFlagConfiguration` CRD taking the lowest priority. 
+When multiple `FeatureFlagSources` are provided, the configurations are merged. The last `CR` takes precedence over the first. 
 
 
 ```mermaid
 flowchart LR
-    FlagSourceConfiguration-values  -->|highest priority| environment-variables -->|lowest priority| defaults
+    FeatureFlagSource-values  -->|highest priority| environment-variables -->|lowest priority| defaults
 ```
 
 
@@ -163,12 +166,12 @@ An example of this behavior:
     metadata:
         annotations:
             openfeature.dev/enabled: "true"
-            openfeature.dev/flagsourceconfiguration:"config-A, config-B"
+            openfeature.dev/featureflagsource:"config-A, config-B"
 ```
 Config-A:
 ```
-apiVersion: core.openfeature.dev/v1alpha2
-kind: FlagSourceConfiguration
+apiVersion: core.openfeature.dev/v1beta1
+kind: FeatureFlagSource
 metadata:
     name: config-A
 spec:
@@ -177,8 +180,8 @@ spec:
 ```
 Config-B:
 ```
-apiVersion: core.openfeature.dev/v1alpha2
-kind: FlagSourceConfiguration
+apiVersion: core.openfeature.dev/v1beta1
+kind: FeatureFlagSource
 metadata:
     name: config-B
 spec:
diff --git a/docs/flagd_proxy.md b/docs/flagd_proxy.md
@@ -2,13 +2,13 @@
 
 > The flagd kube proxy is currently in an experimental state
 
-The `flagd-proxy` is a pub/sub for mechanism watching configuration changes in `FeatureFlagConfiguration` CRs.
+The `flagd-proxy` is a pub/sub for mechanism watching configuration changes in `FeatureFlag` CRs.
 This source type avoids the need for additional cluster wide permissions in the workload pod, and reduces load on the k8s API.
-In order for a pod to have the required permissions to watch a `FeatureFlagConfiguration` CR in the default implementation, it must have its service account appended to the `flagd-kubernetes-sync` role binding, the details for this role can be found [here](./permissions.md).
+In order for a pod to have the required permissions to watch a `FeatureFlag` CR in the default implementation, it must have its service account appended to the `flagd-kubernetes-sync` role binding, the details for this role can be found [here](./permissions.md).
 In some use cases this may not be favorable, in these scenarios the alternative `flagd-proxy` implementation may be used.
 
 The `flagd-proxy` bypasses the widespread permissions issue by acting as the single source of truth for subscribed flagd instances, broadcasting configuration changes to all subscribed pods via gRPC streams.
-For each requested `FeatureFlagConfiguration` a new ISync implementation is started, and closed once there are no longer any listeners.
+For each requested `FeatureFlag` a new ISync implementation is started, and closed once there are no longer any listeners.
 This results in only one set of resources requiring the `flagd-kubernetes-sync` permissions, tightening the restrictions on all other pods.
 
 ## Architecture
@@ -19,15 +19,15 @@ The diagram below describes the high level architecture and implementation of th
     <img src="../images/flagd-proxy-arch.png" width="95%">
 </p>
 
-The `flagd-proxy` is only deployed once the reconcile loop for a `FlagSourceConfiguration` is run with a CR containing the provider `"flagd-proxy"` in its source array.
+The `flagd-proxy` is only deployed once the reconcile loop for a `FeatureFlagSource` is run with a CR containing the provider `"flagd-proxy"` in its source array.
 
 ## Implementation
 
 Update the end-to-end test in `/config/samples/end-to-end.yaml` to use the `"flagd-proxy"` provider, the source should be a `namespace/name`.
 
 ```diff
-apiVersion: core.openfeature.dev/v1alpha2
-kind: FlagSourceConfiguration
+apiVersion: core.openfeature.dev/v1beta1
+kind: FeatureFlagSource
 metadata:
   name: end-to-end
   namespace: open-feature-demo
diff --git a/docs/installation.md b/docs/installation.md
@@ -37,16 +37,16 @@ OpenFeature Operator's CRDs are templated, and can be updated apart from the ope
 helm template openfeature/open-feature-operator -s templates/{CRD} | kubectl apply -f -
 ```
 
-For the `featureflagconfigurations.core.openfeature.dev` CRD:
+For the `featureflags.core.openfeature.dev` CRD:
 
 ```sh
-helm template openfeature/open-feature-operator -s templates/apiextensions.k8s.io_v1_customresourcedefinition_featureflagconfigurations.core.openfeature.dev.yaml | kubectl apply -f -
+helm template openfeature/open-feature-operator -s templates/apiextensions.k8s.io_v1_customresourcedefinition_featureflags.core.openfeature.dev.yaml | kubectl apply -f -
 ```
 
-For the `flagsourceconfigurations.core.openfeature.dev` CRD:
+For the `featureflagsources.core.openfeature.dev` CRD:
 
 ```sh
-helm template openfeature/open-feature-operator -s templates/apiextensions.k8s.io_v1_customresourcedefinition_flagsourceconfigurations.core.openfeature.dev.yaml | kubectl apply -f -
+helm template openfeature/open-feature-operator -s templates/apiextensions.k8s.io_v1_customresourcedefinition_featureflagsources.core.openfeature.dev.yaml | kubectl apply -f -
 ```
 
 Keep in mind, you can set values as usual during this process:
@@ -77,7 +77,7 @@ kubectl delete namespace open-feature-operator-system
 <!-- x-release-please-end -->
 
 ## Release contents
-- `FeatureFlagConfiguration` `CustomResourceDefinition` (custom type that holds the configured state of feature flags).
+- `FeatureFlag` `CustomResourceDefinition` (custom type that holds the configured state of feature flags).
 - Standard kubernetes primitives (e.g. namespace, accounts, roles, bindings, configmaps).
 - Operator controller manager service.
 - Operator webhook service.
diff --git a/docs/permissions.md b/docs/permissions.md
diff --git a/docs/quick_start.md b/docs/quick_start.md
diff --git a/images/source/arch-0.excalidraw b/images/source/arch-0.excalidraw
