A recent change related to sudo securepath broke how sudo -E
works. Now the PATH is reset by sudo as set by tox. As a result
we can no longer rely on sudo -E anywhere in our gating system
relating to path inheritence from the parent shell.
This patch uses a shell operation in the setup_nodes.yml code
to chmod the docker socket to 666 so docker containers can build
properly. Now docker operations don't return a permission denied
and we no longer require the sudo -E operation in any of our tox
scripts. This isn't a security vulnerability because our gate
scripts are only meant to be run in OpenStack infrastructure.
To make this more clear I recommend moving these shell scripts to
tests/gate.
Change-Id: I5b3d6e280e3c12a25defedb14b5589ba642043fa
Closes-Bug: #1562383
Avoids errors about missing journalctl on Ubuntu and missing upstart on
redhat bases.
Closes-Bug: 1554724
Change-Id: I80bb55688398df85f9020d5cfe5dda757fc5a0ef
As with all tools, this is a first pass at the generation. Perhaps we
even want to move this into kolla/kolla/cmd and be generated with tox
itself in the future.
This tool, when run, will only populate empty fields that have no
values meaning that it is safe to run repeatedly on the same file.
Of note, there is no way to preserve comments in the file after it has
been processed by the yaml parser in python. Comments and sections
will remain in the passwords.yml template for additional documentation
if the user wishes to populate the file themselves.
Use SystemRandom and clean up the docs a bit to not use pronouns.
Co-Authored-By: Steven Dake <stdake@cisco.com>
Closes-Bug: #1559266
Change-Id: I2932d592df8871f1b7811059206d0b4d0553a687
This also fixes this version check utility since it was utterly broken
before. While it did run to completion, it never properly returned any
versions that needed updating.
TrivialFix
Change-Id: If5d77f20fd8fc97679d58bc9019115157c5f5967
Some gates are failing to properly pull all logs out resuling in an
UNSTABLE status.
This resets all logs to 777 perms to ensure readability by jenkins.
TrivialFix
Change-Id: Ib92c5bfea5fa8bcc6380ad8aa6001b13888717ac
This playbook only matters for multinode since AIO can recover from
power outage without additional configuration.
DocImpact
Implements: blueprint mariadb-lights-out
Change-Id: I903c3bcd069af39814bcabcef37684b1f043391f
Currently the binary build for the oraclelinux base is just exceeding
the 10GB limit we have set here. Centos is at just under 9GB so will not
be long before it reaches this limit also.
According to infra -
(http://docs.openstack.org/infra/system-config/contribute-cloud.html)
gate VMs should have a 80GB disk, so 20GB for the docker partition does
not seem excessive here.
TrivialFix
Change-Id: I4d7fb240ea90e1e58f8f8046dd7acd0b9502c20d
This change is a "futureproofing" thing. It has already been discussed
that libvirt should not be a child of nova and should be removed out
to the base docker directory (just like openvswitch isn't a child of
neutron). That is not going to happen this cycle but when it does we
can't change the name of the volume. This updates the volumes to the
proper name of libvirtd. This is in contrast with the libvirtlogd
volume that will be needed in newton due to libvirt 1.3
Of note, the container can remain named nova_libvirt since we can
change that on the fly later without breaking instances.
This wont break liberty as named_volumes are not backported yet.
TrivialFix
Change-Id: I16cf9e1b1dbba9b5a9f5cc883494580e276d4f72
The rabbitmq-server package is upgraded to 3.5.7 in cloud-archive
so we update centos to match
The xen-utils package now needs an explict version, xen-utils-4.6 is
what is provided by cloud-archive mitaka
Libvirt 1.3 is in the ubuntu cloud-archive. This has a new daemon for
logging that needs further implementation in newton. For now, it has
been disabled within the qemu.conf
Co-Authored-By: Jeffrey Zhang <jeffrey.zhang@99cloud.net>
TrivialFix
Change-Id: I84217824817c484b6800a64cbd7767b127a3098e
Add cron image and playbook for logrotate.
The "common" Ansible playbook includes configuration files for
logrotate. At this point the operator cannot customize/override the
logrotate configuration.
Closes-Bug: #1553244
Change-Id: Ic9fdda9a273c9ccd90502f0acc7614d2c7157dca
Heka logs almost done. When testing, The collected logs can copy
to the /tmp/logs folder, which will be handle by the gate. This
will be very useful for our gate debug.
TrivialFix
Change-Id: I06ca8ebd13933bfd15cb2fb5e53fc3038b17b8c3
As we will be switching to pinning versions in Kolla this tool will
help remove the 'manual' part of that equation by looking up the
versions we want.
The idea would be to eventually turn this into an autoproposal bot so
we only ever need to approve changes.
More work can be done here like automatically updating the
kolla-build.conf
Co-Authored-By: Martin André <m.andre@redhat.com>
Partially-Implements: blueprint upgrade-kolla
Change-Id: I052159850b2579ca6db79be71672be382be8a3a3
This patch includes changes relative to integrating Heka with
Elasticsearch and Kibana.
The main change is the addition of an Heka ElasticSearchOutput plugin
to make Heka send the logs it collects to Elasticsearch.
Since Logstash is not used the enable_elk deploy variable is renamed
to enable_central_logging.
If enable_central_logging is false then Elasticsearch and Kibana are
not started, and Heka won't attempt to send logs to Elasticsearch.
By default enable_central_logging is set to false. If
enable_central_logging is set to true after deployment then the Heka
container needs to be recreated (for Heka to get the new
configuration).
The Kibana configuration used property names that are deprecated in
Kibana 4.2. This is changed to use non-deprecated property names.
Previously logs read from files and from Syslog had a different Type
in Heka. This is changed to always use "log" for the Type. In this
way just one index instead of two is used in Elasticsearch, making
things easier to the user on the visualization side.
The HAProxy configuration is changed to add entries for Kibana.
Kibana server is now accessible via the internal VIP, and also via
the external VIP if there's one configured.
The HAProxy configuration is changed to add an entry for
Elasticsearch. So Elasticsearch is now accessible via the internal
VIP. Heka uses that channel for communicating with Elasticsearch.
Note that currently the Heka logs include "Plugin
elasticsearch_output" errors when Heka starts. This occurs when Heka
starts processing logs while Elasticsearch is not yet started. These
are transient errors that go away when Elasticsearch is ready. And
with buffering enabled on the ElasticSearchOuput plugin logs will be
buffered and then retransmitted when Elasticsearch is ready.
Change-Id: I6ff7a4f0ad04c4c666e174693a35ff49914280bb
Implements: blueprint central-logging-service
Due to poor planning on our variable names we have a situation where
we have "internal_address" which must be a VIP, but "external_address"
which should be a DNS name. Now with two vips "external_vip_address"
is a new variable.
This corrects that issue by deprecating kolla_internal_address and
replacing it with 4 nicely named variables.
kolla_internal_vip_address
kolla_internal_fqdn
kolla_external_vip_address
kolla_external_fqdn
The default behaviour will remain the same, and the way the variable
inheritance is setup the kolla_internal_address variable can still be
set in globals.yml and propogate out to these 4 new variables like it
normally would, but all reference to kolla_internal_address has been
completely removed.
Change-Id: I4556dcdbf4d91a8d2751981ef9c64bad44a719e5
Partially-Implements: blueprint ssl-kolla
Working towards the blueprint that will add TLS protection
for the external endpoints, kolla needs certificates.
When kolla deploys OpenStack, the external VIP will need
a server side certifcate. Clients that access those endpoints will
need the public CA certificate that signed that certificate.
This ansible script will create these two certificates to make
it easy to use TLS in a test environment. The generated
certificate files are:
/etc/kolla/certificates/haproxy.pem (server side certificate)
/etc/kolla/certificates/haproxy-ca.pem (CA certificate)
The generated certificates are not suitable for use in a
production environment, but will be useful for testing and
verifying operations.
Partially-implements: blueprint ssl-kolla
Change-Id: I208777f9e5eee3bfb06810c7b18a2727beda234d
