| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
- Update dependency org.apache.opennlp:opennlp-tools to v1.9.4
- Use dependency-versions
- Bring jimfs up to date.
- Bring some more libraries up-2-date.
- Reduce usage of assertj
|
|
|
|
| |
Replace use of Hamcrest with junit5/assertj assertions
|
| |
|
| |
|
| |
|
|
|
|
| |
These types are often accidentally imported, and the JDK8 replacement is typically a one-liner.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
vespa-engine/hakonhall/support-flag-conditions-based-on-vespa-release
Support flag conditions based on Vespa release
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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".
|
|/ |
|
| |
|
| |
|
|
|
|
| |
This reverts commit b81b21546cdff92d360cbdf7dda27e6ed7bc7170.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
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.
|