New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Features API and implementation. #14

Merged
merged 1 commit into from Nov 10, 2016

Conversation

Projects
None yet
5 participants
@nickva
Contributor

nickva commented Oct 6, 2016

Implement ability to enable, disable and query feature flags.

Features are identified as binary strings. Usage intent is for
various components in the system to enable features, then the HTTP API will
expose those to the user. For example, features could indicate the presence
of an optional component, a plugin or a new mode of operation.

The API has 3 functions:

  • config:features/0 : Return a sorted list of feature flags
  • config:feature_enable/1 : Enables a feature. Feature argument could be a
    list, a binary or an atom.
  • config:feature_disable/1 : Same as feature_enable/1 but disables the
    feature.

feature_enable/1 and feature_disable/1 are idempotent.

Implementation is a thin wrapper around setting and deleting keys from the
'[features]' config section. This means, users can also set their own features
there via the .ini config files. Features set via the API are not persistent,
so applications will have to set them every time they initialize.

Jira: COUCHDB-3180

@sagelywizard

👍

@kxepal

This comment has been minimized.

Member

kxepal commented Oct 6, 2016

Well, if we're agree that features should be discoverable, may be not introduce intermediate short live solutions that will break backward compatibility at some point?

@kxepal

This comment has been minimized.

Member

kxepal commented Oct 6, 2016

Don't get me wrong about your effort for pushing this feature forward. I worry about all future oblivious improvements for this feature which aren't fit into current implementation. So it'll have to be changed and since it's a thing that users may use in own fashion, such changes may not be harmless.

@nickva

This comment has been minimized.

Contributor

nickva commented Oct 6, 2016

@kxepal

Well, if we're agree that features should be discoverable, may be not introduce intermediate short live solutions that will break backward compatibility at some point?

They are discoverable. config:features() returns all feature flags.

I worry about all future oblivious improvements for this feature which aren't fit into current implementation.

Then we'll change the implementation. Where you thinking of a whole new application or other such thing?

@kxepal

This comment has been minimized.

Member

kxepal commented Oct 7, 2016

@nickva
After good sleep time I think there are no conflicts here. Yes, features need to be discovered, but yes, user need to have an option to turn on/off them easily without doing fancy Erlang tricks.

So config true/false switches is how user may control features availability. I'm hard to image a case when I would shutdown some feature, but it looks useful.

So I take my words back, sorry for that.

Where you thinking of a whole new application or other such thing?

I think new app is a good idea to group there all the features-related logic which will grow in time. For instance, config:features is a bit misplaced here, but for now there is no better place for it.

lists:usort([list_to_binary(Key) || {Key, "true"} <- ?MODULE:get(?FEATURES)]).
feature_enable(Feature) when is_atom(Feature) ->

This comment has been minimized.

@rnewson

rnewson Nov 8, 2016

Member

enable_feature and disable_feature reads better, what do you think? Also, can we insist on atom rather than handle atom and binary and list?

This comment has been minimized.

@rnewson

rnewson Nov 8, 2016

Member

or maybe add_feature / remove_feature. I think you're only supporting remove_feature for testing?

This comment has been minimized.

@nickva

nickva Nov 8, 2016

Contributor

Yeah enable_feature/disable_feature sounds better. Can make it an atom as well.

vs add/remove, enable/disable has more of an idempotent feel to it. But ok with either way.

Features API and implementation.
Implement ability to enable, disable and query feature flags.

Features are identified as atoms. Usage intent is for various components in the
system to enable features, then the HTTP API will expose those to the user.
For example, features could indicate the presence of an optional component, a
plugin or a new mode of operation.

The API has 3 functions:

 * `config:features/0` : Return a sorted list of feature flags

 * `config:enable_feature/1` : Enables a feature. Feature argument could be a
   list, a binary or an atom.

 * `config:disable_feature/1` : Disables a feature.

Implementation is a thin wrapper around setting and deleting keys from the
'[features]' config section. This means, users can also set their own features
there via the .ini config files. Features set via the API are not persistent,
so applications will have to set them every time they initialize.

COUCHDB-3180
@rnewson

This comment has been minimized.

Member

rnewson commented Nov 10, 2016

+1

@asfgit asfgit merged commit f62d553 into apache:master Nov 10, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@nickva nickva deleted the cloudant:couchdb-3180 branch Nov 10, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment