prysm-pulse/shared/featureconfig
Preston Van Loon 14dbc2b74d
Add blst for BLS (#6539)
* Add blst third party dep

* initial build

* add init

* blst passing tests

* add feature flag

* blst and herumi for spec tests

* maybe this works for mac

* Actually set feature flag

* Add stub for VerifyMultipleSignatures for blst

* verifyCompressed

* use correct cores sizes

* aggregate public keys

* add multi-sig verification

* encode not hash

* revert back

* go mod tidy

* update blst to latest commit

* add batch decompress

* fix

* add test

* gofmt

* update blst

* go mod tidy

* remove kubesec, fix

* mod tidy

* disable some remote cache

* disable some remote cache

* disable some remote cache

* disable some remote cache

* Switch to -D__ADX__

* update

* tidy

* fix build

* Make blst for only linux,amd64

* gofmt

* lint

* lint

* gazelle

* fix build tag

* more stub methods

* shift adx instructions to x86

* fix arm64

* Revert "fix arm64"

This reverts commit 4d34ac21b7509a1b385374e3039efecfcab614c1.

* add one more in

* Revert "Revert "fix arm64""

This reverts commit 1c8ae24ad16ff9811590f1058b9d98c90b63251a.

* try darwin now

* Revert "try darwin now"

This reverts commit 6f884714b8e14a7a803b72157672b6e942047f37.

* Add sha256

* remove TODO

* checkpoint

* finally builds

* fix up

* add tag

* try again

* explicit disabling

* remove

* select properly

* fix

* better

* make CI happy too

* Update .bazelrc

* Update .bazelrc

* fix tests

* revert back

* Update shared/bls/blst/public_key.go

Co-authored-by: Victor Farazdagi <simple.square@gmail.com>

* Update shared/bls/blst/public_key.go

Co-authored-by: Victor Farazdagi <simple.square@gmail.com>

* clean up tests

* more clean up

* clean up

* add

* Update shared/bls/blst/signature.go

* Update shared/bls/blst/signature.go

* Update .buildkite-bazelrc

Co-authored-by: Preston Van Loon <preston@prysmaticlabs.com>

* try again

* remove go tag

* revert change

* gaz

* gazelle ignore

Co-authored-by: nisdas <nishdas93@gmail.com>
Co-authored-by: Victor Farazdagi <simple.square@gmail.com>
Co-authored-by: prylabs-bulldozer[bot] <58059840+prylabs-bulldozer[bot]@users.noreply.github.com>
2020-09-16 21:28:28 +08:00
..
BUILD.bazel Applies assertion funcs to shared tests (#6643) 2020-07-19 21:08:29 +00:00
config_test.go Featureflag test: reset init (#7007) 2020-08-15 15:48:12 +00:00
config.go Add blst for BLS (#6539) 2020-09-16 21:28:28 +08:00
filter_flags.go Refactor dependencies, make Prysm "go gettable" (#6053) 2020-05-31 14:44:34 +08:00
flags_test.go Applies assertion funcs to shared tests (#6643) 2020-07-19 21:08:29 +00:00
flags.go Add blst for BLS (#6539) 2020-09-16 21:28:28 +08:00
README.md Add documentation and issue template for feature flags (#6018) 2020-05-27 20:37:37 -05:00

Prysm Feature Flags

Part of Prysm's feature development often involves use of feature flags which serve as a way to toggle new features as they are introduced. Using this methodology, you are assured that your feature can be safely tested in production with a fall back option if any regression were to occur. This reduces the likelihood of an emergency release or rollback of a given feature due to unforeseen issues.

When to use a feature flag?

It is best to use a feature flag any time you are adding or removing functionality in an existing critical application path.

Examples of when to use a feature flag:

  • Adding a caching layer to an expensive RPC call.
  • Optimizing a particular algorithm or routine.
  • Introducing a temporary public testnet configuration.

Examples of when not to use a feature flag:

  • Adding a new gRPC endpoint. (Unless dangerous or expensive to expose).
  • Adding new logging statements.
  • Removing dead code.
  • Adding any trivial feature with no risk of regressions to existing functionality.

How to use a feature flag?

Once it has been decided that you should use a feature flag. Follow these steps to safely releasing your feature. In general, try to create a single PR for each step of this process.

  1. Add your feature flag to shared/featureconfig/flags.go, use the flag to toggle a boolean in the feature config in shared/featureconfig/config.go. It is a good idea to use the enable prefix for your flag since you're going to invert the flag in a later step. i.e you will use disable prefix later. For example, --enable-my-feature. Additionally, create a feature flag tracking issue for your feature using the appropriate issue template.
  2. Use the feature throughout the application to enable your new functionality and be sure to write tests carefully and thoughtfully to ensure you have tested all of your new funcitonality without losing coverage on the existing functionality. This is considered an opt-in feature flag. Example usage:
func someExistingMethod(ctx context.Context) error {
    if featureconfig.Get().MyNewFeature {
       return newMethod(ctx)
    }
    // Otherwise continue with the existing code path.
}
  1. Add the flag to the end to end tests. This set of flags can also be found in shared/featureconfig/flags.go.
  2. Test the functionality locally and safely in production. Once you have enough confidence that your new function works and is safe to release then move onto the next step.
  3. Move your existing flag to the deprecated section of shared/featureconfig/flags.go. It is important NOT to delete your existing flag outright. Deleting a flag can be extremely frustrating to users as it may break their existing workflow! Marking a flag as deprecated gives users time to adjust their start scripts and workflow. Add another feature flag to represent the inverse of your flag from step 1. For example --disable-my-feature. Read the value of this flag to appropriately the config value in shared/featureconfig/config.go.
  4. After your feature has been included in a release as "opt-out" and there are no issues, deprecate the opt-out feature flag, delete the config field from shared/featureconfig/config.go, delete any deprecated / obsolete code paths.

Deprecated flags are deleted upon each major semver point release. Ex: v1, v2, v3.