This commit is part of a series to retire the Packaging Deb
project. Step 2 is to remove all content from the project
repos, replacing it with a README notification where to find
ongoing work, and how to recover the repo if needed at some
future point (as in
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project).
Change-Id: I4b316814b25f0f27367401f48d34404dc73804fb
For shrink, if not specified instance_id should throw
"Not instances specified for shrink operation."
Change-Id: I1aa48d9306873e50e6dd5bb54f624508faac97c6
The integration directory contains the obsolete apidocs, remove them as
they are old and unused. There's a separate api-ref document instead.
Also, remove unneeded imported .gitignore file.
Change-Id: I4fefc99c03145a517e3b2f080b8e9173f46ebccf
When running in the gate environment, there's no need to start
services. Also, it is harder to dertermine whether the services are
wsgi'ed or not and that has been causing intermittent gate failures.
Change-Id: Ibe6a96a9319becf2053d26180fb7e6835a4e3a97
Currently the link in our developer documentation to our api-ref
is old. This updates it to the new one.
Change-Id: I68a36d4136422b823f2a71f3ea579896c7813c81
Redis configuration validation for the 'repl-backlog-size' parameter
uses a wrong MIN value of '0'.When set to less than 16384 value,
I can see that the value in redis.conf[1], but through the
'config get *' see are 16384[2]. Because the minimum default value
in redis is 16384[3]. So I want to modify Min value to 16384.
[1]: repl-backlog-size 0
[2]: 59) "repl-backlog-size"
60) "16384"
[3]:58f79e2ff4/src/server.h (L110)
Closes-Bug: #1697596
Change-Id: I81cb1c02943edf0af3d7bf67ff2f083a4c07d518
oslo_utils.timeutils is deprecating isotime(). In reality they are
deprecating some other things as well but Trove doesn't (currently)
use any of those things.
Much has been written on the subject of this deprecation. I think the
proposal to merely replace isotime with datetime.datetime.isoformat()
is a little simplistic. Well intentioned, but nonetheless I believe
that it is simplistic.
The primary issue I could find with oslo_utils.timeutils.isotime() was
the fact that it was naive. I think it could well have been fixed in
oslo_utils but for whatever reason(s) oslo decided not to want to go
that route.
The primary challenge from Trove's perspective is that I want to
respect the existing API contract while at the same time get an
implementation of time handling that is not identical in its flaws
with oslo_utils.timeutils.isotime().
This change set attempts to address that by making
trove.common.timeutils.isotime() that is aware. It also implements a
utcnow_aware() function that is aware.
ISO 8601 allows for four representations of timezone and those are
<time>Z
<time>[+-]hh:mm
<time>[+-]hhmm
<time>[+-]hh
Trove conventionally used the first one, even if the time wasn't
really a UTC time. That's one of the things being fixed here.
In review cp16net asked whether this change removes the 'Z' at the end
of time strings generated by the isotime() function. The answer is
NO. The new isotime() function performs identical to the old and now
deprecated function in oslo_utils.timeutils for UTC (Z) times.
There was a utcnow() function in trove.common.utils which just wrapped
datetime.datetime.utcnow(). That has been moved now to
trove.common.timeutils with the other new time related functions.
There were a couple of places in Trove where code was using
datetime.now() which was not ideal. Those have been corrected now as
well.
Unit tests have been proposed for the new routines.
Closes-Bug: #1532120
Change-Id: Ic5abf6669edd4f1a9fd62e61f437565aa887aebe
Method 'rolling_configuration_update' in trove/cluster/models.py.
It allow re-applying the same configuration to an instance.In if code
block, if the instance does not attach any configuration or it has
attached the configuration that the parameter passed, then do attach
thing. "else" block means the instance has attached another config,
should use "instance.configuration.id" instead of "configuration_id",
one is a attached configuration, one is a wanted configuration, and
they are not the same.
Besides, fix a spelling mistake in trove/instance/models.py
Change-Id: I4b6fb338de611ce39a8173dcf4b6e17714c380b9
Closes-Bug: 1693466
List options tcp_ports and udp_ports are lists of strings and some
with a '-' in the middle to indicate a range. To help validate the
options better a new type was introduced to oslo.config called Range.
oslo.config version 3.18.0 merged this Range type which will no
longer require the following in our project:
* utility function gen_ports because a Range of ints are returned
* test to check for proper from-to format, the type is smart so
it flips the numbers around for us. So 63000-300 returns
Range(300, 63001) 63001 because inclusion=True is set by default.
Change-Id: I63b6a865a3f3c79202dd299f6cd25dd59e182252
Closes-Bug: #1500141
According bug exception trace this problem cause by host name validate .
The origin code use netaddr.IPAddress to validate host name, it just fit ip address,
so the ip/netmask style do not match this rule.To solve this problem,
I changed this method to netaddr.IPNetwork, which support ip and
ip/netmask. Also provide a test case to validate the method.
Change-Id: I8dad9d1496d09372698821b832d1baa4f0c35a0d
Closes-Bug: #1673874