Files
7589b7b66b51fd87b1124a7a77a85a6f74c88f2b
openstack-ansible-os_nova /handlers /main.yml

91 lines
2.3 KiB
YAML
Raw Normal View History

Convert existing roles into galaxy roles This change implements the blueprint to convert all roles and plays into a more generic setup, following upstream ansible best practices. Items Changed: * All tasks have tags. * All roles use namespaced variables. * All redundant tasks within a given play and role have been removed. * All of the repetitive plays have been removed in-favor of a more simplistic approach. This change duplicates code within the roles but ensures that the roles only ever run within their own scope. * All roles have been built using an ansible galaxy syntax. * The `*requirement.txt` files have been reformatted follow upstream Openstack practices. * Dynamically generated inventory is now more organized, this should assist anyone who may want or need to dive into the JSON blob that is created. In the inventory a properties field is used for items that customize containers within the inventory. * The environment map has been modified to support additional host groups to enable the seperation of infrastructure pieces. While the old infra_hosts group will still work this change allows for groups to be divided up into seperate chunks; eg: deployment of a swift only stack. * The LXC logic now exists within the plays. * etc/openstack_deploy/user_variables.yml has all password/token variables extracted into the separate file etc/openstack_deploy/user_secrets.yml in order to allow seperate security settings on that file. Items Excised: * All of the roles have had the LXC logic removed from within them which should allow roles to be consumed outside of the `os-ansible-deployment` reference architecture. Note: * the directory rpc_deployment still exists and is presently pointed at plays containing a deprecation warning instructing the user to move to the standard playbooks directory. * While all of the rackspace specific components and variables have been removed and or were refactored the repository still relies on an upstream mirror of Openstack built python files and container images. This upstream mirror is hosted at rackspace at "http://rpc-repo.rackspace.com" though this is not locked to and or tied to rackspace specific installations. This repository contains all of the needed code to create and/or clone your own mirror. DocImpact Co-Authored-By: Jesse Pretorius <jesse.pretorius@rackspace.co.uk> Closes-Bug: #1403676 Implements: blueprint galaxy-roles Change-Id: I03df3328b7655f0cc9e43ba83b02623d038d214e
2015年02月14日 10:06:50 -06:00
---
Use dictionary for service group mappings Change the 'nova_service_names' from a list to a dictionary mapping of services, groups that install those services. This brings the method into line with that used in the os_neutron role in order to implement a more standardised method. The init tasks have been updated to run once and loop through this mapping rather than being included multiple times and re-run against each host. This may potentially reduce role run times. Currently the reload of upstart/systemd scripts may not happen if only one script changes as the task uses a loop with only one result register. This patch implements handlers to reload upstart/systemd scripts to ensure that this happens when any one of the scripts change. The handler to reload the services now only tries to restart the service if the host is in the group for the service according to the service group mapping. This allows us to ensure that handler failures are no longer ignored and that no execution time is wasted trying to restart services which do not exist on the host. Finally: - Common variables shared by each service's template files have been updated to use the service namespaced variables. - Unused handlers have been removed. - Unused variables have been removed. Change-Id: I53fb0ab1cc5762e3559d4ee2635d4cca532df7e3
2016年09月28日 18:47:11 +01:00
# Copyright 2015, Rackspace US, Inc.
Convert existing roles into galaxy roles This change implements the blueprint to convert all roles and plays into a more generic setup, following upstream ansible best practices. Items Changed: * All tasks have tags. * All roles use namespaced variables. * All redundant tasks within a given play and role have been removed. * All of the repetitive plays have been removed in-favor of a more simplistic approach. This change duplicates code within the roles but ensures that the roles only ever run within their own scope. * All roles have been built using an ansible galaxy syntax. * The `*requirement.txt` files have been reformatted follow upstream Openstack practices. * Dynamically generated inventory is now more organized, this should assist anyone who may want or need to dive into the JSON blob that is created. In the inventory a properties field is used for items that customize containers within the inventory. * The environment map has been modified to support additional host groups to enable the seperation of infrastructure pieces. While the old infra_hosts group will still work this change allows for groups to be divided up into seperate chunks; eg: deployment of a swift only stack. * The LXC logic now exists within the plays. * etc/openstack_deploy/user_variables.yml has all password/token variables extracted into the separate file etc/openstack_deploy/user_secrets.yml in order to allow seperate security settings on that file. Items Excised: * All of the roles have had the LXC logic removed from within them which should allow roles to be consumed outside of the `os-ansible-deployment` reference architecture. Note: * the directory rpc_deployment still exists and is presently pointed at plays containing a deprecation warning instructing the user to move to the standard playbooks directory. * While all of the rackspace specific components and variables have been removed and or were refactored the repository still relies on an upstream mirror of Openstack built python files and container images. This upstream mirror is hosted at rackspace at "http://rpc-repo.rackspace.com" though this is not locked to and or tied to rackspace specific installations. This repository contains all of the needed code to create and/or clone your own mirror. DocImpact Co-Authored-By: Jesse Pretorius <jesse.pretorius@rackspace.co.uk> Closes-Bug: #1403676 Implements: blueprint galaxy-roles Change-Id: I03df3328b7655f0cc9e43ba83b02623d038d214e
2015年02月14日 10:06:50 -06:00
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
- name:Stop libvirt-bin
service:
name:"{{ libvirt_service_name }}"
enabled:yes
state:"stopped"
listen:
- Restart libvirt-bin
Enable TLS for live migrations Instead of using SSH to live migrate VM's use TLS as this is more secure and SSH migrations are deprecated. https://docs.openstack.org/nova/xena/admin/secure-live-migration-with-qemu-native-tls.html A pre-existing PKI (Public Key Infrastruture) setup is required. TLS live migrations require that all compute hosts can communcate with each other on port 16514 and port range 49152 to 49261. To enable TLS live migrations, both libvirt and QEMU require server and client certificates, the server certicicates is used to verify servers and the client cert is used by servers to authenticate clients. A single cert is created by the pki role, that can be used by both libvirt and QEMU for both client and server auth. The client, server and CA certifcates need to installed in a number of locations on each compute host: * For Libvirt https://libvirt.org/tlscerts.html * For QEMU https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu.conf Depends-On: https://review.opendev.org/c/openstack/ansible-role-pki/+/815007 Depends-On: https://review.opendev.org/c/openstack/ansible-role-pki/+/815849 Depends-On: https://review.opendev.org/c/openstack/ansible-role-pki/+/816857 Change-Id: Iddbe8764bb6d3cd3eaee122b2d5ddc02fa3f7662
2021年10月25日 08:32:04 +01:00
- "cert installed"
Enable TLS for VNC from novncproxy to compute hosts To secure communications from the proxy server to the compute nodes using VeNCrypt authentication scheme. In a previous patch a TLS server certificate was deployed to compute nodes, this patch makes use of this same server cert for securing VNC sessions on compute nodes. It is recommended that this certificate be issued by a dedicated certificate authority solely for the VNC service, as libvirt does not currently have a mechanism to restrict what certificates can be presented by the proxy server. This has not been implemented to reduce complexity. In addition the noVNC proxy needs to present a client certificate so only approved VNC proxy servers can connect to the Compute nodes. The PKI role has been used to create a client certificate for the nova console nodes. Related Nova docs: https://docs.openstack.org/nova/latest/admin/remote-console-access.html To help with the transition from from unencrypted VNC to VeNCrypt, initially compute nodes auth scheme allows for both encrypted and unencrypted sessions using the variable `nova_vencrypt_auth_scheme`, this will be removed in future releases. Change-Id: Iafb788f80fd401c6ce6e4576bafd06c92431bd65
2021年11月08日 15:40:27 +00:00
when:
- "'nova_compute' in group_names"
- nova_virt_type != 'ironic'
- name:Enable sockets when needed
service:
name:"{{ item.name | default(item) }}"
state:"{{ item.condition | default(False) | ternary('started', 'stopped') }}"
enabled:"{{ item.condition | default(False) }}"
masked:no
when:
- libvirtd_version is version('5.7', '>=')
with_items:
- name:libvirtd-tls.socket
condition:"{{ nova_libvirtd_listen_tls | bool }}"
- name:libvirtd-tcp.socket
condition:"{{ nova_libvirtd_listen_tcp | bool }}"
listen:
- Restart libvirt-bin
- name:Start libvirt-bin
service:
name:"{{ libvirt_service_name }}"
enabled:yes
state:"started"
listen:
- Restart libvirt-bin
Enable TLS for live migrations Instead of using SSH to live migrate VM's use TLS as this is more secure and SSH migrations are deprecated. https://docs.openstack.org/nova/xena/admin/secure-live-migration-with-qemu-native-tls.html A pre-existing PKI (Public Key Infrastruture) setup is required. TLS live migrations require that all compute hosts can communcate with each other on port 16514 and port range 49152 to 49261. To enable TLS live migrations, both libvirt and QEMU require server and client certificates, the server certicicates is used to verify servers and the client cert is used by servers to authenticate clients. A single cert is created by the pki role, that can be used by both libvirt and QEMU for both client and server auth. The client, server and CA certifcates need to installed in a number of locations on each compute host: * For Libvirt https://libvirt.org/tlscerts.html * For QEMU https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu.conf Depends-On: https://review.opendev.org/c/openstack/ansible-role-pki/+/815007 Depends-On: https://review.opendev.org/c/openstack/ansible-role-pki/+/815849 Depends-On: https://review.opendev.org/c/openstack/ansible-role-pki/+/816857 Change-Id: Iddbe8764bb6d3cd3eaee122b2d5ddc02fa3f7662
2021年10月25日 08:32:04 +01:00
- "cert installed"
Enable TLS for VNC from novncproxy to compute hosts To secure communications from the proxy server to the compute nodes using VeNCrypt authentication scheme. In a previous patch a TLS server certificate was deployed to compute nodes, this patch makes use of this same server cert for securing VNC sessions on compute nodes. It is recommended that this certificate be issued by a dedicated certificate authority solely for the VNC service, as libvirt does not currently have a mechanism to restrict what certificates can be presented by the proxy server. This has not been implemented to reduce complexity. In addition the noVNC proxy needs to present a client certificate so only approved VNC proxy servers can connect to the Compute nodes. The PKI role has been used to create a client certificate for the nova console nodes. Related Nova docs: https://docs.openstack.org/nova/latest/admin/remote-console-access.html To help with the transition from from unencrypted VNC to VeNCrypt, initially compute nodes auth scheme allows for both encrypted and unencrypted sessions using the variable `nova_vencrypt_auth_scheme`, this will be removed in future releases. Change-Id: Iafb788f80fd401c6ce6e4576bafd06c92431bd65
2021年11月08日 15:40:27 +00:00
when:
- "'nova_compute' in group_names"
- nova_virt_type != 'ironic'
- name:Stop services
service:
name:"{{ item.service_name }}"
enabled:yes
state:"stopped"
daemon_reload:yes
with_items:"{{ filtered_nova_services }}"
register:_stop
until:_stop is success
retries:5
delay:2
Use a common python build/install role In order to radically simplify how we prepare the service venvs, we use a common role to do the wheel builds and the venv preparation. This makes the process far simpler to understand, because the role does its own building and installing. It also reduces the code maintenance burden, because instead of duplicating the build processes in the repo_build role and the service role - we only have it all done in a single place. We also change the role venv tag var to use the integrated build's common venv tag so that we can remove the role's venv tag in group_vars in the integrated build. This reduces memory consumption and also reduces the duplication. This is by no means the final stop in the simplification process, but it is a step forward. The will be work to follow which: 1. Replaces 'developer mode' with an equivalent mechanism that uses the common role and is simpler to understand. We will also simplify the provisioning of pip install arguments when doing this. 2. Simplifies the installation of optional pip packages. Right now it's more complicated than it needs to be due to us needing to keep the py_pkgs plugin working in the integrated build. 3. Deduplicates the distro package installs. Right now the role installs the distro packages twice - just before building the venv, and during the python_venv_build role execution. Depends-On: https://review.openstack.org/598957 Change-Id: I182bde29c049a97bc2b55193aee0b5b3d8532916 Implements: blueprint python-build-install-simplification Signed-off-by: Jesse Pretorius <jesse.pretorius@rackspace.co.uk>
2018年09月02日 18:13:36 +01:00
listen:
- "Restart nova services"
- "venv changed"
Enable TLS for VNC from novncproxy to compute hosts To secure communications from the proxy server to the compute nodes using VeNCrypt authentication scheme. In a previous patch a TLS server certificate was deployed to compute nodes, this patch makes use of this same server cert for securing VNC sessions on compute nodes. It is recommended that this certificate be issued by a dedicated certificate authority solely for the VNC service, as libvirt does not currently have a mechanism to restrict what certificates can be presented by the proxy server. This has not been implemented to reduce complexity. In addition the noVNC proxy needs to present a client certificate so only approved VNC proxy servers can connect to the Compute nodes. The PKI role has been used to create a client certificate for the nova console nodes. Related Nova docs: https://docs.openstack.org/nova/latest/admin/remote-console-access.html To help with the transition from from unencrypted VNC to VeNCrypt, initially compute nodes auth scheme allows for both encrypted and unencrypted sessions using the variable `nova_vencrypt_auth_scheme`, this will be removed in future releases. Change-Id: Iafb788f80fd401c6ce6e4576bafd06c92431bd65
2021年11月08日 15:40:27 +00:00
- "cert installed"
- name:Start services
service:
name:"{{ item.service_name }}"
enabled:yes
state:"started"
daemon_reload:yes
with_items:"{{ filtered_nova_services }}"
register:_start
until:_start is success
retries:5
delay:2
Use a common python build/install role In order to radically simplify how we prepare the service venvs, we use a common role to do the wheel builds and the venv preparation. This makes the process far simpler to understand, because the role does its own building and installing. It also reduces the code maintenance burden, because instead of duplicating the build processes in the repo_build role and the service role - we only have it all done in a single place. We also change the role venv tag var to use the integrated build's common venv tag so that we can remove the role's venv tag in group_vars in the integrated build. This reduces memory consumption and also reduces the duplication. This is by no means the final stop in the simplification process, but it is a step forward. The will be work to follow which: 1. Replaces 'developer mode' with an equivalent mechanism that uses the common role and is simpler to understand. We will also simplify the provisioning of pip install arguments when doing this. 2. Simplifies the installation of optional pip packages. Right now it's more complicated than it needs to be due to us needing to keep the py_pkgs plugin working in the integrated build. 3. Deduplicates the distro package installs. Right now the role installs the distro packages twice - just before building the venv, and during the python_venv_build role execution. Depends-On: https://review.openstack.org/598957 Change-Id: I182bde29c049a97bc2b55193aee0b5b3d8532916 Implements: blueprint python-build-install-simplification Signed-off-by: Jesse Pretorius <jesse.pretorius@rackspace.co.uk>
2018年09月02日 18:13:36 +01:00
listen:
- "Restart nova services"
- "venv changed"
Enable TLS for VNC from novncproxy to compute hosts To secure communications from the proxy server to the compute nodes using VeNCrypt authentication scheme. In a previous patch a TLS server certificate was deployed to compute nodes, this patch makes use of this same server cert for securing VNC sessions on compute nodes. It is recommended that this certificate be issued by a dedicated certificate authority solely for the VNC service, as libvirt does not currently have a mechanism to restrict what certificates can be presented by the proxy server. This has not been implemented to reduce complexity. In addition the noVNC proxy needs to present a client certificate so only approved VNC proxy servers can connect to the Compute nodes. The PKI role has been used to create a client certificate for the nova console nodes. Related Nova docs: https://docs.openstack.org/nova/latest/admin/remote-console-access.html To help with the transition from from unencrypted VNC to VeNCrypt, initially compute nodes auth scheme allows for both encrypted and unencrypted sessions using the variable `nova_vencrypt_auth_scheme`, this will be removed in future releases. Change-Id: Iafb788f80fd401c6ce6e4576bafd06c92431bd65
2021年11月08日 15:40:27 +00:00
- "cert installed"
- meta:noop
listen:Manage LB
when:false