aboutsummaryrefslogtreecommitdiff
path: root/doc/source/reference/compute
AgeCommit message (Collapse)AuthorFilesLines
2024-04-25Merge "Revert "Deprecate Masakari""Zuul1-5/+0
2024-04-19Revert "Deprecate Masakari"Mark Goddard1-5/+0
This reverts commit 9675347fecd2907e7f60e84e405abcedf426b229. Reason for revert: Masakari CI is working Change-Id: Ifb44a437b96c0c029210b1491ee6c6403ee9e6fb
2024-01-22Revert "zun: Deprecate Zun provisionally"hongbin1-12/+0
This reverts commit f8d4db54db8f2ab2c7f99f0fcbc456177d33ddad. Reason for revert: Zun was deprecated due to the hard dependency on old version of docker and etcd. Right now, the problem was fixed. Change-Id: I9fe760e2b9b774b5ea623e6b305de004fc0c6dd2
2024-01-22Revert "Pin zun jobs to Docker 20"hongbin1-14/+0
This reverts commit 94a74f58c7891e41ca637c4e2a6450ca88cbfb56. Reason for revert: Zun/Kuryr-libnetwork has switched to "local" scope which doesn't require docker 20 anymore. It should work for latest docker version. Related patches: https://review.opendev.org/c/openstack/zun/+/903884 Change-Id: Ieb545ae5a5917322f599728587c3f04ea8356126
2023-11-16Deprecate MasakariDr. Jens Harbott1-0/+5
Since the CI is failing and there are no contributors working on fixing this, we are deprecating the service. Also mention other deprecations in the README. Change-Id: Ifff11645f6b4682810c042a0421d1eb569ab0ede
2023-09-26zun: Deprecate Zun provisionallyJan Gutter1-0/+12
* Zun currently has a dependency on a combination of Docker and etcd that is no longer installable (or supported) in newer distros. * These components are core dependencies of other systems and vendoring them will be very painful. * Work to update Zun past this is scheduled for the 'C' cycle. * If Zun regains compatibility, backports to this series will be considered. Change-Id: I6a2a4ffdcaf1c4fab1097e94d5f255ffb9a2947d
2023-09-13debian: Remove kolla-ansible-debian-zun jobJan Gutter1-0/+4
* When the Debian job got upgraded from Bullseye to Bookworm, the non-voting Zun job started failing. * This is because Debian Bookworm doesn't support the required Docker 20 pinning. * Until Zun gains support for newer dependencies this job will keep failing. Change-Id: I1e1d9ea7c76d1b2f77b09b7948f138b88ef483d2
2023-03-21Pin zun jobs to Docker 20Michal Nasiadka1-0/+10
Related-Bug: #2007142 Change-Id: I9ce2a9ce5413e77625201f3986967e31a679ad9c
2023-02-03docs: fix information about libvirt SASL authPierre Riteau1-2/+3
Change-Id: I0ff303a2fad2edbcedbe88486b272d2efa765d8d
2022-12-06docs: Fix reference to Libvirt TLSPierre Riteau1-2/+2
Change-Id: I2df1eff4e9eda42127db5b0bfed4f84b6955c763
2022-11-15Adds a wrapper script to run ovs-vsctl commands in the containerWill Szumski1-0/+17
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-10-07Support specifying Nova compute provider configDoug Szumski1-0/+48
In the Victoria cycle, Nova merged improved support for managing resource providers: https://review.opendev.org/q/topic:bp%252Fprovider-config-file See the blueprint for more details: https://docs.openstack.org/nova/latest/admin/managing-resource-providers.html This change allows us to copy the necessary configuration. Change-Id: I0a3caaad73bc6fe27380e7f6bf6b792aca51c84c
2022-05-31Merge "Control Masakari monitors deploy"Zuul1-3/+6
2022-05-30Merge "docs: add information about development libvirt TLS certs"Zuul1-4/+13
2022-05-25Control Masakari monitors deployMaksim Malchuk1-3/+6
Add a switches to enable/disable deploy of the Masakari monitors. Change-Id: I3ab603f7cab7946ea8f2e063fe91190d6592066a Signed-off-by: Maksim Malchuk <maksim.malchuk@gmail.com>
2022-03-29nova: improve compute service registration failure handlingMark Goddard1-0/+14
If any nova compute service fails to register itself, Kolla Ansible will fail the host that queries the Nova API. This is the first compute host in the inventory, and fails in the task: Waiting for nova-compute services to register themselves Other hosts continue, often leading to further errors later on. Clearly this is not idea. This change modifies the behaviour to query the compute service list until all expected hosts are present, but does not fail the querying host if they are not. A new task is added that executes for all hosts, and fails only those hosts that have not registered successfully. Alternatively, to fail all hosts in a cell when any compute service fails to register, set nova_compute_registration_fatal to true. Change-Id: I12c1928cf1f1fb9e28f1741e7fe4968004ea1816 Closes-Bug: #1940119
2022-03-21libvirt: add nova-libvirt-cleanup commandMark Goddard1-2/+21
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-21libvirt: make it possible to run libvirt on the hostMark Goddard1-3/+18
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-10libvirt: support SASL authenticationMark Goddard1-8/+29
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-21Merge "Add support for VMware First Class Disk (FCD)"Zuul1-3/+44
2022-02-18Merge "Add support for VMware NSXP"Zuul1-10/+183
2022-02-18Add support for VMware First Class Disk (FCD)alecorps1-3/+44
An FCD, also known as an Improved Virtual Disk (IVD) or Managed Virtual Disk, is a named virtual disk independent of a virtual machine. Using FCDs for Cinder volumes eliminates the need for shadow virtual machines. This patch adds Kolla support. Change-Id: Ic0b66269e6d32762e786c95cf6da78cb201d2765
2022-02-17Add support for VMware NSXPAlban Lecorps1-10/+183
NSXP is the OpenStack support for the NSX Policy platform. This is supported from neutron in the Stein version. This patch adds Kolla support This adds a new neutron_plugin_agent type 'vmware_nsxp'. The plugin does not run any neutron agents. Change-Id: I9e9d8f07e586bdc143d293e572031368af7f3fca
2022-02-11docs: add information about development libvirt TLS certsMark Goddard1-4/+13
Adds docs for I1bde9fa018f66037aec82dc74c61ad1f477a7c12. Change-Id: I88a07bb3bfeb0c98bea9dbe8674033208ec3fb9f
2021-11-25Support copying static Vendordata file into Nova API containerDoug Szumski1-0/+9
Nova provides a mechanism to set static vendordata via a file [1]. This patch provides support in Kolla Ansible for using this feature. Arguably this could be part of a generic mechansim for copying arbitrary config, but: - It's not clear if there is anything else that would take advantage of this - One size might not fit all [1] https://docs.openstack.org/nova/latest/configuration/config.html#api.vendordata_jsonfile_path Change-Id: Id420376d96d0c40415c369ae8dd36e845a781820
2021-04-26[doc] fix a typowuchunyang1-1/+1
Trivial Fix Change-Id: Ie08877e339455bed45ee467a87de9648678e88c5
2020-12-15Remove retired Qinling supportGhanshyam Mann2-103/+0
Qinling project is retiring in Wallaby cycle[1]. This commit removes the ansible roles of Qinling project before its code is removed. Needed-By: https://review.opendev.org/c/openstack/qinling/+/764521 [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018638.html Change-Id: I6543bacff638b1649511f7e779807954c34ef570
2020-10-14Revert VMware deprecationzhoulinhui3-13/+0
Nova has reversed their deprecation of the VMware driver, and the Kolla community has shown an interest in it. Change-Id: I82f1074da56ed16c08317d1f92ed7f0a6f4a149a
2020-07-27Drop RDP console variablesRadosław Piliszek1-1/+1
These are noop after Hyper-V support was removed. Change-Id: Ib451b154893e5cedc366aed83c35f48d92c7ab82
2020-07-27Remove Hyper-V integrationChristian Berendt3-185/+2
Change-Id: I2e22ec47f644de2f1509a0111c9e1fffe8da0a1a
2020-06-09Remove XenAPI integrationChristian Berendt4-134/+4
Change-Id: Iea3f4f3d2e5c6040c1e0bc7bfae8719cc7d8ac55
2020-04-30Zun: Add zun-cni-daemon to compute nodeHongbin Lu1-0/+1
Zun has a new component "zun-cni-daemon" which should be deployed in every compute nodes. It is basically an implementation of CNI (Container Network Interface) that performs the neutron port binding. If users is using the capsule (pod) API, the recommended deployment option is using "cri" as capsule driver. This is basically to use a CRI runtime (i.e. CRI plugin for containerd) for supporting capsules (pods). A CRI runtime needs a CNI plugin which is what the "zun-cni-daemon" provides. The configuration is based on the Zun installation guide [1]. It consits of the following steps: * Configure the containerd daemon in the host. The "zun-compute" container will use grpc to communicate with this service. * Install the "zun-cni" binary at host. The containerd process will invoke this binary to call the CNI plugin. * Run a "zun-cni-daemon" container. The "zun-cni" binary will communicate with this container via HTTP. Relevant patches: Blueprint: https://blueprints.launchpad.net/zun/+spec/add-support-cri-runtime Install guide: https://review.opendev.org/#/c/707948/ Devstack plugin: https://review.opendev.org/#/c/705338/ Kolla image: https://review.opendev.org/#/c/708273/ [1] https://docs.openstack.org/zun/latest/install/index.html Depends-On: https://review.opendev.org/#/c/721044/ Change-Id: I9c361a99b355af27907cf80f5c88d97191193495
2020-03-03Add deprecation notes to vmware/xenserver/hyperv guidesChristian Berendt5-0/+29
The support of vmware, xenserver and hyperv was deprecated. Change-Id: Id06770c2247ce242f1fc2ac7220bbe6c3070598d
2020-02-08Docs: fix cells upgrade guideRadosław Piliszek1-4/+4
Change-Id: Ia122aa157413e71eb50bd22e3c9f44a2e5c0bf4f
2020-01-06Fix duplicated words issue like "are are out of"zhufl1-1/+1
This is to fix the duplicated words issue like "Other services that are are out of scope of this". Change-Id: Ie4882dbb64d6e8774888b97895af20ba3855f0f8
2019-10-21Merge "Docs: add nova cells"Zuul3-0/+470
2019-10-20[train] Finish configuring Zun to use PlacementRadosław Piliszek1-1/+0
This also enables Placement when Zun is enabled like Kolla Ansible already does with Nova. Change-Id: Id2a09f702e8503b49d2b9e73e06b2ce9f4d168a9 Closes-bug: #1840573
2019-10-17Docs: add nova cellsMark Goddard3-0/+470
Add documentation about deploying nova with multiple cells. Change-Id: I89ee276917e5b9170746e07b7f644c7593b03da1 Depends-On: https://review.opendev.org/#/c/675659/ Related: blueprint bp/support-nova-cells
2019-10-16Implement IPv6 support in the control planeRadosław Piliszek1-1/+1
Introduce kolla_address filter. Introduce put_address_in_context filter. Add AF config to vars. Address contexts: - raw (default): <ADDR> - memcache: inet6:[<ADDR>] - url: [<ADDR>] Other changes: globals.yml - mention just IP in comment prechecks/port_checks (api_intf) - kolla_address handles validation 3x interface conditional (swift configs: replication/storage) 2x interface variable definition with hostname (haproxy listens; api intf) 1x interface variable definition with hostname with bifrost exclusion (baremetal pre-install /etc/hosts; api intf) neutron's ml2 'overlay_ip_version' set to 6 for IPv6 on tunnel network basic multinode source CI job for IPv6 prechecks for rabbitmq and qdrouterd use proper NSS database now MariaDB Galera Cluster WSREP SST mariabackup workaround (socat and IPv6) Ceph naming workaround in CI TODO: probably needs documenting RabbitMQ IPv6-only proto_dist Ceph ms switch to IPv6 mode Remove neutron-server ml2_type_vxlan/vxlan_group setting as it is not used (let's avoid any confusion) and could break setups without proper multicast routing if it started working (also IPv4-only) haproxy upgrade checks for slaves based on ipv6 addresses TODO: ovs-dpdk grabs ipv4 network address (w/ prefix len / submask) not supported, invalid by default because neutron_external has no address No idea whether ovs-dpdk works at all atm. ml2 for xenapi Xen is not supported too well. This would require working with XenAPI facts. rp_filter setting This would require meddling with ip6tables (there is no sysctl param). By default nothing is dropped. Unlikely we really need it. ironic dnsmasq is configured IPv4-only dnsmasq needs DHCPv6 options and testing in vivo. KNOWN ISSUES (beyond us): One cannot use IPv6 address to reference the image for docker like we currently do, see: https://github.com/moby/moby/issues/39033 (docker_registry; docker API 400 - invalid reference format) workaround: use hostname/FQDN RabbitMQ may fail to bind to IPv6 if hostname resolves also to IPv4. This is due to old RabbitMQ versions available in images. IPv4 is preferred by default and may fail in the IPv6-only scenario. This should be no problem in real life as IPv6-only is indeed IPv6-only. Also, when new RabbitMQ (3.7.16/3.8+) makes it into images, this will no longer be relevant as we supply all the necessary config. See: https://github.com/rabbitmq/rabbitmq-server/pull/1982 For reliable runs, at least Ansible 2.8 is required (2.8.5 confirmed to work well). Older Ansible versions are known to miss IPv6 addresses in interface facts. This may affect redeploys, reconfigures and upgrades which run after VIP address is assigned. See: https://github.com/ansible/ansible/issues/63227 Bifrost Train does not support IPv6 deployments. See: https://storyboard.openstack.org/#!/story/2006689 Change-Id: Ia34e6916ea4f99e9522cd2ddde03a0a4776f7e2c Implements: blueprint ipv6-control-plane Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
2019-10-08Docs: improve Nova documentationMark Goddard5-8/+92
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
2019-09-19Add support for libvirt+tlsKris Lindgren2-0/+97
To securely support live migration between computenodes we should enable tls, with cert auth, instead of TCP with no auth support. Implements: blueprint libvirt-tls Change-Id: I22ea6233933c840b853fdcc8e03400b2bf577271
2019-09-10Configure Zun for Placement (Train+)Hongbin Lu1-0/+1
After the integration with placement [1], we need to configure how zun-compute is going to work with nova-compute. * If zun-compute and nova-compute run on the same compute node, we need to set 'host_shared_with_nova' as true so that Zun will use the resource provider (compute node) created by nova. In this mode, containers and VMs could claim allocations against the same resource provider. * If zun-compute runs on a node without nova-compute, no extra configuration is needed. By default, each zun-compute will create a resource provider in placement to represent the compute node it manages. [1] https://blueprints.launchpad.net/zun/+spec/use-placement-resource-management Change-Id: I2d85911c4504e541d2994ce3d48e2fbb1090b813
2019-08-16Allow to configure docker for ZunRadosław Piliszek1-18/+15
Change-Id: Icf3f01516185afb7b9f642407b06a0204c36ecbe Closes-Bug: #1840315 Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>
2019-08-15Add Masakari Ansible roleKien Nguyen2-0/+35
Masakari provides Instances High Availability Service for OpenStack clouds by automatically recovering failed Instances. Depends-On: https://review.openstack.org/#/c/615469/ Change-Id: I0b3457232ee86576022cff64eb2e227ff9bbf0aa Implements: blueprint ansible-masakari Co-Authored-By: Gaëtan Trellu <gaetan.trellu@incloudus.com>
2019-06-17doc: Start using openstackdoctheme's extlink extensionchenxing3-11/+8
This ensures we have version-specific references to other projects [1]. Note that this doesn't mean the URLs are actually valid - we need to do more work (linkcheck?) here, but it's an improvement nonetheless. [1] https://docs.openstack.org/openstackdocstheme/latest/#external-link-helper Change-Id: I118e4d211617c5df66ff04dc04e308a1d2fc67ad
2019-06-07Remove Neutron LBaaS supportCarlos Goncalves1-2/+1
The project has been retired and there will be no Train release [1]. This patch removes Neutron LBaaS support in Kolla. [1] https://review.opendev.org/#/c/658494/ Change-Id: Ic0d3da02b9556a34d8c27ca21a1ebb3af1f5d34c
2019-06-05Improve Qinling documentationGaetan Trellu1-13/+19
- Remove trusted_cidrs that has just been removed from Qinling code. - Remove use_api_certificate because it's true by default - Improve list syntax - Add etcd section Change-Id: I0426a9d61fbeaa23a1affbc7e981a78283e88263
2019-05-31Adds Qinling Ansible roleGaetan Trellu2-0/+97
Qinling is an OpenStack project to provide "Function as a Service". This project aims to provide a platform to support serverless functions. Change-Id: I239a0130f8c8b061b531dab530d65172b0914d7c Implements: blueprint ansible-qinling-support Story: 2005760 Task: 33468
2019-02-28Update links in docs to latestMark Goddard2-2/+2
To avoid links to OpenStack docs getting out of date in our docs, use the latest version. Ideally after cutting each stable branch we should change these links to use the current release. Co-Authored-By: Isaiah Inuwa Change-Id: Ia1e3c720f4e688861b8f76874a3943b0f4e50b17
2018-11-23Rework documentation into more specific folderEduardo Gonzalez6-0/+716
Change index to ease identify what service want to look. Split docs into more specific folder such as networking and storage. Change-Id: Ic7ac12b3dd555fa5c018eeb897ccd4a5a2dfe8f3
generated by cgit v1.2.3 (git 2.39.1) at 2026-11-11 12:33:50 +0000