This was always testing the upgrade with master, causing CI failures on
the stable/2024.1 branch.
Also remove USE_PYTHON3 which is always true in our supported branches.
Change-Id: I9ba2b02b7c5abd2b6a2114cd3b680ea0244484a4
Change all functions to use ``get_last_processed_timestamp`` instead of
``get_state``, update the tests and remove the ``get_state`` function.
Change-Id: Iea704fc594f4b5201a1fff7d38a6c0bafb9be6f1
This introduces the PUT method for rating modules in the v2 API. Work items:
* Implement the "/v1/rating/modules" endpoints in the v2 API, including
unit tests and documentation
Change-Id: I202c1021c11926c40ac1d9f5ca51c026ec3b674b
Co-Authored-By: Pedro Henrique Pereira Martins <phpm13@gmail.com>
Story: 2006572
Task: 36798
Add file to the reno documentation build to show release notes for
stable/2024.1.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2024.1.
Sem-Ver: feature
Change-Id: Ic60212f53d02906092c8656b1fab8d9bb84d54a8
Updated service name and data object entries that do not match
current default metrics.yml configuration
Change-Id: Ib74661a764b887d24dcfb4e4f22ef376b6d1a4ad
Given these backends are now used in many production environments, they
can no longer be considered experimental.
Change-Id: I9e9f3023bf2a50807540e69b764600c0c5f995d5
Switch to using oslo_db.sqlalchemy.enginefacade instead, as this is
required for SQLAlchemy 2.x support.
Change-Id: Ifcad28239b6907b8ca396d348cbfa54185355f68
This patch allows CloudKitty to use InfluxDB v2 with Flux queries. This
type of query uses less CPU and RAM to be processed in the InfluxDB
backend.
Change-Id: I8ee3c92776aa69afbede353981a5fcd65dd7d099
Depends-On: https://review.opendev.org/c/openstack/requirements/+/895629
Story: 2010863
Task: 48539
We use requests in several places in cloudkitty code, so we need to
depend on it directly instead of installing it through dependencies.
Change-Id: Ibedb9ddba61b39c80b1e1b3910a90468bdfc76ae
After the commit
8778c64776
The module PBR in openstack started to validating the parameters when
creating an embedded WSGI, now if invalid arguments are given
to the cloudkitty-api it raises an error as we are facing in the
devstack when using `CLOUDKITTY_USE_MOD_WSGI=False`:
cloudkitty-api[86126]: usage: cloudkitty-api [-h] [--port PORT] [--host IP] -- [passed options]
cloudkitty-api[86126]: cloudkitty-api: error: unrecognized arguments: --config-file=/etc/cloudkitty/cloudkitty.conf
This PR also extracts the upgrade database workflow to a function
to be used in grenade tests
Change-Id: Ifc1a8563a9efcae2abaa6f8eb036405a93ff296d
As per the current release tested runtime, we test
till python 3.11 so updating the same in python
classifier in setup.cfg
Change-Id: If66420bae76e8db527c1aa191cb31d6ed8a7ff91
There is the need to add human-readable description to the metric
definition. This can then be used to create custom reports in the
`summary` GET API. The value has to be stored in the backend as
we do with the alt_name and unit of the metric as well.
Depends-On: https://review.opendev.org/c/openstack/cloudkitty/+/861786
Change-Id: Icea8d00eaf3343e59f0f7b2234754f6abcb23258
To facilitate the switch from Elasticsearch to OpenSearch, the ES
backend has been duplicated and renamed where appropriate to OpenSearch.
The OpenSearch implementation was modified in places for compatibility
with OpenSearch 2.x, for example:
- remove mapping name from bulk API URL
- replace put_mapping by post_mapping
This will allow for the future removal of the Elasticsearch backend.
Change-Id: I88b0a30f66af13dad1bd75cde412d2880b4ead30
Co-Authored-By: Pierre Riteau <pierre@stackhpc.com>
Introduce new default groupby options: (i) time: to group data by
hourly; (ii) time-d: to group data by day of the year; (iii) time-w:
to group data by week of the year; (iv) time-m: to group data by month;
and, (v) time-y: to group data by year. If you have old data in
CloudKitty and you wish to use these group by methods, you will need
to reprocess the desired timeframe.
Story: #2009839
Task: #44438
Depends-On: https://review.opendev.org/c/x/wsme/+/893677
Change-Id: Iad296f54f6701af84e168796aec9b1033a2a8a2d
Calling GET /v2/task/reprocesses with python-cloudkittyclient was
returning Internal Server Error, with the following API trace:
File "/var/lib/kolla/venv/lib/python3.6/site-packages/cloudkitty/api/v2/task/reprocess.py", line 259, in get
order, ACCEPTED_GET_REPROCESSING_REQUEST_ORDERS)
TypeError: __init__() takes from 1 to 3 positional arguments but 4 were given
This was because http_exceptions.BadRequest was given multiple arguments
(similar to LOG.* methods) instead of a single string.
Another issue is that python-cloudkittyclient sends the "DESC" order
while the API only supports "desc" and "asc". Convert to lower case for
compatibility.
Change-Id: Id1145adff82bc9a01e4eb0f306f0bfa535142459
Currently, when a reprocessing task is scheduled, CloudKitty executes
the cleaning of the data for the reprocessing period in one hour
fashion (the default period). Therefore, for each one of the
timeframes, a delete query is sent to InfluxDB (when using it as a
backend). However, InfluxDB is not a very optimized time series database
for deletion; thus, this workflow generates quite some overhead and
slowness when reprocessing. If we clean right away the whole time
frame for the reprocessing task, and then we just reprocess it, it will
execute a single delete query in InfluxDB, which has a similar cost as
a delete to remove the data for a single time frame.
This patch optimized the reprocessing workflow to execute batch cleaning
of data in the storage backend of CloudKitty.
Change-Id: I8282f44ad837c71df0cb6c73776eafc7014ebedf
The option 'use_all_resource_revisions' is useful when using Gnocchi
with the patch introduced in [1]. That patch can cause queries to
return more than one entry per granularity (timespan), according to
the revisions a resource has. This can be problematic when using the
'mutate' option of Cloudkitty. Therefore, this option
('use_all_resource_revisions') allows operators to discard all
datapoints returned from Gnocchi, but the last one in the granularity
that is queried by CloudKitty. The default behavior is maintained,
which means, CloudKitty always uses all the data points returned.
However, when the 'mutate' option is not used, we need to sum all the
quantities and use this value with the latest version of the attributes
received. Otherwise, we will miss the complete accounting for the time
frame where the revision happened.
[1] https://github.com/gnocchixyz/gnocchi/pull/1059
Change-Id: I45bdaa3783ff483d49ecca70571caf529f3ccbc3