openstack-discuss
Threads by month
- ----- 2026 -----
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
July 2023
- 99 participants
- 115 discussions
23 Apr '25
Looking for someone who knows OpenStack with OpenVSwitch, and in additionto that, DPDK with OpenStack and OVS.I am using OpenStack Queens, withOpenVSwitch. The architecture I am using is documented here:https://docs.openstack.org/neutron/queens/admin/deploy-ovs-provider.htmlTheOVS I am using on the Compute Node, is compiled with DPDK, and I haveenabled the datapath to netdev (DPDK) on br-prv (provider network bridge),and br-tun (tunneling bridge). But these two bridges, br-tun and br-prv,are patched into another OpenStack bridge, called br-int. I wasn’t actuallysure about whether to tinker with this bridge, and wondered what datapathit was using.Then, I realized there is a parameter in theopenvswitch_agent.ini file, which I will list here:# OVS datapath to use. 'system' is the default value and corresponds to the# kernel datapath. To enable the userspace datapath set this value to 'netdev'.# (string value)# Possible values:# system - <No description provided># netdev - <No description provided>#datapath_type = systemdatapath_type = netdevSo in tinkering with this, what I realized, is that when you set thisdatapath_type to system or netdev, it will adjust the br-int bridge to thatdatapath type.So here is my question. How can I launch a non-DPDK VM, ifall of the bridges are using the netdev datapath type?Here is anotherquestion. What if one of the flavors don’t have the largepages property seton them? I assumed OpenStack would revert to a system datapath and not useDPDK for those VM interfaces. Well, I found out in testing, that is not thecase. If you set all your bridges up for netdev, and you don’t set theproperty on the Flavor of the VM (largepages), the VM will launch, but itsimply won’t work.Is there no way, on a specific Compute Host, to supportboth DPDK (netdev datapaths) and non-DPDK (system datapaths)?Either on a VMinterface level (VM has one interface that is netdev DPDK and another thatis system datapath non-DPDK)?Or on a VM by VM basis (VM 1 has 1 or morenetdev datapath interfaces and VM 2 has 1 or more system datapathinterfaces)?Am I right here? Once you set up a Compute Host for DPDK, it’sDPDK or nothing on that Compute Host? (edited)
3 2
22 Apr '25
Hi....as far I understand ovs does support dpdk compute to be deployed. I'mreferring to the guideline '*https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html<https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html>* ' ...It's too brief.. May I know how to config dpdk compute in OVN networkingopenstack? Hope someone could help what is the config to be done....Currently compute is run without dpdk over openstack train ovn based.Please need some info on how I can proceed. Thank you
2 1
ERROR openstack [-] Resource OS::TripleO::Network::Ports::ControlPlaneVipPort maps to type OS::Neutron::Port and the Neutron service is not available when using ephemeral Heat.| Openstack tripleo wallaby version
by Swogat Pradhan 23 Dec '24
by Swogat Pradhan 23 Dec '24
23 Dec '24
Hi,I am currently trying to deploy openstack wallaby using tripleo arch.I created the network jinja templates, ran the following commands also:#openstack overcloud network provision --stack overcloud --outputnetworks-deployed-environment.yaml custom_network_data.yaml# openstack overcloud network vip provision --stack overcloud --outputvip-deployed-environment.yaml custom_vip_data.yaml# openstack overcloud node provision --stack overcloud--overcloud-ssh-key /home/stack/sshkey/id_rsaovercloud-baremetal-deploy.yamland used the environment files in the openstack overcloud deploy command:(undercloud) [stack@hkg2director ~]$ cat deploy.sh#!/bin/bashTHT=/usr/share/openstack-tripleo-heat-templates/CNF=/home/stack/openstack overcloud deploy --templates $THT \-r $CNF/templates/roles_data.yaml \-n $CNF/workplace/custom_network_data.yaml \-e ~/containers-prepare-parameter.yaml \-e $CNF/templates/node-info.yaml \-e $CNF/templates/scheduler-hints.yaml \-e $CNF/workplace/networks-deployed-environment.yaml \-e $CNF/workplace/vip-deployed-environment.yaml \-e $CNF/workplace/overcloud-baremetal-deployed.yaml \-e $CNF/workplace/custom-net-bond-with-vlans.yamlNow when i run the ./deploy.sh script i encounter an error stating:ERROR openstack [-] ResourceOS::TripleO::Network::Ports::ControlPlaneVipPort maps to typeOS::Neutron::Port and the Neutron service is not available when usingephemeral Heat. The generated environments from 'openstack overcloudbaremetal provision' and 'openstack overcloud network provision' must beincluded with the deployment command.:tripleoclient.exceptions.InvalidConfiguration: ResourceOS::TripleO::Network::Ports::ControlPlaneVipPort maps to typeOS::Neutron::Port and the Neutron service is not available when usingephemeral Heat. The generated environments from 'openstack overcloudbaremetal provision' and 'openstack overcloud network provision' must beincluded with the deployment command.2022-04-19 13:47:16.582 735924 INFO osc_lib.shell [-] END return value: 1Can someone tell me where the mistake is?With regards,Swogat Pradhan
4 4
26 Nov '24
Hello Koalas,OpenEuler jobs in master (to be Antelope) are failing for a long time.If no one is interested in maintaining OpenEuler support in Kolla-Ansible - I will propose dropping it’s support on Wednesday Kolla meeting.Best regards,Michal
4 3
10 Oct '24
Hi,I'm attempting to use Kolla Ansible 14.6.0 to deploy OpenStack Yoga on asmall 3-node Ubuntu 20.04 cluster. The nodes have 128 GB RAM each, dualXeon processors, and dual 10G Intel NICs. The NICs are connected to accessports on a 10G switch with separate VLANs for the local and externalnetworks.All the playbooks run cleanly, but cloud-init is failing in theUbuntu 20.04 and 22.04 VMs I attempt to boot. The VM images are unmodifiedfromhttps://cloud-images.ubuntu.com/, and cloud-init works fine if I mounta second volume with user-data. The error is a timeout attempting toreach 169.254.169.254. This occurs both when booting a VM in an internalrouted network and directly in an external network.I tried various neutron plugin agents (ovn, linuxbridge, and openvswitchboth with and without firewall_driver = openvswitch<https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutro…>)first with a clean install of the entire OS each time, all with the sameresult. Running tcpdump looking for 169.254.169.254 shows nothing. As apossible clue, the virtual NICs are unable to pass any traffic (e.g., toreach an external DHCP server) unless I completely disable port security onthe interface (even if the associated security group is wide open). Butdisabling port security does not fix cloud-init (not to mention I don'treally want to disable port security).Are there any additional requirements related to deploying OpenStack withKolla on Ubuntu 20.04?This is a fairly vanilla configuration using the multinode inventory as astarting point. I tried to follow the Quick Start<https://docs.openstack.org/kolla-ansible/yoga/user/quickstart.html> asclosely as possible; the only material difference I see is that I'm usingthe same 3 nodes for control + compute. I am using MAAS so it's easy to geta clean OS install on all three nodes ahead of each attempt. I plan to tryagain with the standard (non-HWE) kernel just in case, but otherwise I amrunning out of ideas. In case of any additional clues, here are myglobals.yml and inventory file, along with the playbook I'm using toconfigure the network, images, VMs, etc., after bootstrapping the cluster:https://gist.github.com/tobiasmcnulty/7dbbdbc67abc08cbb013bf5983852ed6Thank you in advance for any advice!Cheers,Tobias
5 9
06 Aug '24
Hi,I have couple of compute nodes where the live migration fails with existing vms.When I quickly spawn a vm and try live migration it works so I assume shouldn't be a big problem with the compute node.However I have many existing vms where it fails with a servername not found./var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 ERROR nova.conductor.tasks.migrate [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] [instance: 1517a2ac-3b51-4d8d-80b3-89a5614d1ae0] Unable to find record for source node servername on servername: ComputeHostNotFound: Compute host servername could not be found./var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 WARNING nova.scheduler.utils [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] Failed to compute_task_migrate_server: Compute host servername could not be found.: ComputeHostNotFound: Compute host servername could not be found./var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 WARNING nova.scheduler.utils [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] [instance: 1517a2ac-3b51-4d8d-80b3-89a5614d1ae0] Setting instance to ACTIVE state.: ComputeHostNotFound: Compute host servername could not be found./var/log/nova/nova-conductor.log:2021-04-21 14:47:12.672 227612 ERROR oslo_messaging.rpc.server [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] Exception during message handling: ComputeHostNotFound: Compute host am-osfecn-4025Tried with this command:nova live-migration --block-migrate id.Any idea?Thank you.________________________________This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.
5 16
[ptl][tc] OpenStack packages PyPi additional external maintainers audit & cleanup
by Ghanshyam Mann 16 May '24
by Ghanshyam Mann 16 May '24
16 May '24
Hi PTLs,As you might know or have seen for your project package on PyPi, OpenStack deliverables on PyPi haveadditional maintainers, For example,https://pypi.org/project/murano/,https://pypi.org/project/glance/We should keep only 'openstackci' as a maintainer in PyPi so that releases of OpenStack deliverablescan be managed in a single place. Otherwise, we might face the two sets of maintainers' places andpackages might get released in PyPi by additional maintainers without the OpenStack project teamknowing about it. One such case is in Horizon repo 'xstatic-font-awesome' where a new maintainer isadded by an existing additional maintainer and this package was released without the Horizon teamknowing about the changes and release.-https://github.com/openstack/xstatic-font-awesome/pull/2To avoid the 'xstatic-font-awesome' case for other packages, TC discussed it in their weekly meetings[1]and agreed to audit all the OpenStack packages and then clean up the additional maintainers in PyPi(keep only 'openstackci' as maintainers). To help in this task, TC requests project PTL to perform the audit for their project's repo and add commentsin the below etherpad.-https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanupThanks to knikolla to automate the listing of the OpenStack packages with additional maintainers in PyPi whichyou can find the result in output.txt at the bottom of this link. I have added the project list of who needs to checktheir repo in etherpad.-https://gist.github.com/knikolla/7303a65a5ddaa2be553fc6e54619a7a1Please complete the audit for your project before March 15 so that TC can discuss the next step in vPTG.[1]https://meetings.opendev.org/meetings/tc/2023/tc.2023-01-11-16.00.log.html#…-gmann
18 27
[Watcher] How use Watcher to scheduler Openstack resource without cpu_usage
by Nguyễn Hữu Khôi 06 Mar '24
by Nguyễn Hữu Khôi 06 Mar '24
06 Mar '24
Hello guys.I want to use watcher to scheduler openstack resources but some openstackversions are missing cpu_usage metric. How do we use Watcher without it?Thank you.Nguyen Huu Khoi
3 5
12 Feb '24
Hi all!One of the biggest show stoppers for us for OVN is VPNaaS but I think it’s time that we’d like to be involved in getting it over the line, I want to thank Bodo who has shown a lot of patience in getting the code necessary, and it seems that the code works for them in production as well.I’d like to ask if possible for folks to review these two outstanding changes:https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/847007https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353I know Slawek had some concerns, so hoping that raising via the email list if Bodo can address those and over the next bit of time we can get this landed in, since it even has actual proper testing both in CI and with user feedback.Thanks!Mohammed
6 8
[designate] Proposal to deprecate the agent framework and agent based backends
by Michael Johnson 09 Jan '24
by Michael Johnson 09 Jan '24
09 Jan '24
TLDR: The Designate team would like to deprecate the backend agentframework and the agent based backends due to lack of development anddesign issues with the current implementation. The following backendswould be deprecated: Bind9 (Agent), Denominator, Microsoft DNS(Agent), Djbdns (Agent), Gdnsd (Agent), and Knot2 (Agent).Designate includes many backend DNS server drivers[1], many of whichare "native" (also known as xfr type backends) backendimplementations. In addition to the "native" backends, Designate hasan agent backend[2] that supports other backends via an agent process.To quote the agent backend documentation[2]: This backend uses an extension[3] of the DNS protocol itself tosend management requests to the remote agent processes, where the requests will be actioned. The rpc traffic between designate and the agent is bothunauthenticated and unencrypted. Do not run this traffic over unsecured networks.Here are the reasons we are proposing to deprecate the agent framework now:1. The agent protocol used by Designate is using an "unassigned"[4][5]DNS opcode (14) that is causing problems with the dnspython library >=2.3.0 which is now validating the opcode when building DNS messages.It is a bad practice to use "unassigned" values as they may beofficially assigned at any time, likely with an incompatible messageformat.2. The agent backends are not tested in the OpenStack jobs[1].3. Many of the agent backends have been marked as "Experimental" since2016 with no additional contributions beyond general repository codemaintenance.4. The protocol between the Designate worker process and the agentprocess is unauthenticated and unencrypted.5. We do not know of a development resource to rewrite the agentframework protocol to address issue #1 and #4 above.6. The introduction of catalog zones[6] may eliminate the need forsome of the agent based backend drivers.By marking the agent framework and agent based backends "deprecated"in the Antelope cycle, we would remove the code no earlier than the"C" release of OpenStack (per the OpenStack deprecation policy[7]). Inthe meantime, issue #1 has been worked around by overriding thednspython opcode validation[7] as needed in the Designate code(similar to a monkey patch). This is not a sustainable long termsolution.The following backend agent based drivers would be marked "deprecated"in addition to the agent framework itself:Bind9 (Agent)DenominatorMicrosoft DNS (Agent)Djbdns (Agent)Gdnsd (Agent)Knot2 (Agent)We plan to propose patches for the deprecation over the next week, butwill not merge them until at least January 24th to allow time forcomment from the community.If you have concerns about this deprecation plan or are interested inrewriting the agent framework protocol to address the above issues,please reply to this announcement.Michael[1]https://docs.openstack.org/designate/latest/admin/support-matrix.html[2]https://docs.openstack.org/designate/latest/admin/backends/agent.html[3]https://github.com/openstack/designate/blob/master/designate/backend/privat…[4]https://www.rfc-editor.org/rfc/rfc6895.html#section-2.2[5]https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-pa…[6]https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-08.txt[7]https://docs.openstack.org/project-team-guide/deprecation.html[8]https://review.opendev.org/c/openstack/designate/+/870678
3 13