| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
