keystone_*_url are cross role variables. They are used in multi roles.
Move them from the common role to the group vars
TrivialFix
Change-Id: If451823ed7612bfec7bc797ec9dd2597164c6804
Note: This should not result in any behavior changes in regular Kolla,
just Kolla-Kubernetes and only when you've overridden stuff in globals.yml
Allows override of interface address and memcached pools, so that
Kubernetes can do the right thing.
There are some significant architectural issues involved in
memcached pooling in the Kolla-kubernetes world. Avoiding them right
now.
Current working Kolla-Kubernetes globals.yml file, assuming that your
memcached servers are available under the DNS alias "memcached":
api_interface_address: "0.0.0.0"
memcached_servers: "memcached"
keystone_database_address: "mariadb"
keystone_admin_url: "{{ admin_protocol }}://keystone-admin:{{ keystone_admin_port }}/v3"
keystone_internal_url: "{{ internal_protocol }}://keystone-public:{{ keystone_public_port }}/v3"
keystone_public_url: "{{ public_protocol }}://keystone-public:{{ keystone_public_port }}/v3"
Co-authored-by: Ryan Hallisey <rhallise@redhat.com>
Change-Id: I5126f81da7b4d48001b87f73d58bbbfad658209c
Partially-implements: blueprint api-interface-bind-address-override
Note: This should not result in any behavior changes in regular Kolla, just Kolla-Kubernetes and only when you've overridden stuff in globals.yml
Binds to the api_interface_address variable and uses the keystone and memcached facts we defined in earlier patches.
Co-authored-by: Ryan Hallisey <rhallise@redhat.com>
Change-Id: I8610f4adaa557a21fedd05601e10f5c308fd7ce3
Partially-implements: blueprint api-interface-bind-address-override
enable_rabbitmq_cluster is now a "yes" by default but you can set it
to "no" if you want to disable clustering under any circumstances.
The agreement made at OpenStack in Austin was that Kolla-Kubernetes
would concentrate on RabbitMQ and MariaDB without clustering but
with persistent storage and workload migration, then examine how to
do proper distributed functionality as the project progresses, so I
am just following what we'd already agreed upon.
First, it helps us deal with issues of version upgrades without
dealing with clustered version upgrades and the synchronization
thereof.
Second, it provides an alternative model for durability when used in
Kubernetes. Understand that, if we disable RabbitMQ's clustering,
Kubernetes is still able to re-schedule the queue off of a failed node
in ways that Kolla-Ansible is not. There are known issues with
RabbitMQ clustering, especially with auto-heal turned on. For many
small-to-mid-sized clusters, it's going to provide for a better
operator experience to have the known potential for a 30 second blip
after RabbitMQ node failure than it is to have the known potential
for partition and data loss and/or manual operations after you've
turned off auto-heal.
Kolla-kubernetes has already turned off host networking for the
RabbitMQ pod; it's safe to set the interface address in the
Kubernetes context.
The question was asked why don't I just set the RabbitMQ cluster to be
a single instance. It's unlikely that Kubernetes RabbitMQ with a
PetSet will be clustered in the same declaritive fashion as the
rabbitmq-clusterer plugin. Easier to just disable it and worry about
how to configure the kube-friendly clustered RabbitMQ at a later point
in time. Furthermore, it's an entirely valid case for many OpenStack
control planes hosted atop Kolla-Kubernetes to accept the possibility
of a 30-60 second blip in lieu of the long and questionable history
of RabbitMQ clustering in production.
Co-authored-by: Ryan Hallisey <rhallise@redhat.com>
Change-Id: I7f0cb22d29a418fce4af8d69f63739859173d746
Partially-implements: blueprint api-interface-bind-address-override
The reason for introducing this script is to be able
to launch ovsdb-server and initialize it (create external bridge and plug
external interface) in one shot. It is applicable ONLY to Kubernetes environment
and it is required for Kubernetes DaemonSet usage. The behavior in classical
Kolla has not been changed.
TrivialFix
Change-Id: I54897cc2c0f2bcaaf0411822f3409bf96e92833d
The cleanup command in the external API is a misnomer and should
be called destroy.
Change-Id: I083e80699e09bb24266ce1bf549772a5de92a49e
Closes-Bug: 1610364
In the case of a single node environment without haproxy, the var
"kolla_internal_vip_adress" in global.yml should be the ip address
of the host. However, the prechecks will fail, because this ip
address is used by the host node and is pingable.
This commit fixes the prechecks of a vip address properly.
When the var "enable_haproxy" is "no", this fix will skip prechecks
for a vip address.
Change-Id: I0b752f179d20f82e3d6331047ee0bd802ab99a4b
Closes-Bug: #1570935
Github is just a mirror of the OpenStack git-repo.
Changed from Github to OpenStack git url wherever possible.
Change-Id: I7941ef86967de4efe7f23ff9fb11ec86c793901e
This prevented deploying ironic-api using kolla.
Changing to a single entry list fixes the problem and allows the deploy to
succeed.
Closes-Bug: #1606702
Change-Id: I98c2b06ab08e3b8afcaeb712be377cb363220283
Ansible's template action supports replacing keystone's wsgi default
config with custom config, it should only add with_first_found param
to config.yml to support this.
Change-Id: Id66302802db9a57188067982ea697f16faa1d8eb
Closes-Bug: #1609655
This changed introduces 4 new parameters to be able to use an existing
elasticsearch service for central logging.
* elasticsearch_address - address of elasticsearch server
* elasticsearch_protocol - protocol (HTTP/HTTPS) used by elasticsearch server
* enable_elasticsearch - deploy elasticsearch container
* enable_kibana - deploy kibana container
Closes-bug: #1584861
Change-Id: Ia1ff9ae8b6d9929c3826da02693d1e2fc9ea2522
Note: This should not result in any behavior changes in regular Kolla, just
Kolla-Kubernetes and only when you've overridden stuff in globals.yml
Allows override of interface address, memcached pools, and glance registry
host so that Kubernetes can do the right thing.
There are some significant architectural issues involved in memcached pooling
in the Kolla-kubernetes world. Avoiding them right now.
Current working with this Kolla-Kubernetes globals.yml file:
api_interface_address: "0.0.0.0"
memcached_servers: "memcached"
keystone_database_address: "mariadb"
keystone_admin_url: "http://keystone-admin:35357/v3"
keystone_internal_url: "http://keystone-public:5000/v3"
keystone_public_url: "http://keystone-public:5000/v3"
glance_registry_host: "glance-registry"
Two tings to note:
* This depends on a kolla-kubernetes patch, so that it won't be merged
until it's safe for glance to bind to 0.0.0.0. It's OK to bind to
0.0.0.0 in the Kubernetes world because the network fabric controls
access.
* In Kolla-Kubernetes, the global.yml file doesn't do var substitution
so you have to be explicit about the URLs, otherwise Keystone will
look like it was provisioned but it won't quite be provisioned right.
Co-Authored-By: Ryan Hallisey <rhallise@redhat.com>
Change-Id: Ic87566118a1d4f552748392ff394b9b121c91887
Partially-implements: blueprint api-interface-bind-address-override
Depends-On: I586ce1c6c3300254c4e2a398ff46645df576aeb0
Note: This should not result in any behavior changes in regular Kolla, just
Kolla-Kubernetes and only when you've overridden stuff in globals.yml
Allows override of interface address and memcached pools, so that Kubernetes
can do the right thing.
There are some significant architectural issues involved in memcached pooling
in the Kolla-kubernetes world. Avoiding them right now.
Current working with this Kolla-Kubernetes globals.yml file:
api_interface_address: "0.0.0.0"
memcached_servers: "memcached"
keystone_database_address: "mariadb"
keystone_admin_url: "http://keystone-admin:35357/v3"
keystone_internal_url: "http://keystone-public:5000/v3"
keystone_public_url: "http://keystone-public:5000/v3"
Three tings to note:
* In Kolla-Kubernetes, the service is not using net=host, so a
0.0.0.0 interface address is totally OK. That patch has been merged.
* In Kolla-Kubernetes, the global.yml file doesn't do var substitution
so you have to be explicit about the URLs, otherwise Keystone will
look like it was provisioned but it won't quite be provisioned right.
* In order to not duplicate tons of code, moved the keystone_admin_url /
keystone_internal_url / keystone_public_url to the common defaults
from the keystone defaults.
Co-Authored-By: Ryan Hallisey <rhallise@redhat.com>
Change-Id: I586ce1c6c3300254c4e2a398ff46645df576aeb0
Partially-implements: blueprint api-interface-bind-address-override
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>
Introduced nova backend selection flag for Ceph and priority if
multiple backends are configured
Add mechanism to deploy arbitrary ceph.conf and keyring files into
nova-compute and nova-libvirt containers
Added documentation
Change-Id: Id010ca9cc2d914e5358ef79edeb600a28220dd4b
Implements: blueprint external-ceph
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
The cloud-init will not work when those two value are no in a
none router environment
Closes-Bug: #1606756
Change-Id: I2436a8a512b3190605ba97c22b350ea0478b7a84
Remove the unnecessary option in the group_vars/all.yml file.
* removed some cinder.conf options like volume_backend_name,
iscsi_helper, iscsi_protocol etc. these value can be configured by
custom cinder.conf file, no need export as global variables.
* remove meaningless iscsi_ip_addess, which is not used in LVM driver
* force start iscsi relate when enable_cinder_backend_lvm is yes
TrivialFix
Change-Id: Ifcbfdad15e4d68bc5f20fc77e0315a09983ef022
