Unnamed repository; edit this file 'description' to name the repository. https://git.platform-os.org/openstack/kolla-ansible.git/atom?h=stable%2F2024.1 2023-02-03T09:55:29+00:00 2023-02-03T09:55:29+00:00 Pierre Riteau pierre@stackhpc.com 2023-02-03T09:55:29+00:00 urn:sha1:cbf6ce640a10414492a10584be1b537c6a510257 Change-Id: I0ff303a2fad2edbcedbe88486b272d2efa765d8d 2022-12-06T10:39:23+00:00 Pierre Riteau pierre@stackhpc.com 2022-12-06T10:39:23+00:00 urn:sha1:ce28cbc0d8bd907982212f4963b3a3e48215f688 Change-Id: I2df1eff4e9eda42127db5b0bfed4f84b6955c763 2022-11-15T10:16:02+00:00 Will Szumski will@stackhpc.com 2022-11-03T15:53:32+00:00 urn:sha1:a82443481e17edecda728f8698f8b401ec910546 Libvirt needs to be able to plug ports into openvswitch bridges. It does this using the ovs-vsctl command, which it searches for in $PATH[1, 2]. This change will optionally install a wrapper script that executes the ovs-vsctl commands in the context of the openvswitchd container. This is useful when running libvirt on the host whilst still running openvswitch in a container. The advantage of this method over install the packages on the host is that it ensures client compatability with the daemon. The default is set to false as the wrapper could overwrite ovs-vsctl installed on the host. [1] https://github.com/libvirt/libvirt/blob/ee51ab86c2e52b6ff1b17a4c7ad11439fd610c9e/src/util/virnetdevopenvswitch.c#L59 [2] https://github.com/libvirt/libvirt/blob/a89b17c2a75cfbaeb9e430f88e0f8a7475eb4f54/docs/kbase/internals/command.rst#id3 Closes-Bug: #1995409 Change-Id: Iaa6bfb012ae847f5f6aa0a1fc1c27970ac265f93 2022-05-30T13:36:36+00:00 Zuul zuul@review.opendev.org 2022-05-30T13:36:36+00:00 urn:sha1:28b4c5d35c2891e338a2f54ef11144d59f64dcf3 2022-03-21T11:54:54+00:00 Mark Goddard mark@stackhpc.com 2022-02-14T11:56:50+00:00 urn:sha1:80b311bef73ee8469055ae6f0b6083991a61b02a Change Ia1239069ccee39416b20959cbabad962c56693cf added support for running a libvirt daemon on the host, rather than using the nova_libvirt container. It did not cover migration of existing hosts from using a container to using a host daemon. This change adds a kolla-ansible nova-libvirt-cleanup command which may be used to clean up the nova_libvirt container, volumes and related items on hosts, once it has been disabled. The playbook assumes that compute hosts have been emptied of VMs before it runs. A future extension could support migration of existing VMs, but this is currently out of scope. Change-Id: I46854ed7eaf1d5b5e3ccd8531c963427848bdc99 2022-03-21T11:54:31+00:00 Mark Goddard mark@stackhpc.com 2022-01-19T13:21:17+00:00 urn:sha1:4e41acd8f0ccc8dee432f72cfafcca16d01a11b7 In some cases it may be desirable to run the libvirt daemon on the host. For example, when mixing host and container OS distributions or versions. This change makes it possible to disable the nova_libvirt container, by setting enable_nova_libvirt_container to false. The default values of some Docker mounts and other paths have been updated to point to default host directories rather than Docker volumes when using a host libvirt daemon. This change does not handle migration of existing systems from using a nova_libvirt container to libvirt on the host. Depends-On: https://review.opendev.org/c/openstack/ansible-collection-kolla/+/830504 Change-Id: Ia1239069ccee39416b20959cbabad962c56693cf 2022-03-10T16:57:16+00:00 Mark Goddard mark@stackhpc.com 2022-03-04T17:57:24+00:00 urn:sha1:d2d4b53d47df3b1a250c21404a8ec140873d4ce5 In Kolla Ansible OpenStack deployments, by default, libvirt is configured to allow read-write access via an unauthenticated, unencrypted TCP connection, using the internal API network. This is to facilitate migration between hosts. By default, Kolla Ansible does not use encryption for services on the internal network (and did not support it until Ussuri). However, most other services on the internal network are at least authenticated (usually via passwords), ensuring that they cannot be used by anyone with access to the network, unless they have credentials. The main issue here is the lack of authentication. Any client with access to the internal network is able to connect to the libvirt TCP port and make arbitrary changes to the hypervisor. This could include starting a VM, modifying an existing VM, etc. Given the flexibility of the domain options, it could be seen as equivalent to having root access to the hypervisor. Kolla Ansible supports libvirt TLS [1] since the Train release, using client and server certificates for mutual authentication and encryption. However, this feature is not enabled by default, and requires certificates to be generated for each compute host. This change adds support for libvirt SASL authentication, and enables it by default. This provides base level of security. Deployments requiring further security should use libvirt TLS. [1] https://docs.openstack.org/kolla-ansible/latest/reference/compute/libvirt-guide.html#libvirt-tls Depends-On: https://review.opendev.org/c/openstack/kolla/+/833021 Closes-Bug: #1964013 Change-Id: Ia91ceeb609e4cdb144433122b443028c0278b71e 2022-02-11T09:57:20+00:00 Mark Goddard mark@stackhpc.com 2022-02-10T17:22:42+00:00 urn:sha1:f853b323fa90c8f25e29f65bb329571041b58523 Adds docs for I1bde9fa018f66037aec82dc74c61ad1f477a7c12. Change-Id: I88a07bb3bfeb0c98bea9dbe8674033208ec3fb9f 2019-10-08T08:30:35+00:00 Mark Goddard mark@stackhpc.com 2019-10-07T09:47:13+00:00 urn:sha1:e91186c66c00fb3aba9c0650754e1fb681ed02e5 Adds a top-level guide for Nova, with links off to the various virt driver guides. Generalises the libvirt TLS guide into a libvirt guide, and adds info on hardware virtualisation and qemu vs. kvm. Adds information on configuring consoles. Change-Id: I36beaaee313bdbc4bcf8cc15c41dda245a5a81ba