[Question] Feature Flag support as AppConfigurationProvider does (in dotnet env)

[kimpenhaus]

linglingye001 maybe you can help me with this as well 🙂

we currently have theAzureAppConfigurationProvider used in our dotnet apps/code - we want to switch to configmaps built by AppConfiguration-KubernetesProvider. it looks like the only thing preventing us from doing so is that the structure of the feature flags written into the configmaps isn't compatible with the structure theAzureAppConfigurationProvider creates inside IConfigurationRoot.

from AzureAppConfigurationProvider:

in configmaps:

inside IConfiurationRoot with configmaps:

what is the supposed way to handle this? we are currently using IConfigurationRoot with an extension method to check whether a feature is enabled. we combine feature flags from different providers - so the old structure the AzureAppConfigurationProvider gives is very welcome :)

public static bool IsFeatureEnabled(this IConfigurationRoot config, string feature)
        => config.GetValue<bool?>($"FeatureManagement:{feature}")
           ?? config.GetValue<bool?>($"Feature:{feature}")
           ?? throw new FeatureFlagConfigurationNotFoundException("Feature could not be found!").WithData("Feature", feature);

is it supposed to switch to the FeatureManager - as the feature_management created by the kubernetes provider meets the spec: https://github.com/microsoft/FeatureManagement/blob/main/Schema/FeatureManagement.v2.0.0.schema.json

thanks in advance for your help.

[zhiyuanliang-ms]

Hi, Marcus Kimpenhaus (@kimpenhaus) Thanks for reaching out!

we are currently using IConfigurationRoot with an extension method to check whether a feature is enabled. we combine feature flags from different providers - so the old structure the AzureAppConfigurationProvider gives is very welcome :)

is it supposed to switch to the FeatureManager

Just want to double check, I assumed that you have known and tried .NET Feature Management library. But the need to combine feature flags from different providers led you to implement the IsFeatureEnabled by yourself instead of using the Feature Management library.

public static bool IsFeatureEnabled(this IConfigurationRoot config, string feature)
        => config.GetValue<bool?>($"FeatureManagement:{feature}")
           ?? config.GetValue<bool?>($"Feature:{feature}")
           ?? throw new FeatureFlagConfigurationNotFoundException("Feature could not be found!").WithData("Feature", feature);

The code snippet you posted is not our recommended way to consume feature flags. We recommend to use Feature Management libraries to consume feature flags from Azure App Configuration.

The AppConfiguration-KubernetesProvider will convert feature flags into the Microsoft Feature Flag schema which is language-agnostic and supported by all Feature Management libraries.

The "old structure the AzureAppConfigurationProvider gives" is called .NET Feature Flag schema. The App Config .NET provider will convert the classic feature flags without variant and telemetry into the old .NET Feature Flag schema and it will convert feature flags with variant/telemetry into the new Microsoft Feature Flag schema. We did this for the compatibility when users are using old version Feature Managment (ealier than 3.2.0) and the latest .NET provider library. But we will gradually deprecate the usage of old .NET Feature Flag schema.

The pitfall of merging array values in .NET is a well-known issue. We recently supported merge Microsoft feature flags from different configuration source PR. It will be released in the next release. If you want, we can accelerate it.

So, I imagine the solution here is:

1. All configuration providers use Microsoft schema (kubernetes provider & your other configuration provider) to define feature flags
2. Use latest .NET feature management library which can merge Microsoft feature flags from different configuration providers.

Jimmy Campbell (@jimmyca15)

[kimpenhaus]

Zhiyuan Liang (@zhiyuanliang-ms) thanks for your fast and detailed response - appreciate!

But the need to combine feature flags from different providers led you to implement the IsFeatureEnabled by yourself instead of using the Feature Management library.

this and the fact - as what I have seen so far from the feature manager - that it only has an async api like IsEnabledAsync(String). we are using the is feature enabled determination also in attributes of classes to evaluate if need to create an instance or not. it's a very large codebase - would call it brownfield.

I understood your recommended approach and honestly this is where we want to head with our code. 😄 do you know if we have the chance to get an sync api only? as far as I understand all configmaps mounted and add by json file are in the configuration and there is no need for us to call backends or have an async call.

[zhiyuanliang-ms]

bool isBetaEnabled = featureManager.IsEnabledAsync("Beta").GetAwaiter().GetResult();

Can this be a workaround?

do you know if we have the chance to get an sync api only?

Offering async api is a library-level design decision, there was a discussion about it. See #120

[kimpenhaus]

Zhiyuan Liang (@zhiyuanliang-ms) we'll see if we can go down this route 👍🏼 thanks for you explanations and your effort 🙏🏼

[jimmyca15]

Hi, @kimpenhaus Thanks for reaching out!

we are currently using IConfigurationRoot with an extension method to check whether a feature is enabled. we combine feature flags from different providers - so the old structure the AzureAppConfigurationProvider gives is very welcome :)

is it supposed to switch to the FeatureManager

Just want to double check, I assumed that you have known and tried .NET Feature Management library. But the need to combine feature flags from different providers led you to implement the IsFeatureEnabled by yourself instead of using the Feature Management library.

public static bool IsFeatureEnabled(this IConfigurationRoot config, string feature)
=> config.GetValue<bool?>($"FeatureManagement:{feature}")
?? config.GetValue<bool?>($"Feature:{feature}")
?? throw new FeatureFlagConfigurationNotFoundException("Feature could not be found!").WithData("Feature", feature);

The code snippet you posted is not our recommended way to consume feature flags. We recommend to use Feature Management libraries to consume feature flags from Azure App Configuration.

The AppConfiguration-KubernetesProvider will convert feature flags into the Microsoft Feature Flag schema which is language-agnostic and supported by all Feature Management libraries.

The "old structure the AzureAppConfigurationProvider gives" is called .NET Feature Flag schema. The App Config .NET provider will convert the classic feature flags without variant and telemetry into the old .NET Feature Flag schema and it will convert feature flags with variant/telemetry into the new Microsoft Feature Flag schema. We did this for the compatibility when users are using old version Feature Managment (ealier than 3.2.0) and the latest .NET provider library. But we will gradually deprecate the usage of old .NET Feature Flag schema.

The pitfall of merging array values in .NET is a well-known issue. We recently supported merge Microsoft feature flags from different configuration source PR. It will be released in the next release. If you want, we can accelerate it.

So, I imagine the solution here is:

1. All configuration providers use Microsoft schema (kubernetes provider & your other configuration provider) to define feature flags
2. Use latest .NET feature management library which can merge Microsoft feature flags from different configuration providers.

@jimmyca15

This sounds right Zhiyuan Liang (@zhiyuanliang-ms). And to add, this issue in the .NET App Configuration Provider discusses that we will be adding an environment variable to force the .NET provider to use the Microsoft Schema, the same schema the Kubernetes provider uses.

Once that is released, and once the next feature management version is released I think the way forward would be to safely depend on these libraries as they will allow merging of feature flag sources.