This patch adds support for external Ceph clusters for Cinder.
For clean integration the backend configuration mechanism had to be
slightly adjusted.
We now have the option to enable multiple backends for Cinder
independently.
Currently, the flags cinder_backend_iscsi and cinder_backend_ceph are
used to toggle backends.
Documentation on how to use external ceph was added.
Change-Id: I7e0267b90d62d6d881f24f063cdb894422ec8618
Partially-Implements: Blueprint: external-ceph
Most simple implementation of external ceph support.
We use INI merge to configure RBD backend for Glance and copy
ceph.conf and keyring provided by the user into the container.
Set_configs.py had to be extended to support globbing (wildcards) in
order to copy ceph keyring file which is named depending on the cephx
user name.
Partially-Implements Blueprint: external-ceph
Partially-Implements Blueprint: selectable-ceph
Change-Id: Iacadbd8ec9956e9f075206ea03b28f044cb6ffb8
To use Cinder LVM2 backend with iSCSI,
add enable_iscsi option and fix document.
Change-Id: I286733508b5582c311c313c172b3c3a774be993c
Closes-Bug: #1599088
This introduces a new configuration parameter neutron_enable_qos to
be able to enable the Neutron QoS service plugin.
More details about the Neutron QoS service plugin are available at:
http://docs.openstack.org/liberty/networking-guide/adv-config-qos.html
Change-Id: I8525bf4dce5f1e225f72a4e1c3760b64a36b17f6
Closes-bug: #1593183
Implements: bp netowrking-qos
Previously, kolla did not support neutron lbaas functionality.
Only Lbaasv2 is supported in Mitaka. Additional information can
be found here:
http://docs.openstack.org/mitaka/networking-guide/adv-config-lbaas.html
Magnum uses Neutron Lbaas to provide high availability to COE API
and Etcd endpoints within a bay. Therefore, Neutron Lbaas is required
for Kolla to support Magnum.
Co-Authored-By: Serguei Bezverkhi <sbezverk@cisco.com>
Partial-Bug: #1551992
Change-Id: I05360b7c447c601fcb3c2b6b2a913ef5cc0f3a1b
This fix adds several variables required for Cinder iSCSI backend
configutation.
Change-Id: I2f709f8589fdbf62e3d0b265452fd58f413bee65
Closes-Bug: #1579800
The nova_ssh_private_key and nova_ssh_public_key is useless, and
they should not be merged.
Change-Id: I7e7178398242060a78fe7caee6e14fa77f2ffe35
Closes-Bug: #1576199
Add a nova-ssh container to handle the `nova migrate` and
`nova resize` case, in which the nova will use ssh to copy
files between machines.
Change-Id: Ie6675943f3aeabfbba8589d308d55b9c89d732db
Closes-Bug: #1562141
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
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
The user variable was incorrectly in passwords.yml
The naming was inconsistent, it should be prefixed with manila_*
Removed old unused variable
TrivialFix
Change-Id: I182797fcc6d62d35174403d78d71c8ad7ddcbc43
The in-process cache for keystone tokens has been deprecated due to
"incosistent results and high memory usage" with the expectation we
switch to memcached_servers if we want to stay performant.
Add memcache_servers [cache] section to the appropriate servers as the
[DEFAULT]\memcache_servers options was deprecated.
TrivialFix
Related-Id: Ied2b88c8cefe5655a88d0c2f334de04e588fa75a
Change-Id: Ic971bdddc0be3338b15924f7cc0f97d4a3ad2440
The parameter values in global.yml were inconsist,
for some variable default values are shown while for
others it's not.
From user point of view it is important to know
the default values of the parameters and the globals.yml is
the file where user is supposed to look for config variable,
for sure a user do not want to look kolla/ansible/group_var/all.yml
file just for checking default values. So it is better to show all
default values in global.yml
This patch will solve this issue.
TrivialFix
Change-Id: I991fc5e1d4ed48d106da002a0f18a2b31525a482
This patch adds some explanations for different options available
in /etc/kolla/globals.yml for customizing swift configuration.
Trivial fix
Change-Id: Iaf03f5293804d63c87d8881ac4282909a81b0bfe
Changed docker_registry placeholder for consistency with
documentation; port 4000 is used instead of Docker's default port
5000 to avoid conflicts.
TrivialFix
Change-Id: I539547ce573642022ccdf1fbb47b4adc2f852ff2
In kolla/ansible/group_vars/all.yml config_strategy is COPY_ALWAYS
In kolla/etc/kolla/globals.yml the default value shown is COPY_ONCE
TrivialFix
Change-Id: If7000b811715c6cb84af3539cb522c22d31dc03b
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
Admin token has been deprecated upstream. It will be removed in O. We
switch over to the new `keystone-manage bootstrap` method for creating
the initial admin user, role, and project.
Co-Authored-By: Sam Yaple <sam@yaple.net>
Change-Id: I6ca90e8d4c3b71009e24b049b2efbc08c05ebfbf
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