aboutsummaryrefslogtreecommitdiffstats
path: root/configserver-flags
Commit message (Collapse)AuthorAgeFilesLines
* Update 2019 Oath copyrights.gjoranv2021-10-273-3/+3
|
* Update 2019 Yahoo Holdings copyright notices.gjoranv2021-10-071-1/+1
|
* Update 2018 copyright notices.gjoranv2021-10-0715-15/+15
|
* Update 2017 copyright notices.gjoranv2021-10-071-1/+1
|
* Remove com.yahoo.vespa.jdk8compatBjørn Christian Seime2021-03-101-1/+1
| | | | These types are often accidentally imported, and the JDK8 replacement is typically a one-liner.
* Update expected json outputBjørn Christian Seime2020-12-021-2/+2
|
* Flag definition has changedBjørn Christian Seime2020-12-022-4/+6
|
* Specify owner and expected time-to-leave for feature flagsBjørn Christian Seime2020-12-021-1/+6
| | | | Actual owners will be specified in upcoming PR
* LogLevel.WARNING -> Level.WARNINGgjoranv2020-04-251-1/+1
|
* Import java.util.logging.Level instead of com.yahoo.log.LogLevelgjoranv2020-04-251-1/+1
|
* Use withX instead of setXHåkon Hallingstad2019-10-231-1/+1
|
* Make fluent-style paramsHåkon Hallingstad2019-10-231-3/+1
|
* Revert "Revert "Support flag conditions based on Vespa release ""Håkon Hallingstad2019-10-231-1/+5
|
* Revert "Support flag conditions based on Vespa release "Harald Musum2019-10-231-5/+1
|
* Merge pull request #11037 from ↵Håkon Hallingstad2019-10-231-1/+5
|\ | | | | | | | | vespa-engine/hakonhall/support-flag-conditions-based-on-vespa-release Support flag conditions based on Vespa release
| * Document HOSTNAME and make factoriesHåkon Hallingstad2019-10-221-1/+1
| |
| * Support flag conditions based on Vespa releaseHåkon Hallingstad2019-10-221-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Supports a "relational" condition with a new dimension "vespa-version", that can be satisfied with e.g. "predicate": ">= 7.120.5" as long as the condition is evaluated in a JVM that has a Vtag at least high as 7.120.5. The typical use-case for this condition would be: The developer has used the flag to test and verify the feature is ready to roll out globally. The developer can now roll the feature with the next release, and ORCHESTRATED, halting if anything goes wrong like any normal rollout. This also allows one-shot tests of a feature flag in integration tests: Just enable it for an upcoming version with predicate "== 7.x.y".
* | Use mockito-core 3.1.0Håkon Hallingstad2019-10-181-1/+1
|/
* Move FlagRepository to flagsValerij Fredriksen2019-10-114-8/+5
|
* Move general REST API classes to com.yahoo.restapiMartin Polden2019-09-203-104/+1
|
* Decouple flags REST API from config serverMartin Polden2019-07-1614-3/+704
|
* Revert "Decouple flags REST API from config server"Martin Polden2019-07-126-4/+150
| | | | This reverts commit b81b21546cdff92d360cbdf7dda27e6ed7bc7170.
* Decouple flags REST API from config serverMartin Polden2019-07-126-150/+4
|
* Start the cacheHåkon Hallingstad2019-01-281-0/+1
|
* Curator/Zk requires an absolute pathHåkon Hallingstad2019-01-271-1/+1
|
* Cache flags DBHåkon Hallingstad2019-01-262-9/+20
| | | | | | | | | Up until now every lookup of a flag on ZooKeeperFlagSource would hit ZooKeeper. Flags are ideal for caching: Changes seldom, little data, clients should handle short-lived inconsistencies. This PR will make the backing FlagsDbImpl cache the /flags/v1 ZK directory and completes the optimization of ConfigServerFlagSource.
* Read override file flags from file only once for config serverHåkon Hallingstad2019-01-264-2/+157
| | | | | | | | | | | | | | | | | | Up until now, every lookup of a flag in the ConfigServerFlagSource would 1. try to read 2 flag files under /etc/vespa/flags, causing exceptions because they are typically not set, and 2. then read flag from ZooKeeper through ZooKeeperFlagSource Optimization was deliberately held off until later (now). This PR fixes (1). Changes the ConfigServerFlagSource to: 1'. Read VESPA_HOME/var/vespa/flag.db once during component graph construction. As before, if a flag is defined on file, the flag is not looked up in ZK, which may be useful in emergencies. 2. As before. Also, removes the last usages of FileFlagSource and its reading of flags in /etc/vespa/flags.
* Set 7-SNAPSHOT for new module, and remove redundant 'name'.gjoranv2019-01-211-3/+2
|
* Inject exported FlagDb instead of non-exported FlagsDbImplHåkon Hallingstad2019-01-102-4/+4
|
* Include flag id in flag data and other review fixesHåkon Hallingstad2019-01-021-3/+2
|
* Configserver flags REST APIHåkon Hallingstad2018-12-3010-0/+293
Adds a new ZooKeeper backed flag source. It is defined in a new module configserver-flags to allow as many as possible config server modules to depend on it by minimizing dependencies. The content of the ZK backed flag source can be viewed and modified through REST API on the config server/controller. The data stored per flag looks like { "rules": [ { "conditions": [ { "type": "whitelist", "dimension": "hostname", "values": ["host1"] } ], "value": true } ] } typical for enabling a feature flag on host1. 2 types of conditions are so far supported: whitelist and blacklist. All the conditions must match in order for the value to apply. If the value is null (or absent), the default value will be used. At the time the flag's value is retrieved, it is resolved against the conditions with the current zone, hostname, and/or application. The same data structure is used for FileFlagSource for files in /etc/vespa/flags with the ".2" extension. The FlagSource component injected in the config server is changed to: 1. Return the flag value if specified in /etc/vespa/flags, or otherwise 2. return flag value from ZooKeeper (same as REST API) The current flags (module) is also changed: - All flags must be defined in com.yahoo.vespa.flags.Flags. This allows the ZK backed flag source additional sanity checking when modifying flags. - If it makes sense to have different flag value depending on e.g. the application, then at some point before the value is retrieved, one has to bind the flag to that application (using with() to set up the fetch vector). Future changes would be to 0. make a merged FlagSource in host admin, 1. add support for viewing and modifying feature flags in dashboard, 2. in hv tool.