To be kolla deploy multiple clouds, we need to be able to configure
virtual_router_id other wise haproxy will fail setup the VIP for the
second cloud.
Partially-Implements: blueprint multiple-cloud
Closes-Bug: #1564547
Change-Id: I9eb27dd6fba61205841eadafc96601e235d2fe6d
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
Ubuntu did not have mod_headers enabled by default
Remove unused variable and adjust 'when' conditional positioning
TrivialFix
Change-Id: I82b8724526c24f4481a80165520d624f6a02c336
TLS can be used to encrypt and authenticate the connection with
OpenStack endpoints. This patch provides the necessary
parameters and changes the resulting service configurations to
enable TLS for the Kolla deployed OpenStack cloud.
The new input parameters are:
kolla_enable_tls_external: "yes" or "no" (default is "no")
kolla_external_fqdn_cert: "/etc/kolla/certificates/haproxy.pem"
kolla_external_fqdn_cacert: "/etc/kolla/certificates/haproxy-ca.crt"
Implements: blueprint kolla-ssl
Change-Id: I48ef8a781c3035d58817f9bf6f36d59a488bab41
After our switch to keystone-manage bootstrap Horizon is not happy
due to v3 not being setup correctly. This patch fixes that
This also includes removal of unused variables (transforms them into
endpoint url variables)
TrivialFix
Change-Id: I1e04db8c24049f80e974c063f03068a2ab32a563
Due to the fact COPY_ONCE is not how most people expect the container
to work, as well as causing additional delays in the reconfigure
process by needing to delete and recreate teh container, we should
default to COPY_ALWAYS. It is both how operators and deployers expect
things to work and allows a quick restart to pull in a new config.
TrivialFix
Change-Id: Ie5f043fc66aa85378f456017c9e31ddbbe6d8880
Use kolla_internal_vip_address for kolla_internal_fqdn in the all.yml
file. In this way, the global.yml no need set the old/deprecated
kolla_internal_address variable.
TrivialFix
Change-Id: I0768b9a2b615afb6a8b1f7c065189a495b8f9c9b
This runs first sanity check for swift. Once
swift is deployed it checks list()
Change-Id: I613bf9f2893d66814863893ec5acde5aa252548d
Partially-Implements: blueprint sanity-check-container
This runs first sanity check for cinder. Once
cinder is deployed it checks volumes.list()
Change-Id: I1b4cc57f21cf0fa52a391229c2c2b3fa995d32a8
Partially-Implements: blueprint sanity-check-container
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
To improve security, operators have asked for two VIPs for
their cloud.
VIP 1 is the internal VIP that can reach internal and admin endpoints.
In addition, the internal VIP can also reach other internal services,
such as the database and message services.
VIP 2 is the external VIP that can only reach public endpoints.
With one VIP only, all services are reached at the same address.
To add a second VIP, this patch adds two new configuration parameters.
kolla_external_vip_address: is an IPv4 address to use for created VIP
kolla_external_vip_interface: is the network interface to use for VIP
In this scenario, the first VIP (the internal VIP), is defined by
the original parameters (kolla_internal address and network_interface).
When using two VIPs, the existing kolla_external_address parameter
should be/point to/resolve to the kolla_external_vip_address.
Closes-bug: 1535333
Change-Id: I5bfcefaf7899298455cdade8209c34324aebfecb
To allow for TLS to protect the service endpoints, the protocol
in the URLs for the endpoints will be either http or https.
This patch removes the hardcoded values of http and replaces them
with variables that can be adjusted accordingly in future patches.
Change-Id: Ibca6f8aac09c65115d1ac9957410e7f81ac7671e
Partially-implements: blueprint ssl-kolla
Part of ELK stack. Includes Dockerfiles for both Centos and Ubuntu.
Change-Id: I9f76adf084cd4f68e29326112b76ffd02b5adada
Partially-implements: blueprint central-logging-service
Part of ELK stack. Includes Dockerfiles for both Centos and Ubuntu.
Change-Id: I1d955a5c51e416cc572eb2c9b4c57982a1d6ab67
Partially-implements: blueprint central-logging-service
It's good if k8s reuses ansible templates, but we need to abstract all
ansible specific variables to achieve that.
- Implements ansible override variable api_interface_address.
- Adds api_interface_address setting and comments to globals.yml
- Makes changes to mariadb templates to accept this new setting.
- Disabled Galera when api_interface_address==0.0.0.0 in the
case of Kubernetes. Otherwise, mariadb fails to start.
- Tested with and without setting to ensure kolla genconfig output
does not change when setting is disabled or undefined.
Change-Id: Ia0e4951c327be01b717aebb86ef4c3a4e7ed170e
Partially-implements: blueprint api-interface-bind-address-override
Co-authored-by: David Wang <dcwangmit01@gmail.com>
Co-authored-by: Ryan Hallisey <rhallise@redhat.com>
Co-authored-by: Kevin Fox <kevin@efox.cc>
Use a lower number of workers rather than the default value, which is
equal to the number of the cpu. Otherwise, in a multi cpu environment,
the number of the processes will very high.
In this PS, we use min(5, << number of cpu >>) as the default worker
count.
Closes-Bug: #1582254
Change-Id: I1c32cf0db794b43b8fb8be18f39190422ca5846f
Previous work on Watcher added the Docker images, this
change adds the ansible configuration.
There is support for HA, via haproxy to balance across the
Watcher API hosts.
There is also a hook into nova.conf to conditionally add
Nova compute Host metrics via Ceilometer if Watcher is enabled.
This defaults to enabled false.
Change-Id: I8763528bb6ff12943b810212c71396d2d7cf6836
Partial-bug: #1598929
Partially-implements: bp watcher
Signed-off-by: Dave Walker (Daviey) <email@daviey.com>
Update the group_vars and globals docuementation as well.
Change-Id: I3ffd49b8d99667425596a2753845767a62e05bf1
Partially-Implements: blueprint kolla-docker-module
- See instructions in doc/nova-fake-driver.rst
Implements: blueprint nova-fake-driver
Change-Id: I553a40c2df39bdcc391eb1b8b2b8fd5f4ed48c33
Signed-off-by: Hui Kang <kangh@us.ibm.com>
Signed-off-by: Marcio D. Silva <marcios@us.ibm.com>
The upstream docker module in control of Ansible has proven to be a
major breaking point for Kolla. It is the reason we have a cap on
Docker of 1.8.2. They have stated no support for the Docker registry
v1 moving forward. We have to wait for a patch to land and then
upgrade to the latest Ansible version to take advantage of a new
Docker feature. Doing that is slow and it is not always possible to
upgrade if there are other breaking changes (aka ansible 2.0).
For these reasons we can build our own Docker module.
Partially-Implements: blueprint kolla-docker-module
Change-Id: I2ca57010c45710635cfe80ff23a2a5e2edabee57
Master version was still set to 1.0.0. This became alot more obvious
in a recent patch when we started pulling that version number for the
tag...
TrivialFix
Change-Id: Ie9c95a4dc606d0527c44fcd624b4473e45f7f3cf
This changes default behaviour of build.py to instad of putting latest
tag on it, it puts current kolla version as found in setup.cfg
Change-Id: I4d6e9a0159c6a5598abd58072594df4204427308
Partially-Implements: blueprint upgrade-nova
Partially-Implements: blueprint record-version
This runs first sanity check for glance. After glance is deployed
it checks images.list(). Also consist few fixes for previous patches
Change-Id: I03d05d246302d8411b2e94c94ca7fe046c00d735
Partially-Implements: blueprint sanity-check-container
This runs first sanity check for keystone. After keystone is deployed
it checks tenants.list()
Change-Id: Ie919ffe6124eb70428309404a434d9b0eb0b9f70
Partially-Implements: blueprint sanity-check-container
The main reason for this change is to allow the DinD stuff to work. It
has limited use outside of that use case, but it may still be useful
to others in the future.
Change-Id: Ib3a4639cfb3fc0d378d33fc8b9ff8eb597f818ab
Partially-Implements: blueprint multinode-gate
