While not immediately useful for fecthing the configuration, this is
basically a version information about the configuration currently loaded
from etcd. A typical use-case for this index is monitoring the freshness
of the configuration across a cluster of servers.
Bug: T182597
Change-Id: I58189d36a5b620fb44323bae87257f085a64386e
Deprecate the unnamespaced version and move it to includes/compat.
Bug: T147167
Depends-On: I39c805bfb98b32f32f3d0dc1eee9e823afe1c21a
Change-Id: I3780c7adf51683f3f7adb35a88f9a25a0a2e2530
Allowing slashes in config key names allows us to trivially support the
proposed hierarchical structure with a single EtcdConfig object, by
fetching values with the relevant prefixes on startup.
Bug: T156924
Change-Id: Ica0914e61baba9c0462481925be15d79b66dc342
* Log HTTP debug lines to the "http" channel instead of wfDebug()
* Add the ability to do debug logging to MultiHttpClient
* Add a static method Http::createMultiClient() which provides a
MultiHttpClient configured similarly to the way individual requests
are configured, respecting the wiki's $wgHTTPTimeout and writing debug
logs.
* In EtcdConfig, pass the logger instance through to the MultiHttpClient
backend.
Change-Id: Ic5bdcb0cae95d7b3715ab5261758be082751c3ff
removeServer() returns the modified array, rather than passing by
reference, so you have to use the return value to avoid an infinite loop
when a server is down.
Tune the timeout downwards, to 2s. With three servers in the SRV pool,
if they are all unreachable, this will mean an overall request time of
6s, which is conveniently less than the APC lock time and the cache
TTL (9-10s). If the APC lock time is significantly shorter than the time
it takes to do the HTTP requests, then additional threads join in
waiting for the server. This could have stability consequences if the
maximum HHVM worker count is exceeded.
Change-Id: I3176aa41b8833c0ba0b668859e59911cd4392250
* Use makeGlobalKey instead of makeKey to avoid fragmenting
the cache by the wiki-specific key space.
* Add "EtcdConfig" and $this->host to the cache key to make
it less generic and less likely to conflict with unrelated values
in case multiple instances exist somewhere in the MediaWiki run
time (or during testing/debugging).
Adding $this->host should be fine given we were already including
the directory within that host. Although I do recognise that we
may want to encourage slow cache rollover instead of instance
cache rollover in case the host name needs to changed. Perhaps
we should have some kind of canonical name for the instance for
the purpose of caching so that directory or host can be changed
without changing the cache key, and thus have cache roll over
normally over the course of 10 seconds, instead of immediately.
On the other hand, deployment will likely already spread things
out a little bit.
In addition, due to the cache being kept indefinitely this means
the old key will stay indefinitely. Perhaps not an issue given
it's just one key, which will clear on restart eventually?
Bug: T156924
Change-Id: I622e6618f2d4171626e4b272bcb11a97a85cb770
If the cache is stale and the lock keeps being acquired, but the re-fetch
fails each time, the method would end up failing after the timeout was
reached. Instead, use the stale cache if available.
Change-Id: Ieafc9de17e6c60d8eea7b937923b4ad548e99be8
