There are a couple of places that still use a hardcoded
127.0.0.1 value, even if devstack is run with
SERVICE_IP_VERSION=6 in local.conf. While things still
work, SERVICE_LOCAL_HOST should be used instead since
everything else could be using IPv6.
Change-Id: I2dd9247a4ac19f565d4d5ecb2e1490501fda8bca
This patch allows to skip the installation
of the database backend packages (MySQL or Postgres)
with the introduction of the INSTALL_DATABASE_SERVER_PACKAGES
variable (defaulted to True).
This is useful in such environments that do not require
to install the MySQL/Postgres server packages directly but using
a container serving that purpose, for those cases all the
remaining steps should be executed just skipping the
packages install.
Change-Id: I26628a31fdda3ce95ed04a2b7ae7b132c288581f
mysqladmin is incorrectly installed in Fedora 34 with mariadb. This
causes the failure of Zuul Fedora based jobs. The issue is a conflict
between mariadb and community mysql that is described in [1] and [2].
The workaround is to explicitly install package "mariadb"
Also configure an increased swap size like for the other platform jobs
in order to avoid OOM issues.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2026933
[2] https://lists.launchpad.net/maria-discuss/msg06179.html
Closes-Bug: #1956116
Change-Id: Icf6d7e1af5130689ea10b29d37cc9b188b2c9754
Some adaption in database handling is all that is missing. Also add a
platform job that tests this.
Co-Authored-By: Radosław Piliszek <radoslaw.piliszek@gmail.com>
Change-Id: I6dd3e48444dd415d84df5e7f5c74540847cdd6db
We have lib/databases/mysql which is installing databases, remove it
from the bulk package lists.
Split is_fedora (fedora & centos8 -- soon) to install mariadb-server
and mariadb-devel to retain status-quo.
On suse this seems to be a meta-package
'mariadb-server' not found in package names. Trying capabilities.
so split that out. It seems it has never been installing the -devel
package, and things work (presumably clients are coming from wheels so
don't need to build against it).
Change-Id: I86433318e8f76c40c5c792b795411a5c9d8351d3
The GRANT command in mysql8 can no longer create a user implicitly.
Split that part into a dedicated CREATE USER command.
Also drop disabling the query_cache, it is off by default for some time
and the option got removed in mysql8.
Change-Id: I31bcc285ff8e373abbacb303c1269857c9cfa9ed
This variable can be now set in Devstack's config file and in
such case Devstack will not set it automatically to value most
likely correct for the distro.
By default this value is empty string and in such case Devstack
will work in exactly same way as it was before this patch and
will determine automatically what name should be used there.
In addition in case of Ubuntu package $MYSQL_SERVICE_NAME-server
will be now installed instead of mysql-server always.
This will allow to easy configure e.g. CI job which will run using
Mariadb instead of Mysql on Ubuntu.
Change-Id: I25af0b54ad235b08c6c399b4125c737acf57ee2e
Based on resolution [1], there's no clear indication that next
steps involve the removal of the DB from Devstack or from the gate.
[1] I332cef8ec4539520adcf37c6d2ea11488289fcfd
This reverts commit d9aaae95f2b84170bf35e037715e4963d89f940c.
Change-Id: I8410d65c0e0b24035aa035fac7560a686d53ec50
This reverts commit 168ca7f0a474f1207ee01dab0ca2e70f34783e9c.
Removing postgresql support from devstack was unnecessary
since it's not broken and not causing maintenance issues
as far as I know. The commit being reverted said that pg
support was deprecated in Pike but nothing in the docs or
commit message refer to official deprecation of postgres
support in devstack or openstack in general. Not to mention
that there are still postgres-based jobs that will no
longer work *and* the notification to the mailing list about
doing this happened *after* it was already done [1] leaving
stakeholders with no time to reply.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010196.html
Change-Id: Ie7036d37d79e6aba462b7c97f917e2e7aed108f9
This was deprecated for removal in Pike. It's probably time to drop it.
Note that the 'postgresql-devel'/'postgresql-server-dev-all' packages
are retained since some packages still include 'psycopg2' in their
general requirements.
Change-Id: I51e8354e99972757253ce259e6c03c91da24398c
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Older mariadb packages on SLES 12 provided mysql.service. The newer
ones on SLES 12 and 15 use mariadb.service; they also provide a
mysql.service symlink for backwards-compatibility, but let's not rely
on that.
Change-Id: Ife6bd007ba30af0b77d44832b19d518034bdb12b
Leap 15.0 has been released May 25th, 2018 (see
https://en.opensuse.org/Portal:15.0 ) and we'd like to
transition devstack against it and remove Leap 42.3 from
the testing matrix. Leap 15.0 is newer than Leap 42.3 as
the numbering schema of openSUSE was changed.
Co-Authored-By: Antonio Ojea <itsuugo@gmail.com>
Change-Id: I078f9a2580160c564c33e575008516f5e92239d6
- There are some locations where we need the raw IPv6 address instead of the
url-quoted version enclosed in brackets.
- Make nova-api-metadata service listen on IPv6 when we need that.
- Use SERVICE_HOST instead of HOST_IP for TLS_IP.
Change-Id: Id074be38ee95754e88b7219de7d9beb06f796fad
Partial-Bug: 1656329
The mysql-community-server is a compat provide, openSUSE uses
mariadb for quite some time. Make it futureproof in case
the compat provide goes away in the future. Cleanup
mysql service name to MYSQL_SERVICE_NAME and consistently
use it.
Change-Id: I2df7b8d8b798dfa7ceade90e0c127e0609524a8b
In Fedora mariadb, cracklib has been enabled [0] in order to verify the
password strength.
Disable cracklib in Fedora devstack in order to allow simple passwords
in dev environments.
[0] https://src.fedoraproject.org/cgit/rpms/mariadb.git/
commit: 9442da192282aa74f43e86c96202109a173bbaba
Change-Id: I2d5e965f0f19f86992794eec78134e862899c931
The diet seems to be too strict, jobs failing with "out of sort memory". Needs more investigation before resubmitting.
This reverts commit 1e66388c5f2b81b4fc5d544dbf5fde2935218bd0.
Change-Id: Ic10effaaf047eb3527082baab889772c5e57fa90
We propose several MySQL configuration parameter changes (with
explanations) to reduce the memory footprint of MySQL. A demonstration
of the improvement is provided in
https://etherpad.openstack.org/p/change-438668.
As Clint provided some of the descriptions that I've used, I have
listed him as a co-author (thanks Clint). Let this serve as a warning
to all that commetors may be enlisted :)
Change-Id: Icb2d6ea91d3d45a68ce99c817a746b10039479cc
Co-Authored-By: Clint 'SpamapS' Byrum <clint@fewbar.com>
We currently use a more permisive STRICT_ALL_TABLES mode, but that's
not what modern MySQL versions default to (i.e. TRADITIONAL):
https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode-changes
(non-Devstack deployments will most likely use TRADITIONAL as well)
Due to the fact that we default to TRADITIONAL in oslo.db, this
produces annoying warnings on MySQL 5.7 versions we use in the gate:
Warning: (3090, u"Changing sql mode 'NO_AUTO_CREATE_USER' is
deprecated. It will be removed in a future release.")
https://git.openstack.org/cgit/openstack/oslo.db/tree/oslo_db/options.py#n49
Unlike STRICT_ALL_TABLES, TRADITIONAL mode includes NO_AUTO_CREATE_USER,
and MySQL emits this warning on switching it on:
https://dev.mysql.com/worklog/task/?id=8326
So we have two options here:
1) make oslo.db default to STRICT_ALL_TABLES
2) make Devstack default to TRADITIONAL
The latter seems to be more appropriate as:
1) it's what modern MySQL versions default to
2) it's what people are actually using, if they do not override the
oslo.db default
3) it's more strict
Closes-Bug: #1652452
Change-Id: Ie6d823c9f8465ac9f2ce4825929d1a50438fab45
On Ubuntu nodes, devstack tries to predefine the initial mysql root
password by doing some debconf-set-selections, but these will not take
effect if the corresponding package has been installed earlier. So
just try to set it every time, like we do on other distros.
Change-Id: I2c167051fc5e53dd0ccf82a60ab085cd9cdea28d
Role "root" it is hardcode.
In general case role name comes from local.conf: string "DATABASE_USER="
Change-Id: Iedfca48e04d23c313851f48d68ac40ba29340805
postgresql 9.3 don't create /etc/postgresql and related conf file by
default. So we need start the pg_createcluster in devstack if has not
started after package installed.
Change-Id: I2b348658d79b23b5f21871b33d8023499b2fb956
Close-bug: #1552051
in fedora postgresql is the service name and postgresql-server is
the package.[1]
os: Fedora release 23 (Twenty Three)
psql: psql (PostgreSQL) 9.4.5
i'm not entirely sure when this changed, but it's devstack is broken
in above environment.
[1]https://fedoraproject.org/wiki/PostgreSQL
Change-Id: Id940fed2a777ca469ce77402e1136251ba572359
Solve the devstack ./rejoin-stack.sh when is reboot-safe in RHEL 7.
Enable mysql, postgresql, rabbitmq-server, openvswitch service when on boot.
Change-Id: I3ce9fc58ccc76092ad08314de1c3c9339ebfb3b5
Related-Bug: #1486833
I noticed this when debugging some grenade issues failures.
An include of grenade/functions stores the current value of XTRACE
(on) and disables xtrace for the rest of the import.
We then include devstack's "functions" library, which now overwrites
the stored value of XTRACE the current state; i.e. disabled.
When it finishes it restores the prior state (disabled), and then
grenade restores the same value of XTRACE (disabled).
The result is that xtrace is incorrectly disabled until the next time
it just happens to be turned on.
The solution is to name-space the store of the current-value of xtrace
so when we finish sourcing a file, we always restore the tracing value
to what it was when we entered.
Some files had already discovered this. In general there is
inconsistency around the setting of the variable, and a lot of obvious
copy-paste. This brings consistency across all files by using
_XTRACE_* prefixes for the sotre/restore of tracing values.
Change-Id: Iba7739eada5711d9c269cb4127fa712e9f961695
stack.sh creates a user-specific configuration file ~/.my.cnf for mysql.
If devstack is installed with SERVICE_IP_VERSION=6 option in local.conf,
the IPv6 host address was stored in the ~/.my.cnf file with square
brackets. However mysql does not use bracketing for IPv6 addresses,
resulting in 'Unknown MySQL server host' error when 'mysql' command is
run. With this patch IPv6 host address is written to ~/.my.cnf without
brackets.
Closes-Bug: #1516776
Change-Id: I27a7be8c75cf6b09b4a75dc4c9d09cd36bc5ac81
If all databases drivers are loaded, MySQL SQLAlchemy driver
overrides all the other one that might not have set one.
This patches fixes that.
Change-Id: If6d8d08e5b7b7c48ca012677b536d71058def6fd
Closes-Bug: #1493304
The existing mysql code is wrong and not detected as failing [1], and
boto config requires work-arounds [2,3] that are all fairly ugly. Use
-sudo argument to iniset to handle this.
[1] I24388b5de777995f92d73076524122cf599d6371
[2] I5f4c43bbbe477c570936e2e40ac05cc38febbb3f
[3] Ib7556dac9aaaf2f3c96237e0ca28ed6ae1b1b7ac
Change-Id: Iaceb8d42ce37be728adae6fd0a30a1f9d33d4029
devstack attempts to set bind-address, sql_mode, default-storage-engine,
max_connections, query_cache_type and query_cache_size.
However the bash command is missing some '&&'s and was omiting
max_connections, query_cache_type and query_cache_size.
Change-Id: I24388b5de777995f92d73076524122cf599d6371
By default, most Openstack services are bound to 0.0.0.0
and service endpoints are registered as IPv4 addresses.
With this change we introduce two new variables to control
this behavior:
SERVICE_IP_VERSION - can either be "4" or "6".
When set to "4" (default if not set) devstack will operate
as today - most services will open listen sockets on 0.0.0.0
and service endpoints will be registered using HOST_IP as the
address.
When set to "6" devstack services will open listen sockets on ::
and service endpoints will be registered using HOST_IPV6 as the
address.
There is no support for "4+6", more work is required for that.
HOST_IPV6 - if SERVICE_IP_VERSION=6 this must be an IPv6
address configured on the system.
Some existing services, like the Openvswitch agent, will continue
to use IPv4 addresses for things like tunnel endpoints. This is
a current restriction in the code and can be updated at a later
time. This change is just a first step to supporting IPv6-only
control and data planes in devstack.
This change is also partly based on two previous patches,
https://review.openstack.org/#/c/140519/ and
https://review.openstack.org/#/c/176898/
Change-Id: I5c0b775490ce54ab104fd5e89b20fb700212ae74
Co-Authored-By: Sean Collins <sean@coreitpro.com>
Co-Authored-By: Baodong Li <baoli@cisco.com>
Co-Authored-By: Sridhar Gaddam <sridhar.gaddam@enovance.com>
Co-Authored-By: Adam Kacmarsky <adam.kacmarsky@hp.com>
Co-Authored-By: Jeremy Alvis <jeremy.alvis@hp.com>
With PyMySQL in the projects we can expect things to happen more
concurrently now. The query cache is a hinderance to concurrency, and
more connections will be required.
Change-Id: Icfb8cdbb9ed39cfd7732ad05fe740e01c767af7b
Some projects (Neutron) seem to be affected more than others, so we should revert this
to allow for a more selective choice of the DB driver on a per project basis.
We can re-enable the use MySQL-python just for Neutron.
This reverts commit de8d29ed8ce4a26b61cbee48f9fe5418d5416a06.
Related-Bug: #1464612
Change-Id: I889f4f8b116c413b300ab9eecc7b428a9a4afb1a
The failure rate with neutron is too high to keep this
as the default.
Related-Bug: #1464612
This reverts commit b3798af474955368211a297ba85332fde5491993.
Change-Id: Ie9550aeb25d472a38e3d3ef6f3711622c9221c46
As discussed in the Liberty Design Summit "Moving apps to Python 3"
cross-project workshop, the way forward in the near future is to
switch to the pure-python PyMySQL library as a default.
https://etherpad.openstack.org/p/liberty-cross-project-python3
Change-Id: Ic609ce136061b753ca692b37509a0b29c60bb8b5
This creates a new pip_install_gr that installs from global
requirements allowed versions. Now that stable branches are getting
capped all of devstack needs to be fixed to do things like this.
Change-Id: I8fd0ef2bfc544ca2576fab09d3018f760b8848fe
Most of the changes revolves around using MySQL rather than MariaDB,
plus enabling the addon repos on public-yum.oracle.com.
The patch just touch the areas where there is a divergence between the
Fedora and Oracle distributions and in all other cases the is_fedora
will result in the correct decision to be made and left as is.
Collapsed the is_suse and is_oraclelinux into a single check in
configure_database_mysql and cleanup_database_mysql
Added Oracle Linux to MAINTAINERS.rst
Rather than duplicating most of the Redhat version check code, added
a check in the block to do the determination if it is Oracle Linux
Change-Id: I5f1f15106329eec67aa008b17847fa44863f243f
Adds USE_VENV to globally enable/disable use of virtual environments.
ADDITIONAL_VENV_PACKAGES is used to manually add packages that do not
appear in requirements.txt or test-requirements.txt to be installed
into each venv. Database Python bindings are handled this way when
a dataabse service is enabled.
Change-Id: I9cf298b936fd10c95e2ce5f51aab0d49d4b7f37f
This is a follow-on to comments in https://review.openstack.org/156356
and https://review.openstack.org/#/c/151513/
* Remove work-around for /var/cache/pip
* Remove WHEELHOUSE setting in tools/build_wheels.sh and use the pip
default directory '<cwd>/wheelhouse'
* Remove bogus MySQL-python install
* Removed unused bits and clean up pip commands in from tools/build_venvs.sh
Closes-Bug: #1423720
Change-Id: I0283b0dff9146b1b63bd821358505a93566270c6
Building a bunch of virtual envs later is going to be tedious if we do not
pre-cache certain annoying-to-build packages.
* tools/build_wheels.sh: pre-build some wheels for annoying package installs
* list distro package dependencies in files/*/venv
* list packages to pre-build as wheels in files/venv-requirements.txt
* install database Python modules when setting up the database
Change-Id: Idff1ea69a5ca12ba56098e664dbf6924fe6a2e47