OpenFeature Operator version v0.5.0 contain improved, stable CRDs which were upgraded to v1beta1 api version.
This document shows what was changed and how you can upgrade your existing CRDs to be compatible with this new release.
Along with the API version upgrade to v1beta1, we have renamed FeatureFlagConfiguration to FeatureFlag, making the naming clearer for the custom resource maintainers.
In this CRD, spec section naming has changed. The older CRD used featureFlagSpec to define flag configurations.
In the new version, flags are configured under flagSpec element.
Consider below example with diff from old version to new version,
- apiVersion: core.openfeature.dev/v1alpha3
- kind: FeatureFlagConfiguration
+ apiVersion: core.openfeature.dev/v1beta1
+ kind: FeatureFlag
metadata:
name: end-to-end
labels:
app: open-feature-demo
spec:
- featureFlagSpec:
+ flagSpec
flags:
new-welcome-message:
state: ENABLED
variants:
'on': true
'off': false
defaultVariant: 'off'
There are two annotations to control how OFO works on your workload.
With the upgrade to v1beta1, we no longer support deprecated openfeature.dev/featureflagconfiguration annotation.
Workloads which require feature flagging now need to use openfeature.dev/featureflagsource annotation, referring a FeatureFlagSource CRD.
This is the CRD previously named FlagSourceConfiguration.
annotations:
openfeature.dev/enabled: "true"
- openfeature.dev/featureflagconfiguration: "end-to-end"
+ openfeature.dev/featureflagsource: "end-to-end"
FeatureFlagSource provide more flexibility by allowing users to configure the injected flag with many options.
Consider below example for a FeatureFlagSource where flagd is instructed to use FeatureFlag custom resource named end-to-end as its flag source
- apiVersion: core.openfeature.dev/v1alpha3
- kind: FlagSourceConfiguration
+ apiVersion: core.openfeature.dev/v1beta1
+ kind: FeatureFlagSource
metadata:
name: end-to-end
labels:
app: open-feature-demo
spec:
sources:
- source: end-to-end
provider: kubernetes
The new operator no longer support older API versions. Because of this, you need to plan your upgrade carefully.
We recommend following migration steps,
If you have used flagd-proxy provider, then you have to upgrade the image used by the flagd-proxy deployment.
For this, please edit the deployment of flagd-proxy to version v0.3.1 or above.
[!NOTE] Since OFO version
v0.5.4, the instance offlagd-proxypod (if used) will be upgraded automatically to the to the latest supported version byopen-feature-operator. For more information see the upgrade section.