This is follow-up of 76d414e58d and fixes
the incomplete construction of an exception message. This also removes
the translation according to the other messages.
Change-Id: Ie2ed619b06d9d6340eb81fc1fac4dbd21702de19
This adds functional tests with redis and redis sentinel, to ensure
the current implementation can initialize clients properly.
Change-Id: I6318f6ad00d5b0ee3db1be5e8671a4c346b9daff
This introduces support for Redis Sentinel backend. Users can now
use Redis Sentinel backend instead of Redis backend by configurations
like the example below.
[cache]
enabled = True
backend = dogpile.cache.redis_sentinel
redis_password = <password>
redis_sentinels = 192.0.2.1:26379,192.0.2.2:26379,192.0.2.3:26379
If tls_enabled option is set to True then all the tls settings are
applied for connections to Redis as well as connections to Redis
Sentinel.
Change-Id: Ic3b84fe6810e08337a884c68625ccfed11665269
This introduces a few new redis_* options to simplify the settings
required to use the redis backend. The main aim of this change is to
replace the requirement to inject url by backend_argument.
[cache]
backend=dogpile.cache.redis
redis_server=127.0.0.1:6379
redis_username=default
redis_password=a_big_secret
redis_socket_timeout=1.0
Closes-Bug: #2052351
Change-Id: Id72878f9cddaa99146eab5fb4ee76c8e6a633809
Because these are not intentional default. This also adds a validation
logic to catch the case where SASL is requested but username or
password is not given.
Change-Id: Ia98bfc5f9a42c13acfdb2192bb1fa11773f6ccf8
This adds support for configuring certificate/key files used for TLS
connection with Redis using the existing tls_* options.
example)
[cache]
backend=dogpile.cache.backend.redis
backend_arguments=url:rediss://:a_big_secret@localhost:2679
tls_enabled=True
tls_cafile = /etc/pki/tls/certs/ca-bundle.crt
Change-Id: I2ab38b8c88274cb4908791eea8212a79e3d524a2
The tls_enabled option works properly only for the following backends.
- oslo_cache.memcache_pool
- dogpile.cache.bmemcache
- dogpile.cache.pymemcache
Currently the tls options are all ignored in case a different backend
is used, but this does not allow users to notice that TLS is not
enabled contrary to their expectations.
This introduces the validation to ensure an appropriate backend is used
when tls is enabled.
NOTE:
The oslo_cache.memcache_pool bakcend supports tls_enabled only when
sasl_enabled is true, which can be fixed separately.
Change-Id: Ib967bf8cb21fb97fff94a6d6cb5983374e4798eb
The ConnectionPool currently opens sockets, but never closes them. As a
result, any client using oslo.cache memcache pool leaves sockets in a
CLOSE_WAIT state, with the source port not being re-usable.
In our production system, were we have A LOT of activity, this creates
a storm of non-reusable ports: all source ports are in use, making the
node unuseable for other things.
This patch adds a __del__ destructor closing inactive connections,
fixing the issue.
Closes-Bug: #2043121
Change-Id: I09d632346c76d1aff7c534f0d040162d1985f548
This feature is supposed to check for alive servers more frequently when they are all down.
Unfortunately, it does more harm than good.
I have made several tests with keystone and here is what I saw when all memcached backends were unreachable:
1. memcached services were stopped but their hosts were alive(keystone received 'connection refused') - everything was working fine
2. memcached backends and their hosts were completely unreachable(keystone received 'no route to host') - the whole keystone stopped responding
Keystone should be working fine even if all memcached backends are down. In this case it wasn't.
After I deleted the discussed functionality from the code, keystone was finally able to handle failure of all memcached backends.
I believe this issue is not only limited to keystone, I just used it as an example.
Change-Id: Ib3e3028d967c166d21b60cf4cb7c9d5dc82a8fe7
This allows oslo_cache.memcache_pool to be used without the
python-binary-memcached package being installed, as it is
only required if sasl_enabled is set to True.
Closes-Bug: #1991250
Change-Id: I7e6cc83864be68e946d86b1f4b44847b95ea8b05
Add the SASL protocol for memcached, to improve the security of authority.
SASL(Simple Authentication and Security Layer): is a memchanism used to
extend the verification ability of C/S mode. SASL is only the
authentication process, which integrates the application layer and the
system authentication mechanism. However, the current memcached hasn't
any authenticaction mechanism to protect the user's data cached in
memcached server.
Depends-On: 7828bed0febabfa11a0a8f6960f4c7cc8acec841
Implements: blueprint enable-sasl-protocol
Change-Id: I40b9f4eac518f34a3dfb710b5c4ab3a76da7c00c
Current description says the option is used by only two backends but
in fact this option is used by all backends dependent on memcached.
Note that the inet6 prefix is specific to the python-memcached library
and should not be used if a backend dependent on different libraries
(eg. pymemcache) is used. This change describes that point, too.
Change-Id: I3c967841c94b9409096c9b9591f9fb162db7a1ac
The TLS features were introduced to be consummed by the
dogpile.cache.pymemcache backend [1][2], however, the tests
modified by this commit do not instantiate the
dogpile.cache.pymemcache backend but rather the oslo_cache.dict
backend which won't consumme the TLS arguments.
These tests do not really reflects the thing they were made for.
The oslo.cache.dict backend do not expect TLS options [3] whereas
the dogpile.cache.memcached module (and backend) expect TLS
context [4].
This patch propose to switch to the right backend.
[1] 996036acd7
[2] a2e25bc743
[3] https://opendev.org/openstack/oslo.cache/src/branch/master/oslo_cache/backends/dictionary.py
[4] https://github.com/sqlalchemy/dogpile.cache/search?q=tls_context
Change-Id: Ia28ce314044f5790372e6a75dd5d6ae0407bec74
This patch expose a couple of pymemcache's HashClient public
params that can be useful to configure HA and failover for
clustered memcached servers.
These options can be used in addition of the previously added
retrying mechanismes.
This patch rely on recent changes [1] of dogpile.cache that
aim to expose these options too.
[1] https://gerrit.sqlalchemy.org/c/sqlalchemy/dogpile.cache/+/3528
Change-Id: I24fc853db4237c08b87871ddff1b3ced27cc7fce
This patch specifies a set of options required to setup a retry
context. The context built from those options can later on be
passed to any of the oslo.cache backends that supports pymemcache's
retry mechanisms.
This patch also sets up the retry mechanisms context based on
the configuration option passed via oslo.config and adds it
as an argument to be passed to the selected oslo.cache backend.
Change-Id: I6c1a4872d7cf19e3a55c676ef4b4200f18e08f2c
If module etcd3gw is not required for used backend,
then no need to have it installed and imported.
Otherwise we always have ugly log error:
Could not load 'oslo_cache.etcd3gw': No module named 'etcd3gw': ModuleNotFoundError: No module named 'etcd3gw
Closes-Bug: 1928318
Change-Id: Icbe6dc3e93b4d2fec1ceb88366027294e49d7032
This backend lack of documentation and technical details.
Many people think that this the memcache pool backend is going to be HA
and think that values are replicated.
The added details try to give more details about how this backend works
under the hood.
Change-Id: If9056168aacca85ae072172ec203319af42962d8
These were moved in Python 3.3 and the aliases will be dropped in 3.10.
Change-Id: I98985aef57ebe024e97e444ffd0d43ee2b88b332
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Param flush_on_reconnect is very risky to use on production
deployments. It can cause exponential raising of connections
to memcached servers. Moreover this option makes sense only
in keystone's oslo.cache config.
This patch is moving flush_on_reconnect from code to oslo.cache
config block to be configurable.
Co-Authored-By: Hervé Beraud <hberaud@redhat.com>
Change-Id: I8e6826bfb2c85e7ceed03e1667bd6a06b3dff469
Closes-Bug: #1888394
Introducing the needed changes to functional tests to run
them against the memcache_pool backend.
These changes introduced a new zuul job related to memcache
to isolate this part during CI and get clear outputs.
Change-Id: Ib84b3db83e8c50c7929874c63177c94f459a1a2c
Co-authored-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
This patch sets up the TLS context object based on the configuration
options passed via oslo.config and adds it as an argument to be passed
to the selected oslo.cache backend.
Change-Id: I825b5c37b2c6a96b459e6cc162ba5d1254091f0f
Signed-off-by: Moisés Guimarães de Medeiros <moguimar@redhat.com>
This patch specifies a set of options required to build a TLS context.
The context built from those options can later on be passed to any of
the oslo.cache backends that supports TLS connections.
Change-Id: Ief83bd490826d90eb5239ebb71394aa516f033b7
Signed-off-by: Moisés Guimarães de Medeiros <moguimar@redhat.com>
Refactoring the functional tests by using the standard usages [1]
and best pratices available in the oslo.cache documentation.
The main goal of these changes is to help us to
test oslo.cache in the way that quite close to real life usages.
To test new backend now we just need to create the associated test class
dedicated to pass backend's config fixture.
These changes allow to test a new backend by:
- passing the right config to backend by using dedicated config fixture;
- adding the zuul job dedicated to manage functional tests
against etcd backend;
- adding the right server backend to bindep.
[1] https://docs.openstack.org/oslo.cache/latest/user/usage.html
Change-Id: Iaf196d2d93225afa54e324fb830761049059926e
Takashi Kajinami