Add a new spec DSL operator called `range-in` that allowes users of
the spec_matcher to match values against numeric ranges.
The surrounding brackets determines whether the limit should be
inclusive or not.
examples:
<range-in> [ 10 20 ] : 10 <= x <= 20
<range-in> ( 10 20 ] : 10 < x <= 20
<range-in> [ 10 20 ) : 10 <= x < 20
<range-in> ( 10 20 ) : 10 < x < 20
Closes-Bug: #2052619
Change-Id: I444c01219d02ea7572d4b82117b89b8d3eb75e56
Signed-off-by: Adam Rozman <adam.rozman@est.tech>
Co-authored-by: Takashi Kajinami <kajinamit@oss.nttdata.com>
This is deprecated in the favor of:
datetime.datetime.now(datetime.timezone.utc)
In order to return a ``datetime.datetime`` object without the TZ
zone defined, the ``tzinfo`` member is deleted. That allows the
addition/substraction from offset-naive ``datetime.datetime`` objects.
Change-Id: Id345167e71bf576ec383b9d700f222343b08b249
Sometimes we have to use the latest code instead of the latest release
to test upcoming changes (eg. sqlalchemy). In such case the version
string might contain its development status such as beta, and causes
failure while parsing the version string.
This makes the parse logic ignore the development status suffix to
avoid the failure.
Closes-Bug: #2042886
Change-Id: I27c14ede026c5600173047b1a0892a02a54dbb06
The assertAlmostEquals method has been deprecated since Python 3.2 and
was removed in Python 3.12 [1], assertAlmostEqual should be used as the
replacement.
[1] https://docs.python.org/3.13/whatsnew/3.12.html#removed
Change-Id: I1c1be8072e8be6aa5a0e876d08817b1255a31275
Signed-off-by: Petr Vaněk <arkamar@atlas.cz>
We removed compatibility with Python 3.8 once but it was added back to
tested runtimes for 2023.2. Thus we have to make sure the code works
with Python 3.8, which was broken by [1].
Note that ptyz is added back to requirmenets.txt and is now required
regardless of the python version. This is a short term solution until
we figure out the way to fix the requirement-check job (or we again
remove python 3.8 support).
[1] 7d9fda625f
Change-Id: Ica344021a4e922bcfd20d20cffcce585a5742c8f
Following Resolution 3 of the 27th General Conference on Weights
and Measures (CGPM) in 2022 [0], update oslo units to include
'ronna' and 'quetta' for decimal prefixes. Although ISO/IEC
80000-13 has not yet been updated for the binary equivalents,
it's safe to assume ISO will follow current practice [1], so
those are added as well.
[0] https://www.bipm.org/en/cgpm-2022/resolution-3
[1] https://iopscience.iop.org/article/10.1088/1681-7575/ac6afd
Change-Id: I6e6b3fe9fe24533553f655a687a3c4e6714fde6f
Zoneinfo was introduced within python 3.9.
The support of pytz will be removed within RHEL 10 [1].
2023.2 (bobcat) will move our testing runtime to py3.9 and py3.10
so we want to see pytz removed within this series.
tzdata is required at runtime in our gates, because, by default,
zoneinfo uses the system’s time zone data if available; if no system
time zone data is available, the library will fall back to using the
first-party tzdata package available on PyPI. Apparently our gates have no
time zone data available nor tzdata installed by default because we get the
following error without tzdata installed [3]:
`ModuleNotFoundError: No module named 'tzdata'
So I prefer to add tzdata in our requirements to avoid runtime failure
related to time zone and ensure that time zone are always available.
[1] https://issues.redhat.com/browse/RHEL-219
[2] https://review.opendev.org/c/openstack/governance/+/872232
[3] https://zuul.opendev.org/t/openstack/build/0a1576775e894b09bc31269fea00ba03/log/job-output.txt#1445`
Depends-on: https://review.opendev.org/c/openstack/requirements/+/875854
Change-Id: I1f88bdadc68bfa726eac1da1c5824c1ed352ad98
The strict argument has been deprecated since 4.6.0 because it has no
effect in Python >=3.8 [1].
Because now this library supports only Python >=3.8, the logic for old
python versions can be removed.
[1] https://review.opendev.org/c/openstack/oslo.utils/+/750216
Related-Bug: #1841072
Change-Id: I5873c0df347a4e9a8a1fbfcf9f1212af14f7aef2
Remove the 'isotime', 'strtime' and 'iso8601_from_timestamp' helpers
from 'oslo_utils.timeutils'. These are all available in the stdlib now.
Change-Id: If4afb9242b14c48cc70e409463865b7b644a919f
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This has been deprecated for a long time. No need to keep it around any
longer.
Change-Id: I8273e164243e014a658b725a375e5632af211945
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This is a slow import and the single user of it, the 'split_by_commas'
helper, does not appear to have any users outside of python-glareclient
(which is a dead project). We might want to remove the user at some
point, but for now simply defer loading of the library.
Change-Id: I91d0c6eec5333a660f995a9d1436e4b068693900
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Those regexes will fix Object style representation output.
See the payload used in tests for details. This kind
of output can be obtained by using the command:
```
$ openstack --debug
```
Co-Authored-By: Daniel Bengtsson <dbengt@redhat.com>
Change-Id: I9024be93b109d1b64ca736546c0f69db7a5e06d0
Some use cases are poorly handled by the regex used
to mask password. Indeed when the password contains
quotes or double quotes in the middle such as `pass"word`,
the mask_password method will return `***"word`.
For more details please see
https://bugs.launchpad.net/oslo.utils/+bug/1949623
Closes-Bug: #1949623
Change-Id: I941750b4d49d2d75f0831b24d6dd17f4040f70a2
Since libvirt 6, it might be important to understand the
format of the backing image [1] and verify it before operations.
So we adding backing file format to the output of the QemuImgInfo
[1] https://libvirt.org/kbase/backing_chains.html
Change-Id: If83289882e79a973bc77f332408f8f7317351f6f
The qemu-img info command shows the encrpyed field in different formats
according to the output format. When the default human format is used
the field can be 'yes' or None while when json format is used the same
field can be True or False.
This change ensures the corresponding attribute has the consistent
format regardless of the output format used.
Closes-Bug: #1942682
Change-Id: I949f07582a708114fdfba76f1a05aa3a3e5c4f40
Keystone User IDs and Project IDs are used in unit tests, but
_UUIDSentinels() class doesn't generate UUIDs without hyphens.
This patch makes backward compatible modifications to
_UUIDSentinels() class and introduces keystoneidsentinel global
that could be used in the same way as existing uuidsentinel.
Original "UUID sentinel" change: I214ff21b461fa1ca4b83476e1d0a763efe986217
Related-Bug: #1746747
Change-Id: Idb3e893cc03d64ad0522b5e4cedfa30c4f4a2a2f
Change 73eb0673f6 deprecated usage of
the human format and introduced a deprecatipon warning message which
is shown unless format is explicitly set to 'json'.
To avoid the deprecation warning, all usage of QemuImgInfo requires
explicit definition of format='json'. This means that we should add
the format parameter to all existing usage of QemuImgInfo even if
output is blank as is described in the following example.
QemuImgInfo()
QemuImgInfo(output=None)
However later we should revert these implementations again when we
deprecated or remove the format parameter. These steps are very
redundant.
This change suppresses the warning message when output is blank so that
we can avoid deprecation warnings without redundant update and revert.
Change-Id: If1ec42dae757fa3d74c740a52c346701ea19f1c9
[1] Enabled warnings without specifying category,
leading to all sort of warnings enabled, this patch
drops it and let it to consumers to enable warnings
types which they are interested in.
[1] https://review.opendev.org/c/openstack/oslo.utils/+/790429
Closes-Bug: #1934098
Change-Id: I822138c18e0932e8f7e3dc62267f167876c962ae
Oslo.utils's fnmatch module was added to fix the py2.7 fnmatch module
who was not thread safe [1]. Python 2.7 is no longer supported so now we
can use the stdlib's fnmatch module and deprecate the one of oslo.utils.
[1] https://bugs.python.org/issue23191$
[2] e46a46ba90
Change-Id: I538379f91d2ba415c566ada8d221b62b47ba80bb
``human`` format parsing introduced many issue in the past.
Each time qemu will update it's human format output we could be
impacted by their changes and it could introduce new issues on
oslo.utils.
Human format is a human readable format which need to be parsed by
regexes, in other words it's not really a format that machine can
consume natively.
Qemu introduced json output since version 1.3 [1] and this format is
machine readable, for the sake of stability on oslo.utils we decided to
drop the support of the human format and to use json as the unique and
only supported format.
We will reach our goal by following this scenario:
step 1: deprecate the human format
step 2: remove the human format and deprecate the format parameters
step 3: remove the parameter (json all the time)
These changes deprecate the ``human`` format (step 1)
[1] https://wiki.qemu.org/ChangeLog/1.3
Change-Id: Ia8d6cd08a8989395f9b0f9097d2e57757b8cb915
The abstract base classes previously defined in 'collections' were moved
to 'collections.abc' in 3.3. The aliases will be removed in 3.10.
Preempt this change now with a simple find-replace:
$ ag -l 'collections.($TYPES)' | \
xargs sed -i 's/\(collections\)\.\($TYPES\)/\1.abc.\2/g'
Where $TYPES is the list of moved ABCs from [1].
[1] https://docs.python.org/3/library/collections.abc.html
Change-Id: I85f2757852c0313967f5d82166124feb10aa4c6a
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
As the name suggests this is simply an id referring to a key and not the
actual key itself. As such we should stop masking this in an effort to
ease debugging and troubleshooting when it is logged.
This was previously incorrectly masked by
I9e684cd8bab85728ff0117f95a30eb7dbb5bf51c as part of bug #1814365.
Closes-Bug: #1905264
Change-Id: I856e3cf32c409debdfb15aa96415c3309fe2f516
For systems in FIPS mode, invocations of MD5 will fail. This occurs
even in cases where the MD5 is used in a non-cryptographical context
eg. for an etag in swift.
There is a proposal in Python to allow developers to mark these
non-crypto cases as valid through a new usedforsecurity keyword.
See https://bugs.python.org/issue9216.
Some downstream versions of python already implement this keyword.
To permit OpenStack to run in FIPS enabled systems with these versions
of python, we add a simple encapsulation of hashlib.md5() here.
Once the issue is resolved in upstream python, we can remove this
function.
Change-Id: I09433fea6ad6e6849677a93b269e24dec5c05b69
Adam Rozman
yatinkarel