Feature flags

[iilyak]

Overview

Once in a while we merge a highly experimental features. It is beneficial to be able to have the codepath for these features effectivelly disabled by default until the implementation is stabilized.
This PR introduces an ability to add feature flag checks for experimental features.
This feature is for developers only and wouldn't need documentation.

The feature configuration

[feature_flags]

my_feature||* = false
my_feature||mytestdatabaseprefix* = true

Notes:

• The * is only allowed at the end of the path
• In order to distinguish between shards and clustered db the following convention is used.
  • it is a shard if pattern starts with /
• It is also possible to enable multiple flags for the path using alternative syntax
  • mytestdatabaseprefix* = [my_featureA, my_featureB]

Usage of the feature in the code

case couch_flags:is_enabled(my_feature, Subject) of
    true -> ...;
    false -> ...
end

Where Subject is one of #db{} | #httpd{) | #shard{} | #ordered_shard{} | ShardName :: binary() | ShardName :: list() | DbName :: binary() | DbName :: list()

Performance

There is a naive performance test in the test suite it does 1 million of calls to is_enabled/2. One million of calls takes "1.884 s" on the laptop.

Security

It is not safe to allow configuration of the feature flags over http since there might be a possibility of injecting arbitrary code via name of the configuration key within feature_flags section. Therefore the http access is disabled.

Testing recommendations

make eunit apps=couch suites=couch_flags_tests,couch_flags_config

Related Issues or Pull Requests

N/A

Checklist

• Code is written and works correctly;
• Changes are covered by tests;
• Documentation reflects the changes;

[nickva]

FYI: There is already a similar config-based "features" feature implementation:

apache/couchdb-config@f62d553

That's used by various components to indicated their presence and then those features are bubbled up to the top level API.

https://github.com/apache/couchdb/blob/master/src/chttpd/src/chttpd_misc.erl#L53

[iilyak]

@nickva FYI: There is already a similar config-based "features" feature implementation:

There are few important differences:

1. config-based "features" are really supported capabilities. People use welcome message to check if new API is available on the cluster. While feature flags are totally internal things. The flags suppose to be deleted once feature is stable and officially released.
2. config-based "features" are global. It is impossible to enable it for some databases and disable for others.

[nickva]

Ah you're right. It was mostly a capabilities thing. I just wanted to call it out in the PR so it's visible. As the old thing has the (confusing) "features" name.

Maybe it would be good to replace the old thing with this? The "config" capabilities thing was a quick adhock thing, this seems better designed.

[garrensmith]

Nice work.

[garrensmith]

@nickva just checking, are you happy with this PR? Are you ok with us merging it?

[nickva]

@garrensmith I didn't review the PR contents in detail so as far as that I am +0 so if you reviewed and looks good, go ahead and merge.

[garrensmith]

I think IIya wants to add one more thing before merging.

…

________________________________ From: Nick Vatamaniuc <notifications@github.com> Sent: Thursday, November 1, 2018 4:46:18 PM To: apache/couchdb Cc: garren smith; Mention Subject: Re: [apache/couchdb] Feature flags (#1682) @garrensmith<https://github.com/garrensmith> I didn't review the PR contents in detail so as far as that I am +0 so if you reviewed and looks good, go ahead and merge. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1682 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAK9An81IkitazaMSLLhWB6JfF7OQb-oks5uqwk6gaJpZM4X6XHv>.

[jaydoane]

make eunit apps=couch suites=couch_flags_tests,couch_flags_config
  [done in 15.251 s]
=======================================================
  All 5059 tests passed.

(that's a lot of new tests!)

[jaydoane]

s/rely/relies/

[jaydoane]

I would love to see type specs defined for public functions