Nova-consoleauth support was removed in
I099080979f5497537e390f531005a517ab12aa7a, but these variables were
left.
Change-Id: I1ce1631119bba991225835e8e409f11d53276550
During an upgrade, nova pins the version of RPC calls to the minimum
seen across all services. This ensures that old services do not receive
data they cannot handle. After the upgrade is complete, all nova
services are supposed to be reloaded via SIGHUP to cause them to check
again the RPC versions of services and use the new latest version which
should now be supported by all running services.
Due to a bug [1] in oslo.service, sending services SIGHUP is currently
broken. We replaced the HUP with a restart for the nova_compute
container for bug 1821362, but not other nova services. It seems we need
to restart all nova services to allow the RPC version pin to be removed.
Testing in a Queens to Rocky upgrade, we find the following in the logs:
Automatically selected compute RPC version 5.0 from minimum service
version 30
However, the service version in Rocky is 35.
There is a second issue in that it takes some time for the upgraded
services to update the nova services database table with their new
version. We need to wait until all nova-compute services have done this
before the restart is performed, otherwise the RPC version cap will
remain in place. There is currently no interface in nova available for
checking these versions [2], so as a workaround we use a configurable
delay with a default duration of 30 seconds. Testing showed it takes
about 10 seconds for the version to be updated, so this gives us some
headroom.
This change restarts all nova services after an upgrade, after a 30
second delay.
[1] https://bugs.launchpad.net/oslo.service/+bug/1715374
[2] https://bugs.launchpad.net/nova/+bug/1833542
Change-Id: Ia6fc9011ee6f5461f40a1307b72709d769814a79
Closes-Bug: #1833069
Related-Bug: #1833542
When integrating 3rd party component into openstack with kolla-ansible,
maybe have to mount some extra volumes to container.
Change-Id: I69108209320edad4c4ffa37dabadff62d7340939
Implements: blueprint support-extra-volumes
After upgrading from Rocky to Stein, nova-compute services fail to start
new instances with the following error message:
Failed to allocate the network(s), not rescheduling.
Looking in the nova-compute logs, we also see this:
Neutron Reported failure on event
network-vif-plugged-60c05a0d-8758-44c9-81e4-754551567be5 for instance
32c493c4-d88c-4f14-98db-c7af64bf3324: NovaException: In shutdown, no new
events can be scheduled
During the upgrade process, we send nova containers a SIGHUP to cause
them to reload their object version state. Speaking to the nova team in
IRC, there is a known issue with this, caused by oslo.service performing
a full shutdown in response to a SIGHUP, which breaks nova-compute.
There is a patch [1] in review to address this.
The workaround employed here is to restart the nova compute service.
[1] https://review.openstack.org/#/c/641907
Change-Id: Ia4fcc558a3f62ced2d629d7a22d0bc1eb6b879f1
Closes-Bug: #1821362
This allows nova service endpoints to use custom hostnames, and adds the
following variables:
* nova_internal_fqdn
* nova_external_fqdn
* placement_internal_fqdn
* placement_external_fqdn
* nova_novncproxy_fqdn
* nova_spicehtml5proxy_fqdn
* nova_serialproxy_fqdn
These default to the old values of kolla_internal_fqdn or
kolla_external_fqdn.
This also adds the following variables:
* nova_api_listen_port
* nova_metadata_listen_port
* nova_novncproxy_listen_port
* nova_spicehtml5proxy_listen_port
* nova_serialproxy_listen_port
* placement_api_listen_port
These default to <service>_port, e.g. nova_api_port, for backward
compatibility.
These options allow the user to differentiate between the port the
service listens on, and the port the service is reachable on. This is
useful for external load balancers which live on the same host as the
service itself.
Change-Id: I7bcce56a2138eeadcabac79dd07c8dba1c5af644
Implements: blueprint service-hostnames
bump up the max_files to 32768 and max_processes to 131072.
when nova used ceph as backend, the default limit 1024 is not enough.
each connection from rbd image to osd needs 1 fd and 2 threads. if we
have 200 osds, we need 200 fds and 400 threads for 1 image.
Change-Id: I94c3ec111473ea2ccacdea5dbbf3fdc9c569859f
Add an enable_cinder_backend_quobyte option to etc/kolla/globals.yml to
enable use the Quobyte Cinder backend.
Change the bind mounts for /var/lib/nova/mnt to include the shared
propogation if Quobyte is enabled.
Update the documentation to include a section on configuring the Cinder.
Implements: blueprint cinder-quobyte-backend
Change-Id: I364939407ad244fe81cea40f880effdbcaa8a20d
According [1], vitrage notification has to be configured in Nova,
Neutron, Cinder & Aodh config file.
[1] https://review.openstack.org/#/c/302802/
Change-Id: Iaf8cd7d40e6eb988adf4d208e6ad784f1004caa5
Currently, the serial consoles as accessed through Horizon,
timeout after the haproxy_client_timeout (default: 1m) of
inactivity. This change allows you to set a larger timeout.
Change-Id: I2a9923cb69d5db976395146685aded83922c4120
Closes-Bug: #1800643
Kolla-ansible provides support for the dev mode for some projects
of openstack, but there are still some projects that do not yet
support specific release tag. This patch will implement this function
for these project.
Change-Id: I917b27dd61295b542457a21b240afe2cd4e83e58
The cephx keys are missing a default permission
to allow to see blacklisted clients.
This permission ensures that in the event of a client
crash (kill -9/hard shutdown/power outage) the client
can re-connect and write to any devices after reboot.
Closes-Bug: 1773449
Change-Id: I44d3982233f892d2c0ce3b9964194d8098453978
Signed-off-by: Jorge Niedbalski <jorge.niedbalski@linaro.org>
Having all services in one giant haproxy file makes altering
configuration for a service both painful and dangerous. Each service
should be configured with a simple set of variables and rendered with a
single unified template.
Available are two new templates:
* haproxy_single_service_listen.cfg.j2: close to the original style, but
only one service per file
* haproxy_single_service_split.cfg.j2: using the newer haproxy syntax
for separated frontend and backend
For now the default will be the single listen block, for ease of
transition.
Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
Add a possibility to mount sources as volumes to containers,
in "more than documentation" way. That will let us to use kolla
as a replacement for devstack.
Partially implements: blueprint mount-sources
Co-Authored-By: zhulingjie <easyzlj@gmail.com>
Change-Id: I10677e5ad22f2107a0657feeeaf32287ab9f8e28
Enables setting rp_filter mode on Neutron L3 agent and Nova compute
hosts whilst maintaining the default that it is disabled.
Closes-Bug: #1782799
Change-Id: I93e53bad9727beb786b00bd7fcd6d78785c619c2
This service is only required if you want to support cold migration.
In some instances that is not a needed feature, and avoiding having
another key to manage is an advantage.
Co-Authored-By: Adam Harwell <flux.adam@gmail.com>
Change-Id: I0a55a91673d9178933f134832df4bd849ddf5af4
This commit will constrain the dimensions of service `Nova`
and sub-containers deployed along with it.
A user can give the dimension values in `/etc/kolla/globals.yml`
the data-types just like stated in this commit.
Reference-Docs:
https://docs.docker.com/config/containers/resource_constraints/
Added Test-cases for the same.
Partially-Implements: blueprint resource-constraints
Change-Id: I6458d8fb7b26a6e7c3a9fd0d674d9cf129b0bf5d
User can use custom directory for nova instance.
For example using a shared file system as backend.
Change-Id: I11fe4891719a2e2a34888d8b798df5602e294e4f
NSXV3 is the OpenStack support for the NSX Transformers platform.
This is supported from neutron in the Mitaka version. This patch
adds Kolla support
This adds a new neutron_plugin_agent type 'vmware_nsxv3'. The plugin
does not run any neutron agents.
Change-Id: I1ecd7e5f3471e4ff03cfe8c9a3aff17af3fe1842
This patch allows configuration of the Infoblox
pluggable IPAM driver in neutron [0].
When 'infoblox' is chosen as the driver, an Infoblox
IPAM agent can be started as well. The agent
allows for enhanced DNS capabilities by listening
for neutron and nova notifications.
[0] https://github.com/openstack/networking-infoblox/blob/master/README.rst
Change-Id: I4f863750a7806a7b6eaf13900d44e5f063afe3de
Depends-On: Ia44f0e0d7a0d60cebf0857ad51700e02eba5099b
Partially-Implements: blueprint neutron-ipam-driver-infoblox
This patchset implements yamllint test to all *.yml
files.
Also fixes syntax errors to make jobs to pass.
Change-Id: I3186adf9835b4d0cada272d156b17d1bc9c2b799
This change allows the following use cases:
1. Using an already-configured MariaDB / MySQL server / Cluster
2. Using already-created DB users, without requiring root DB access.
Update: added external mariadb precheck
Change-Id: I78b0d178306d7c5293b0bf53e445f19f18b4b824
Implements: blueprint external-mariadb-support.
Closes-Bug: #1603121
through the database_address has beed defined in groups_vars/all.yml, we should
better use it, this way, if we want to use external database, we just need to
redefined in all.yml
refer to https://github.com/openstack/kolla-ansible/blob/master/ansible/group_vars/all.yml#L83
Co-Authored-By: chenqiaomin <chen.qiaomin@99cloud.net>
Change-Id: Ie559301451954e16347ceaabf02f594c5c5cbe56
The envirenment variable LIBGUESTFS_BACKEND = direct
is not enabled by default in docker container.
Without it, GuestFS() init failed.
Closes-Bug: #1742029
Change-Id: I24330502df7abc8e8f952ebb41bd9ae5e4ba1168
Instance failed to spawn: libvirtError: unsupported configuration: CPU
mode 'host-model' for aarch64 kvm domain on aarch64 host is not
supported by hypervisor.
Change-Id: Iad530457aef24ee8f561a8f7d2c6c6150c55bc42
ipc_mode=host is required after enabled multipath in nova.
Closes-Bug: #1713639
Depends-On: I0a1d85597999415cab11feb71a7fdfd7af3f7148
Change-Id: Ib0b8961a47b686b6c35456768bbbccc741cb7adf
Implements compute part of the blueprint.
Make virt_type of nova_compute configerable.
Change-Id: I0f37e49e09c4f14a64797506007bb55a6f534f0f
Partially-implements: blueprint kolla-ansible-support-vsphere
Co-Authored-By: shaofeng cheng <chengsf@winhong.com>
kolla-kubernetes is using its own configuration generation[0], so it is
time for kolla-ansible to remove the related code to simplify the
logical.
[0] https://github.com/openstack/kolla-kubernetes/tree/master/ansible
Change-Id: I7bb0b7fe3b8eea906613e936d5e9d19f4f2e80bb
Implements: blueprint clean-k8s-config
With the following configuration in globals.yml
enable_ceilometer="no"
enable_designate="no"
enable_searchlight="yes"
nova.conf is generated like following:
[oslo_messaging_notifications]
driver = messagingv2
topics =
topics value is missing.
Change-Id: I27145c0da8b864b2614091933c33d83bdec8b9be
Closes-Bug: #1671935
Co-Authored-By: Jeffrey Zhang <jeffrey.zhang@99cloud.net>
In case Kolla's users want to deploy with both of
binary and source image, we should have a variable
install type that define install type for each project.
We also add specific image tag for each Openstack project.
This commit is implemented for Neutron, Nova,
Octavia project and Openvswitch as well.
Change-Id: I04d3a17231b607795bbddb85cd940fa725ff7a61
Implements: blueprint mixing-binary-and-source-image
