| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
vespa-engine/jonmv/unify-hostname-classes"
This reverts commit 87e5b33c003d07ca585d73e0166857fe22b4c16f, reversing
changes made to 80b96d32550ae0df59572a58cd62f507e8068c2c.
|
|
|
|
|
|
|
| |
vespa-engine/jonmv/unify-hostname-classes"
This reverts commit 8aa4c83df5ce7843c040afa41706fcc7c3afd030, reversing
changes made to f95ad44fae879da9db19f73eabe62c53baeb0c36.
|
| |
|
|
|
|
|
|
|
| |
vespa-engine/revert-22049-jonmv/unify-hostname-classes"
This reverts commit 4ffc54339186574491a32b3166223c3fc50ba8fe, reversing
changes made to db9e570a36decb24e6cb13f44bd0ff444ab762e3.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
activate
I have seen a few "Host not found" messages in CD the last 2 days, and found
this bug in how the duper model indices are maintained on application
activation.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order for Orchestrator to remove application data from ZooKeeper, it must
know which applications do NOT exist. Since the duper model starts with 0
applications, always, the only way of knowing what applications do not exist is
for the bootstrap code to notify the super model/duper model when bootstrap is
complete. There are 2 sources of applications that must signal completeness:
- The super model, once all applications have been redeployed in
ConfigServerBootstrap.
- The infrastructure application, in the InfrastructureProvisioner the first
time it runs.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tenant hosts are allocated to the zone (routing) app in the node-admin
cluster. These hosts also have various other services like logd,
config-sentinel, etc that do not run.
The metricsproxy container is a new service that will be added to all hosts,
and that will be Slobrok monitored. Except, it will not run on tenant hosts as
above. To avoid having metrics cluster spanning the whole of the zone app, and
have them DOWN on all tenant hosts, we'll filter those service away from the
model when generating the ApplicationInstance of the service model.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This is necessary to avoid using too many threads when monitoring the
host-admin on the tenant Docker hosts.
|