Without this, "tox -e py38" fails with an error from
setuptools:
error: Multiple top-level packages discovered in
a flat-layout: ['etc', 'os_brick', 'releasenotes'].
Change-Id: Icd68f845d83df2d4875e61a7e92630e73e4564c4
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
This adds the "tox -e mypy" environment which works
the same way we have introduced mypy in Cinder.
Files added to mypy-files.txt are validated with mypy.
Change-Id: I6d09422dbdf5ea58661aad7a63c4d4d7a2839833
Resolves warnings like the following:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
Change-Id: Ibda458a394207539db128d99fbd45a1d4560562c
These translation sections are not needed anymore, Babel can
generate translation files without them.
Change-Id: I07cac802653e5b266d598387e72f5556936551e9
Now that we are running the Victoria tests that include a
voting py38, we can now add the Python 3.8 metadata to the
package information to reflect that support.
Change-Id: I74edd4b312c2a59f413ea66f9e26fe097146579f
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Make a few cleanups:
- Remove python 2.7 stanza from setup.py
- Add requires on python >= 3.6 to setup.cfg so that pypi and pip
know about the requirement
- Remove obsolete sections from setup.cfg
- Update classifiers
Change-Id: I34abafc045b4f50ded19bd0b8d87fa3c77f1a1b9
Makes Python 3 the base python for all tox venvs and removes
py2 jobs from zuul.yaml.
Remaining:
- move the legacy gate jobs from openstack-zuul-jobs to the os-brick
repo and make them py3 jobs
- adjust setup.cfg to require py3 and remove py2 requirements from
test-requirements.txt and doc/requirements.txt
Partial-bug: #1853372
Change-Id: Ib447656aa213914bafd50380b3821090f93776f8
This is a followup to Drop py35 jobs from gate and tox env[1].
[1] https://review.openstack.org/#/c/639387/
Change-Id: I9e27e95a4493d9887a7dd8c7d7c7c5b511277f95
We have three populated sections:
- install
- user
- reference
There are three docs removed, as they served little useful purpose and
were mostly unreferenced.
Sphinx's 'warning-is-error' option is enabled to catch the few issues
that has snuck into the docs.
Change-Id: I04e426faf337f0b03175f439c80b3369d4066733
1) Update doc links according to OpenStack document migration
2) Use https instead of http for docs links
Change-Id: Ib98f33de8d7f6ef84a2f6ecb498530b336da875b
Now that there is a passing gate job, we can claim
support for Python 3.5 in the classifier.
This patch also adds the convenience py35 venv.
Change-Id: Ic3967cf2461add370a03cd15e71087664b9ec1d7
"Python 3.3 support is being dropped since OpenStack Liberty."
written in following URL.
https://wiki.openstack.org/wiki/Python3
And already the infra team and the oslo team are dropping py33
support from their projects.
Since we rely on oslo for a lot of our work, and depend on infra
for our CI, we should drop py33 support too.
Change-Id: Ia5dba7d192e283bc1ba2ab24868402ab4a958870
Since there are so many components in openstack,
by describing the URL info in the configuration file,
it is more convenient to find the developer documentation
than from the unified portal
Change-Id: I624427a3d18007121f04e53e7382140c6f29cefa
OpenStack projects are no longer being tested under Python 2.6, so
remove the trove classifier implying that this project supports 2.6.
Change-Id: I9047beded251de0083bf6b6d48688e40872437d1
This patch adds os-bricks list of rootwrap filters for commands
that are needed to execute. The filters are a self contained entire
list of expected filters that os-brick needs to run. It's expected that
this filter file is added to any rootwrap enabled service that needs to use
os-brick.
Devstack associated patch: https://review.openstack.org/#/c/207677/
Partial-Bug: #1479842
UpgradeImpact: Need to place the os-brick.filters file in service's
rootwrap.d directory to enable filters.
Change-Id: I2b1e657b87c7b27548200a20b991f34c3413c24b
Zuul