| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the following deprecation warnings.
* DeprecationWarning: Using the 'user' argument is deprecated
in version '2.18' and will be removed in version '3.0',
please use the 'user_id' argument instead
* DeprecationWarning: Property 'user' has moved to 'user_id'
in version '2.6' and will be removed in version '3.0'
Change-Id: I18802ae1e2318eae3c62a26459178b259c728ac4
Signed-off-by: Takashi Natsume <takanattie@gmail.com>
|
| |
|
|
|
|
| |
Change-Id: I0e00de3bc5c0ff797fc5c1a13f0275d596c12b5d
Story: 2008314
Task: 41209
|
| |
|
|
| |
Change-Id: Ic59f2fd94c5f216414effe7d13d0dd486dce9243
|
| |
|
|
|
|
|
|
|
|
|
| |
- 'HEALTHY' means the db service is responsive, 'ACTIVE' means the db
service is alive.
- Remove the CI job fakemodetests, but will add similar testing task in
the future.
- Fix the periodic CI job
- Remove MongoDB and related jobs
Change-Id: I5abe9091ba203297dc87db5fba139179166321f7
|
| |
|
|
|
|
| |
The current admin credential config options are confusing
Change-Id: I92c15c065edf364b955f2243b3599e0b8cae8b4f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The RootHistory intends to record by whom and when the root user of the
underlying datastore backend was enabled. So the "user" column should
always be set to the context user, not the actual root user in the
database. But report_root(and report_root_enabled in
taskmanager.models) use the database user instead, this is not correct,
This patch will fix.
Also remove the "user" argument from Root.create() and
HistoryRoot.create() because the context is already passed in as an
argument when these methods are called.
Closes-Bug: #1546372
Change-Id: I3b4c8ee56c7e0876fb384f0c5841d2d391bd555d
Signed-off-by: Zhao Chao <zhaochao1984@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The following directories were fixed in this commit:
- extensions/
According to OpenStack Guideline[1], logged string message should be
interpolated by the logger.
[1]: http://docs.openstack.org/developer/oslo.i18n/guidelines.html#adding-variables-to-log-messages
Change-Id: I47b7215cd0b61c52405917ecde849a3ea1ae5e32
Related-Bug: #1642552
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All validation of requests is currently done against the MySQL datastore
models. In order to switch to using datastore extensions for validation
the models need to be refactored.
The current approach to guestagent/db/models.py is getting unruly and
is difficult to apply to other datastores.
This change moves the models from the guestagent package to the common
package, so that the extensions package can use it in the future.
That is: guestagent/db/models.py -> common/db/models.py
The generic models are separated from the datastore-specific models. For
datastores with custom models the classes have been moved to their own
sub-package.
Example: common/db/mysql/models.py
Using this new approach any datastores that want custom models just need
to create packages similar to the common/db/mysql/ package.
The code references to these models have all been updated. Non-MySQL
based datastores using these references have been switched to using the
generic models.
The tests for these models have been improved.
Change-Id: If321202a3ec4ab0f57ee8e516b885a8307d464b7
Partial-Bug: 1498573
|
| |
|
|
|
|
|
|
| |
This patch removes cfg and logging import unused in trove
Change-Id: Ic50a58123481faa37b8898565a597dcdb1f1fa46
Closes-Bug: #1618281
Closes-Bug: #1618347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added the route action for disabling the root user in the extensions.
Modified the resource extension to allow the generation of a DELETE
route on the resource itself.
Implemented root-disable on the mysql guest. Added not implemented
error messages for all other datastores.
Change-Id: I52519b86c47694c554b624d1d2fbe7a001af55fc
Partially implements: blueprint root-disable
Depends-On: I27831eb361c2b219a9623f152b9def73a2865d67
|
|
|
Adds support for root-enable for Vertica clusters,
with optional user-provided passwords. In order to
support root-enable for clusters, a new route was added.
A new VerticaRootController extends the features that
the RootController provides for clusters. This datastore
specific controller is added to the subfolder vertica
in extensions.
Added unit tests for new Vertica functionalities.
Refactoring:
1. Made this patch dependant on pxc patch, in order to be able to
address these changes for pxc clustering. Also added
rootController entry to pxc's config
2. Moved all the RootEnable code inside trove/extensions/common.
Since there was nothing specific to mysql in that code.
3. Changed the cfg.py to now include a default RootController for
all the datastores. Because without this patch all the datastores
were going through the same old mysql root controller anyways,
so no need to change the bahavior of the other datastores. Which
ever datastores don't provide root implementation they will raise
appropriate exceptions anyways.
4. If root_password is not passed then calling enable_root, if the
password is supplied then calling enable_root_with_password. That way
the datastores which provide enable_root implementation but not
enable_root_with_password can be handled correctly, appropriate
exceptions are raised to indicate to user that supplied password
will not be honored.
5. If root-enable is called on clusters, then default root controller
implementation raises exception, as other than vertica nobody
provides the implementation for it as of now. For vertica, this
is processed correctly.
Change-Id: I28209ab562b26f45742b5db65c5cc057e07f7f51
Implements blueprint: vertica-cluster-user-features
Depends-On: I3e23c87c0e48a7f910e54207116fc75b5ce0ad0c
|
