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
Getting the following error for an invalid callback in extension
registration is not helpful:
Fatal error: Uncaught exception 'InvalidArgumentException' with message
'Invalid callback provided' in /includes/config/ConfigFactory.php:108
Changed message to
Invalid callback '$1' provided
Added a test case for the instanceof part of the if
Change-Id: I425e2607b651c666336289c2c0d93730bb6312ed
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
NOTE: This also changes the semantics of MediaWikiServices::resetGlobalInstance
to only reset services instances, not service wiring. The wiring will be copied
from the old global MediaWikiServices instance to the new one.
Bug: T132707
Change-Id: Ie2ca3ff99aa74fffa9eb6c8faccab857dc0874f7
(This is part of I6ec374ac9 wich was a re-submit of Ie98bf5af5
which got reverted by Ide7ab563)
This change provides a mechanism to reset global service instances
in an orderly manner. There are three use cases for this:
* the installation process
* integration tests (which most of the existing phpunit tests are)
In contrast to I6ec374ac9, this change does not cause singeltons
of legacy services to be reset. It is assumed that legacy services
use global state to access services and configuration, so any
change in confuguration would affect them immediately.
NOTE: the original I6ec374ac9 would cause session information to
get lost if the user session was creatsed before initialization
was complete. This was apparently triggered by the MobileFrontend
extension under some circumstances. Check with Addshore and Catrope.
Change-Id: Ie06782ffb96e675c0aa55dc26fb8f22037e8517d
This change provides a mechanism to reset global service instances
in an orderly manner. There are three use cases for this:
* the installation process
* forking processes
* integration tests (which must of the existing phpunit tests are)
Depends-On: I5d638ad415fc3840186a0beaa09ac02ea688539b
Change-Id: Ie98bf5af59208f186dba59a9e971c72ea0b63e69
The service locator, MediaWikiServices, is intended to facilitate
"manual" dependency injection in static entry points.
See also the Dependency Injection RFC T384 and Service Locator
RFC T124792 for details.
The following key points were implemented according the
discussion surrounding these RFCs:
* a configurable DI container that allows extensions to add and replace services.
* no auto-wiring, since it's prone to add confusion in large and complex applications.
* no 3rd party framework, since they typically do too much.
The following services in MediaWiki core are made accessible via the service locator
mechanism to showcase the bootstrapping mechanism:
* ConfigFactory and MainConfig
* SiteLookup and SiteStore
However, the implementation of these services was not yet converted to using proper DI
throughout the code.
Bug: T124792
Change-Id: I3c25c0ac17300d3dd13e1cf5100558a605eee15f
This change adds MultiConfig and HashConfig classes,
but does not actually use them anywhere. In a future
change, we can convert DefaultSettings.php into
a HashConfig instance and use MultiConfig as the
'main' config instance.
Bug: 69418
Change-Id: I0ef2fbb86d5c27602d70240219ee08be31e2d09b
Introduces a new interface for Config types
that are mutable. Not all Config instances
should be mutable, like MultiConfig.
Change-Id: I56e193cbbf72b7afdf551f60ea635fc347e14b3e
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I7b65fe04db431342cc58b469dc48f41a50c4e891
- Removed spaces after not operator (!)
- Removed spaces inside array index
- use tab as indent instead of spaces
- Add newline at end of file
- Removed spaces after casts
Change-Id: I9ba17c4385fcb43d38998d45f89cf42952bc791b
- use tab as indent instead of spaces
- Added space after closures "function"
- Added spaces around string_concat
- Added newline inside empty blocks
- Removed four spaces after comma
Change-Id: I4425b0c6a69b36f40acfea6511b8950cf09ce2b2
Follow up to I13baec0b6 ("Config: Add Config and GlobalConfig classes"):
Config:
* Rather than returning Status objects, Config::set will now throw an exception
if an error is encountered
* Config::factory was moved into it's own ConfigFactory class.
* Since there are no more functions in it, Config was turned into an interface.
GlobalConfig:
* Remove $prefix args from Config::set and ::get. The idea of having an
abstract Config class is to abstract some notion of configuration data from
the particular way in which it is currently implemented (global variables).
So the abstract base class has no business dealing with variable name
prefixes.
** Instead GlobalVarConfig's implementations of get and set call getWithPrefix
and setWithPrefix internally, which are now protected
* Rename GlobalConfig to GlobalVarConfig, which makes it clearer that it isn't
referring to the scope of the configuration value, but to the scope of the
variable name which provides it.
ConfigFactory:
* ConfigFactory is where Config objects are registered, and later constructed.
* Config objects are registered with a given name, and a callback factory function.
This allows for implementations to construct the object with the parameters they want,
and avoids the overhead of needing an entire class.
** The name 'main' is the default object returned by RequestContext::getConfig(),
and is intended to be used by core.
* This is a singleton class, the main instance can be obtained with:
ConfigFactory::getDefaultInstance()
In addition to the above:
* $wgConfigClass was removed, and $wgConfigRegistry was introduced, which
stores a name => callback. The name is to be what the Config instance is
registered with, and the callback should return an implementation of Config.
* Tests were written for the new ConfigFactory, and GlobalVarConfig's tests
were improved.
Co-Authored-By: Ori Livneh <ori@wikimedia.org>
Co-Authored-By: Chad Horohoe <chadh@wikimedia.org>
Co-Authored-By: Mattflaschen <mflaschen@wikimedia.org>
Co-Authored-By: Parent5446 <tylerromeo@gmail.com>
Co-Authored-By: Reedy <reedy@wikimedia.org>
Co-Authored-By: Daniel Kinzler <daniel.kinzler@wikimedia.de>
Change-Id: I5a5857fcfa07598ba4ce9ae5bbb4ce54a567d31e
Allows configuration options to be fetched from context.
Only one implementation, GlobalConfig, is provided, which
simply returns $GLOBALS[$name]. There can be more classes
in the future, possibly a database-based one. For convinience
the "wg" prefix is automatically added.
Ironically, this adds the $wgConfigClass global variable
which is used to determine which implementation of Config
to use by default.
The ContextSource getConfig and setConfig methods were introduced
in I23194d1ba (1.23), but have no uses in Gerrit, so they can safely
be re-purposed.
Change-Id: I13baec0b6d4ea7badf20b9c5f9b40846348838e4
