Expected lifecycle of flags

[justinabrahms]

We think of flags in two ways.

First, temporary flags. These help us ramp traffic onto a feature slowly and safely using targeting rules. This is the main use-case. These flags happen to have an expected end date and we plan to nag people if the flag is still active after that date.

Second, there are "long-lived flags", which are expected to follow a kill-switch use-case. As an example, we have a latency sensitive homepage. If the "recommended products" module is causing us to breach our latency SLAs, we want to toggle the flag and disable that from rendering, so we can get the site back under the latency budget.

From an API standpoint, they are identical.

Is this how others are thinking about flags?

[justinabrahms]

cc #27 where this was originally brought up.

[beeme1mr]

Unleash has a nice blog about this. Basically, the type of flag should indicate the life expectancy. That assumes you're able to determine what type of flag it is.

[toddbaert]

Cloudbees Feature Management shows some interesting flag states related to this (see "stale"/"inactive"):

Active - Received impressions with different values over the last seven days

Stale - Received impressions over the last seven days, but all had the same value

Inactive - Received no impressions over the last seven days

Setup - No impressions received yet

Permanent - A permanent (long lived) flag, ignoring impression data

https://docs.cloudbees.com/docs/cloudbees-feature-management/latest/feature-flags/environments#_feature_flag_status

Another key use-case for long-lived flags (one that I'm particularly interested in from a security perspective) is flags that allow swaths of related functionality to be disabled due to a security breach, or as a circuit-breaker during an attack, for instance. Perhaps with a well-defined standard such as OpenFeature, it might even be possible to have security software perform such actions automatically.

[InTheCloudDan]

LaunchDarkly has support for multiple types of flag statuses as outlined at: https://docs.launchdarkly.com/home/code/flag-status

In addition we do have the concept of temporary vs permanent flags. And from the API(What we call the SDK) standpoint those are the same

[beeme1mr]

@InTheCloudDan is temporary and permanent flags only used for UI purposes? I'm assuming it's used to highlight potentially stale flags that should be removed.

[InTheCloudDan]

@beeme1mr exactly, it does not have any impact on evaluation of the flags.

[toddbaert]

@justinabrahms I think this is a good discussion to have on record, and based on the info here, it seems like we can think of this as a "backend" concern that doesn't necessarily need to be defined in the OpenFeature spec or modeled in the SDK itself.

That said, I'm going to close this issue in the interest of keeping things tidy, but feel free to re-open if you disagree!