| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
Since version 0 states were ambiguous with the sentinel values for
"not written to ZK/not tagged as official", this could be mis-interpreted.
|
| |
|
| |
|
|\
| |
| |
| |
| | |
vespa-engine/vekterli/inhibit-db-connectivity-until-slobrok-is-ready
Inhibit ZooKeeper connections until our local Slobrok mirror is ready.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Otherwise, if there are transient Slobrok issues during CC startup and
we end up winning the election, we risk publishing a cluster state where
the entire cluster appears down (since we do not have any knowledge of
Slobrok node mapping state). This will adversely affect availability for
all the obvious reasons.
|
|\ \
| | |
| | |
| | |
| | | |
vespa-engine/revert-16934-revert-16932-balder/move-metrics-from-partition-to-node-level
Revert "Revert "GC unused DiskState and add the partition metrics to node level.""
|
| | | |
|
| | |
| | |
| | |
| | | |
level.""
|
|/ / |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| | |
vespa-engine/vekterli/dont-store-full-bundle-objects-in-state-history
Don't store full bundle objects in state history
|
| | |
|
| |
| |
| |
| |
| | |
Always print regardless of leader eligibility state; config is not
predicated on this.
|
| |
| |
| |
| |
| | |
Much less immediately interesting than the actual cluster node information.
Move it just above the general event log instead.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Bundles have a lot of sub-objects per state, so in systems with a
high amount of node entries, this adds unnecessary pressure on the
heap. Instead, store the string representations of the bundle and
the string representation of the diff to the previous state version
(if any). This is also inherently faster than computing the diffs
on-demand on every status page render.
Also remove mutable `official` field from `ClusterState`. Not worth
violating immutability of an object just to get some prettier (but
with high likelihood actually more confusing) status page rendering.
|
|/ |
|
|\
| |
| | |
GC unused DiskState
|
| | |
|
| | |
|
|\ \
| |/
|/| |
Add shared ZK client config generator for zkfacade and vespa-zkcli [run-systemtest]
|
| |
| |
| |
| | |
Use ZKClientConfig builder from Curator and ZooKeeperDatabase
|
| | |
|
| | |
|
| | |
|
|/
|
|
| |
initProgress and capacity. Also gc unused 'reliability' member.
|
|
|
|
| |
These types are often accidentally imported, and the JDK8 replacement is typically a one-liner.
|
|\
| |
| |
| |
| | |
vespa-engine/vekterli/immediately-exit-cc-if-node-index-changed-live
Immediately exit cluster controller if node index config is changed live
|
| |
| |
| |
| |
| | |
We do not support live reconfigs of CC index, so swiftly exit if we
detect this, allowing the config sentinel to restart the service.
|
|\ \
| |/
|/| |
Bjorncs/upgrade zk client [run-systemtest]
|
| |
| |
| |
| | |
Ensure extra required ZK dependencies are present on test classpath
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds the following safeguards/improvements:
- Do not clear pending (non-persisted) writes over a `connect()` edge.
Avoids having the controller eternally wait for a doomed pending
write to be completed when it has no other events that can trigger
a new write.
- Trigger `lostDatabaseConnection()` whenever ZK is reconfigured to
ensure we reload the newest state before trying to compute/publish
any new states.
- Explicitly drop leadership in `lostDatabaseConnection()` to immediately
prevent controller from trying any funny leader-related business
since it no longer can depend on ZK watches triggering.
- When falling back to default state/cluster bundle, ensure that any
subsequent dependent znode write is predicated on the pre-existing
znode version being 0, i.e. did not previously exist.
|
| |
|
|\
| |
| |
| |
| | |
vespa-engine/geirst/cluster-controller-resouce-usage-limits-metrics
Expose resource usage metrics for disk and memory limits for feed blo…
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
| |
Available nodes here mean nodes that are reported as Up/Initializing
and where the wanted state is Up/Retired.
|
|
|
|
| |
indirectly
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ZooKeeper
This avoids a subtle edge case where the underlying ZK integration code
may fail silently a write, leaving the core controller logic to think that
it had actually durably persisted a particular state version.
In case of reelections racing with broadcasts, it would be possible for
leader-edge readbacks from ZK to retrieve a _lower_ version than one
that had already been published. This would cause the cluster controller
to get very confused about which cluster states nodes had already observed.
If a newly produced state version overlapped with a previously broadcast
state, the controller would not push the updated state to the nodes, as it
would (with good reason) assume the node had already observed it, seeing
that it had already ACKed the particular version number.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|