| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Makes new FlagRepository config server client to retrieve all flag data.
- Makes WireFlagDataList to be used for creating the HTTP response in the
config server, and parse the HTTP response in host admin.
- Fixes problem with URL generation for controller: when port is not present
in the request, remove ":-1" port specification in the url.
- Makes a new FlagDirectory class, responsible for reading flags from
/opt/vespa/var/vespa/flags (in FlagData JSON format), and reversely,
sync that directory to exactly match a set of FlagData.
- No longer have 'State state()' as a default method in interface.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DuperModel is (will be) responsible for both active tenant applications
(through SuperModel) and infrastructure applications. This PR is one step
in that direction:
- All infrastructure applications (config, confighost, controller,
controllerhost, and proxyhost) are owned and managed by DuperModel.
- The InfrastructureProvisioner retrieves all possible infra apps from the
DuperModel (through a reduced API), and "activates" each of them if
target is set and there are any nodes etc.
- The InfrastructureProvisioner then notifies the DuperModel which
apps have been activated, and with which hosts.
- The DuperModel can then build delegate artificially create ApplicationInfo,
which gets translated into the application model, and finally the service
model.
- The resulting service model has NOT_CHECKED for each hostadmin service
instance. This is sufficient for goal 1 of this sprint.
- The config server application currently has health, so that's kept as-is
for now.
- Feature flags have been tried and works and allows 1. to disable adding the
infra apps in the DuperModel, and 2. to enable the infra configserver
instead of the currently created configserver w/health.
|
|
|
FileFlagSource reads flags from files in /etc/vespa/flags and is a component
that can be injected in host admin, config server, etc. A flag named foo
corresponds to filename foo.
In general a FlagSource manages:
- Feature flags: A feature is either set (true/enabled) or otherwise false.
Touching a file foo means the feature flag foo is set (true).
- Value flags: Either a String or empty if not set. The String corresponds to
the file content.
The plan is to make the config server another source of flags. A unified
FlagSource can merge the two sources with some priority and used in e.g. parts
of node-admin. In other parts one would only have access to the file source.
Defines various flag facades:
- FeatureFlag: Used to test whether a feature has been enabled or not.
- IntFlag
- JacksonFlag: Deserializes JSON to Jackson class, or return default if unset.
- LongFlag
- OptionalJacksonFlag: Deserializes JSON to Jackson class, or empty if unset.
- OptionalStringFlag
- StringFlag
This is part of removing some of the last Chef recipes. Some minor tweaks have
been necessary as part of this and are included in this PR (test whether a
systemd service exists, task-friendly file deletion, allow capitalized letters
in YUM package name).
|
