From 0271c2f809a05dc43b4d3014e6503bc020c09670 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 16:10:00 +1000
Subject: [PATCH 01/21] add menu items and pages. point
docs/configuration/configuration.md to website
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/configuration/configuration.md | 171 +---------------------------
mkdocs.yml | 3 +
web-docs/reference/configuration.md | 158 +++++++++++++++++++++++++
web-docs/reference/flagd_start.md | 36 ++++++
4 files changed, 198 insertions(+), 170 deletions(-)
create mode 100644 web-docs/reference/configuration.md
create mode 100644 web-docs/reference/flagd_start.md
diff --git a/docs/configuration/configuration.md b/docs/configuration/configuration.md
index 5b1f070ee..8f0428cfe 100644
--- a/docs/configuration/configuration.md
+++ b/docs/configuration/configuration.md
@@ -1,172 +1,3 @@
# Configuration
-
-- [Configuration](#configuration)
- - [Sync providers](#sync-providers)
- - [Kubernetes provider](#kubernetes-provider)
- - [Filepath provider](#filepath-provider)
- - [Remote provider](#remote-provider)
- - [GRPC provider](#grpc-provider)
- - [Sync provider configurations](#sync-provider-configurations)
- - [URI patterns](#uri-patterns)
- - [Source Configuration](#source-configuration)
-
-
-`flagd` supports configuration via config file, environment variables and start-up flags. In cases of a conflict,
-start-up flags have the highest priority, followed by environment variables and config file.
-
-Supported start-up flags are documented (auto-generated) [here](./flagd_start.md).
-
-Environment variable keys are uppercase, prefixed with `FLAGD_` and all `-` are replaced with `_`. For example,
-`metrics-port` flag in environment variable form is `FLAGD_METRICS_PORT`.
-
-The config file expects the keys to have the exact naming as startup-flags flags.
-
-## Sync providers
-
-Sync providers are a core part of flagd; they are the abstraction that enables different sources for feature flag configurations.
-flagd currently support the following sync providers:
-
-- [Configuration](#configuration)
- - [Sync providers](#sync-providers)
- - [Kubernetes provider](#kubernetes-provider)
- - [Filepath provider](#filepath-provider)
- - [Remote provider](#remote-provider)
- - [GRPC provider](#grpc-provider)
- - [Sync provider configurations](#sync-provider-configurations)
- - [URI patterns](#uri-patterns)
- - [Source Configuration](#source-configuration)
-
-### Kubernetes provider
-
-The Kubernetes sync provider allows flagd to connect to a Kubernetes cluster and evaluate flags against a specified
-FeatureFlagConfiguration resource as defined within
-the [open-feature-operator](https://github.com/open-feature/open-feature-operator/blob/main/apis/core/v1alpha1/featureflagconfiguration_types.go)
-spec.
-
-To use an existing FeatureFlagConfiguration custom resource, start flagD with the following command:
-
-```shell
-flagd start --uri core.openfeature.dev/default/my_example
-```
-
-In this example, `default/my_example` expected to be a valid FeatureFlagConfiguration resource, where `default` is the
-namespace and `my_example` being the resource name.
-
-### Filepath provider
-
-The file path sync provider reads and watch the source file for updates(ex:- changes and deletions).
-
-```shell
-flagd start --uri file:etc/featureflags.json
-```
-
-In this example, `etc/featureflags.json` is a valid feature flag configuration file accessible by the flagd runtime.
-
-### Remote provider
-
-The HTTP sync provider fetch flags from a remote source and periodically poll the source for flag configuration updates.
-
-```shell
-flagd start --uri https://my-flag-source.json
-```
-
-In this example, `https://my-flag-source.json` is a remote endpoint responding valid feature flag configurations when
-invoked with **HTTP GET** request.
-
-### GRPC provider
-
-The GRPC sync provider streams flag configurations from a grpc sync provider implementation. This stream connection is ruled
-by
-the [sync service protobuf definition](https://github.com/open-feature/schemas/blob/main/protobuf/sync/v1/sync_service.proto).
-
-```shell
-flagd start --uri grpc://grpc-sync-source
-```
-
-In this example, `grpc-sync-source` is a grpc target implementing flagd protobuf definition.
-
-There are two mechanisms to provide configurations of sync providers,
-
-- [URI patterns](#uri-patterns)
-- [Source Configuration](#source-configuration)
-
-## Sync provider configurations
-
-### URI patterns
-
-Any URI passed to flagd via the `--uri` flag must follow one of the 4 following patterns with prefixes to ensure that
-it is passed to the correct implementation:
-
-| Sync | Prefix | Example |
-| ---------- | ---------------------- | ------------------------------------- |
-| Kubernetes | `core.openfeature.dev` | `core.openfeature.dev/default/my-crd` |
-| Filepath | `file:` | `file:etc/flagd/my-flags.json` |
-| Remote | `http(s)://` | `https://my-flags.com/flags` |
-| Grpc | `grpc(s)://` | `grpc://my-flags-server` |
-
-### Source Configuration
-
-While a URI may be passed to flagd via the `--uri` flag, some implementations may require further configurations.
-In these cases the `--sources` flag should be used.
-
-The flagd accepts a string argument, which should be a JSON representation of an array of `SourceConfig` objects.
-
-Alternatively, these configurations can be passed to flagd via config file, specified using the `--config` flag.
-
-| Field | Type | Note |
-| ----------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |
-| uri | required `string` | Flag configuration source of the provider |
-| provider | required `string` | Provider type - `file`, `kubernetes`, `http` or `grpc` |
-| bearerToken | optional `string` | Used for http sync; token gets appended to `Authorization` header with [bearer schema](https://www.rfc-editor.org/rfc/rfc6750#section-2.1) |
-| interval | optional `uint32` | Used for http sync; requests will be made at this interval. Defaults to 5 seconds. |
-| tls | optional `boolean` | Enable/Disable secure TLS connectivity. Currently used only by GRPC sync. Default(ex:- if unset) is false, which will use an insecure connection |
-| providerID | optional `string` | Value binds to grpc connection's providerID field. GRPC server implementations may use this to identify connecting flagd instance |
-| selector | optional `string` | Value binds to grpc connection's selector field. GRPC server implementations may use this to filter flag configurations |
-| certPath | optional `string` | Used for grpcs sync when TLS certificate is needed. If not provided, system certificates will be used for TLS connection |
-
-The `uri` field values **do not** follow the [URI patterns](#uri-patterns). The provider type is instead derived
-from the `provider` field. Only exception is the remote provider where `http(s)://` is expected by default. Incorrect
-URIs will result in a flagd start-up failure with errors from the respective sync provider implementation.
-
-Given below are example sync providers, startup command and equivalent config file definition:
-
-Sync providers,
-
-- `file` - config/samples/example_flags.json
-- `http` -
-- `kubernetes` - default/my-flag-config
-- `grpc`(insecure) - grpc-source:8080
-- `grpc`(secure) - my-flag-source:8080
-
-Startup command,
-
-```sh
-./bin/flagd start
---sources='[{"uri":"config/samples/example_flags.json","provider":"file"},
- {"uri":"http://my-flag-source.json","provider":"http","bearerToken":"bearer-dji34ld2l"},
- {"uri":"default/my-flag-config","provider":"kubernetes"},
- {"uri":"grpc-source:8080","provider":"grpc"},
- {"uri":"my-flag-source:8080","provider":"grpc", "certPath": "/certs/ca.cert", "tls": true, "providerID": "flagd-weatherapp-sidecar", "selector": "source=database,app=weatherapp"}]'
-```
-
-Configuration file,
-
-```yaml
-sources:
- - uri: config/samples/example_flags.json
- provider: file
- - uri: http://my-flag-source.json
- provider: http
- bearerToken: bearer-dji34ld2l
- - uri: default/my-flag-config
- provider: kubernetes
- - uri: my-flag-source:8080
- provider: grpc
- - uri: my-flag-source:8080
- provider: grpc
- certPath: /certs/ca.cert
- tls: true
- providerID: flagd-weatherapp-sidecar
- selector: 'source=database,app=weatherapp'
-```
+The content of this page has moved. See [flagd configuration](https://flagd.dev/reference/configuration.md)
\ No newline at end of file
diff --git a/mkdocs.yml b/mkdocs.yml
index d67cfcdd9..444ef6de3 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -50,5 +50,8 @@ nav:
- 'Kubernetes Custom Resources':
- 'FlagSourceConfiguration': 'k8s/crds/flagsourceconfiguration.md'
- 'FeatureFlagConfiguration': 'k8s/crds/featureflagconfiguration.md'
+ - 'Reference':
+ - 'Flagd Configuration': 'reference/configuration.md'
+ - 'Flagd Start': 'reference/flagd_start.md'
- 'Flagd Telemetry':
- 'Flagd OpenTelemetry Support': 'concepts/opentelemetry.md'
\ No newline at end of file
diff --git a/web-docs/reference/configuration.md b/web-docs/reference/configuration.md
new file mode 100644
index 000000000..886677109
--- /dev/null
+++ b/web-docs/reference/configuration.md
@@ -0,0 +1,158 @@
+`flagd` supports configuration via config file, environment variables and start-up flags. In cases of a conflict,
+start-up flags have the highest priority, followed by environment variables and config file.
+
+Supported start-up flags are documented (auto-generated) [here](./flagd_start.md).
+
+Environment variable keys are uppercase, prefixed with `FLAGD_` and all `-` are replaced with `_`. For example,
+`metrics-port` flag in environment variable form is `FLAGD_METRICS_PORT`.
+
+The config file expects the keys to have the exact naming as startup-flags flags.
+
+## Sync providers
+
+Sync providers are a core part of flagd; they are the abstraction that enables different sources for feature flag configurations.
+flagd currently support the following sync providers:
+
+- [Configuration](#configuration)
+ - [Sync providers](#sync-providers)
+ - [Kubernetes provider](#kubernetes-provider)
+ - [Filepath provider](#filepath-provider)
+ - [Remote provider](#remote-provider)
+ - [GRPC provider](#grpc-provider)
+ - [Sync provider configurations](#sync-provider-configurations)
+ - [URI patterns](#uri-patterns)
+ - [Source Configuration](#source-configuration)
+
+### Kubernetes provider
+
+The Kubernetes sync provider allows flagd to connect to a Kubernetes cluster and evaluate flags against a specified
+FeatureFlagConfiguration resource as defined within
+the [open-feature-operator](https://github.com/open-feature/open-feature-operator/blob/main/apis/core/v1alpha1/featureflagconfiguration_types.go)
+spec.
+
+To use an existing FeatureFlagConfiguration custom resource, start flagD with the following command:
+
+```shell
+flagd start --uri core.openfeature.dev/default/my_example
+```
+
+In this example, `default/my_example` expected to be a valid FeatureFlagConfiguration resource, where `default` is the
+namespace and `my_example` being the resource name.
+
+### Filepath provider
+
+The file path sync provider reads and watch the source file for updates(ex:- changes and deletions).
+
+```shell
+flagd start --uri file:etc/featureflags.json
+```
+
+In this example, `etc/featureflags.json` is a valid feature flag configuration file accessible by the flagd runtime.
+
+### Remote provider
+
+The HTTP sync provider fetch flags from a remote source and periodically poll the source for flag configuration updates.
+
+```shell
+flagd start --uri https://my-flag-source.json
+```
+
+In this example, `https://my-flag-source.json` is a remote endpoint responding valid feature flag configurations when
+invoked with **HTTP GET** request.
+
+### GRPC provider
+
+The GRPC sync provider streams flag configurations from a grpc sync provider implementation. This stream connection is ruled
+by
+the [sync service protobuf definition](https://github.com/open-feature/schemas/blob/main/protobuf/sync/v1/sync_service.proto).
+
+```shell
+flagd start --uri grpc://grpc-sync-source
+```
+
+In this example, `grpc-sync-source` is a grpc target implementing flagd protobuf definition.
+
+There are two mechanisms to provide configurations of sync providers,
+
+- [URI patterns](#uri-patterns)
+- [Source Configuration](#source-configuration)
+
+## Sync provider configurations
+
+### URI patterns
+
+Any URI passed to flagd via the `--uri` flag must follow one of the 4 following patterns with prefixes to ensure that
+it is passed to the correct implementation:
+
+| Sync | Prefix | Example |
+| ---------- | ---------------------- | ------------------------------------- |
+| Kubernetes | `core.openfeature.dev` | `core.openfeature.dev/default/my-crd` |
+| Filepath | `file:` | `file:etc/flagd/my-flags.json` |
+| Remote | `http(s)://` | `https://my-flags.com/flags` |
+| Grpc | `grpc(s)://` | `grpc://my-flags-server` |
+
+### Source Configuration
+
+While a URI may be passed to flagd via the `--uri` flag, some implementations may require further configurations.
+In these cases the `--sources` flag should be used.
+
+The flagd accepts a string argument, which should be a JSON representation of an array of `SourceConfig` objects.
+
+Alternatively, these configurations can be passed to flagd via config file, specified using the `--config` flag.
+
+| Field | Type | Note |
+| ----------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |
+| uri | required `string` | Flag configuration source of the provider |
+| provider | required `string` | Provider type - `file`, `kubernetes`, `http` or `grpc` |
+| bearerToken | optional `string` | Used for http sync; token gets appended to `Authorization` header with [bearer schema](https://www.rfc-editor.org/rfc/rfc6750#section-2.1) |
+| interval | optional `uint32` | Used for http sync; requests will be made at this interval. Defaults to 5 seconds. |
+| tls | optional `boolean` | Enable/Disable secure TLS connectivity. Currently used only by GRPC sync. Default(ex:- if unset) is false, which will use an insecure connection |
+| providerID | optional `string` | Value binds to grpc connection's providerID field. GRPC server implementations may use this to identify connecting flagd instance |
+| selector | optional `string` | Value binds to grpc connection's selector field. GRPC server implementations may use this to filter flag configurations |
+| certPath | optional `string` | Used for grpcs sync when TLS certificate is needed. If not provided, system certificates will be used for TLS connection |
+
+The `uri` field values **do not** follow the [URI patterns](#uri-patterns). The provider type is instead derived
+from the `provider` field. Only exception is the remote provider where `http(s)://` is expected by default. Incorrect
+URIs will result in a flagd start-up failure with errors from the respective sync provider implementation.
+
+Given below are example sync providers, startup command and equivalent config file definition:
+
+Sync providers,
+
+- `file` - config/samples/example_flags.json
+- `http` -
+- `kubernetes` - default/my-flag-config
+- `grpc`(insecure) - grpc-source:8080
+- `grpc`(secure) - my-flag-source:8080
+
+Startup command,
+
+```sh
+./bin/flagd start
+--sources='[{"uri":"config/samples/example_flags.json","provider":"file"},
+ {"uri":"http://my-flag-source.json","provider":"http","bearerToken":"bearer-dji34ld2l"},
+ {"uri":"default/my-flag-config","provider":"kubernetes"},
+ {"uri":"grpc-source:8080","provider":"grpc"},
+ {"uri":"my-flag-source:8080","provider":"grpc", "certPath": "/certs/ca.cert", "tls": true, "providerID": "flagd-weatherapp-sidecar", "selector": "source=database,app=weatherapp"}]'
+```
+
+Configuration file,
+
+```yaml
+sources:
+ - uri: config/samples/example_flags.json
+ provider: file
+ - uri: http://my-flag-source.json
+ provider: http
+ bearerToken: bearer-dji34ld2l
+ - uri: default/my-flag-config
+ provider: kubernetes
+ - uri: my-flag-source:8080
+ provider: grpc
+ - uri: my-flag-source:8080
+ provider: grpc
+ certPath: /certs/ca.cert
+ tls: true
+ providerID: flagd-weatherapp-sidecar
+ selector: 'source=database,app=weatherapp'
+```
\ No newline at end of file
diff --git a/web-docs/reference/flagd_start.md b/web-docs/reference/flagd_start.md
new file mode 100644
index 000000000..c443eebfa
--- /dev/null
+++ b/web-docs/reference/flagd_start.md
@@ -0,0 +1,36 @@
+
+## flagd start
+
+Start flagd
+
+```
+flagd start [flags]
+```
+
+### Options
+
+```
+ -b, --bearer-token string DEPRECATED: Superseded by --sources.
+ -C, --cors-origin strings CORS allowed origins, * will allow all origins
+ -e, --evaluator string DEPRECATED: Set an evaluator e.g. json, yaml/yml.Please note that yaml/yml and json evaluations work the same (yaml/yml files are converted to json internally) (default "json")
+ -h, --help help for start
+ -z, --log-format string Set the logging format, e.g. console or json (default "console")
+ -t, --metrics-exporter string Set the metrics exporter. Default(if unset) is Prometheus. Can be override to otel - OpenTelemetry metric exporter. Overriding to otel require otelCollectorURI to be present
+ -m, --metrics-port int32 Port to serve metrics on (default 8014)
+ -o, --otel-collector-uri string Set the grpc URI of the OpenTelemetry collector for flagd runtime. If unset, the collector setup will be ignored and traces will not be exported.
+ -p, --port int32 Port to listen on (default 8013)
+ -c, --server-cert-path string Server side tls certificate path
+ -k, --server-key-path string Server side tls key path
+ -d, --socket-path string Flagd socket path. With grpc the service will become available on this address. With http(s) the grpc-gateway proxy will use this address internally.
+ -s, --sources string JSON representation of an array of SourceConfig objects. This object contains 2 required fields, uri (string) and provider (string). Documentation for this object: https://github.com/open-feature/flagd/blob/main/docs/configuration/configuration.md#sync-provider-customisation
+ -y, --sync-provider string DEPRECATED: Set a sync provider e.g. filepath or remote
+ -a, --sync-provider-args stringToString DEPRECATED: Sync provider arguments as key values separated by = (default [])
+ -f, --uri .yaml/.yml/.json Set a sync provider uri to read data from, this can be a filepath,url (http and grpc) or FeatureFlagConfiguration. When flag keys are duplicated across multiple providers the merge priority follows the index of the flag arguments, as such flags from the uri at index 0 take the lowest precedence, with duplicated keys being overwritten by those from the uri at index 1. Please note that if you are using filepath, flagd only supports files with .yaml/.yml/.json extension.
+```
+
+### Options inherited from parent commands
+
+```
+ --config string config file (default is $HOME/.agent.yaml)
+ -x, --debug verbose logging
+```
\ No newline at end of file
From d31d1f37a6a9ceaca4fdd6060944f6945ba7da9a Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 16:15:37 +1000
Subject: [PATCH 02/21] markdown lint
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/configuration/configuration.md | 2 +-
web-docs/reference/configuration.md | 8 +++++---
web-docs/reference/flagd_start.md | 15 +++++++--------
3 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/docs/configuration/configuration.md b/docs/configuration/configuration.md
index 8f0428cfe..7ba7746d8 100644
--- a/docs/configuration/configuration.md
+++ b/docs/configuration/configuration.md
@@ -1,3 +1,3 @@
# Configuration
-The content of this page has moved. See [flagd configuration](https://flagd.dev/reference/configuration.md)
\ No newline at end of file
+The content of this page has moved. See [flagd configuration](https://flagd.dev/reference/configuration.md)
diff --git a/web-docs/reference/configuration.md b/web-docs/reference/configuration.md
index 886677109..f3a1f4377 100644
--- a/web-docs/reference/configuration.md
+++ b/web-docs/reference/configuration.md
@@ -1,7 +1,9 @@
+# flagd Configuration
+
`flagd` supports configuration via config file, environment variables and start-up flags. In cases of a conflict,
start-up flags have the highest priority, followed by environment variables and config file.
-Supported start-up flags are documented (auto-generated) [here](./flagd_start.md).
+Supported start-up flags are documented (auto-generated) [here](flagd_start.md).
Environment variable keys are uppercase, prefixed with `FLAGD_` and all `-` are replaced with `_`. For example,
`metrics-port` flag in environment variable form is `FLAGD_METRICS_PORT`.
@@ -13,7 +15,7 @@ The config file expects the keys to have the exact naming as startup-flags flags
Sync providers are a core part of flagd; they are the abstraction that enables different sources for feature flag configurations.
flagd currently support the following sync providers:
-- [Configuration](#configuration)
+- [Configuration](./#configuration)
- [Sync providers](#sync-providers)
- [Kubernetes provider](#kubernetes-provider)
- [Filepath provider](#filepath-provider)
@@ -155,4 +157,4 @@ sources:
tls: true
providerID: flagd-weatherapp-sidecar
selector: 'source=database,app=weatherapp'
-```
\ No newline at end of file
+```
diff --git a/web-docs/reference/flagd_start.md b/web-docs/reference/flagd_start.md
index c443eebfa..36fa5fd75 100644
--- a/web-docs/reference/flagd_start.md
+++ b/web-docs/reference/flagd_start.md
@@ -1,15 +1,14 @@
-
-## flagd start
+# flagd start
-Start flagd
+Start flagd:
-```
+```shell
flagd start [flags]
```
-### Options
+## Options
-```
+```shell
-b, --bearer-token string DEPRECATED: Superseded by --sources.
-C, --cors-origin strings CORS allowed origins, * will allow all origins
-e, --evaluator string DEPRECATED: Set an evaluator e.g. json, yaml/yml.Please note that yaml/yml and json evaluations work the same (yaml/yml files are converted to json internally) (default "json")
@@ -30,7 +29,7 @@ flagd start [flags]
### Options inherited from parent commands
-```
+```shell
--config string config file (default is $HOME/.agent.yaml)
-x, --debug verbose logging
-```
\ No newline at end of file
+```
From d5131de63e5f4f1ae13f59c30ac98fb4807d562d Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 17:02:58 +1000
Subject: [PATCH 03/21] move otel to reference
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
mkdocs.yml | 3 +--
web-docs/concepts/index.md | 2 +-
web-docs/{concepts => reference}/opentelemetry.md | 0
3 files changed, 2 insertions(+), 3 deletions(-)
rename web-docs/{concepts => reference}/opentelemetry.md (100%)
diff --git a/mkdocs.yml b/mkdocs.yml
index 444ef6de3..6cc8d2535 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -53,5 +53,4 @@ nav:
- 'Reference':
- 'Flagd Configuration': 'reference/configuration.md'
- 'Flagd Start': 'reference/flagd_start.md'
- - 'Flagd Telemetry':
- - 'Flagd OpenTelemetry Support': 'concepts/opentelemetry.md'
\ No newline at end of file
+ - 'Flagd OpenTelemetry Support': 'reference/opentelemetry.md'
\ No newline at end of file
diff --git a/web-docs/concepts/index.md b/web-docs/concepts/index.md
index ebbe07c3b..a4bbe788f 100644
--- a/web-docs/concepts/index.md
+++ b/web-docs/concepts/index.md
@@ -194,4 +194,4 @@ flagd is fully compatible with OpenTelemetry:
- flagd exposes metrics at `http://localhost:8014/metrics`
- flagd can export metrics and traces to an OpenTelemetry collector.
-See the [flagd OpenTelemetry](opentelemetry.md) page for more information.
+See the [flagd OpenTelemetry](reference/opentelemetry.md) page for more information.
diff --git a/web-docs/concepts/opentelemetry.md b/web-docs/reference/opentelemetry.md
similarity index 100%
rename from web-docs/concepts/opentelemetry.md
rename to web-docs/reference/opentelemetry.md
From b70fa31aa4583964a2227e16558ffd4b1f46fa9c Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 17:04:41 +1000
Subject: [PATCH 04/21] update link
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/configuration/configuration.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/configuration/configuration.md b/docs/configuration/configuration.md
index 7ba7746d8..fa8147b16 100644
--- a/docs/configuration/configuration.md
+++ b/docs/configuration/configuration.md
@@ -1,3 +1,3 @@
# Configuration
-The content of this page has moved. See [flagd configuration](https://flagd.dev/reference/configuration.md)
+The content of this page has moved. See [flagd configuration](https://flagd.dev/reference/configuration)
From 1ecc2dbf2367f6724a38d9003564b1481f279f57 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 17:05:25 +1000
Subject: [PATCH 05/21] update docs/flagd_start.md
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/configuration/flagd_start.md | 40 +------------------------------
1 file changed, 1 insertion(+), 39 deletions(-)
diff --git a/docs/configuration/flagd_start.md b/docs/configuration/flagd_start.md
index a633b66ad..4aeadde19 100644
--- a/docs/configuration/flagd_start.md
+++ b/docs/configuration/flagd_start.md
@@ -1,41 +1,3 @@
-
## flagd start
-Start flagd
-
-```
-flagd start [flags]
-```
-
-### Options
-
-```
- -b, --bearer-token string DEPRECATED: Superseded by --sources.
- -C, --cors-origin strings CORS allowed origins, * will allow all origins
- -e, --evaluator string DEPRECATED: Set an evaluator e.g. json, yaml/yml.Please note that yaml/yml and json evaluations work the same (yaml/yml files are converted to json internally) (default "json")
- -h, --help help for start
- -z, --log-format string Set the logging format, e.g. console or json (default "console")
- -t, --metrics-exporter string Set the metrics exporter. Default(if unset) is Prometheus. Can be override to otel - OpenTelemetry metric exporter. Overriding to otel require otelCollectorURI to be present
- -m, --metrics-port int32 Port to serve metrics on (default 8014)
- -o, --otel-collector-uri string Set the grpc URI of the OpenTelemetry collector for flagd runtime. If unset, the collector setup will be ignored and traces will not be exported.
- -p, --port int32 Port to listen on (default 8013)
- -c, --server-cert-path string Server side tls certificate path
- -k, --server-key-path string Server side tls key path
- -d, --socket-path string Flagd socket path. With grpc the service will become available on this address. With http(s) the grpc-gateway proxy will use this address internally.
- -s, --sources string JSON representation of an array of SourceConfig objects. This object contains 2 required fields, uri (string) and provider (string). Documentation for this object: https://github.com/open-feature/flagd/blob/main/docs/configuration/configuration.md#sync-provider-customisation
- -y, --sync-provider string DEPRECATED: Set a sync provider e.g. filepath or remote
- -a, --sync-provider-args stringToString DEPRECATED: Sync provider arguments as key values separated by = (default [])
- -f, --uri .yaml/.yml/.json Set a sync provider uri to read data from, this can be a filepath,url (http and grpc) or FeatureFlagConfiguration. When flag keys are duplicated across multiple providers the merge priority follows the index of the flag arguments, as such flags from the uri at index 0 take the lowest precedence, with duplicated keys being overwritten by those from the uri at index 1. Please note that if you are using filepath, flagd only supports files with .yaml/.yml/.json extension.
-```
-
-### Options inherited from parent commands
-
-```
- --config string config file (default is $HOME/.agent.yaml)
- -x, --debug verbose logging
-```
-
-### SEE ALSO
-
-* [flagd](flagd) - Flagd is a simple command line tool for fetching and presenting feature flags to services. It is designed to conform to Open Feature schema for flag definitions.
-
+The content of this page has moved. See [flagd configuration](https://flagd.dev/reference/flagd_start)
\ No newline at end of file
From f459e5d5d045e9d191a805c1c0c53858f08a1a59 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 17:11:47 +1000
Subject: [PATCH 06/21] update
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
.../flag_configuration_merging.md | 62 +------------------
web-docs/concepts/index.md | 2 +-
web-docs/reference/configuration.md | 13 ++--
3 files changed, 6 insertions(+), 71 deletions(-)
diff --git a/docs/configuration/flag_configuration_merging.md b/docs/configuration/flag_configuration_merging.md
index c964c372a..c6b584e28 100644
--- a/docs/configuration/flag_configuration_merging.md
+++ b/docs/configuration/flag_configuration_merging.md
@@ -1,63 +1,3 @@
# Flag Configuration Merging
-Flagd can be configured to read from multiple sources at once, when this is the case flagd will merge all flag configurations into a single
-merged state.
-For example:
-
-```mermaid
-flowchart LR
- source-A -->|config-A| store -->|merge|source-A-config-A\nsource-B-config-B
- source-B -->|config-B| store
-```
-
-In this example, `source-A` and `source-B` provide a single flag configuration, `config-A` and `config-B` respectively.
-The merge logic for this configuration is simple, both flag configurations are added to the `store`.
-In most scenarios, these flag sources will be supplying `n` number of configurations, using a unique flag key for each configuration.
-However, as multiple sources are being used, there is the opportunity for keys to be duplicated, intentionally or not, between flag sources.
-In these situations `flagd` uses a merge priority order to ensure that its behavior is consistent.
-
-Merge order is dictated by the order that `sync-providers` and `uris` are defined, with the latest defined source taking precedence over those defined before it, as an example:
-
-```sh
-./bin/flagd start --uri file:source-A.json --uri file:source-B.json --uri file:source-C.json
-```
-
-When `flagd` is started with the command defined above, `source-B` takes priority over `source-A`, whilst `source-C` takes priority over both `source-B` and `source-A`.
-Using the above example, if a flag key is duplicated across all 3 sources, then the configuration from `source-C` would be the only one stored in the merged state.
-
-```mermaid
-flowchart LR
- source-A -->|config-A| store -->source-C-config-A
- source-B -->|config-A| store
- source-C -->|config-A| store
-```
-
-## State Resync Events
-
-Given the above example, the `source-A` and `source-B` 'versions' of flag configuration `config-A` have been discarded, so if a delete event in `source-C` results in the removal of `config-A`, there will no longer be any reference of`config-A` in flagd's store.
-As a result of this flagd will return `FLAG_NOT_FOUND` errors, and the OpenFeature SDK will always return the default value.
-
-To prevent flagd falling out of sync with its flag sources during delete events, resync events are used.
-When a delete event results in a flag configuration being removed from the merged state, the full set of configurations is requested from all flag sources, and the merged state is rebuilt.
-As a result, the value of `config-A` from `source-B` will be stored in the merged state, preventing flagd from returning `FLAG_NOT_FOUND` errors.
-
-```mermaid
-flowchart LR
- source-A -->|config-A| store -->source-C-config-A
- source-B -->|config-A| store
- source-C -->|config-A| store
- source-C -->|delete config-A|source-C-config-A
- source-C-config-A --> resync-event
-```
-
-In the example above, a delete event results in a resync event being fired, as `source-C` has deleted its 'version' of `config-A`, this results in a new merge state being formed from the remaining configurations.
-
-```mermaid
-flowchart LR
- source-A -->|config-A| store -->source-B-config-A
- source-B -->|config-A| store
- source-C -->store
-
-```
-
-Resync events may lead to further resync events if the returned flag configurations result in further delete events, however the state will eventually be resolved correctly.
+This content has moved. See [flag configuration merging](https://flagd.dev/nonk8s/flagmerging/)
\ No newline at end of file
diff --git a/web-docs/concepts/index.md b/web-docs/concepts/index.md
index a4bbe788f..b128ee288 100644
--- a/web-docs/concepts/index.md
+++ b/web-docs/concepts/index.md
@@ -194,4 +194,4 @@ flagd is fully compatible with OpenTelemetry:
- flagd exposes metrics at `http://localhost:8014/metrics`
- flagd can export metrics and traces to an OpenTelemetry collector.
-See the [flagd OpenTelemetry](reference/opentelemetry.md) page for more information.
+See the [flagd OpenTelemetry](../reference/opentelemetry.md) page for more information.
diff --git a/web-docs/reference/configuration.md b/web-docs/reference/configuration.md
index f3a1f4377..35979debb 100644
--- a/web-docs/reference/configuration.md
+++ b/web-docs/reference/configuration.md
@@ -15,15 +15,10 @@ The config file expects the keys to have the exact naming as startup-flags flags
Sync providers are a core part of flagd; they are the abstraction that enables different sources for feature flag configurations.
flagd currently support the following sync providers:
-- [Configuration](./#configuration)
- - [Sync providers](#sync-providers)
- - [Kubernetes provider](#kubernetes-provider)
- - [Filepath provider](#filepath-provider)
- - [Remote provider](#remote-provider)
- - [GRPC provider](#grpc-provider)
- - [Sync provider configurations](#sync-provider-configurations)
- - [URI patterns](#uri-patterns)
- - [Source Configuration](#source-configuration)
+- [Kubernetes provider](#kubernetes-provider)
+- [Filepath provider](#filepath-provider)
+- [Remote provider](#remote-provider)
+- [GRPC provider](#grpc-provider)
### Kubernetes provider
From dc5afaf6b601ecabd92802abac8fa792002712b2 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 17:17:11 +1000
Subject: [PATCH 07/21] update pointers
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/configuration/flag_configuration_merging.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/configuration/flag_configuration_merging.md b/docs/configuration/flag_configuration_merging.md
index c6b584e28..28b843b57 100644
--- a/docs/configuration/flag_configuration_merging.md
+++ b/docs/configuration/flag_configuration_merging.md
@@ -1,3 +1,3 @@
# Flag Configuration Merging
-This content has moved. See [flag configuration merging](https://flagd.dev/nonk8s/flagmerging/)
\ No newline at end of file
+The content of this page has moved. See [flag configuration merging](https://flagd.dev/nonk8s/flagmerging/)
\ No newline at end of file
From fc9527d951700a1fe2ecc3dfd345fed8330d4124 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 17:19:59 +1000
Subject: [PATCH 08/21] revert change. Handled in different PR
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
.../flag_configuration_merging.md | 62 ++++++++++++++++++-
1 file changed, 61 insertions(+), 1 deletion(-)
diff --git a/docs/configuration/flag_configuration_merging.md b/docs/configuration/flag_configuration_merging.md
index 28b843b57..60a4ffb46 100644
--- a/docs/configuration/flag_configuration_merging.md
+++ b/docs/configuration/flag_configuration_merging.md
@@ -1,3 +1,63 @@
# Flag Configuration Merging
-The content of this page has moved. See [flag configuration merging](https://flagd.dev/nonk8s/flagmerging/)
\ No newline at end of file
+Flagd can be configured to read from multiple sources at once, when this is the case flagd will merge all flag configurations into a single
+merged state.
+For example:
+
+```mermaid
+flowchart LR
+ source-A -->|config-A| store -->|merge|source-A-config-A\nsource-B-config-B
+ source-B -->|config-B| store
+```
+
+In this example, `source-A` and `source-B` provide a single flag configuration, `config-A` and `config-B` respectively.
+The merge logic for this configuration is simple, both flag configurations are added to the `store`.
+In most scenarios, these flag sources will be supplying `n` number of configurations, using a unique flag key for each configuration.
+However, as multiple sources are being used, there is the opportunity for keys to be duplicated, intentionally or not, between flag sources.
+In these situations `flagd` uses a merge priority order to ensure that its behavior is consistent.
+
+Merge order is dictated by the order that `sync-providers` and `uris` are defined, with the latest defined source taking precedence over those defined before it, as an example:
+
+```sh
+./bin/flagd start --uri file:source-A.json --uri file:source-B.json --uri file:source-C.json
+```
+
+When `flagd` is started with the command defined above, `source-B` takes priority over `source-A`, whilst `source-C` takes priority over both `source-B` and `source-A`.
+Using the above example, if a flag key is duplicated across all 3 sources, then the configuration from `source-C` would be the only one stored in the merged state.
+
+```mermaid
+flowchart LR
+ source-A -->|config-A| store -->source-C-config-A
+ source-B -->|config-A| store
+ source-C -->|config-A| store
+```
+
+## State Resync Events
+
+Given the above example, the `source-A` and `source-B` 'versions' of flag configuration `config-A` have been discarded, so if a delete event in `source-C` results in the removal of `config-A`, there will no longer be any reference of`config-A` in flagd's store.
+As a result of this flagd will return `FLAG_NOT_FOUND` errors, and the OpenFeature SDK will always return the default value.
+
+To prevent flagd falling out of sync with its flag sources during delete events, resync events are used.
+When a delete event results in a flag configuration being removed from the merged state, the full set of configurations is requested from all flag sources, and the merged state is rebuilt.
+As a result, the value of `config-A` from `source-B` will be stored in the merged state, preventing flagd from returning `FLAG_NOT_FOUND` errors.
+
+```mermaid
+flowchart LR
+ source-A -->|config-A| store -->source-C-config-A
+ source-B -->|config-A| store
+ source-C -->|config-A| store
+ source-C -->|delete config-A|source-C-config-A
+ source-C-config-A --> resync-event
+```
+
+In the example above, a delete event results in a resync event being fired, as `source-C` has deleted its 'version' of `config-A`, this results in a new merge state being formed from the remaining configurations.
+
+```mermaid
+flowchart LR
+ source-A -->|config-A| store -->source-B-config-A
+ source-B -->|config-A| store
+ source-C -->store
+
+```
+
+Resync events may lead to further resync events if the returned flag configurations result in further delete events, however the state will eventually be resolved correctly.
\ No newline at end of file
From da92715563a525a3d28eb7584310ad660e00b70f Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 17:23:14 +1000
Subject: [PATCH 09/21] update
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/configuration/flagd.md | 19 ++-----------------
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/docs/configuration/flagd.md b/docs/configuration/flagd.md
index 97c4ae6a6..13d1fdf1b 100644
--- a/docs/configuration/flagd.md
+++ b/docs/configuration/flagd.md
@@ -1,18 +1,3 @@
-
-## flagd
-
-Flagd is a simple command line tool for fetching and presenting feature flags to services. It is designed to conform to Open Feature schema for flag definitions.
-
-### Options
-
-```
- --config string config file (default is $HOME/.agent.yaml)
- -x, --debug verbose logging
- -h, --help help for flagd
-```
-
-### SEE ALSO
-
-* [flagd start](flagd_start) - Start flagd
-* [flagd version](flagd_version) - Print the version number of FlagD
+# flagd
+[https://flagd.dev](https://flagd.dev) is the new home of flagd documentation.
\ No newline at end of file
From 15d922db55f958163c52697604648a3b58931b9d Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 17:46:16 +1000
Subject: [PATCH 10/21] update
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
mkdocs.yml | 4 +-
web-docs/concepts/index.md | 2 +-
web-docs/reference/caching.md | 32 +++
web-docs/reference/flag_syntax.md | 379 ++++++++++++++++++++++++++++++
4 files changed, 415 insertions(+), 2 deletions(-)
create mode 100644 web-docs/reference/caching.md
create mode 100644 web-docs/reference/flag_syntax.md
diff --git a/mkdocs.yml b/mkdocs.yml
index 6cc8d2535..c6e7da4c9 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -53,4 +53,6 @@ nav:
- 'Reference':
- 'Flagd Configuration': 'reference/configuration.md'
- 'Flagd Start': 'reference/flagd_start.md'
- - 'Flagd OpenTelemetry Support': 'reference/opentelemetry.md'
\ No newline at end of file
+ - 'Flagd OpenTelemetry Support': 'reference/opentelemetry.md'
+ - 'Flag Syntax': 'reference/flag_syntax.md'
+ - 'Flag Caching': 'reference/caching.md'
\ No newline at end of file
diff --git a/web-docs/concepts/index.md b/web-docs/concepts/index.md
index b128ee288..12b4d1211 100644
--- a/web-docs/concepts/index.md
+++ b/web-docs/concepts/index.md
@@ -185,7 +185,7 @@ The example above shows the `in` keyword being used, but flagd is also compatibl
- [starts_with](https://github.com/open-feature/flagd/blob/main/docs/configuration/string_comparison_evaluation.md#startswith-evaluation-configuration)
- [ends_with](https://github.com/open-feature/flagd/blob/main/docs/configuration/string_comparison_evaluation.md#endswith-evaluation-configuration)
-- [sem_ver comparisons](https://github.com/open-feature/flagd/blob/main/docs/configuration/sem_ver_evaluation.md)
+- [sem_ver comparisons](../reference/flag_syntax.md#semver-evaluation)
## flagd OpenTelemetry
diff --git a/web-docs/reference/caching.md b/web-docs/reference/caching.md
new file mode 100644
index 000000000..763bf09b8
--- /dev/null
+++ b/web-docs/reference/caching.md
@@ -0,0 +1,32 @@
+# Caching
+
+`flagd` has a caching strategy implementable by providers that support server-to-client streaming.
+
+## Cacheable flags
+
+`flagd` sets the `reason` of a flag evaluation as `STATIC` when no targeting rules are configured for the flag.
+A client can safely store the result of a static evaluation in its cache indefinitely (until the configuration of the flag changes, see [cache invalidation](#cache-invalidation)).
+
+Put simply in pseudocode:
+
+```pseudo
+if reason == "STATIC" {
+ isFlagCacheable = true
+}
+```
+
+## Cache invalidation
+
+`flagd` emits events to the server-to-client stream, among these is the `configuration_change` event.
+The structure of this event is as such:
+
+```json
+{
+ "type": "delete", // ENUM:["delete","write","update"]
+ "source": "/flag-configuration.json", // the source of the flag configuration
+ "flagKey": "foo"
+}
+```
+
+A client should invalidate the cache of any flag found in a `configuration_change` event to prevent stale data.
+If the connection drops all cache values must be cleared (any number of events may have been missed).
diff --git a/web-docs/reference/flag_syntax.md b/web-docs/reference/flag_syntax.md
new file mode 100644
index 000000000..cede801e8
--- /dev/null
+++ b/web-docs/reference/flag_syntax.md
@@ -0,0 +1,379 @@
+# Flag Syntax
+
+## Flags
+
+`flags` is a **required** property.
+The flags property is a top level property that contains a collection of individual flags and their corresponding flag configurations.
+
+```json
+{
+ "flags": {
+ ...
+ }
+}
+```
+
+## Flag configuration
+
+`flag key` is a **required** property.
+The flag key **must** uniquely identify a flag so that it can be used during flag evaluation.
+The flag key **should** convey the intent of the flag.
+
+```json
+{
+ "flags": {
+ "new-welcome-banner": {
+ ...
+ }
+ }
+}
+```
+
+## Flag properties
+
+A fully configured flag may look like this.
+
+```json
+{
+ "flags": {
+ "new-welcome-banner": {
+ "state": "ENABLED",
+ "variants": {
+ "true": true,
+ "false": false
+ },
+ "defaultVariant": "false",
+ "targeting": { "in": ["@example.com", { "var": "email" }] }
+ }
+ }
+}
+```
+
+See below for a detailed description of each property.
+
+### State
+
+`state` is a **required** property.
+Validate states are "ENABLED" or "DISABLED".
+When the state is set to "DISABLED", flagd will behave like the flag doesn't exist.
+
+Example:
+
+```json
+"state": "ENABLED"
+```
+
+### Variants
+
+`variants` is a **required** property.
+It is an object containing the possible variations supported by the flag.
+All the values of the object **must** be the same type (e.g. boolean, numbers, string, JSON).
+The type used as the variant value will correspond directly affects how the flag is accessed.
+For example, to use a flag configured with boolean values the `/schema.v1.Service/ResolveBoolean` path should be used.
+If another path such as `/schema.v1.Service/ResolveString` is called, a type mismatch occurred and an error is returned.
+
+Example:
+
+```json
+"variants": {
+ "red": "c05543",
+ "green": "2f5230",
+ "blue": "0d507b"
+}
+```
+
+Example:
+
+```json
+"variants": {
+ "on": true,
+ "off": false
+}
+```
+
+Example of an invalid configuration:
+
+```json
+"variants": {
+ "on": true,
+ "off": "false"
+}
+```
+
+### Default Variant
+
+`defaultVariant` is a **required** property.
+The value **must** match the name of one of the variants defined above.
+The default variant is always used unless a targeting rule explicitly overrides it.
+
+Example:
+
+```json
+"variants": {
+ "on": true,
+ "off": false
+},
+"defaultVariant": "off"
+```
+
+Example:
+
+```json
+"variants": {
+ "red": "c05543",
+ "green": "2f5230",
+ "blue": "0d507b"
+},
+"defaultVariant": "red"
+```
+
+Example of an invalid configuration:
+
+```json
+"variants": {
+ "red": "c05543",
+ "green": "2f5230",
+ "blue": "0d507b"
+},
+"defaultVariant": "purple"
+```
+
+### Targeting Rules
+
+`targeting` is an **optional** property.
+A targeting rule **must** be valid JSON.
+Flagd uses a modified version of [JSON Logic](https://jsonlogic.com/), as well as some custom pre-processing, to evaluate these rules.
+The output of the targeting rule **must** match the name of one of the variants defined above.
+If an invalid or null value is returned by the targeting rule, the `defaultVariant` value is used.
+If no targeting rules are defined, the response reason will always be `STATIC`, this allows for the flag values to be cached, this behavior is described [here](caching.md).
+
+#### Evaluation Context
+
+Evaluation context is included as part of the evaluation request.
+For example, when accessing flagd via HTTP, the POST body may look like this:
+
+```json
+{
+ "flagKey": "booleanFlagKey",
+ "context": {
+ "email": "noreply@example.com"
+ }
+}
+```
+
+The evaluation context can be accessed in targeting rules using the `var` operation followed the evaluation context property name.
+
+| Description | Example |
+| -------------------------------------------------------------- | --------------------------------------------- |
+| Retrieve property from the evaluation context | `{ "var": "email" }` |
+| Retrieve property from the evaluation context or use a default | `{ "var": ["email", "noreply@example.com"] }` |
+| Retrieve a nested property from the evaluation context | `{ "var": "user.email" }` |
+
+> For more information, see the `var` section in the [JSON Logic documentation](https://jsonlogic.com/operations.html#var).
+
+#### Conditions
+
+Conditions can be used to control the logical flow and grouping of targeting rules.
+
+| Conditional | Example |
+| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| If | Logic: `{"if" : [ true, "yes", "no" ]}`
Result: `"yes"`
Logic: `{"if" : [ false, "yes", "no" ]}`
Result: `"no"` |
+| If else | Logic: `{"if" : [ false, "yes", false, "no", "maybe" ]}`
Result: `"maybe"`
Logic: `{"if" : [ false, "yes", false, "no", false, "maybe", "who knows" ]}`
Result: `"who knows"` |
+| Or | Logic: `{"or" : [ true, false ]}`
Result: `true`
Logic: `{"or" : [ false, false ]}`
Result: `false` |
+| And | Logic: `{"and" : [ true, false ]}`
Result: `false`
Logic: `{"and" : [ true, true ]}`
Result: `true` |
+
+#### Operators
+
+Operators are used to take action on, or compare properties retrieved from the context.
+
+| Operator | Description | Context type | Example |
+| ---------------------- | -------------------------------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Equals | Attribute equals the specified value, with type coercion. | any | Logic: `{ "==" : [1, 1] }`
Result: `true`
Logic: `{ "==" : [1, "1"] }`
Result: `true` |
+| Strict equals | Attribute equals the specified value, with strict comparison. | any | Logic: `{ "===" : [1, 1] }`
Result: `true`
Logic: `{ "===" : [1, "1"] }`
Result: `false` |
+| Not equals | Attribute doesn't equal the specified value, with type coercion. | any | Logic: `{ "!=" : [1, 2] }`
Result: `true`
Logic: `{ "!=" : [1, "1"] }`
Result: `false` |
+| Strict not equal | Attribute doesn't equal the specified value, with strict comparison. | any | Logic: `{ "!==" : [1, 2] }`
Result: `true`
Logic: `{ "!==" : [1, "1"] }`
Result: `true` |
+| Exists | Attribute is defined | any | Logic: `{ "!!": [ "mike" ] }`
Result: `true`
Logic: `{ "!!": [ "" ] }`
Result: `false` |
+| Not exists | Attribute is not defined | any | Logic: `{"!": [ "mike" ] }`
Result: `false`
Logic: `{"!": [ "" ] }`
Result: `true` |
+| Greater than | Attribute is greater than the specified value | number | Logic: `{ ">" : [2, 1] }`
Result: `true`
Logic: `{ ">" : [1, 2] }`
Result: `false` |
+| Greater than or equals | Attribute is greater or equal to the specified value | number | Logic: `{ ">=" : [2, 1] }`
Result: `true`
Logic: `{ ">=" : [1, 1] }`
Result: `true` |
+| Less than | Attribute is less than the specified value | number | Logic: `{ "<" : [1, 2] }`
Result: `true`
Logic: `{ "<" : [2, 1] }`
Result: `false` |
+| Less than or equals | Attribute is less or equal to the specified value | number | Logic: `{ "<=" : [1, 1] }`
Result: `true`
Logic: `{ "<=" : [2, 1] }`
Result: `false` |
+| Between | Attribute between the specified values | number | Logic: `{ "<" : [1, 5, 10]}`
Result: `true`
Logic: `{ "<" : [1, 11, 10] }`
Result: `false` |
+| Between inclusive | Attribute between or equal to the specified values | number | Logic: `{"<=" : [1, 1, 10] }`
Result: `true`
Logic: `{"<=" : [1, 11, 10] }`
Result: `false` |
+| Contains | Contains string | string | Logic: `{ "in": ["Spring", "Springfield"] }`
Result: `true`
Logic: `{ "in":["Illinois", "Springfield"] }`
Result: `false` |
+| Not contains | Does not contain a string | string | Logic: `{ "!": { "in":["Spring", "Springfield"] } }`
Result: `false`
Logic: `{ "!": { "in":["Illinois", "Springfield"] } }`
Result: `true` |
+| In | Attribute is in an array of strings | string | Logic: `{ "in" : [ "Mike", ["Bob", "Mike"]] }`
Result: `true`
Logic: `{ "in":["Todd", ["Bob", "Mike"]] }`
Result: `false` |
+| Not it | Attribute is not in an array of strings | string | Logic: `{ "!": { "in" : [ "Mike", ["Bob", "Mike"]] } }`
Result: `false`
Logic: `{ "!": { "in":["Todd", ["Bob", "Mike"]] } }`
Result: `true` |
+
+#### Functions
+
+Functions can be used to create more advanced targeting rules.
+They are purpose built extensions to JSON logic in order to support popular feature flag use cases.
+
+| Function | Description | Example |
+| -------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `fractionalEvaluation` | Deterministic percentage-based rollout | Logic: `{ "fractionalEvaluation" : [ "email", [ "red" , 50], [ "green" , 50 ] ] }`
Result: Pseudo randomly `red` or `green` based on the evaluation context property `email`.
Additional documentation can be found [here](../../concepts#fractional-evaluation) |
+| `starts_with` | Attribute starts with the specified value | Logic: `{ "starts_with" : [ "192.168.0.1", "192.168"] }`
Result: `true`
Logic: `{ "starts_with" : [ "10.0.0.1", "192.168"] }`
Result: `false` |
+| `ends_with` | Attribute ends with the specified value | Logic: `{ "ends_with" : [ "noreply@example.com", "@example.com"] }`
Result: `true`
Logic: `{ ends_with" : [ "noreply@example.com", "@test.com"] }`
Result: `false` |
+| `sem_ver` | Attribute matches a semantic versioning condition | Logic: `{"sem_ver": ["1.1.2", ">=", "1.0.0"]}`
Result: `true`
Additional documentation can be found [here](#semver-evaluation) |
+
+## Shared evaluators
+
+`$evaluators` is an **optional** property.
+It's a collection of shared targeting configurations used to reduce the number of duplicated targeting rules.
+
+Example:
+
+```json
+{
+ "flags": {
+ "fibAlgo": {
+ "variants": {
+ "recursive": "recursive",
+ "memo": "memo",
+ "loop": "loop",
+ "binet": "binet"
+ },
+ "defaultVariant": "recursive",
+ "state": "ENABLED",
+ "targeting": {
+ "if": [
+ {
+ "$ref": "emailWithFaas"
+ },
+ "binet",
+ null
+ ]
+ }
+ },
+ "headerColor": {
+ "variants": {
+ "red": "#FF0000",
+ "blue": "#0000FF",
+ "green": "#00FF00",
+ "yellow": "#FFFF00"
+ },
+ "defaultVariant": "red",
+ "state": "ENABLED",
+ "targeting": {
+ "if": [
+ {
+ "$ref": "emailWithFaas"
+ },
+ {
+ "fractionalEvaluation": [
+ "email",
+ ["red", 25],
+ ["blue", 25],
+ ["green", 25],
+ ["yellow", 25]
+ ]
+ },
+ null
+ ]
+ }
+ }
+ },
+ "$evaluators": {
+ "emailWithFaas": {
+ "in": [
+ "@faas.com",
+ {
+ "var": ["email"]
+ }
+ ]
+ }
+ }
+}
+```
+
+## SemVer Evaluation
+
+OpenFeature allows clients to pass contextual information which can then be used during a flag evaluation. For example, a client could pass the email address of the user.
+
+In some scenarios, it is desirable to use that contextual information to segment the user population further and thus return dynamic values.
+
+### Technical Description
+
+The `sem_ver` evaluation checks if the given property matches a semantic versioning condition.
+It returns 'true', if the value of the given property meets the condition, 'false' if not.
+
+### Configuration
+
+The `sem_ver` evaluation can be added as part of a targeting definition.
+Note that the 'sem_ver' evaluation rule must contain exactly three items:
+
+1. Target property: this needs which both resolve to a semantic versioning string
+2. Operator: One of the following: `=`, `!=`, `>`, `<`, `>=`, `<=`, `~` (match minor version), `^` (match major version)
+3. Target value: this needs which both resolve to a semantic versioning string
+
+The `sem_ver` evaluation returns a boolean, indicating whether the condition has been met.
+
+```js
+{
+ "if": [
+ {
+ "sem_ver": [{"var": "version"}, ">=", "1.0.0"]
+ },
+ "red", null
+ ]
+}
+```
+
+### Example for 'sem_ver' Evaluation
+
+Flags defined as such:
+
+```json
+{
+ "flags": {
+ "headerColor": {
+ "variants": {
+ "red": "#FF0000",
+ "blue": "#0000FF",
+ "green": "#00FF00"
+ },
+ "defaultVariant": "blue",
+ "state": "ENABLED",
+ "targeting": {
+ "if": [
+ {
+ "sem_ver": [{"var": "version"}, ">=", "1.0.0"]
+ },
+ "red", "green"
+ ]
+ }
+ }
+ }
+}
+```
+
+will return variant `red`, if the value of the `version` is a semantic version that is greater than or equal to `1.0.0`.
+
+Command:
+
+```shell
+curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"headerColor","context":{"version": "1.0.1"}}' -H "Content-Type: application/json"
+```
+
+Result:
+
+```json
+{"value":"#00FF00","reason":"TARGETING_MATCH","variant":"red"}
+```
+
+Command:
+
+```shell
+curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"headerColor","context":{"version": "0.1.0"}}' -H "Content-Type: application/json"
+```
+
+Result:
+
+```shell
+{"value":"#0000FF","reason":"TARGETING_MATCH","variant":"green"}
+```
+
+## Examples
+
+Sample configurations can be found at .
\ No newline at end of file
From ecb177883ebaf6832ffbfab829f6ec7639ca03e5 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 18:46:00 +1000
Subject: [PATCH 11/21] make md lint happy
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/configuration/flag_configuration_merging.md | 2 +-
docs/configuration/flagd.md | 2 +-
docs/configuration/flagd_start.md | 4 ++--
web-docs/reference/flag_syntax.md | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/docs/configuration/flag_configuration_merging.md b/docs/configuration/flag_configuration_merging.md
index 60a4ffb46..c964c372a 100644
--- a/docs/configuration/flag_configuration_merging.md
+++ b/docs/configuration/flag_configuration_merging.md
@@ -60,4 +60,4 @@ flowchart LR
```
-Resync events may lead to further resync events if the returned flag configurations result in further delete events, however the state will eventually be resolved correctly.
\ No newline at end of file
+Resync events may lead to further resync events if the returned flag configurations result in further delete events, however the state will eventually be resolved correctly.
diff --git a/docs/configuration/flagd.md b/docs/configuration/flagd.md
index 13d1fdf1b..bcfa8990b 100644
--- a/docs/configuration/flagd.md
+++ b/docs/configuration/flagd.md
@@ -1,3 +1,3 @@
# flagd
-[https://flagd.dev](https://flagd.dev) is the new home of flagd documentation.
\ No newline at end of file
+[https://flagd.dev](https://flagd.dev) is the new home of flagd documentation.
diff --git a/docs/configuration/flagd_start.md b/docs/configuration/flagd_start.md
index 4aeadde19..f4c7daa11 100644
--- a/docs/configuration/flagd_start.md
+++ b/docs/configuration/flagd_start.md
@@ -1,3 +1,3 @@
-## flagd start
+# flagd start
-The content of this page has moved. See [flagd configuration](https://flagd.dev/reference/flagd_start)
\ No newline at end of file
+The content of this page has moved. See [flagd configuration](https://flagd.dev/reference/flagd_start)
diff --git a/web-docs/reference/flag_syntax.md b/web-docs/reference/flag_syntax.md
index cede801e8..fd28eeaa1 100644
--- a/web-docs/reference/flag_syntax.md
+++ b/web-docs/reference/flag_syntax.md
@@ -376,4 +376,4 @@ Result:
## Examples
-Sample configurations can be found at .
\ No newline at end of file
+Sample configurations can be found at .
From fb98149b034834e7f2d720fac2b784f64d5e5323 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 18:46:54 +1000
Subject: [PATCH 12/21] Revert "make md lint happy"
This reverts commit cd56c7e446f0b31ea31d860b60d9f8a6eb2fb5a8.
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/configuration/flag_configuration_merging.md | 2 +-
docs/configuration/flagd.md | 2 +-
docs/configuration/flagd_start.md | 4 ++--
web-docs/reference/flag_syntax.md | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/docs/configuration/flag_configuration_merging.md b/docs/configuration/flag_configuration_merging.md
index c964c372a..60a4ffb46 100644
--- a/docs/configuration/flag_configuration_merging.md
+++ b/docs/configuration/flag_configuration_merging.md
@@ -60,4 +60,4 @@ flowchart LR
```
-Resync events may lead to further resync events if the returned flag configurations result in further delete events, however the state will eventually be resolved correctly.
+Resync events may lead to further resync events if the returned flag configurations result in further delete events, however the state will eventually be resolved correctly.
\ No newline at end of file
diff --git a/docs/configuration/flagd.md b/docs/configuration/flagd.md
index bcfa8990b..13d1fdf1b 100644
--- a/docs/configuration/flagd.md
+++ b/docs/configuration/flagd.md
@@ -1,3 +1,3 @@
# flagd
-[https://flagd.dev](https://flagd.dev) is the new home of flagd documentation.
+[https://flagd.dev](https://flagd.dev) is the new home of flagd documentation.
\ No newline at end of file
diff --git a/docs/configuration/flagd_start.md b/docs/configuration/flagd_start.md
index f4c7daa11..4aeadde19 100644
--- a/docs/configuration/flagd_start.md
+++ b/docs/configuration/flagd_start.md
@@ -1,3 +1,3 @@
-# flagd start
+## flagd start
-The content of this page has moved. See [flagd configuration](https://flagd.dev/reference/flagd_start)
+The content of this page has moved. See [flagd configuration](https://flagd.dev/reference/flagd_start)
\ No newline at end of file
diff --git a/web-docs/reference/flag_syntax.md b/web-docs/reference/flag_syntax.md
index fd28eeaa1..cede801e8 100644
--- a/web-docs/reference/flag_syntax.md
+++ b/web-docs/reference/flag_syntax.md
@@ -376,4 +376,4 @@ Result:
## Examples
-Sample configurations can be found at .
+Sample configurations can be found at .
\ No newline at end of file
From c89a1b89876643b8f2ee61762081b07bc971de76 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 9 Aug 2023 18:48:16 +1000
Subject: [PATCH 13/21] make mdlint happy
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/configuration/flag_configuration_merging.md | 2 +-
docs/configuration/flagd.md | 2 +-
docs/configuration/flagd_start.md | 4 ++--
web-docs/reference/flag_syntax.md | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/docs/configuration/flag_configuration_merging.md b/docs/configuration/flag_configuration_merging.md
index 60a4ffb46..c964c372a 100644
--- a/docs/configuration/flag_configuration_merging.md
+++ b/docs/configuration/flag_configuration_merging.md
@@ -60,4 +60,4 @@ flowchart LR
```
-Resync events may lead to further resync events if the returned flag configurations result in further delete events, however the state will eventually be resolved correctly.
\ No newline at end of file
+Resync events may lead to further resync events if the returned flag configurations result in further delete events, however the state will eventually be resolved correctly.
diff --git a/docs/configuration/flagd.md b/docs/configuration/flagd.md
index 13d1fdf1b..bcfa8990b 100644
--- a/docs/configuration/flagd.md
+++ b/docs/configuration/flagd.md
@@ -1,3 +1,3 @@
# flagd
-[https://flagd.dev](https://flagd.dev) is the new home of flagd documentation.
\ No newline at end of file
+[https://flagd.dev](https://flagd.dev) is the new home of flagd documentation.
diff --git a/docs/configuration/flagd_start.md b/docs/configuration/flagd_start.md
index 4aeadde19..f4c7daa11 100644
--- a/docs/configuration/flagd_start.md
+++ b/docs/configuration/flagd_start.md
@@ -1,3 +1,3 @@
-## flagd start
+# flagd start
-The content of this page has moved. See [flagd configuration](https://flagd.dev/reference/flagd_start)
\ No newline at end of file
+The content of this page has moved. See [flagd configuration](https://flagd.dev/reference/flagd_start)
diff --git a/web-docs/reference/flag_syntax.md b/web-docs/reference/flag_syntax.md
index cede801e8..fd28eeaa1 100644
--- a/web-docs/reference/flag_syntax.md
+++ b/web-docs/reference/flag_syntax.md
@@ -376,4 +376,4 @@ Result:
## Examples
-Sample configurations can be found at .
\ No newline at end of file
+Sample configurations can be found at .
From a93c5cd294b42c5920a9290ecf9daea9c07636b8 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Thu, 7 Sep 2023 15:13:02 +1000
Subject: [PATCH 14/21] flagd_version
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/configuration/flagd_version.md | 25 ++-----------------------
mkdocs.yml | 5 +++--
web-docs/reference/flagd_version.md | 21 +++++++++++++++++++++
3 files changed, 26 insertions(+), 25 deletions(-)
create mode 100644 web-docs/reference/flagd_version.md
diff --git a/docs/configuration/flagd_version.md b/docs/configuration/flagd_version.md
index 305ecafb2..320d334f3 100644
--- a/docs/configuration/flagd_version.md
+++ b/docs/configuration/flagd_version.md
@@ -1,26 +1,5 @@
-## flagd version
-Print the version number of FlagD
-
-```
-flagd version [flags]
-```
-
-### Options
-
-```
- -h, --help help for version
-```
-
-### Options inherited from parent commands
-
-```
- --config string config file (default is $HOME/.agent.yaml)
- -x, --debug verbose logging
-```
-
-### SEE ALSO
-
-* [flagd](flagd) - Flagd is a simple command line tool for fetching and presenting feature flags to services. It is designed to conform to Open Feature schema for flag definitions.
+# flagd version
+The content of this page has moved. See [flagd version](https://flagd.dev/reference/flagd_version)
\ No newline at end of file
diff --git a/mkdocs.yml b/mkdocs.yml
index bae54b1fc..5b96cec0b 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -56,8 +56,9 @@ nav:
- 'Flagd OpenTelemetry Support': 'reference/opentelemetry.md'
- 'Flag Syntax': 'reference/flag_syntax.md'
- 'Flag Caching': 'reference/caching.md'
+ - 'Flagd Version': 'reference/flagd_version.md'
- 'Flagd Telemetry':
- 'Flagd OpenTelemetry Support': 'concepts/opentelemetry.md'
- 'Troubleshooting': 'troubleshooting.md'
-plugins:
- - social
+#plugins:
+# - social
diff --git a/web-docs/reference/flagd_version.md b/web-docs/reference/flagd_version.md
new file mode 100644
index 000000000..5cf279abf
--- /dev/null
+++ b/web-docs/reference/flagd_version.md
@@ -0,0 +1,21 @@
+
+## flagd version
+
+Print the version number of flagd
+
+```shell
+flagd version [flags]
+```
+
+### Options
+
+```shell
+-h, --help help for version
+```
+
+### Options inherited from parent commands
+
+```shell
+--config string config file (default is $HOME/.agent.yaml)
+-x, --debug verbose logging
+```
\ No newline at end of file
From 9a69fdc5ef073e2c358a25717c2c0d10876c9c05 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Thu, 7 Sep 2023 15:22:04 +1000
Subject: [PATCH 15/21] fractional evaluation page move
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/configuration/fractional_evaluation.md | 118 +---------------
mkdocs.yml | 1 +
web-docs/reference/fractional_evaluation.md | 144 ++++++++++++++++++++
3 files changed, 148 insertions(+), 115 deletions(-)
create mode 100644 web-docs/reference/fractional_evaluation.md
diff --git a/docs/configuration/fractional_evaluation.md b/docs/configuration/fractional_evaluation.md
index 83b8e22b6..a253159fb 100644
--- a/docs/configuration/fractional_evaluation.md
+++ b/docs/configuration/fractional_evaluation.md
@@ -1,117 +1,5 @@
-# Fractional Evaluation
-
-OpenFeature allows clients to pass contextual information which can then be used during a flag evaluation. For example, a client could pass the email address of the user.
-
-In some scenarios, it is desirable to use that contextual information to segment the user population further and thus return dynamic values.
-
-Look at the [headerColor](https://github.com/open-feature/flagd/blob/main/samples/example_flags.flagd.json#L88-#L133) flag. The `defaultVariant` is `red`, but it contains a [targeting rule](reusable_targeting_rules.md), meaning a fractional evaluation occurs for flag evaluation with a `context` object containing `email` and where that `email` value contains `@faas.com`.
-
-In this case, `25%` of the email addresses will receive `red`, `25%` will receive `blue`, and so on.
-
-Importantly, the evaluations are "sticky" meaning that the same `email` address will always belong to the same "bucket" and thus always receive the same color.
-
-## Fractional Evaluation: Technical Description
-
-The `fractionalEvaluation` operation is a custom JsonLogic operation which deterministically selects a variant based on
-the defined distribution of each variant (as a percentage).
-This works by hashing ([murmur3](https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp))
-the given data point, converting it into an int in the range [0, 99].
-Whichever range this int falls in decides which variant
-is selected.
-As hashing is deterministic we can be sure to get the same result every time for the same data point.
-
-## Fractional evaluation configuration
-
-The `fractionalEvaluation` can be added as part of a targeting definition.
-The value is an array and the first element is the name of the property to use from the evaluation context.
-This value should typically be something that remains consistent for the duration of a users session (e.g. email or session ID).
-The other elements in the array are nested arrays with the first element representing a variant and the second being the percentage that this option is selected.
-There is no limit to the number of elements but the configured percentages must add up to 100.
-
-```js
-// Factional evaluation property name used in a targeting rule
-"fractionalEvaluation": [
- // Evaluation context property used to determine the split
- "email",
- // Split definitions contain an array with a variant and percentage
- // Percentages must add up to 100
- [
- // Must match a variant defined in the flag configuration
- "red",
- // The probability this configuration is selected
- 50
- ],
- [
- // Must match a variant defined in the flag configuration
- "green",
- // The probability this configuration is selected
- 50
- ]
-]
-```
-
-## Example
+
-Flags defined as such:
-
-```json
-{
- "flags": {
- "headerColor": {
- "variants": {
- "red": "#FF0000",
- "blue": "#0000FF",
- "green": "#00FF00"
- },
- "defaultVariant": "red",
- "state": "ENABLED",
- "targeting": {
- "fractionalEvaluation": [
- "email",
- [
- "red",
- 50
- ],
- [
- "blue",
- 20
- ],
- [
- "green",
- 30
- ]
- ]
- }
- }
- }
-}
-```
-
-will return variant `red` 50% of the time, `blue` 20% of the time & `green` 30% of the time.
-
-Command:
-
-```shell
-curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"headerColor","context":{"email": "foo@bar.com"}}' -H "Content-Type: application/json"
-```
-
-Result:
-
-```shell
-{"value":"#0000FF","reason":"TARGETING_MATCH","variant":"blue"}
-```
-
-Command:
-
-```shell
-curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"headerColor","context":{"email": "foo@test.com"}}' -H "Content-Type: application/json"
-```
-
-Result:
-
-```json
-{"value":"#00FF00","reason":"TARGETING_MATCH","variant":"green"}
-```
+# Fractional Evaluation
-Notice that rerunning either curl command will always return the same variant and value.
-The only way to get a different value is to change the email or update the `fractionalEvaluation` configuration.
+The content of this page has moved. See [fractional evaluation](https://flagd.dev/reference/fractional_evaluation)
\ No newline at end of file
diff --git a/mkdocs.yml b/mkdocs.yml
index 5b96cec0b..4845c33c8 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -57,6 +57,7 @@ nav:
- 'Flag Syntax': 'reference/flag_syntax.md'
- 'Flag Caching': 'reference/caching.md'
- 'Flagd Version': 'reference/flagd_version.md'
+ - 'Fractional Evaluation': 'reference/fractional_evaluation.md'
- 'Flagd Telemetry':
- 'Flagd OpenTelemetry Support': 'concepts/opentelemetry.md'
- 'Troubleshooting': 'troubleshooting.md'
diff --git a/web-docs/reference/fractional_evaluation.md b/web-docs/reference/fractional_evaluation.md
new file mode 100644
index 000000000..6bccd7d8e
--- /dev/null
+++ b/web-docs/reference/fractional_evaluation.md
@@ -0,0 +1,144 @@
+# Fractional Evaluation
+
+OpenFeature allows clients to pass contextual information which can then be used during a flag evaluation. For example, a client could pass the email address of the user.
+
+In some scenarios, it is desirable to use that contextual information to segment the user population further and thus return dynamic values.
+
+See the [headerColor](https://github.com/open-feature/flagd/blob/main/samples/example_flags.flagd.json#L88-#L133) flag.
+The `defaultVariant` is `red`, but it contains a [targeting rule](reusable_targeting_rules.md), meaning a fractional evaluation occurs for flag evaluation with a `context` object containing `email` and where that `email` value contains `@faas.com`.
+
+In this case, `25%` of the evaluations will receive `red`, `25%` will receive `blue`, and so on.
+
+Assignment is deterministic (sticky) based on the expression supplied as the first parameter (`{ "var": "email" }`, in this case).
+The value retrieved by this expression is referred to as the "bucketing value".
+The bucketing value expression can be omitted, in which case a concatenation of the `targetingKey` and the `flagKey` will be used.
+
+## Fractional Evaluation: Technical Description
+
+The `fractional` operation is a custom JsonLogic operation which deterministically selects a variant based on
+the defined distribution of each variant (as a percentage).
+This works by hashing ([murmur3](https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp))
+the given data point, converting it into an int in the range [0, 99].
+Whichever range this int falls in decides which variant
+is selected.
+As hashing is deterministic we can be sure to get the same result every time for the same data point.
+
+## Fractional evaluation configuration
+
+The `fractional` operation can be added as part of a targeting definition.
+The value is an array and the first element is the name of the property to use from the evaluation context.
+This value should typically be something that remains consistent for the duration of a users session (e.g. email or session ID).
+The other elements in the array are nested arrays with the first element representing a variant and the second being the percentage that this option is selected.
+There is no limit to the number of elements but the configured percentages must add up to 100.
+
+```js
+// Factional evaluation property name used in a targeting rule
+"fractional": [
+ // Evaluation context property used to determine the split
+ { "var": "email" },
+ // Split definitions contain an array with a variant and percentage
+ // Percentages must add up to 100
+ [
+ // Must match a variant defined in the flag configuration
+ "red",
+ // The probability this configuration is selected
+ 50
+ ],
+ [
+ // Must match a variant defined in the flag configuration
+ "green",
+ // The probability this configuration is selected
+ 50
+ ]
+]
+```
+
+## Example
+
+Flags defined as such:
+
+```json
+{
+ "flags": {
+ "headerColor": {
+ "variants": {
+ "red": "#FF0000",
+ "blue": "#0000FF",
+ "green": "#00FF00"
+ },
+ "defaultVariant": "red",
+ "state": "ENABLED",
+ "targeting": {
+ "fractional": [
+ { "var": "email" },
+ [
+ "red",
+ 50
+ ],
+ [
+ "blue",
+ 20
+ ],
+ [
+ "green",
+ 30
+ ]
+ ]
+ }
+ }
+ }
+}
+```
+
+will return variant `red` 50% of the time, `blue` 20% of the time & `green` 30% of the time.
+
+Command:
+
+```shell
+curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"headerColor","context":{"email": "foo@bar.com"}}' -H "Content-Type: application/json"
+```
+
+Result:
+
+```shell
+{"value":"#0000FF","reason":"TARGETING_MATCH","variant":"blue"}
+```
+
+Command:
+
+```shell
+curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"headerColor","context":{"email": "foo@test.com"}}' -H "Content-Type: application/json"
+```
+
+Result:
+
+```json
+{"value":"#00FF00","reason":"TARGETING_MATCH","variant":"green"}
+```
+
+Notice that rerunning either curl command will always return the same variant and value.
+The only way to get a different value is to change the email or update the `fractional` configuration.
+
+### Migrating from legacy fractionalEvaluation
+
+If you are using a legacy fractional evaluation (`fractionalEvaluation`), it's recommended you migrate to `fractional`.
+The new `fractional` evaluator supports nested properties and JsonLogic expressions.
+To migrate, simply use a JsonLogic variable declaration for the bucketing property, instead of a string:
+
+old:
+
+```json
+"fractionalEvaluation": [
+ "email",
+ [ "red", 25 ], [ "blue", 25 ], [ "green", 25 ], [ "yellow", 25 ]
+]
+```
+
+new:
+
+```json
+"fractional": [
+ { "var": "email" },
+ [ "red", 25 ], [ "blue", 25 ], [ "green", 25 ], [ "yellow", 25 ]
+]
+```
\ No newline at end of file
From da22536f137c3168b322e18346fc4518391282f4 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Thu, 7 Sep 2023 15:27:04 +1000
Subject: [PATCH 16/21] reusable targeting rules
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
.../configuration/reusable_targeting_rules.md | 71 +---
mkdocs.yml | 1 +
.../reference/targeting_rules_specifiers.md | 316 ++++++++++++++++++
3 files changed, 320 insertions(+), 68 deletions(-)
create mode 100644 web-docs/reference/targeting_rules_specifiers.md
diff --git a/docs/configuration/reusable_targeting_rules.md b/docs/configuration/reusable_targeting_rules.md
index ae0746ff2..ec7bc5863 100644
--- a/docs/configuration/reusable_targeting_rules.md
+++ b/docs/configuration/reusable_targeting_rules.md
@@ -1,70 +1,5 @@
-# Reusable targeting rules
-
-At the same level as the `flags` key one can define an `$evaluators` object.
-Each object defined under `$evaluators` is
-a reusable targeting rule.
-In any targeting rule one can reference a defined reusable targeting rule, foo, like so:
-`"$ref": "foo"`
-
-## Example
+
-Flags/evaluators defined as such:
-
-```json
-{
- "flags": {
- "fibAlgo": {
- "variants": {
- "recursive": "recursive",
- "memo": "memo",
- "loop": "loop",
- "binet": "binet"
- },
- "defaultVariant": "recursive",
- "state": "ENABLED",
- "targeting": {
- "if": [
- {
- "$ref": "emailWithFaas"
- }, "binet", null
- ]
- }
- }
- },
- "$evaluators": {
- "emailWithFaas": {
- "in": ["@faas.com", {
- "var": ["email"]
- }]
- }
- }
-}
-```
-
-becomes (once the `$evaluators` have been substituted):
+# Reusable targeting rules
-```json
-{
- "flags": {
- "fibAlgo": {
- "variants": {
- "recursive": "recursive",
- "memo": "memo",
- "loop": "loop",
- "binet": "binet"
- },
- "defaultVariant": "recursive",
- "state": "ENABLED",
- "targeting": {
- "if": [
- {
- "in": ["@faas.com", {
- "var": ["email"]
- }]
- }, "binet", null
- ]
- }
- }
- }
-}
-```
+This content has moved. See [reusable targeting rules](https://flagd.dev/reference/targeting_rules_specifiers)
\ No newline at end of file
diff --git a/mkdocs.yml b/mkdocs.yml
index 4845c33c8..0c2451f58 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -58,6 +58,7 @@ nav:
- 'Flag Caching': 'reference/caching.md'
- 'Flagd Version': 'reference/flagd_version.md'
- 'Fractional Evaluation': 'reference/fractional_evaluation.md'
+ - 'Targeting Rules and Specifiers: 'reference/targeting_rules_specifiers.md'
- 'Flagd Telemetry':
- 'Flagd OpenTelemetry Support': 'concepts/opentelemetry.md'
- 'Troubleshooting': 'troubleshooting.md'
diff --git a/web-docs/reference/targeting_rules_specifiers.md b/web-docs/reference/targeting_rules_specifiers.md
new file mode 100644
index 000000000..0ec8fc7ad
--- /dev/null
+++ b/web-docs/reference/targeting_rules_specifiers.md
@@ -0,0 +1,316 @@
+# Reusable Targeting Rules and Specifiers
+
+## Reusable targeting rules
+
+At the same level as the `flags` key one can define an `$evaluators` object.
+Each object defined under `$evaluators` is
+a reusable targeting rule.
+In any targeting rule one can reference a defined reusable targeting rule, foo, like so:
+`"$ref": "foo"`
+
+## Example (using `in`)
+
+Flags/evaluators defined as such:
+
+```json
+{
+ "flags": {
+ "fibAlgo": {
+ "variants": {
+ "recursive": "recursive",
+ "memo": "memo",
+ "loop": "loop",
+ "binet": "binet"
+ },
+ "defaultVariant": "recursive",
+ "state": "ENABLED",
+ "targeting": {
+ "if": [
+ {
+ "$ref": "emailWithFaas"
+ }, "binet", null
+ ]
+ }
+ }
+ },
+ "$evaluators": {
+ "emailWithFaas": {
+ "in": ["@faas.com", {
+ "var": ["email"]
+ }]
+ }
+ }
+}
+```
+
+becomes (once the `$evaluators` have been substituted):
+
+```json
+{
+ "flags": {
+ "fibAlgo": {
+ "variants": {
+ "recursive": "recursive",
+ "memo": "memo",
+ "loop": "loop",
+ "binet": "binet"
+ },
+ "defaultVariant": "recursive",
+ "state": "ENABLED",
+ "targeting": {
+ "if": [
+ {
+ "in": ["@faas.com", {
+ "var": ["email"]
+ }]
+ }, "binet", null
+ ]
+ }
+ }
+ }
+}
+```
+
+## StartsWith/EndsWith Evaluation
+
+OpenFeature allows clients to pass contextual information which can then be used during a flag evaluation. For example, a client could pass the email address of the user.
+
+In some scenarios, it is desirable to use that contextual information to segment the user population further and thus return dynamic values.
+
+### StartsWith/EndsWith Evaluation: Technical Description
+
+The `starts_with`/`ends_with` operation is a custom JsonLogic operation which selects a variant based on
+whether the specified property starts/ends with a certain value.
+
+### StartsWith Evaluation Configuration
+
+The `starts_with` evaluation can be added as part of a targeting definition.
+The value is an array consisting of exactly two items, which both need to resolve to a string value.
+The first entry of the array represents the property to be considered, while the second entry represents
+the target value, i.e. the prefix that needs to be present in the value of the referenced property.
+This value should typically be something that remains consistent for the duration of a users session (e.g. email or session ID).
+The `starts_with` evaluation returns a boolean, indicating whether the condition has been met.
+
+```js
+// starts_with property name used in a targeting rule
+"starts_with": [
+ // Evaluation context property the be evaluated
+ {"var": "email"},
+ // prefix that has to be present in the value of the referenced property
+ "user@faas"
+]
+```
+
+### Example for 'starts_with' Evaluation
+
+Flags defined as such:
+
+```json
+{
+ "flags": {
+ "headerColor": {
+ "variants": {
+ "red": "#FF0000",
+ "blue": "#0000FF",
+ "green": "#00FF00"
+ },
+ "defaultVariant": "blue",
+ "state": "ENABLED",
+ "targeting": {
+ "if": [
+ {
+ "starts_with": [{"var": "email"}, "user@faas"]
+ },
+ "red", "green"
+ ]
+ }
+ }
+ }
+}
+```
+
+will return variant `red`, if the value of the `email` property starts with `user@faas`, and the variant `green` otherwise.
+
+Command:
+
+```shell
+curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"headerColor","context":{"email": "user@faas.com"}}' -H "Content-Type: application/json"
+```
+
+Result:
+
+```json
+{"value":"#00FF00","reason":"TARGETING_MATCH","variant":"red"}
+```
+
+Command:
+
+```shell
+curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"headerColor","context":{"email": "foo@bar.com"}}' -H "Content-Type: application/json"
+```
+
+Result:
+
+```shell
+{"value":"#0000FF","reason":"TARGETING_MATCH","variant":"green"}
+```
+
+### EndsWith Evaluation Configuration
+
+The `ends_with` evaluation can be added as part of a targeting definition.
+The value is an array consisting of exactly two items, which both need to resolve to a string value.
+The first entry of the array represents the property to be considered, while the second entry represents
+the target value, i.e. the suffix that needs to be present in the value of the referenced property.
+This value should typically be something that remains consistent for the duration of a users session (e.g. email or session ID).
+The `ends_with` evaluation returns a boolean, indicating whether the condition has been met.
+
+```js
+// starts_with property name used in a targeting rule
+"ends_with": [
+ // Evaluation context property the be evaluated
+ {"var": "email"},
+ // suffix that has to be present in the value of the referenced property
+ "faas.com"
+]
+```
+
+### Example for 'ends_with' Evaluation
+
+Flags defined as such:
+
+```json
+{
+ "flags": {
+ "headerColor": {
+ "variants": {
+ "red": "#FF0000",
+ "blue": "#0000FF",
+ "green": "#00FF00"
+ },
+ "defaultVariant": "blue",
+ "state": "ENABLED",
+ "targeting": {
+ "if": [
+ {
+ "ends_with": [{"var": "email"}, "faas.com"]
+ },
+ "red", "green"
+ ]
+ }
+ }
+ }
+}
+```
+
+will return variant `red`, if the value of the `email` property ends with `faas.com`, and the variant `green` otherwise.
+
+Command:
+
+```shell
+curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"headerColor","context":{"email": "user@faas.com"}}' -H "Content-Type: application/json"
+```
+
+Result:
+
+```json
+{"value":"#00FF00","reason":"TARGETING_MATCH","variant":"red"}
+```
+
+Command:
+
+```shell
+curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"headerColor","context":{"email": "foo@bar.com"}}' -H "Content-Type: application/json"
+```
+
+Result:
+
+```shell
+{"value":"#0000FF","reason":"TARGETING_MATCH","variant":"green"}
+```
+
+## SemVer Evaluation
+
+OpenFeature allows clients to pass contextual information which can then be used during a flag evaluation. For example, a client could pass the email address of the user.
+
+In some scenarios, it is desirable to use that contextual information to segment the user population further and thus return dynamic values.
+
+### SemVer Evaluation: Technical Description
+
+The `sem_ver` evaluation checks if the given property matches a semantic versioning condition.
+It returns 'true', if the value of the given property meets the condition, 'false' if not.
+
+### SemVer Evaluation Configuration
+
+The `sem_ver` evaluation can be added as part of a targeting definition.
+Note that the 'sem_ver' evaluation rule must contain exactly three items:
+
+1. Target property: this needs which both resolve to a semantic versioning string
+1. Operator: One of the following: `=`, `!=`, `>`, `<`, `>=`, `<=`, `~` (match minor version), `^` (match major version)
+1. Target value: this needs which both resolve to a semantic versioning string
+
+The `sem_ver` evaluation returns a boolean, indicating whether the condition has been met.
+
+```js
+{
+ "if": [
+ {
+ "sem_ver": [{"var": "version"}, ">=", "1.0.0"]
+ },
+ "red", null
+ ]
+}
+```
+
+### Example for 'sem_ver' Evaluation
+
+Flags defined as such:
+
+```json
+{
+ "flags": {
+ "headerColor": {
+ "variants": {
+ "red": "#FF0000",
+ "blue": "#0000FF",
+ "green": "#00FF00"
+ },
+ "defaultVariant": "blue",
+ "state": "ENABLED",
+ "targeting": {
+ "if": [
+ {
+ "sem_ver": [{"var": "version"}, ">=", "1.0.0"]
+ },
+ "red", "green"
+ ]
+ }
+ }
+ }
+}
+```
+
+will return variant `red`, if the value of the `version` is a semantic version that is greater than or equal to `1.0.0`.
+
+Command:
+
+```shell
+curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"headerColor","context":{"version": "1.0.1"}}' -H "Content-Type: application/json"
+```
+
+Result:
+
+```json
+{"value":"#00FF00","reason":"TARGETING_MATCH","variant":"red"}
+```
+
+Command:
+
+```shell
+curl -X POST "localhost:8013/schema.v1.Service/ResolveString" -d '{"flagKey":"headerColor","context":{"version": "0.1.0"}}' -H "Content-Type: application/json"
+```
+
+Result:
+
+```shell
+{"value":"#0000FF","reason":"TARGETING_MATCH","variant":"green"}
+```
From b9881a37b1e368e3f2239a33590d4d11cb6a0571 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Thu, 7 Sep 2023 15:32:47 +1000
Subject: [PATCH 17/21] add contributing page
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
CONTRIBUTING.md | 112 ++-------------------------------------
mkdocs.yml | 1 +
web-docs/contributing.md | 111 ++++++++++++++++++++++++++++++++++++++
3 files changed, 115 insertions(+), 109 deletions(-)
create mode 100644 web-docs/contributing.md
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 60c546762..f2dec6ac1 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,111 +1,5 @@
-# Welcome
-
-There are a few things to consider before contributing to flagd.
-
-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 unit tests.
-These can be validated with `make test` or the automated github workflow will run them on PR creation.
-
-This project uses a go workspace, to setup the project run
-
-```shell
-make workspace-init
-```
-
-The go version in the `go.work` is the currently supported version of go.
-
-The project uses remote buf packages, changing the remote generation source will require a one-time registry configuration:
-
-```shell
-export GOPRIVATE=buf.build/gen/go
-```
-
-## DCO Sign-Off
-
-A DCO (Developer Certificate of Origin) sign-off is a line placed at the end of
-a commit message containing a contributor's "signature." In adding this, the
-contributor certifies that they have the right to contribute the material in
-question.
-
-Here are the steps to sign your work:
-
-1. Verify the contribution in your commit complies with the
- [terms of the DCO](https://developercertificate.org/).
-
-1. Add a line like the following to your commit message:
-
- ```shell
- Signed-off-by: Joe Smith
- ```
-
- You MUST use your legal name -- handles or other pseudonyms are not
- permitted.
-
- While you could manually add DCO sign-off to every commit, there is an easier
- way:
-
- 1. Configure your git client appropriately. This is one-time setup.
-
- ```shell
- git config user.name
- git config user.email
- ```
+
- If you work on multiple projects that require a DCO sign-off, you can
- configure your git client to use these settings globally instead of only
- for Brigade:
-
- ```shell
- git config --global user.name
- git config --global user.email
- ```
-
- 1. Use the `--signoff` or `-s` (lowercase) flag when making each commit.
- For example:
-
- ```shell
- git commit --message "" --signoff
- ```
-
- If you ever make a commit and forget to use the `--signoff` flag, you
- can amend your commit with this information before pushing:
-
- ```shell
- git commit --amend --signoff
- ```
-
- 1. You can verify the above worked as expected using `git log`. Your latest
- commit should look similar to this one:
-
- ```shell
- Author: Joe Smith
- Date: Thu Feb 2 11:41:15 2018 -0800
-
- Update README
-
- Signed-off-by: Joe Smith
- ```
-
- Notice the `Author` and `Signed-off-by` lines match. If they do not, the
- PR will be rejected by the automated DCO check.
-
-## Conventional PR Titles
-
-When raising PRs, please format according to [conventional commit standards](https://www.conventionalcommits.org/en/v1.0.0/#summary)
-
-For example: `docs: some PR title here...`
-
-Thanks!
-Issues and pull requests following these guidelines are welcome.
-
-## Markdown Lint and Markdown Lint Fix
-
-PRs are expected to conform to markdown lint rules.
-
-Therefore, run `make markdownlint-fix` to auto-fix _most_ issues.
-Then commit the results.
+# Welcome
-For those issues that cannot be auto-fixed, run `make markdownlint`
-then manually fix whatever it warns about.
+This content has moved. See [contributing to flagd](https://flagd.dev/contributing)
\ No newline at end of file
diff --git a/mkdocs.yml b/mkdocs.yml
index 0c2451f58..58bfb7723 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -62,5 +62,6 @@ nav:
- 'Flagd Telemetry':
- 'Flagd OpenTelemetry Support': 'concepts/opentelemetry.md'
- 'Troubleshooting': 'troubleshooting.md'
+ - 'Contributing': 'contributing.md'
#plugins:
# - social
diff --git a/web-docs/contributing.md b/web-docs/contributing.md
new file mode 100644
index 000000000..60c546762
--- /dev/null
+++ b/web-docs/contributing.md
@@ -0,0 +1,111 @@
+# Welcome
+
+There are a few things to consider before contributing to flagd.
+
+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 unit tests.
+These can be validated with `make test` or the automated github workflow will run them on PR creation.
+
+This project uses a go workspace, to setup the project run
+
+```shell
+make workspace-init
+```
+
+The go version in the `go.work` is the currently supported version of go.
+
+The project uses remote buf packages, changing the remote generation source will require a one-time registry configuration:
+
+```shell
+export GOPRIVATE=buf.build/gen/go
+```
+
+## DCO Sign-Off
+
+A DCO (Developer Certificate of Origin) sign-off is a line placed at the end of
+a commit message containing a contributor's "signature." In adding this, the
+contributor certifies that they have the right to contribute the material in
+question.
+
+Here are the steps to sign your work:
+
+1. Verify the contribution in your commit complies with the
+ [terms of the DCO](https://developercertificate.org/).
+
+1. Add a line like the following to your commit message:
+
+ ```shell
+ Signed-off-by: Joe Smith
+ ```
+
+ You MUST use your legal name -- handles or other pseudonyms are not
+ permitted.
+
+ While you could manually add DCO sign-off to every commit, there is an easier
+ way:
+
+ 1. Configure your git client appropriately. This is one-time setup.
+
+ ```shell
+ git config user.name
+ git config user.email
+ ```
+
+ If you work on multiple projects that require a DCO sign-off, you can
+ configure your git client to use these settings globally instead of only
+ for Brigade:
+
+ ```shell
+ git config --global user.name
+ git config --global user.email
+ ```
+
+ 1. Use the `--signoff` or `-s` (lowercase) flag when making each commit.
+ For example:
+
+ ```shell
+ git commit --message "" --signoff
+ ```
+
+ If you ever make a commit and forget to use the `--signoff` flag, you
+ can amend your commit with this information before pushing:
+
+ ```shell
+ git commit --amend --signoff
+ ```
+
+ 1. You can verify the above worked as expected using `git log`. Your latest
+ commit should look similar to this one:
+
+ ```shell
+ Author: Joe Smith
+ Date: Thu Feb 2 11:41:15 2018 -0800
+
+ Update README
+
+ Signed-off-by: Joe Smith
+ ```
+
+ Notice the `Author` and `Signed-off-by` lines match. If they do not, the
+ PR will be rejected by the automated DCO check.
+
+## Conventional PR Titles
+
+When raising PRs, please format according to [conventional commit standards](https://www.conventionalcommits.org/en/v1.0.0/#summary)
+
+For example: `docs: some PR title here...`
+
+Thanks!
+Issues and pull requests following these guidelines are welcome.
+
+## Markdown Lint and Markdown Lint Fix
+
+PRs are expected to conform to markdown lint rules.
+
+Therefore, run `make markdownlint-fix` to auto-fix _most_ issues.
+Then commit the results.
+
+For those issues that cannot be auto-fixed, run `make markdownlint`
+then manually fix whatever it warns about.
From 53f032ddc065f8c3a3445f99c9bfd8abb51a9764 Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Thu, 7 Sep 2023 15:45:45 +1000
Subject: [PATCH 18/21] move flag configuration docs
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/configuration/flag_configuration.md | 308 +----------------------
web-docs/reference/flag_configuration.md | 290 +++++++++++++++++++++
2 files changed, 293 insertions(+), 305 deletions(-)
create mode 100644 web-docs/reference/flag_configuration.md
diff --git a/docs/configuration/flag_configuration.md b/docs/configuration/flag_configuration.md
index c30867bea..04d992fa8 100644
--- a/docs/configuration/flag_configuration.md
+++ b/docs/configuration/flag_configuration.md
@@ -1,307 +1,5 @@
-# Flag Configuration
-
-- [Flag Configuration](#flag-configuration)
- - [Flags](#flags)
- - [Flag configuration](#flag-configuration-1)
- - [Flag properties](#flag-properties)
- - [State](#state)
- - [Variants](#variants)
- - [Default Variant](#default-variant)
- - [Targeting Rules](#targeting-rules)
- - [Evaluation Context](#evaluation-context)
- - [Conditions](#conditions)
- - [Operators](#operators)
- - [Functions](#functions)
- - [Shared evaluators](#shared-evaluators)
- - [Examples](#examples)
-
-## Flags
-
-`flags` is a **required** property.
-The flags property is a top level property that contains a collection of individual flags and their corresponding flag configurations.
-
-```json
-{
- "flags": {
- ...
- }
-}
-```
-
-## Flag configuration
-
-`flag key` is a **required** property.
-The flag key **must** uniquely identify a flag so that it can be used during flag evaluation.
-The flag key **should** convey the intent of the flag.
-
-```json
-{
- "flags": {
- "new-welcome-banner": {
- ...
- }
- }
-}
-```
-
-## Flag properties
-
-A fully configured flag may look like this.
-
-```json
-{
- "flags": {
- "new-welcome-banner": {
- "state": "ENABLED",
- "variants": {
- "true": true,
- "false": false
- },
- "defaultVariant": "false",
- "targeting": { "in": ["@example.com", { "var": "email" }] }
- }
- }
-}
-```
-
-See below for a detailed description of each property.
-
-### State
-
-`state` is a **required** property.
-Validate states are "ENABLED" or "DISABLED".
-When the state is set to "DISABLED", flagd will behave like the flag doesn't exist.
-
-Example:
-
-```json
-"state": "ENABLED"
-```
-
-### Variants
-
-`variants` is a **required** property.
-It is an object containing the possible variations supported by the flag.
-All the values of the object **must** be the same type (e.g. boolean, numbers, string, JSON).
-The type used as the variant value will correspond directly affects how the flag is accessed.
-For example, to use a flag configured with boolean values the `/schema.v1.Service/ResolveBoolean` path should be used.
-If another path such as `/schema.v1.Service/ResolveString` is called, a type mismatch occurred and an error is returned.
-
-Example:
-
-```json
-"variants": {
- "red": "c05543",
- "green": "2f5230",
- "blue": "0d507b"
-}
-```
-
-Example:
-
-```json
-"variants": {
- "on": true,
- "off": false
-}
-```
-
-Example of an invalid configuration:
-
-```json
-"variants": {
- "on": true,
- "off": "false"
-}
-```
-
-### Default Variant
-
-`defaultVariant` is a **required** property.
-The value **must** match the name of one of the variants defined above.
-The default variant is always used unless a targeting rule explicitly overrides it.
-
-Example:
+
-```json
-"variants": {
- "on": true,
- "off": false
-},
-"defaultVariant": "off"
-```
-
-Example:
-
-```json
-"variants": {
- "red": "c05543",
- "green": "2f5230",
- "blue": "0d507b"
-},
-"defaultVariant": "red"
-```
-
-Example of an invalid configuration:
-
-```json
-"variants": {
- "red": "c05543",
- "green": "2f5230",
- "blue": "0d507b"
-},
-"defaultVariant": "purple"
-```
-
-### Targeting Rules
-
-`targeting` is an **optional** property.
-A targeting rule **must** be valid JSON.
-Flagd uses a modified version of [JSON Logic](https://jsonlogic.com/), as well as some custom pre-processing, to evaluate these rules.
-The output of the targeting rule **must** match the name of one of the variants defined above.
-If an invalid or null value is returned by the targeting rule, the `defaultVariant` value is used.
-If no targeting rules are defined, the response reason will always be `STATIC`, this allows for the flag values to be cached, this behavior is described [here](../other_resources/caching.md).
-
-#### Evaluation Context
-
-Evaluation context is included as part of the evaluation request.
-For example, when accessing flagd via HTTP, the POST body may look like this:
-
-```json
-{
- "flagKey": "booleanFlagKey",
- "context": {
- "email": "noreply@example.com"
- }
-}
-```
-
-The evaluation context can be accessed in targeting rules using the `var` operation followed the evaluation context property name.
-
-| Description | Example |
-| -------------------------------------------------------------- | --------------------------------------------- |
-| Retrieve property from the evaluation context | `{ "var": "email" }` |
-| Retrieve property from the evaluation context or use a default | `{ "var": ["email", "noreply@example.com"] }` |
-| Retrieve a nested property from the evaluation context | `{ "var": "user.email" }` |
-
-> For more information, see the `var` section in the [JSON Logic documentation](https://jsonlogic.com/operations.html#var).
-
-#### Conditions
-
-Conditions can be used to control the logical flow and grouping of targeting rules.
-
-| Conditional | Example |
-| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| If | Logic: `{"if" : [ true, "yes", "no" ]}`
Result: `"yes"`
Logic: `{"if" : [ false, "yes", "no" ]}`
Result: `"no"` |
-| If else | Logic: `{"if" : [ false, "yes", false, "no", "maybe" ]}`
Result: `"maybe"`
Logic: `{"if" : [ false, "yes", false, "no", false, "maybe", "who knows" ]}`
Result: `"who knows"` |
-| Or | Logic: `{"or" : [ true, false ]}`
Result: `true`
Logic: `{"or" : [ false, false ]}`
Result: `false` |
-| And | Logic: `{"and" : [ true, false ]}`
Result: `false`
Logic: `{"and" : [ true, true ]}`
Result: `true` |
-
-#### Operators
-
-Operators are used to take action on, or compare properties retrieved from the context.
-
-| Operator | Description | Context type | Example |
-| ---------------------- | -------------------------------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Equals | Attribute equals the specified value, with type coercion. | any | Logic: `{ "==" : [1, 1] }`
Result: `true`
Logic: `{ "==" : [1, "1"] }`
Result: `true` |
-| Strict equals | Attribute equals the specified value, with strict comparison. | any | Logic: `{ "===" : [1, 1] }`
Result: `true`
Logic: `{ "===" : [1, "1"] }`
Result: `false` |
-| Not equals | Attribute doesn't equal the specified value, with type coercion. | any | Logic: `{ "!=" : [1, 2] }`
Result: `true`
Logic: `{ "!=" : [1, "1"] }`
Result: `false` |
-| Strict not equal | Attribute doesn't equal the specified value, with strict comparison. | any | Logic: `{ "!==" : [1, 2] }`
Result: `true`
Logic: `{ "!==" : [1, "1"] }`
Result: `true` |
-| Exists | Attribute is defined | any | Logic: `{ "!!": [ "mike" ] }`
Result: `true`
Logic: `{ "!!": [ "" ] }`
Result: `false` |
-| Not exists | Attribute is not defined | any | Logic: `{"!": [ "mike" ] }`
Result: `false`
Logic: `{"!": [ "" ] }`
Result: `true` |
-| Greater than | Attribute is greater than the specified value | number | Logic: `{ ">" : [2, 1] }`
Result: `true`
Logic: `{ ">" : [1, 2] }`
Result: `false` |
-| Greater than or equals | Attribute is greater or equal to the specified value | number | Logic: `{ ">=" : [2, 1] }`
Result: `true`
Logic: `{ ">=" : [1, 1] }`
Result: `true` |
-| Less than | Attribute is less than the specified value | number | Logic: `{ "<" : [1, 2] }`
Result: `true`
Logic: `{ "<" : [2, 1] }`
Result: `false` |
-| Less than or equals | Attribute is less or equal to the specified value | number | Logic: `{ "<=" : [1, 1] }`
Result: `true`
Logic: `{ "<=" : [2, 1] }`
Result: `false` |
-| Between | Attribute between the specified values | number | Logic: `{ "<" : [1, 5, 10]}`
Result: `true`
Logic: `{ "<" : [1, 11, 10] }`
Result: `false` |
-| Between inclusive | Attribute between or equal to the specified values | number | Logic: `{"<=" : [1, 1, 10] }`
Result: `true`
Logic: `{"<=" : [1, 11, 10] }`
Result: `false` |
-| Contains | Contains string | string | Logic: `{ "in": ["Spring", "Springfield"] }`
Result: `true`
Logic: `{ "in":["Illinois", "Springfield"] }`
Result: `false` |
-| Not contains | Does not contain a string | string | Logic: `{ "!": { "in":["Spring", "Springfield"] } }`
Result: `false`
Logic: `{ "!": { "in":["Illinois", "Springfield"] } }`
Result: `true` |
-| In | Attribute is in an array of strings | string | Logic: `{ "in" : [ "Mike", ["Bob", "Mike"]] }`
Result: `true`
Logic: `{ "in":["Todd", ["Bob", "Mike"]] }`
Result: `false` |
-| Not it | Attribute is not in an array of strings | string | Logic: `{ "!": { "in" : [ "Mike", ["Bob", "Mike"]] } }`
Result: `false`
Logic: `{ "!": { "in":["Todd", ["Bob", "Mike"]] } }`
Result: `true` |
-
-#### Functions
-
-Functions can be used to create more advanced targeting rules.
-They are purpose built extensions to JSON logic in order to support popular feature flag use cases.
-
-| Function | Description | Example |
-| -------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `fractionalEvaluation` | Deterministic percentage-based rollout | Logic: `{ "fractionalEvaluation" : [ "email", [ "red" , 50], [ "green" , 50 ] ] }`
Result: Pseudo randomly `red` or `green` based on the evaluation context property `email`.
Additional documentation can be found [here](./fractional_evaluation.md) |
-| `starts_with` | Attribute starts with the specified value | Logic: `{ "starts_with" : [ "192.168.0.1", "192.168"] }`
Result: `true`
Logic: `{ "starts_with" : [ "10.0.0.1", "192.168"] }`
Result: `false` |
-| `ends_with` | Attribute ends with the specified value | Logic: `{ "ends_with" : [ "noreply@example.com", "@example.com"] }`
Result: `true`
Logic: `{ ends_with" : [ "noreply@example.com", "@test.com"] }`
Result: `false` |
-| `sem_ver` | Attribute matches a semantic versioning condition | Logic: `{"sem_ver": ["1.1.2", ">=", "1.0.0"]}`
Result: `true`
Additional documentation can be found [here](./sem_ver_evaluation.md) |
-
-## Shared evaluators
-
-`$evaluators` is an **optional** property.
-It's a collection of shared targeting configurations used to reduce the number of duplicated targeting rules.
-
-Example:
-
-```json
-{
- "flags": {
- "fibAlgo": {
- "variants": {
- "recursive": "recursive",
- "memo": "memo",
- "loop": "loop",
- "binet": "binet"
- },
- "defaultVariant": "recursive",
- "state": "ENABLED",
- "targeting": {
- "if": [
- {
- "$ref": "emailWithFaas"
- },
- "binet",
- null
- ]
- }
- },
- "headerColor": {
- "variants": {
- "red": "#FF0000",
- "blue": "#0000FF",
- "green": "#00FF00",
- "yellow": "#FFFF00"
- },
- "defaultVariant": "red",
- "state": "ENABLED",
- "targeting": {
- "if": [
- {
- "$ref": "emailWithFaas"
- },
- {
- "fractionalEvaluation": [
- "email",
- ["red", 25],
- ["blue", 25],
- ["green", 25],
- ["yellow", 25]
- ]
- },
- null
- ]
- }
- }
- },
- "$evaluators": {
- "emailWithFaas": {
- "in": [
- "@faas.com",
- {
- "var": ["email"]
- }
- ]
- }
- }
-}
-```
-
-## Examples
+# Flag Configuration
-Sample configurations can be found at .
+This content has moved. See [flag configuration](https://flagd.dev/reference/flag_configuration)
diff --git a/web-docs/reference/flag_configuration.md b/web-docs/reference/flag_configuration.md
new file mode 100644
index 000000000..24c434a9a
--- /dev/null
+++ b/web-docs/reference/flag_configuration.md
@@ -0,0 +1,290 @@
+## Flags
+
+`flags` is a **required** property.
+The flags property is a top level property that contains a collection of individual flags and their corresponding flag configurations.
+
+```json
+{
+ "flags": {
+ ...
+ }
+}
+```
+
+## Flag configuration
+
+`flag key` is a **required** property.
+The flag key **must** uniquely identify a flag so that it can be used during flag evaluation.
+The flag key **should** convey the intent of the flag.
+
+```json
+{
+ "flags": {
+ "new-welcome-banner": {
+ ...
+ }
+ }
+}
+```
+
+## Flag properties
+
+A fully configured flag may look like this.
+
+```json
+{
+ "flags": {
+ "new-welcome-banner": {
+ "state": "ENABLED",
+ "variants": {
+ "true": true,
+ "false": false
+ },
+ "defaultVariant": "false",
+ "targeting": { "in": ["@example.com", { "var": "email" }] }
+ }
+ }
+}
+```
+
+See below for a detailed description of each property.
+
+### State
+
+`state` is a **required** property.
+Validate states are "ENABLED" or "DISABLED".
+When the state is set to "DISABLED", flagd will behave like the flag doesn't exist.
+
+Example:
+
+```json
+"state": "ENABLED"
+```
+
+### Variants
+
+`variants` is a **required** property.
+It is an object containing the possible variations supported by the flag.
+All the values of the object **must** be the same type (e.g. boolean, numbers, string, JSON).
+The type used as the variant value will correspond directly affects how the flag is accessed.
+For example, to use a flag configured with boolean values the `/schema.v1.Service/ResolveBoolean` path should be used.
+If another path such as `/schema.v1.Service/ResolveString` is called, a type mismatch occurred and an error is returned.
+
+Example:
+
+```json
+"variants": {
+ "red": "c05543",
+ "green": "2f5230",
+ "blue": "0d507b"
+}
+```
+
+Example:
+
+```json
+"variants": {
+ "on": true,
+ "off": false
+}
+```
+
+Example of an invalid configuration:
+
+```json
+"variants": {
+ "on": true,
+ "off": "false"
+}
+```
+
+### Default Variant
+
+`defaultVariant` is a **required** property.
+The value **must** match the name of one of the variants defined above.
+The default variant is always used unless a targeting rule explicitly overrides it.
+
+Example:
+
+```json
+"variants": {
+ "on": true,
+ "off": false
+},
+"defaultVariant": "off"
+```
+
+Example:
+
+```json
+"variants": {
+ "red": "c05543",
+ "green": "2f5230",
+ "blue": "0d507b"
+},
+"defaultVariant": "red"
+```
+
+Example of an invalid configuration:
+
+```json
+"variants": {
+ "red": "c05543",
+ "green": "2f5230",
+ "blue": "0d507b"
+},
+"defaultVariant": "purple"
+```
+
+### Targeting Rules
+
+`targeting` is an **optional** property.
+A targeting rule **must** be valid JSON.
+Flagd uses a modified version of [JSON Logic](https://jsonlogic.com/), as well as some custom pre-processing, to evaluate these rules.
+The output of the targeting rule **must** match the name of one of the variants defined above.
+If an invalid or null value is returned by the targeting rule, the `defaultVariant` value is used.
+If no targeting rules are defined, the response reason will always be `STATIC`, this allows for the flag values to be cached, this behavior is described [here](../other_resources/caching.md).
+
+#### Evaluation Context
+
+Evaluation context is included as part of the evaluation request.
+For example, when accessing flagd via HTTP, the POST body may look like this:
+
+```json
+{
+ "flagKey": "booleanFlagKey",
+ "context": {
+ "email": "noreply@example.com"
+ }
+}
+```
+
+The evaluation context can be accessed in targeting rules using the `var` operation followed the evaluation context property name.
+
+| Description | Example |
+| -------------------------------------------------------------- | --------------------------------------------- |
+| Retrieve property from the evaluation context | `{ "var": "email" }` |
+| Retrieve property from the evaluation context or use a default | `{ "var": ["email", "noreply@example.com"] }` |
+| Retrieve a nested property from the evaluation context | `{ "var": "user.email" }` |
+
+> For more information, see the `var` section in the [JSON Logic documentation](https://jsonlogic.com/operations.html#var).
+
+#### Conditions
+
+Conditions can be used to control the logical flow and grouping of targeting rules.
+
+| Conditional | Example |
+| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| If | Logic: `{"if" : [ true, "yes", "no" ]}`
Result: `"yes"`
Logic: `{"if" : [ false, "yes", "no" ]}`
Result: `"no"` |
+| If else | Logic: `{"if" : [ false, "yes", false, "no", "maybe" ]}`
Result: `"maybe"`
Logic: `{"if" : [ false, "yes", false, "no", false, "maybe", "who knows" ]}`
Result: `"who knows"` |
+| Or | Logic: `{"or" : [ true, false ]}`
Result: `true`
Logic: `{"or" : [ false, false ]}`
Result: `false` |
+| And | Logic: `{"and" : [ true, false ]}`
Result: `false`
Logic: `{"and" : [ true, true ]}`
Result: `true` |
+
+#### Operators
+
+Operators are used to take action on, or compare properties retrieved from the context.
+
+| Operator | Description | Context type | Example |
+| ---------------------- | -------------------------------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Equals | Attribute equals the specified value, with type coercion. | any | Logic: `{ "==" : [1, 1] }`
Result: `true`
Logic: `{ "==" : [1, "1"] }`
Result: `true` |
+| Strict equals | Attribute equals the specified value, with strict comparison. | any | Logic: `{ "===" : [1, 1] }`
Result: `true`
Logic: `{ "===" : [1, "1"] }`
Result: `false` |
+| Not equals | Attribute doesn't equal the specified value, with type coercion. | any | Logic: `{ "!=" : [1, 2] }`
Result: `true`
Logic: `{ "!=" : [1, "1"] }`
Result: `false` |
+| Strict not equal | Attribute doesn't equal the specified value, with strict comparison. | any | Logic: `{ "!==" : [1, 2] }`
Result: `true`
Logic: `{ "!==" : [1, "1"] }`
Result: `true` |
+| Exists | Attribute is defined | any | Logic: `{ "!!": [ "mike" ] }`
Result: `true`
Logic: `{ "!!": [ "" ] }`
Result: `false` |
+| Not exists | Attribute is not defined | any | Logic: `{"!": [ "mike" ] }`
Result: `false`
Logic: `{"!": [ "" ] }`
Result: `true` |
+| Greater than | Attribute is greater than the specified value | number | Logic: `{ ">" : [2, 1] }`
Result: `true`
Logic: `{ ">" : [1, 2] }`
Result: `false` |
+| Greater than or equals | Attribute is greater or equal to the specified value | number | Logic: `{ ">=" : [2, 1] }`
Result: `true`
Logic: `{ ">=" : [1, 1] }`
Result: `true` |
+| Less than | Attribute is less than the specified value | number | Logic: `{ "<" : [1, 2] }`
Result: `true`
Logic: `{ "<" : [2, 1] }`
Result: `false` |
+| Less than or equals | Attribute is less or equal to the specified value | number | Logic: `{ "<=" : [1, 1] }`
Result: `true`
Logic: `{ "<=" : [2, 1] }`
Result: `false` |
+| Between | Attribute between the specified values | number | Logic: `{ "<" : [1, 5, 10]}`
Result: `true`
Logic: `{ "<" : [1, 11, 10] }`
Result: `false` |
+| Between inclusive | Attribute between or equal to the specified values | number | Logic: `{"<=" : [1, 1, 10] }`
Result: `true`
Logic: `{"<=" : [1, 11, 10] }`
Result: `false` |
+| Contains | Contains string | string | Logic: `{ "in": ["Spring", "Springfield"] }`
Result: `true`
Logic: `{ "in":["Illinois", "Springfield"] }`
Result: `false` |
+| Not contains | Does not contain a string | string | Logic: `{ "!": { "in":["Spring", "Springfield"] } }`
Result: `false`
Logic: `{ "!": { "in":["Illinois", "Springfield"] } }`
Result: `true` |
+| In | Attribute is in an array of strings | string | Logic: `{ "in" : [ "Mike", ["Bob", "Mike"]] }`
Result: `true`
Logic: `{ "in":["Todd", ["Bob", "Mike"]] }`
Result: `false` |
+| Not it | Attribute is not in an array of strings | string | Logic: `{ "!": { "in" : [ "Mike", ["Bob", "Mike"]] } }`
Result: `false`
Logic: `{ "!": { "in":["Todd", ["Bob", "Mike"]] } }`
Result: `true` |
+
+#### Functions
+
+Functions can be used to create more advanced targeting rules.
+They are purpose built extensions to JSON logic in order to support popular feature flag use cases.
+
+| Function | Description | Example |
+| -------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `fractionalEvaluation` | Deterministic percentage-based rollout | Logic: `{ "fractionalEvaluation" : [ "email", [ "red" , 50], [ "green" , 50 ] ] }`
Result: Pseudo randomly `red` or `green` based on the evaluation context property `email`.
Additional documentation can be found [here](./fractional_evaluation.md) |
+| `starts_with` | Attribute starts with the specified value | Logic: `{ "starts_with" : [ "192.168.0.1", "192.168"] }`
Result: `true`
Logic: `{ "starts_with" : [ "10.0.0.1", "192.168"] }`
Result: `false` |
+| `ends_with` | Attribute ends with the specified value | Logic: `{ "ends_with" : [ "noreply@example.com", "@example.com"] }`
Result: `true`
Logic: `{ ends_with" : [ "noreply@example.com", "@test.com"] }`
Result: `false` |
+| `sem_ver` | Attribute matches a semantic versioning condition | Logic: `{"sem_ver": ["1.1.2", ">=", "1.0.0"]}`
Result: `true`
Additional documentation can be found [here](./sem_ver_evaluation.md) |
+
+## Shared evaluators
+
+`$evaluators` is an **optional** property.
+It's a collection of shared targeting configurations used to reduce the number of duplicated targeting rules.
+
+Example:
+
+```json
+{
+ "flags": {
+ "fibAlgo": {
+ "variants": {
+ "recursive": "recursive",
+ "memo": "memo",
+ "loop": "loop",
+ "binet": "binet"
+ },
+ "defaultVariant": "recursive",
+ "state": "ENABLED",
+ "targeting": {
+ "if": [
+ {
+ "$ref": "emailWithFaas"
+ },
+ "binet",
+ null
+ ]
+ }
+ },
+ "headerColor": {
+ "variants": {
+ "red": "#FF0000",
+ "blue": "#0000FF",
+ "green": "#00FF00",
+ "yellow": "#FFFF00"
+ },
+ "defaultVariant": "red",
+ "state": "ENABLED",
+ "targeting": {
+ "if": [
+ {
+ "$ref": "emailWithFaas"
+ },
+ {
+ "fractionalEvaluation": [
+ "email",
+ ["red", 25],
+ ["blue", 25],
+ ["green", 25],
+ ["yellow", 25]
+ ]
+ },
+ null
+ ]
+ }
+ }
+ },
+ "$evaluators": {
+ "emailWithFaas": {
+ "in": [
+ "@faas.com",
+ {
+ "var": ["email"]
+ }
+ ]
+ }
+ }
+}
+```
+
+## Examples
+
+Sample configurations can be found at .
From 9e6037bc4293725174df12679db015648463a76c Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Thu, 7 Sep 2023 17:03:53 +1000
Subject: [PATCH 19/21] systemd updates
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
docs/other_resources/systemd_service.md | 21 ++-------------------
mkdocs.yml | 1 +
2 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/docs/other_resources/systemd_service.md b/docs/other_resources/systemd_service.md
index 7d6e359c2..d4f0218e3 100644
--- a/docs/other_resources/systemd_service.md
+++ b/docs/other_resources/systemd_service.md
@@ -1,22 +1,5 @@
+
# Run flagD as a systemd Service
-To install as a systemd service clone the repo and run `sudo make install`.
-This will place the binary by default in `/usr/local/bin`.
+This content has moved. See [flagd as a systemd Service](https://flagd.dev/nonk8s/systemservice/)
-There will also be a default provider and sync enabled ( http / filepath ) both of which can be modified in the flagd.service.
-
-Validation can be run with `systemctl status flagd`
-And result similar to below will be seen
-
-```console
- flagd.service - "A generic feature flag daemon"
- Loaded: loaded (/etc/systemd/system/flagd.service; disabled; vendor preset: enabled)
- Active: active (running) since Mon 2022-05-30 12:19:55 BST; 5min ago
- Main PID: 64610 (flagd)
- Tasks: 7 (limit: 4572)
- Memory: 1.4M
- CGroup: /system.slice/flagd.service
- └─64610 /usr/local/bin/flagd start -f=/etc/flagd/flags.json
-
-May 30 12:19:55 foo systemd[1]: Started "A generic feature flag daemon".
-```
diff --git a/mkdocs.yml b/mkdocs.yml
index 58bfb7723..425ed5b58 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -51,6 +51,7 @@ nav:
- 'FlagSourceConfiguration': 'k8s/crds/flagsourceconfiguration.md'
- 'FeatureFlagConfiguration': 'k8s/crds/featureflagconfiguration.md'
- 'Reference':
+ - 'Configuration of flags': 'reference/flag_configuration.md'
- 'Flagd Configuration': 'reference/configuration.md'
- 'Flagd Start': 'reference/flagd_start.md'
- 'Flagd OpenTelemetry Support': 'reference/opentelemetry.md'
From c1def1beae369e0541e18f0ddc19db31b28beb2f Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 13 Sep 2023 16:04:25 +1000
Subject: [PATCH 20/21] fix mkdocs error
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
mkdocs.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mkdocs.yml b/mkdocs.yml
index 425ed5b58..afda1c4cf 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -59,7 +59,7 @@ nav:
- 'Flag Caching': 'reference/caching.md'
- 'Flagd Version': 'reference/flagd_version.md'
- 'Fractional Evaluation': 'reference/fractional_evaluation.md'
- - 'Targeting Rules and Specifiers: 'reference/targeting_rules_specifiers.md'
+ - 'Targeting Rules and Specifiers': 'reference/targeting_rules_specifiers.md'
- 'Flagd Telemetry':
- 'Flagd OpenTelemetry Support': 'concepts/opentelemetry.md'
- 'Troubleshooting': 'troubleshooting.md'
From 7ffa0b504ca6c0f98eba8b7d417f5e1c13a32c1c Mon Sep 17 00:00:00 2001
From: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
Date: Wed, 13 Sep 2023 16:44:16 +1000
Subject: [PATCH 21/21] fix formatting for markdownlint
Signed-off-by: Adam Gardner <26523841+agardnerIT@users.noreply.github.com>
---
web-docs/reference/flag_configuration.md | 2 +-
web-docs/reference/fractional_evaluation.md | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/web-docs/reference/flag_configuration.md b/web-docs/reference/flag_configuration.md
index 24c434a9a..02ae5fc7d 100644
--- a/web-docs/reference/flag_configuration.md
+++ b/web-docs/reference/flag_configuration.md
@@ -1,4 +1,4 @@
-## Flags
+# Flags
`flags` is a **required** property.
The flags property is a top level property that contains a collection of individual flags and their corresponding flag configurations.
diff --git a/web-docs/reference/fractional_evaluation.md b/web-docs/reference/fractional_evaluation.md
index 6bccd7d8e..2080df582 100644
--- a/web-docs/reference/fractional_evaluation.md
+++ b/web-docs/reference/fractional_evaluation.md
@@ -141,4 +141,4 @@ new:
{ "var": "email" },
[ "red", 25 ], [ "blue", 25 ], [ "green", 25 ], [ "yellow", 25 ]
]
-```
\ No newline at end of file
+```