Eventlet hasn't actually been a direct os-brick
requirement since Ussuri Change-Id I9684db.
Leave it in test-reqs since we have a unit test
that mocks it. (Used via oslo.service.)
Change-Id: I9a72d41c9bb70ad568e5cd9218730b93b226b202
OS-Brick uses file locks to ensure single access to critital sections,
and uses the oslo concurrency "lock_path" configuration option to
determine where to create these locks.
This is fine when each host has a single service using os-brick, which
is the case of Compute nodes and Controller nodes where Glance is not
using Cinder as its backend.
The problem happens when we have an HCI deployment where Cinder and Nova
are collocated on the same host or when Glance uses Cinder as its
backend and is running on the same host. In those scenarios os-brick
will create file locks in different paths for each service, which is not
the intended behavior.
A possible solutions is to set the "lock_path" of all the services to
the same location, which is not great, not only because we'll have all
nova, cinder, glance, and os-brick locks mixed in a single location
(service prefixes help a bit here), but also because then Cinder will
have permissions on the Nova and Glance locks, which doesn't seem right.
This patch introduces a new mechanism in os-brick to have its own
"lock_path" configuration option in the "os_brick" group. It defaults
to the current behavior if not explicitly defined, so it will use olso
concurrency's "lock_path".
To do this the patch introduces the oslo.config dependency and adds a
new "setup" method that sets the default of the os_brick "lock_path".
This new "setup" method is required because the order in which
configuration options for the different namespaces are imported cannot
be guaranteed, so the setup must be called *after* the service has
already imported all (or at least the ones os-brick cares about)
configuration option namespaces.
In other words, when os-brick files are loaded the value for oslo
concurrency's "lock_path" is not yet known, so it cannot be used as a
default, and the oslo_config substitution feature does not support
values from other namespaces, so we cannot default the "lock_path" from
the os_brick namespace to the value in "oslo_concurrency".
Since the value that is going to be used as the "lock_path" is not known
until the "setup" method is called, we cannot use the standard
"synchronized" method from "oslo_concurrency.lock_utils" and we need to
use our own.
In the current os-brick code, each connector that requires a lock is
importing and creating its own "synchronized" instance, but this patch
changes this behavior and creates a single instance, just like Cinder
does.
This feature requires changes in multiple projects -os-brick, cinder,
nova, glance, glance_store, devstack- to be fully supported, but this is
the base of all this effort.
Change-Id: Ic52338278eb5bb3d90ce582fe6b23f37eb5568c4
Had to raise min oslo.vmware to 3.10.0 or can't run on py3.9.
So while I was in there, looked at the other requirements.
Updated most of the openstack libraries, left the third party
ones alone (see notes below).
requirements
------------
pbr>=5.5.1 -> >=5.8.0 in u-c for 3 months
oslo.concurrency>=4.4.0 -> >=4.5.0 in u-c for 4 months
oslo.context>=3.1.1 -> >=3.4.0 in u-c for 4 months
oslo.log>=4.4.0 -> >=4.6.1 in u-c for 4 months
oslo.i18n>=5.0.1 -> >=5.1.0 in u-c for 5 months
oslo.privsep>=2.4.0 -> >=2.6.2 in u-c for 6 months
oslo.serialization>=4.1.0 -> >=4.2.0 in u-c for 6 months
oslo.service>=2.5.0 -> >=2.8.0 in u-c for 1 month
oslo.utils>=4.8.0 -> >=4.12.1 in u-c for 3 weeks
os-win>=5.4.0 -> >=5.5.0 in u-c for 6 months
eventlet >=0.30.1 -> >=0.30.1,!=0.32.0
- 0.33.0 has been in u-c for about 3 months
- 0.32.0 breaks ironic
- no reason to raise the min right now
requests >=2.25.1 -> unchanged
- 2.27.1 has been in u-c for 1 month
- 2.26.0 drops py3.5 support
- no reason to raise the min right now
test requirements
-----------------
castellan>=3.7.0 -> >=3.10.0 in u-c for 4 months
oslo.vmware>=3.8.0 -> >=3.10.0 in u-c for 4 months
oslotest>=4.4.1 -> >=4.5.0 in u-c for 5 months
stestr>=3.1.0 -> >=3.2.1 in u-c for 4 months
coverage>=5.5 -> unchanged
- 6.3: stopped supporting py3.6; u-c caps py3.6 at 6.2
- current is 6.3.1 which is also the u-c cap for py3.8
- no reason to raise the min right now
Change-Id: Iec14833ab502b4bb342938d5477c57742068f1b8
Raise the minimum versions in the various requirements files to
reflect what we're actually testing with right now.
Change-Id: Ie7dcc859e1291bd1d50b1ae516be38d8732de836
The latest pip version has a stricter dependency resolver,
which broke the "lower-constraints" job for quite a few openstack
projects, including os-brick and cinder.
This change alings the os-brick dependency version constraints with
the ones used by Cinder, thus fixing the lower constraints job.
Change-Id: I4a6ac7ec0974372dc6f1585a797c7023c2fd8d78
md5 is not an approved algorithm in FIPS mode, and trying to
instantiate a hashlib.md5() will fail when the system is running in
FIPS mode.
md5 is allowed when in a non-security context. There is a plan to
add a keyword parameter (usedforsecurity) to hashlib.md5() to annotate
whether or not the instance is being used in a security context.
In the case where it is not, the instantiation of md5 will be allowed.
See https://bugs.python.org/issue9216 for more details.
Some downstream python versions already support this parameter. To
support these versions, a new encapsulation of md5() has been added to
oslo_utils. See https://review.opendev.org/#/c/750031/
This patch is to replace the instances of hashlib.md5() with this new
encapsulation, adding an annotation indicating whether the usage is
a security context or not.
In this case, we use md5 in a single case, when creating an identifier
for a mount point.
Change-Id: I08226895818185337425ebffc2464db05f3969c9
Depends-On: https://review.opendev.org/#/c/760160
This updates lower constraints to versions that will work with py38 so
that when we move to running on focal nodes, which has py38 as its
default py3 runtime, the lower-constraints job will continue to pass.
It also cleans out some secondary requirements that are no longer needed
due to our direct dependencies being updated.
Linters are removed that are kept in the global requirements blacklist
as those are not version tracked and are not relevant for our
lower-constraints unit test runs.
Change-Id: Ic9b2b425a4910809a21bd250a4d9730a30fadf22
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This switching our retry mechanism over from the retrying library to the
tenacity library. Retrying has been active for a few years now and
appears to be no longer maintained.
This has a small behavior change in that before we were applying an
exponential backoff to the first time a retry was needed. This no longer
happens, but retries will exponentially back off with each retry.
Also cleaned up some minor nits with unit test assert argument order.
Closes-bug: #1635397
Change-Id: I24cab206b16e63859d4886c55d40a03d398ce30d
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Cinder and Nova already require this version,
as it provides significant performance enhancements.
Change-Id: I42623a2172ebd80a237006e880189095bc27e70f
This patch adds a Windows iSCSI connector while the following
changes will add SMBFS and Fibre Channel connectors as well.
os-win is added as a requirement, as well as ddt. Note that
both are in the global requirements list. os-win is under OpenStack
governance and already being used by multiple OpenStack projects
such as Nova and Cinder.
The patch using Windows os-brick connectors in the Hyper-V
Nova driver: https://review.openstack.org/#/c/273504/
Change-Id: I19dfc8dd2e9e8a1b17675b55c63de903804480e4
Partial-Implements: blueprint os-brick-windows-support
Rajat Dhasmana