| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|
|
|
| |
Also change scope of 'annotations' to provided.
|
| |
|
|\
| |
| |
| |
| | |
vespa-engine/jvenstad/fix-config-model-inconsitency
Jvenstad/fix config model inconsitency
|
| | |
|
|\ \
| |/
|/| |
Nonfunctional changes only
|
| | |
|
|/ |
|
| |
|
| |
|
|\
| |
| | |
Add support for rotations element
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Makes a new REST API /orchestrator/v1/health/<ApplicationId> that shows the
list of services that are monitored for health. This information is currently a
bit difficult to infer from
/orchestrator/v1/instances/<ApplicationInstanceReference> since it is the
combined view of health and Slobrok. There are already APIs for Slobrok.
Example content:
$ curl -s localhost:19071/orchestrator/v1/health/hosted-vespa:zone-config-serve\
rs:default|jq .
{
"services": [
{
"clusterId": "zone-config-servers",
"serviceType": "configserver",
"configId": "zone-config-servers/cfg6",
"status": {
"serviceStatus": "UP",
"lastChecked": 1548939111.708718,
"since": 1548939051.686223,
"endpoint": "http://cfg4.prod.cd-us-central-1.vespahosted.ne1.yahoo.com:19071/state/v1/health"
}
},
...
]
}
This view is slightly different from the application model view, just because
that's exactly how the health monitoring is structured (individual monitors
against endpoints).
The "endpoint" information will also be added to /instances if the status comes
from health and not Slobrok.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The service monitor uses /state/v1/health to monitor config servers and the
host admins (but not yet tenant host admins).
This commit adds some metadata about the status of a service:
- The time the status was last checked
- The time the status changed to the current
This can be used to e.g. make more intelligent decisions in the Orchestrator,
e.g. only allowing a service to suspend if it has been DOWN longer than X
seconds (to avoid spurious DOWN to break redundancy and uptime guarantees).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
dupermodel-use-configserverconfig, proxyhost-uses-real-orchestrator, and confighost-uses-real-orchestrator flags
|
|
|
|
|
|
|
|
|
|
| |
This reintroduces the non-generic flag classes:
- a value() returns the primitive type for flags wrapping a primitive type
- easier to use in testing
- Serializer is moved to internals of typed class
Defines the flag backed by boolean BooleanFlag instead of FeatureFlag since not
all boolean flags are necessarily guarding a feature.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
try 2
|
|
|
|
|
| |
This is necessary to avoid using too many threads when monitoring the
host-admin on the tenant Docker hosts.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Notify monitors of infrastructure application activation. Live-flipping the
content of the duper model is non-trivial and has been removed.
- Split out DuperModel as a simple mutable and thread-unsafe container of the
applications in the duper model, that also handles calls listeners on
changes. The previous DuperModel has been renamed to DuperModelManager.
- Replace SuperModelProvider::snapshot method (fast but difficult to use
right) with registerListener.
- Shorten the fully qualified package names by 1-2 levels for mosts classes.
Next steps:
- Make HA query the real orchestrator
- Start experimenting with health monitoring of infra apps
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Need to keep old constructor and make a temporary one with an ignored
argument to make this work (since arguments will be equal due to type erasure)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|