Remove Feature Flag Service in favor of OpenFeature + flagd

[austinlparker]

Changes

This PR removes the Erlang featureflag service and its dependencies in favor of OpenFeature ecosystem projects.

Rationale

Feature Flag Service is a bit of a heavy dependency for the project to maintain. We don't have any regular Erlang contributors in maintainer/approver ranks, which makes it difficult to evaluate changes. There's been a fairly long-standing issue with cross-platform builds in QEMU and various Erlang components which has kept the service on outdated versions of OTP. We've had several feature requests for more flexibility around the feature flags that require setting via API, and the lack of a dedicated client for the feature flag service itself makes it somewhat challenging for contributors to add new things (as they have to write handlers for each application).

OpenFeature is a CNCF incubating project that's under active development and provides several things:

• Client libraries for most languages
• Lightweight flag daemon (flagd)
• Kubernetes integration
• Native OpenTelemetry support

Merge Requirements

For new features contributions please make sure you have completed the following
essential items:

• CHANGELOG.md updated to document new feature additions
• Appropriate documentation updates in the docs
• Appropriate Helm chart updates in the helm-charts

Maintainers will not merge until the above have been completed. If you're unsure
which docs need to be changed ping the
@open-telemetry/demo-approvers.

[julianocosta89]

Wow!
This is a huge change but I'd hold it for a bit.
I wouldn't replace the FeatureFlagService without having another Erlang/Elixir service on the demo.

[austinlparker]

Wow! This is a huge change but I'd hold it for a bit. I wouldn't replace the FeatureFlagService without having another Erlang/Elixir service on the demo.

See #1343 (comment) -- I think we'll need to get another Erlang service added in as a stub off Kafka somehow. I don't necessarily think it should block this PR, though.

[julianocosta89]

Wow! This is a huge change but I'd hold it for a bit. I wouldn't replace the FeatureFlagService without having another Erlang/Elixir service on the demo.

See #1343 (comment) -- I think we'll need to get another Erlang service added in as a stub off Kafka somehow. I don't necessarily think it should block this PR, though.

So you would drop Erlang/Elixir from the demo till we get a new service rewritten?

[julianocosta89]

I vote against it.

[austinlparker]

We can discuss it at the next SIG meeting. I don't anticipate releasing the demo without an Erlang service, but we also can't arbitrarily hold off on integrating new changes because of implicit dependencies.

[tsloughter]

Wish I'd known about this I'd have done what I could to make it not necessary, I wasn't aware it was being considered. Does Erlang/Elixir now get no demo app?

[austinlparker]

Wish I'd known about this I'd have done what I could to make it not necessary, I wasn't aware it was being considered. Does Erlang/Elixir now get no demo app?

No, we'll still have an Erlang demo app, but probably a smaller one that's less of a maintenance burden?

[tsloughter]

So I can try to help, what burdern does it ease to be another service? You mention the build pipeline, how would that be different for product service or the new kafka service?

[austinlparker]

@tsloughter moving this convo over to #1343

[beeme1mr]

Hey @austinlparker, I'm one of the maintainers of OpenFeature. Thanks for getting this started! Please let me know if you have any questions.

[agardnerIT]

I'd have done what I could to make it not necessary

For the future, calls to the OpenFeature SDK can specify a default value so even if the backend is unavailable, you'll still get a working app.

[austinlparker]

I'd have done what I could to make it not necessary

For the future, calls to the OpenFeature SDK can specify a default value so even if the backend is unavailable, you'll still get a working app.

Feel free to check my work but I'm pretty sure that's what I've done here.

[austinlparker]

Hey @austinlparker, I'm one of the maintainers of OpenFeature. Thanks for getting this started! Please let me know if you have any questions.

Rad! Could you look into getting the python flagd provider released? :)

[beeme1mr]

Rad! Could you look into getting the python flagd provider released? :)

@thisthat has opened a PR. Hopefully, we can get publishing working tomorrow.

open-feature/python-sdk-contrib#38

[austinlparker]

Perfect!

[mviitane]

When running this branch, I constantly get this error:
frontend | Error: 12 UNIMPLEMENTED: Method not found: oteldemo.AdService/GetAds
Anyone else see this?

[julianocosta89]

@mviitane yes!

Error: 12 UNIMPLEMENTED: Method not found: oteldemo.AdService/GetAds
    at callErrorFromStatus (/app/node_modules/@grpc/grpc-js/build/src/call.js:31:19)
    at Object.onReceiveStatus (/app/node_modules/@grpc/grpc-js/build/src/client.js:192:76)
    at Object.onReceiveStatus (/app/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:360:141)
    at Object.onReceiveStatus (/app/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:323:181)
    at /app/node_modules/@grpc/grpc-js/build/src/resolving-call.js:99:78
    at process.processTicksAndRejections (node:internal/process/task_queues:77:11)
for call at
    at ServiceClientImpl.makeUnaryRequest (/app/node_modules/@grpc/grpc-js/build/src/client.js:160:32)
    at ServiceClientImpl.<anonymous> (/app/node_modules/@grpc/grpc-js/build/src/make-client.js:105:19)
    at /app/node_modules/@opentelemetry/instrumentation-grpc/build/src/grpc-js/clientUtils.js:131:31
    at /app/node_modules/@opentelemetry/instrumentation-grpc/build/src/grpc-js/index.js:233:209
    at AsyncLocalStorage.run (node:async_hooks:338:14)
    at AsyncLocalStorageContextManager.with (/app/node_modules/@opentelemetry/context-async-hooks/build/src/AsyncLocalStorageContextManager.js:33:40)
    at ContextAPI.with (/app/node_modules/@opentelemetry/api/build/src/api/context.js:60:46)
    at ServiceClientImpl.clientMethodTrace [as getAds] (/app/node_modules/@opentelemetry/instrumentation-grpc/build/src/grpc-js/index.js:233:42)
    at /app/.next/server/pages/api/data.js:63:58
    at new Promise (<anonymous>) {
  code: 12,
  details: 'Method not found: oteldemo.AdService/GetAds',
  metadata: Metadata {
    internalRepr: Map(1) { 'content-type' => [Array] },
    options: {}
  }
}

@austinlparker was that working on the initial PR?

[julianocosta89]

Ads are not being loaded at all:

[austinlparker]

Huh. I thought it was?

[austinlparker]

Hm, does seem like it's not working. The ad service is running fine though.

[austinlparker]

Should be working now, my bad.

[austinlparker]

@beeme1mr looks like the python otel hook isn't published yet?

[austinlparker]

See #1436 for notes on how we will integrate with k8s

[julianocosta89]

Tested it, and everything seems to be working fine.
Let's ship it! 🚀

[beeme1mr]

@beeme1mr looks like the python otel hook isn't published yet?

We'll publish the hook and include it in a follow up PR.

[federicobond]

@austinlparker the Python OTel hook is now released! Note that you need to update the import paths for the released version

https://pypi.org/project/openfeature-hooks-opentelemetry/

[julianocosta89]

@federicobond I've tried adding it, but it seems there is an issue with the hook.
I've opened an issue here: open-feature/python-sdk-contrib#67