they are not maintained for a long time, and trove already switch
the tests to templest.
This commit removes the usage of them. more details see story.
Story: 2010882
Task: 48606
Depends-On: https://review.opendev.org/c/openstack/trove/+/914228
Change-Id: Ie021e0bd708cf8ed13853dea632312af38190205
Added a new field ``operating_status`` for the instance to show the actual
operational status of user's database.
Change-Id: I7c52cff0ec48289fe1a260e99e02a506d4f8ddec
Significant changes:
* Using docker image to install datastore.
* Datastore image is common to different datastores.
* Using backup docker image to do backup and restore.
* Support MariaDB replication
* Set most of the functional jobs as non-voting as nested
virtualization is not supported in CI.
Change-Id: Ia9c97a63a961eebc336b70d28dc77638144c1834
Allow the cloud admin to control the security groups on the management
port of Trove instance, a new config option `management_security_groups`
is introduced for that purpose.
Change-Id: I4b22b87d37792be700d4ec7f78a7ea479ddb5814
Story: 2006466
Task: 36395
During debugging, the following changes are also included:
- Support to specify an image ID to run the integration test.
- Fix the reboot function bug.
- Remove the unsuccessful restart test.
How to run integration test with dev_mode=false:
ADMIN_PASSWORD=password \
SERVICE_PASSWORD=password \
DEV_MODE=false \
/opt/stack/trove/integration/scripts/trovestack gate-tests mysql mysql
Change-Id: I31d4ee579a554f4c98f9facb9fd4b7779665a3dd
The service tenant deployment model means Trove creates most of the
resources(vm, volume, security group, etc.) relating to a database
instance in the Trove service tenant rather than the end user.
With this deployment model, most of the related resources behind the
scenes are invisible to the user, which is a more secure deployment
model for either private or public cloud provider.
DevStack should follow this model as it will be recommended for Trove
deployment in production.
Changes included in this patch that are necessary in order to make that
happen:
- Add 'admin' role to Trove service user(username: trove, project:
service) in DevStack.
- Create Trove management network resources for Trove service user in
DevStack.
- Enable Trove remote client configuration by default in DevStack.
- Mainly use alt_demo user in alt_demo project for integration tests,
config trove user as the admin role user in integration tests.
- Disable the module related tests(module_groups) for now because of no
use cases but need effort to fix all the failed tests in the service
tenant model.
Story: #2005445
Task: #30489
Change-Id: I2efb69d3d50344914a875b773f62a227dba2ccaf
Functional tests are executed by trovestack script, which uses python
in default OS version which is 2.7.
This change wraps python in tox and executes trovestack int_tests in
virtual enviroment, starting them in python3.
Any future python version change could be managed by tox framework.
Change-Id: I3a849978241d3d0669ef9e1c802ff504ac3c32cb
Signed-off-by: Marcin Piwowarczyk <m.piwowarczy@samsung.com>
When instances fail to build successfully during the gate runs
it is common to see a KeyError on 'ip'. This is coming from the
test_runner code which is expecting the instance to have an IP
address.
This puts a check on 'ip' before its usage and fails the tests
with an more explicit error message.
Change-Id: Ibd926e90190024a5b1979b3a09fa1eda12aa7106
Under 9ec134996a the exception
handling of the test_runners was changed to do a bare
raise of the original test failing exception. This was
done to preserve the original traceback. This had the
unintended side effect of allowing exceptions in the error
handling and log reporting code to be raised as the test
case failing exception.
This commit fixes the exception handling to save off the
exc_info and re-raise the original exception with original
traceback.
Change-Id: I13bcf194bb289749ec289216f2541d4923f5f2bf
Issue 1:
The os-testr 1.0.0 release had a couple of required config changes due
to it's internal usage of stestr.
This change to stestr changed the way tests were discovered by
os-testr and as a result the unit test run was picking up tempest
tests.
A regex is added to the py3base environment call of ostestr because
the use of --serial and --blacklist-file together is broken in stestr
and adding the regex parameter allows the blacklist-file to be
processed. The stestr issue is documented here [1].
Issue 2:
Cache dirs for PKI tokens have been removed for all services in
devstack under I5680376e70e74882e9fdb87ee1b95d5f40570ad7.
We must also remove the use here to pass the right parameters to
configure_auth_token_middleware.
Issue 3:
Keystone V2 APIs have been removed. When creating Nova and Glance
clients, the test code was either hard coding v2 Keystone or not
providing enough information for the V3 auth.
Issue 4:
Oslo context has deprecated parameters such as 'tenant', has removed
them from its constructor and is using a rename decorator to handle
them. As such, the code and test case to check for unrecognized
parameters to TroveContext and Context is erroneously removing the
tenant parameter. Oslo context has also changed the from_dict method
since the original code to remove parameters was introduced into
Trove. The new method signature and code should already provide most
or all of the protections against incompatibility the original code
was attempting to provide. The fix for this issue is to change
TroveContext's from_dict method to use the kwargs to handle its own
__init__ parameters and be more in line with what Nova is doing in
its RequestContext subclass.
Issue 5:
Jobs run as jenkins on Zuul v2 but run as user zuul on Zuul v3.
Issue 6:
Ignore one case of pylint E1101 in the Ceilometer notification
code base.
[1] https://github.com/mtreinish/stestr/issues/103
Change-Id: Ic55187b0d73d4c572d7f8332882b4f455a6177c8
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
Implement the helper client methods for data operations
in scenario tests.
Fixed two other test-related issues discovered
while testing Couchbase:
* The code that builds helper user json definition
generates invalid payload when no database is specified
(i.e. it uses None as database name which is wrong).
* Another issue is that the flavor for
cluster grow tests is retrieved from the
instance info which would not be initialized when
running standalone (i.e. --group=cluster) cluster tests.
Change-Id: Iab0c9b4b98f9c428f2ea7461f5d5834461b66fa4
Implement configuration attach and detach API for clusters.
Implement rolling strategy for applying configuration changes
(both attach and detach follow the same pattern).
1. Persist the changes on all nodes (leaving nodes in RESTART_REQUIRED state).
2. Update Trove records.
3. Apply changes dynamically via one or all node(s) if possible
(and remove RESTART_REQUIRED flag from all nodes).
Notes:
The single instance implementation has been restructured (similar to above)
such that it always leaves the instance in one of the three states:
a) Unchanged
b) Changes persisted but not applied
(Instance has configuration attached but requires restart.
It is safe restart manually or detach the group to avoid
any changes)
c) Changes persisted and applied (if possible)
This implemenation should always leave the cluster (and each instance)
in a consistent state.
Runtime configuration will not be changed until it is first persisted
on all nodes.
If there is a failure during step 1) the cluster is still running
the old configuration. Some instances may have new configuration
persisted, but not applied.
The cluster will not have configuration attached unless it can
be applied to all nodes.
The individual nodes will have configuration attached as soon as it is
persisted on the guest.
It is safe to retry, reapplying the same configuration on a node is
noop.
It is safe to detach. Removing configuration from nodes without one
is a noop.
It is safe to detach the configuration from individual nodes via
single-instance API.
It is safe to attach the configuration to remaining nodes via
single-instance API and rerun cluster attach to update Trove records.
If 3) fails for whatewer reason the instances are left
in RESTART_REQUIRED state.
It is safe to retry or detach configuration or restart the
instances manually.
Also fixed various minor cluster issues.
Implements: blueprint cluster-configuration-groups
Change-Id: I7c0a22c6a0287128d0c37e100589c78173fd9c1a
As an aid to debug guest failures, a Metaclass was added
to the TestRunner class that allows failed tests to
pull back and echo the guest log from 'registered'
instances.
This uses the guest-log feature that is available for
all datastores.
IDs for instances created in the tests were registered
to report on failures.
Two guest-log tests were also commented out, as they
seem to not work properly: see
https://bugs.launchpad.net/trove/+bug/1653614
This was discovered while testing the new retrieval
code. Other tests were also modified so that
'SkipTest' exceptions would be raised properly.
Change-Id: I448bd2f0181351ef1536e20c41f9d45f95478587
Partial-Bug: 1652964
Sometimes tests fail becaused there's a double check for
the instance state. If the state changes in between the
two checks, the test will fail to acknowledge the first
'correct' response and timeout while waiting for the state
to re-occur (which doesn't happen).
Sample output would look like:
[REPORT] Polling instance '<id>' for state 'REBOOT', was 'REBOOT'.
[REPORT] Polling instance '<id>' for state 'REBOOT', was 'ACTIVE'.
...
[REPORT] Polling instance '<id>' for state 'REBOOT', was 'ACTIVE'.
...
[REPORT] Status of instance '<id>' did not change to 'REBOOT' after 1201.3s.
Also broke down the instance-create tests into instance-create and
instance-init-create so that the initialzed instance won't
need to be created for manual runs or multi runs in the gate.
Reorganized the backup create so that on fast nodes there's
more chance that the backup is still around while the
negative tests run.
Change-Id: I9731bf7a93e7b8b3398cf73d1bc15d70f5bfa96a
If a node is really slow then a single test can take longer than an
hour. It will then fail as the client it has cached will now have an
expired token. To alleviate this, the caching of the clients was removed
(since the time saved on caching the clients is probably negligible
anyway).
Checking the client code was also cleaned up for a number of tests.
The cluster tests were modified, however the code was reverted as
there is no way to test it at present (they will not run as they
haven't been modified to work with the new neutron set up). This
will be fixed in a separate changereq (since they are currently not
being tested in the gate, this should not hold up development).
Change-Id: I63d5b78084486b806bff38068260e42128c0d0ed
Closes-Bug: 1647002
This change uses the alt-demo network instead of sharing
the private network from the demo tenant. This should
fix the tempest tests on python-troveclient complaining
about this and also brings us one step closer to using
neutron entirely.
Tested with the demo tenant as well and it still
puts on a network without using the --nic parameter, the
only drawback is that the ip doesn't appear on the trove
show command.
The scenario and api tests were modified to always pass
in the nic parameter (as it probably should have been done
from the beginning anyways).
Change-Id: I9f3cbae3490e9995ba5f835fc2304442b83464e4
Closes-Bug: 1647001
Post-prepare actions take long.
About 1 min or more on some datastores.
We need to wait for the helper user/database
to appear on the instance before proceeding with
other tests that require them.
Change-Id: If06fc9eede0d1f11c2a7ca723e540e0068871cf6
The scenario tests currently use the first ip address (or in the
case of clusters, all) that is found. Unfortunately some datastores
don't support IPV6, so if a non-ipv4 ip is used, the test will fail.
Until all datastores support IPV6 (or we can come up with a strategy
to intelligently decide which to use) we should only use the IPV4 ips,
so the tests have been changed to accomodate this.
Closes-Bug: 1642741
Depends-On: Ia4fc545a10c7c16532aefd73818dd7d90c9c271b
Change-Id: I6aff776680c9c0632d8965c3ed70ed26db0a63f2
In the SQLAlchemy keep_alive class, MariaDB is failing
as pymysql reports an invalid packet sequence.
MariaDB seems to timeout the client in a different
way than MySQL and PXC, which manifests itself as the
aforementioned invalid sequence. It is now handled
as a special-case exception.
With this fix, the MariaDB scenario tests now pass.
The scenario tests were also tweaked a bit, which aided
in the testing of the fix. 'group=instance' was created,
plus instance_error properly interleaved with
instance_create. _has_status now calls get_instance with
the admin client so that any faults are accompanied by
a relevant stack trace. Cases where the result code
was being checked out-of-sequence were removed, and explicit
calls to check the http code for the right client were added.
The replication error messages for promote and eject were
enhanced as well to attempt to debug spurious failures.
One of those failures was 'Replication is not on after 60 seconds.'
This was fixed by setting 'MASTER_CONNECT_RETRY' in the mariadb
gtid replication strategy as was done in:
https://review.openstack.org/#/c/188933
Finally, backup_incremental was added to MariaDB supported
groups and cleaned up elsewhere.
Closes-Bug: #1621702
Change-Id: Id6bde5a34e1d79eece3084f761dcd153c38ccbad
Sometimes an instance/cluster can be stuck in BUILD state forever.
Attempting to delete the instance in this state is currently not
allowed. Add force-delete and reset-status command. Reset-status
will reset the status of an instance to ERROR and cluster to NONE.
The reset-status command can only be used if the instance/cluster
is in BUILD or ERROR state. Resetting the status of an instance in
ERROR state can be useful as an instance might go ACTIVE after the
specified timeout. Once the status has been reset it is possible
for an instance to go ACTIVE if it receives a hearbeat from the
guestagent.
Force-delete will combine functionality of reset-status and delete.
Change-Id: I83f6cdcdd884e51d002295b0d1f07341990e512c
Depends-On: I957b4be5030e493e0eb8c6b6855d41b942b2823c
Partial-Bug: #1579141
Support for standard WAL based streaming replication for
postgresql guests. Sets up read-only hot standby servers.
Basic replication is supported for 9.3, but promote
requires pg_rewind which is only supported for 9.4 and
greater. Promote currently only works with single
master-replica configurations (see TODO and associated
bug 1553339 for details)
Test changes:
- moved the replication promote tests to a separate group
- skipped known issues with bug reference
Change-Id: I519fa58d786edddb09bf14ce7629e1be51b62600
Implements: bp/pgsql-replication
There is a test to eject a valid master during replication that is
failing more and more often in the scenario tests. Basically the
eject will only work if the heartbeat from the current master is
more than a minute old. This shouldn't happen in the scenario
test run, but it does - quite often.
Since this is consuming a large amount of gate resources, and the
bug isn't that onerous (but is probably hard to fix), the current
'eject valid master' test will be turned off until the fix lands.
The scenario test will print out the bug number during each run
as a reminder (using the new SkipKnownBug method).
Co-Authored-By: Peter Stachowski <peter@tesora.com>
Co-Authored-By: Amrith Kumar <amrith@tesora.com>
Author: Peter Stachowski <peter@tesora.com>
Change-Id: Ia543da551ad4394d4964541f9db474e0792b9337
Related-Bug: #1622014
The backup scenario tests currently only
verify data in the helper database.
We should also make sure no other databases
are created or deleted in the process.
Also removed a leftover mixin class.
That code was not used anywhere.
Also change the base instance name pattern
to allow selecting the name by double-clicking it.
(Linux bash stops at ':', and Mac equvalent stops at
':' and '-'. Windows shell always selects the whole
thing.)
Change-Id: I01ad0472bde59a95c619fb881cef976937b79fa6
Cluster tests rely on the instance flavor to be set
already. This works when the single instance tests
run before (they initialize it) but not when
running cluster tests standalone.
Make cluster tests retrieve the flavor themselves.
Change-Id: I8bac99fecc9508bb5452169836e8c28a3e3a92b5
When an error occurs in Trove, it is very difficult
to determine the cause without access to the
server logs. To make these errors available to
the end user, they are now persisted in the database
and can be viewed using the standard 'show' command.
Also fixed TESTS_USE_INSTANCE_ID test path, as it
somehow got broken over time.
Change-Id: I84ed28ee73a24a2dd6bdbf895662d26e406e9fae
Depends-On: I5d3339e9cbfd6aeb0c3ff6936fefa8dbe9e841f8
Implements: blueprint persist-error-message
This changeset stitches together all the different groups
in a way to have 3 instances being created at any given
time (where possible). The groupings will be:
-- module
|- configuration
-- instance_actions
-- database_actions
|- backup
-- instance_actions
-- user_actions
|- root_actions
-- guest_log
-- replication
Times (on a fast test machine) went from 2230s to 1720s, an
improvement of 23%.
The group labels were moved into the __init__.py file to facilitate
being accessed by different group implementations (to avoid a
circular import issue).
Tests were also cleaned up and homogenized wherever possible.
Change-Id: Idc3daab243261584ac5fa9350d952f5bb3984300
Closes-Bug: #1571092
The replication scenario tests were broken into separate
parts to facilitate parallel runs in the gate.
The verify_data helper was also enhanced to retry so that
arbitrary sleeps are no longer necessary to ensure that
data has time to replicate.
Additional data was also added/verified once the replication
network is back to its original configuration.
Partial-Bug: #1571092
Change-Id: I78bc945b36b1abba19e102cc2742984bd2375513
In order to allow replication sets to be all on the same hypervisor
(affinity) or all on different hypervisors (anti-affinity) a new
argument (locality) needed to be added to the Trove create API.
This changeset addresses the Trove server part of this feature.
'locality' can now be added to the ReST payload for a create command
and it is passed along as a scheduler hint to Nova.
The replication scenario tests were enhanced to test that 'affinity'
works and 'anti-affinity' fails (since devstack sets up a single
hypervisor by default). A check for the existance (and
lack of) server-groups was added. This is to ensure that not only is
the server-group created properly, but also that it has been deleted
after all the related instances are gone.
DocImpact: New functionality
Partially implements: blueprint replication-cluster-locality
Depends-On: I18f242983775526a7f1e2644302ebdc0dac025cf
Change-Id: I7d924c25d832f9ff4386e9497bfd214f1b2b3503
User and database actions like create, delete and update
are guestagent casts. The tests cannot reliably assume
they would be completed once the client call returns
(especially on datastores other than MySQL).
Add methods to wait for listing changes after the above actions.
Change-Id: Ic84b028e67ce19fb9297ebcacd2aafa6fd058d43
The scenario tests need to have the group classes broken
up to allow interleaving of the different parts of the tests
so that the gate can finish in a reasonable amount of time.
The runners, however, need to be the same for each main group,
thus allowing state to be preserved between groups of the same
feature. The creation of runners was refactored to allow for this.
The module tests were also modified to use the new paradym, which
allowed the removal of the global varaibles in the runner.
Dependencies on tests.api were also removed.
Change-Id: I66fcb2bce8c6cbc99c9ff071c242e4741500056d
Partial-Bug: #1571092
This changeset handles the details of creating,
updating, listing and deleting Trove 'modules.'
Two new tables have been added to the Trove database:
modules
instance_modules
although the instance_modules table is at present unused.
Scenario tests have been written as well, to exercise the
new functionality. These tests can be run by:
./redstack int-tests --group=module_create
In the follow-up changeset, all module tests can be run
by:
./redstack int-tests --group=module
Since module support is available for all datastores
(controlled by a CONF option) the module test has been
added to the common modules group.
Note: Trying to do admin tasks with none admin
credentials results in an Unauthorized exception
being thrown, instead of Forbidden. This
is due to the fact that Forbidden is in the
HTTPUnauthorized section of wsgi.py instead of
the HTTPForbidden section. Moving the exception
caused too many failures, so I created a 'Module'
Forbidden exception and put it in the right section.
Change-Id: I755b0431b33b870ae02d903527f071fd8e23130d
Depends-On: I54d37025275dee4731ad49ebbd21612c4464e4c4
Depends-On: I779c24472d3d96a7b2fe4ed0284fd5869cdef93b
Partially-Implements: blueprint module-maintenance
The test_log_generator_swift_client_sys test needs to run after a
specific test (test_log_generator_publish_sys) when running int-tests
with TESTS_DO_NOT_DELETE_INSTANCE set. This is due to the fact that
the logs are not otherwise left in a known state and running
subsequent tests with TESTS_USE_INSTANCE_ID will cause failures.
The swift client created by the tests should also pass in the
proper region code from the test file, not from the environment
Change-Id: Ib21cb9483cc26d311313361d9ccd6d748d5fa0fb
Depends-On: I19155463505500d1ca9a22ee9a58c80ff0c23ac2
Depends-On: I77981d282a6504379bb75a1e56cfb410e1c54f9a
The vertica root enable extension has a similar pattern that other
datastores can use for enabling root. (i.e. pxc) Made a few changes to
abstract this logic to a cluster centric root enable controller and
still allowed the specific vertica changes to its own extension.
Adding the scenario test to verify that the root user can connect and
see the added initial data. Also added a delete of the root restore
instance.
Unit tests added for coverage.
Implements: blueprint pxc-root-enable
Change-Id: I7b59914487bedd5b0f3b40dcae6c07024920365e
Implements log file retrieval from the guest agent. The contents
of the log file are pushed up to a swift container as a series of
objects that represent a subset of the lines in the log.
The following trove CLI commands are now supported:
trove log-list <instance> : lists log files available on guest
trove log-enable <instance> <log> : enables writing to log file
trove log-disable <instance> <log>: disables writing to log file
trove log-publish <instance> <log>: publishes updates to swift container
trove log-discard <instance> <log>: discards published logs
trove log-tail <instance> <log> : displays last lines of log
trove log-save <instance> <log> : saves the entire log to a file
Log declarations and scenario tests were added for MySQL and
PostgreSQL.
Co-Authored-By: Morgan Jones <morgan@tesora.com>
Co-Authored-By: Alex Tomic <atomic@tesora.com>
Co-Authored-By: Peter Stachowski <peter@tesora.com>
Implements: blueprint datastore-log-operations
Change-Id: I16c3bba4a3183d05af2971be6ba56110105797a6
1) Fix the cluster comminication test.
Replace the old way of testing an existing cluster by
creating a database on the cluster and checking its existence
afterwards, which is not compatible with datastores that do not
support databases.
Use the 'test_helper' infrastructure to test operations on an actual
data set - the same method used by single-instance tests as well.
2) Add missing int-tests for cluster grow and shrink operations.
The test verifies data operations after grow and shrink
operations respectively.
3) Move the Redis and PXC cluster tests to the new framework.
4) Make cluster tests independent of instance test by deriving
them from 'base' rather than 'instance_create' test group -
- i.e. no need to run instance tests for clusters.
5) Added (disabled until https://review.openstack.org/#/c/224363/
merges) code to create a helper user/database on a cluster.
6) Added test flags:
- TESTS_USE_CLUSTER_ID
- TESTS_DO_NOT_DELETE_CLUSTER
Change-Id: I4c97c77669b56295745fa2af8bb14f07ac52dd7a
Adding a helper client for MySQL will enable int-tests
involving actual data operations.
The test_helper.py file was also modified to push
more boiler-plate code into the base class, as it has
become apparent that only one 'add' 'remove' and 'verify'
method is probably adecuate for most datastores (given
the right sane parameters). The Redis helper was also
cleaned up to use the new format.
Change-Id: Iff34ca0b922adc9eea8b3861b05adf0251109221
Co-Authored-By: Petr Malik <pmalik@tesora.com>
Co-Authored-By: Peter Stachowski <peter@tesora.com>
Add generic integration tests for instance create.
Also moved some global constants to the base runner.
Note: Did some additional cleanup work on other test groups as well.
Broke down some negative tests into more self-contained units.
Added a comment string on tests that did not have it.
Had to fix database_actions test to work for users defining
hosts (like MySQL users).
Change-Id: I7c1413fa5742c276454e26ebbbeae8e02569a392
Implements a replication strategy for Redis. The following
commands have been added to the Redis datastore manager:
create (with --replica_of and --replica_count arguments)
detach-replica
eject-replica-source
promote-to-replica-source
Unit tests were added, along with integration tests.
To run:
./redstack install
./redstack kick-start redis
(vi /etc/trove/test.conf and change volume_support to false)
./redstack int-tests --group=replication (or --group=redis_supported)
DocImpact: Documentation should reflect the newly supported
features for Redis (see above).
Depends-On: I633273d438c22f98bef2fd1535730bcdb5e5cff0
Change-Id: I2f0d53fe9049026faf1f37a40c1b5788abae4428
Implements: blueprint redis-replication
The int-tests in Trove are very MySQL specific, which makes it difficult
to reuse code for other datastores. This changeset breaks them down
into 'groups' and 'runners.' Runners can be over-ridden to add
datastore specific handling/tests. This should allow most generic
code to be reused across datastores, while also providing for datastore
specific enhancements.
Runner implementations are stored in a new package
'trove.tests.scenario.runners'. A datastore-specific implementation can
be added to the appropriate runner module file. Its name has to match
'PrefixBaseRunnerClassName' pattern, where 'BaseRunnerClassName' is the
name of the default runner and 'Prefix' is the datastore's manager
name with the first letter capitalized.
Example:
Given the default implementation for negative cluster tests in
'trove.tests.api.runners.NegativeClusterActionsGroup'. One can
provide a custom implementation for MongoDB (with manager mongodb)
in 'trove.tests.api.runners.MongodbNegativeClusterActionsRunner'
This initial changeset adds tests for basic actions on instances
and clusters. Some basic replication tests were also migrated.
The concept of a helper class for datastore specific activies
was also created. This makes it easy to have tests use standard
methods of adding data and verifying that the datastore behaves
as it should.
Vertica was refactored to use the new infrastructure.
Running the tests can be accomplished by specifying one of the
new groups in int-tests (see int_tests.py for the complete list):
./redstack kick-start mongodb
./redstack int-tests --group=instance_actions --group=cluster
or
./redstack int-tests --group=mongodb_supported (to run all
tests supported by the MongoDB datastore)
As with the original int-tests, the datastore used is the one
referenced in test configuration file (test.conf) under the
key dbaas_datastore. This key is automatically set when
kick-start is run.
Additional Notes:
Also temporarily disabled volume size check in
instances tests.
It is supposed to assert that the used space on the
Trove volume is less that the size of the volume.
It however often fails because 'used' > 'size'.
From inspection of the instance it appears that the reported
'used' space is from the root volume instead of the
attached Trove volume. Plus it sometimes returns int instead of float.
Change-Id: I34fb974a32dc1b457026f5b9d98e20d1c7219009
Authored-By: Petr Malik <pmalik@tesora.com>
Co-Authored-By: Peter Stachowski <peter@tesora.com>
wu.chunyang