Mark Goddard 96a96a2655 Restart all nova services after upgrade
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
(cherry picked from commit e6d2b92200d02715649d923b0ef2d6981905a6b9)
2019-06-27 15:17:13 +01:00
2019-06-06 13:17:42 +01:00
2018-07-24 14:18:20 +07:00
2019-04-19 19:29:09 +00:00
2018-07-24 14:18:20 +07:00
2018-03-26 17:56:22 +02:00
2016-11-03 16:07:47 +00:00
2014-09-20 17:29:35 -07:00
2019-03-08 10:46:53 +08:00
2017-03-02 17:44:00 +00:00
2018-12-27 04:44:49 +00:00

Team and repository tags

image

Kolla-Ansible Overview

The Kolla-Ansible is a deliverable project separated from Kolla project.

Kolla-Ansible deploys OpenStack services and infrastructure components in Docker containers.

Kolla's mission statement is:

To provide production-ready containers and deployment tools for operating
OpenStack clouds.

Kolla is highly opinionated out of the box, but allows for complete customization. This permits operators with little experience to deploy OpenStack quickly and as experience grows modify the OpenStack configuration to suit the operator's exact requirements.

Getting Started

Learn about Kolla-Ansible by reading the documentation online Kolla-Ansible.

Get started by reading the Developer Quickstart.

OpenStack services

Kolla-Ansible deploys containers for the following OpenStack projects:

Infrastructure components

Kolla-Ansible deploys containers for the following infrastructure components:

Directories

  • ansible - Contains Ansible playbooks to deploy OpenStack services and infrastructure components in Docker containers.
  • contrib - Contains demos scenarios for Heat, Magnum and Tacker and a development environment for Vagrant
  • doc - Contains documentation.
  • etc - Contains a reference etc directory structure which requires configuration of a small number of configuration variables to achieve a working All-in-One (AIO) deployment.
  • kolla_ansible - Contains password generation script.
  • releasenotes - Contains releasenote of all features added in Kolla-Ansible.
  • specs - Contains the Kolla-Ansible communities key arguments about architectural shifts in the code base.
  • tests - Contains functional testing tools.
  • tools - Contains tools for interacting with Kolla-Ansible.
  • zuul.d - Contains project gate job definitions.

Getting Involved

Need a feature? Find a bug? Let us know! Contributions are much appreciated and should follow the standard Gerrit workflow.

  • We communicate using the #openstack-kolla irc channel.
  • File bugs, blueprints, track releases, etc on Launchpad.
  • Attend weekly meetings.
  • Contribute code.

Contributors

Check out who's contributing code and contributing reviews.

Notices

Docker and the Docker logo are trademarks or registered trademarks of Docker, Inc. in the United States and/or other countries. Docker, Inc. and other parties may also have trademark rights in other terms used herein.

Description
Ansible deployment of the Kolla containers
Readme 175 MiB
Languages
Jinja 48.3%
Python 38.9%
Shell 12.6%
Ruby 0.2%