You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: CONTRIBUTING.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -7,16 +7,16 @@ There are a few things to consider before contributing to open-feature-operator.
7
7
Firstly, there's [a code of conduct](https://github.com/open-feature/.github/blob/main/CODE_OF_CONDUCT.md).
8
8
TLDR: be respectful.
9
9
10
-
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.
10
+
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.
11
11
12
12
The go version in the `go.mod` is the currently supported version of go.
13
13
14
14
Thanks! Issues and pull requests following these guidelines are welcome.
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`.
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`.
20
20
Follow [this tutorial](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html) to implement a new version of the custom resource definition.
Copy file name to clipboardexpand all lines: docs/README.md
+5-5
Original file line number
Diff line number
Diff line change
@@ -12,14 +12,14 @@ Follow the detailed installation guide to deploy open feature operator to your l
12
12
13
13
## Configuration
14
14
15
-
Configuration of the deployed sidecars is handled through the `FlagSourceConfiguration` custom resources defined at`openfeature.dev/flagsourceconfiguration` annotation of the deployed `PodSpec`.
15
+
Configuration of the deployed sidecars is handled through the `FeatureFlagSource` custom resources referenced via `openfeature.dev/featureflagsource` annotations of the deployed `PodSpec`.
16
16
17
17
The relationship between the deployment and custom resources is highlighted in the diagram below,
provider: kubernetes # kubernetes flag source backed by FeatureFlag custom resource
17
17
port: 8080# port of the flagd sidecar
18
18
```
19
19
20
20
## Feature flag sources
21
21
22
22
This section explains how to configure feature flag sources to injected flag sidecar.
23
23
24
-
`FlagSourceConfiguration` support multiple flag sources. Sources are configured as a list and given below are supported sources and their configurations,
24
+
`FeatureFlagSource` support multiple flag sources. Sources are configured as a list.
25
+
Supported sources and their configurations are listed below.
25
26
26
-
### kubernetes aka `FeatureFlagConfiguration`
27
+
### kubernetes aka `FeatureFlag`
27
28
28
-
This is `FeatureFlagConfiguration` custom resource backed flagd feature flag definition.
29
-
Read more on the custom resource at the dedicated documentation of [FeatureFlagConfiguration](./feature_flag_configuration.md)
29
+
This is `FeatureFlag` custom resource backed flagd feature flag definition.
30
+
Read more about the custom resource at the dedicated documentation of [FeatureFlag](./feature_flag.md)
30
31
31
-
To refer this custom resource in `FlagSourceConfiguration`, provider type `kubernetes` is used as below example,
32
+
The following example of a `FeatureFlagSource` uses `kubernetes` as the `provider` type:
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.
112
113
113
-
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):
114
+
The `FeatureFlagSource` version `v1beta1` CRD defines a CR with the following example structure.
115
+
The documentation for this CRD can be found
116
+
[here](crds.md#featureflagsource):
114
117
115
118
```yaml
116
-
apiVersion: core.openfeature.dev/v1alpha3
117
-
kind: FlagSourceConfiguration
119
+
apiVersion: core.openfeature.dev/v1beta1
120
+
kind: FeatureFlagSource
118
121
metadata:
119
-
name: flag-source-sample
122
+
name: feature-flag-source-sample
120
123
spec:
121
124
metricsPort: 8080
122
125
port: 80
@@ -145,16 +148,16 @@ spec:
145
148
memory: 256Mi
146
149
```
147
150
148
-
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.
151
+
The relevant `FeatureFlagSources` are passed to the operator by setting the `openfeature.dev/featureflagsource` annotation, which provides the full configuration of the injected sidecar.
149
152
150
153
## Configuration Merging
151
154
152
-
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.
155
+
When multiple `FeatureFlagSources` are provided, the configurations are merged. The last `CR` takes precedence over the first.
Copy file name to clipboardexpand all lines: docs/flagd_proxy.md
+6-6
Original file line number
Diff line number
Diff line change
@@ -2,13 +2,13 @@
2
2
3
3
> The flagd kube proxy is currently in an experimental state
4
4
5
-
The `flagd-proxy` is a pub/sub for mechanism watching configuration changes in `FeatureFlagConfiguration` CRs.
5
+
The `flagd-proxy` is a pub/sub for mechanism watching configuration changes in `FeatureFlag` CRs.
6
6
This source type avoids the need for additional cluster wide permissions in the workload pod, and reduces load on the k8s API.
7
-
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).
7
+
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).
8
8
In some use cases this may not be favorable, in these scenarios the alternative `flagd-proxy` implementation may be used.
9
9
10
10
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.
11
-
For each requested `FeatureFlagConfiguration` a new ISync implementation is started, and closed once there are no longer any listeners.
11
+
For each requested `FeatureFlag` a new ISync implementation is started, and closed once there are no longer any listeners.
12
12
This results in only one set of resources requiring the `flagd-kubernetes-sync` permissions, tightening the restrictions on all other pods.
13
13
14
14
## Architecture
@@ -19,15 +19,15 @@ The diagram below describes the high level architecture and implementation of th
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.
22
+
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.
23
23
24
24
## Implementation
25
25
26
26
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`.
0 commit comments