As no content will be returned to the client if a root-disable request
succeeds, a HTTP 204 (Not Content) response is more appropriate.
Redis root-disable scenario test fails because it's return HTTP 204, but
all API related tests are expecting a HTTP 200. Although changing Redis
root-disable API is a much simpler way to resolve the problem, migrating
from HTTP 200 to HTTP 204 should be a better solution. Related tests and
documents are also updated accordingly.
APIImpact
Change-Id: If732a578009fd35436e810fb7ceceefd1ada3778
Signed-off-by: Zhao Chao <zhaochao1984@gmail.com>
Doc style:
* use tildes for heading 2 (following the rst convention);
* break source lines exceeded 79 characters (rst convention);
* remove unneccessary blank lines:
* 4 blank lines between sections;
* 2 blank lines between sub-sections;
* 1 blank line between paragraphs in a section/subsection;
* no blank lines at the bottom of a source file.
* add a space after commas in the middle of a line;
Instances API:
* change the order to match the description at the begin;
* add "Update instance name";
* add "Upgrade datastore version".
Change-Id: I3520e42f6ad97cb30632cf05241cec316409c9be
Signed-off-by: Zhao Chao <zhaochao1984@gmail.com>
Ubuntu Trusty continues to get MySQL 5.6.
The selection of the MySQL version is based on the version
of Ubuntu that is installed. If the script trovestack is
invoked on Xenial, the version that is chosen is 5.7. If
it is invoked on Trusty, then version 5.6 is chosen.
The only thing that is eliminated is the dubious combination
of MySQL 5.6 on Ubuntu Xenial. This combination is probably
not supported by Ubuntu as it is down level from their
standard offering is probably not tested anywhere.
Note Xenial does not provide the 5.6 version of mysql. This
was accomplished by initializing the Apt repo with the
Trusty software repository.
The size of the root file system is increased from 3 to 4 GBs
as the Mysql Xenial image does not fit in 3 GBs. This has an
impact on the flavors that are used by Trove for testing as the
name of the flavor includes the size of the root file system.
This is turn caused a change to each of the db specific test
config files as the trove falvors are referenced in them.
Change-Id: I4f4e497208b8f4728580e48239a8ae208e0a96dd
I can create and delete a user named "mytest.abc" correctly both
with mysql-5.6 and mongodb-3.0, not as the details describe that
"Do not use periods in user names".
In addition, in order to create a mongodb database user in trove,
its format must be as "DBName.UserName". And, I can delete the users correctly!
Closes-Bug: #1652889
Change-Id: I2316943475b0bcfdb498733e221d2021b8a827a0
This is an interim commit of the changes for secure
oslo-messaging.rpc. In this commit we introduce the code for
serializers that will encrypt all traffic being sent on
oslo_messaging.rpc.
Each guest communicates with the control plane with traffic encrypted
using a per-instance key. This includes both traffic from the
taskmanager to the guest as well as the guest and the conductor.
Per-instance keys are stored in the infrastructure database. These
keys are further encrypted in the database.
Tests that got annoyed have been placated.
Upgrade related changes have been proposed. If an instance has no key,
no encryption is performed. If the guest gets no key, it won't
encrypt, just pass through. When an instance is upgraded, keys are
added.
The output of the trove show command (and the show API) have been
augmented to show which instances are using secure RPC communication
** if the requestor is an administrator **.
A simple caching mechanism for encryption keys has been proposed; this
will avoid the frequent database access to get the encryption
keys. For Ocata, to handle the upgrade case, None as an encryption_key
is a valid one, and is therefore not cached. This is why we can't use
something like lrucache.
A brief writeup has been included in dev docs
(dev/secure_oslo_messaging.rst) which shows how the feature can be
used and would help the documentation team write up the documentation
for this capability.
Change-Id: Iad03f190c99039fd34cbfb0e6aade23de8654b28
DocImpact: see dev/secure_oslo_messaging.rst
Blueprint: secure-oslo-messaging-messages
Related: If0146f08b3c5ad49a277963fcc685f5192d92edb
Related: I04cb76793cbb8b7e404841e9bb864fda93d06504
The switch to XtraBackup 2.3 was causing an issue on RHEL/Centos
related to is using the "mysql" user instead of "trove". The fix on
Ubuntu was to move the os_admin credentials to ~trove/.my.cnf. While
this is a better place to write the credentials anyway (i.e. they
shouldn't be stored in server my.cnf) this doesn't solve the whole
issue on Centos. This commit changes the XB backup strategy to pass
the user/password in on the innobackupex command line.
Also, it was noticed that the "socket" option wasn't being specified
in the config.template. This is causing some client connections,
such as XB to fail connect because it can't locate the socket.
Forcing the server/client to write/read the socket from a known
location fixes this.
Change-Id: Iea941ce60179ef4dc5c403c2fc374cc8eb7d1617
Closes-bug: 1649592
The Compute ID (server_id) and Volume ID (volume_id)
associated with a trove instance are useful information
for an administrator. This commit add these fields to the
trove show output. They will only be visible to users
with admin rights.
Change-Id: I4a39b59ae610803f5aaf849f2e20ebb6e4ea1565
Closes-Bug: 1633581
This is an initial attempt at supporting multiple regions. It should
handle the mechanics of deploying an instance/volume to a remote
region. Additional changes may be required to allow the guest
agent on the instance to connect back to the originating region.
Co-Authored-By: Petr Malik <pmalik@tesora.com>
Change-Id: I780de59dae5f90955139ab8393cf7d59ff3a21f6
This change updates the api-ref documentation with some issues
identified in an earlier review.
Change-Id: Ic769a1ae376e8569f5a13af8feada88f4cf0ac32
Closes-Bug: 1614923
Related: I3315261aa18729fa7a6aa79d4a1d6c24de1e2c6b
This patch removes some parameters which are in parameters.yaml
but are not used in other *.inc files.
Change-Id: I202c182188a0cb276d1523991500d3576011da29
Recent changes to api need to be reflected in api examples. This has
come to light because client 2.5.0 is now released.
Change-Id: I924cfd1ca93bef7f3dc79149519df10305390779
Currently, Trove api-ref is not configured with logABug feature.
When users click "Report bug" button, it leads to
"bugs.launchpad.net/openstack-manuals" which is default.
We should change it to "bugs.launchpad.net/trove/".
Change-Id: I90b37c3ef6b73daf2e05f253b9778ce548a38a1c
With this email[0], you must migrate API reference docs into RST. The
conf.py and the tox environment are also cribbed from nova.
Still need to retain the install_command in tox.ini, otherwise the
api-ref job fails.
[0] http://lists.openstack.org/pipermail/openstack-dev/2016-May/093765.html
Co-Authored-By: Anne Gentle <agentle@cisco.com>
Co-Authored-By: Amrith Kumar <amrith@tesora.com>
Change-Id: I3315261aa18729fa7a6aa79d4a1d6c24de1e2c6b