- openstack-discuss - lists.openstack.org

[heat-translator][tacker] Propose Hiromu Asahina (h-asahina) for heat-translator core team
by Yoshito Ito 24 Jun '22

24 Jun '22

Hi heat-translator team! I would like to propose Hiromu Asahina (h-asahina) as a member of the heat-translator core team. I'm now not able to actively contribute to heat-translator, and he can lead the team instead of me. He is mainly contributing to Tacker by fixing issues, refactoring existing codes, and a lot of helpful reviews, with his experience as a research engineer in NTT. Tacker highly depends on heat-translator in its main functionality, so I believe he can manage it with his knowledge of Tacker. Please vote for his nomination by answering this mail till June 1st. Best Regards, Yoshito Ito

7 10

[ER] Revive elastic recheck
by Dariusz Smigiel 24 Jun '22

24 Jun '22

Hey Team! I started cherry picking changes from the rdo branch back to the master branch for Elastic Recheck. [1] I'm planning to continue doing so, to revive the master branch and continue development in the main branch. Some of the changes are incompatible between releases. We're gonna clear them case by case to enable it in the future. Thanks, Darius [1]: https://review.opendev.org/c/opendev/elastic-recheck/+/847259

1 1

[all][tc] Technical Committee next weekly meeting on 23 June 2022 at 1500 UTC
by Ghanshyam Mann 23 Jun '22

23 Jun '22

Hello Everyone, The technical Committee's next weekly meeting is scheduled for 23 June 2022, at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, 22 June at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

Swift issues in one cluster
by Albert Braden 23 Jun '22

23 Jun '22

We have multiple Swift clusters, all configured the same. One of them started failing this week. The symptom is that Swift commands take a long time to execute and sometimes they fail: $ openstack container list Unable to establish connection to https://swift.<region>.<domain>:8080/v1/AUTH_<project>: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer') When we look at the logs we see lots of swift-proxy-server errors: (from Splunk): Payload: swift-proxy-server: STDERR: File "/usr/lib64/python3.6/socket.py", line 604, in write#012 return self._sock.send(b) Payload: swift-proxy-server: STDERR: BlockingIOError Payload: swift-proxy-server: STDERR: os.read(self.rfd, 1) Payload: swift-proxy-server: STDERR: File "/usr/lib/python3.6/site-packages/eventlet/wsgi.py", line 818, in process_request#012 proto.__init__(conn_state, self) Payload: swift-proxy-server: STDERR: File "/usr/lib/python3.6/site-packages/eventlet/greenio/base.py", line 397, in send Payload: swift-proxy-server: STDERR: return self._sock.send(b) When we look at network connections, we see haproxy stacking up (many lines of this): # netstat -ntup | sort -b -k2 -n -r | head -n +100 tcp 5976932 0 127.0.0.1:60738 127.0.0.1:8080 ESTABLISHED 13045/haproxy tcp 5976446 0 127.0.0.1:58480 127.0.0.1:8080 ESTABLISHED 13045/haproxy tcp 5973217 0 127.0.0.1:33244 127.0.0.1:8080 ESTABLISHED 13045/haproxy tcp 5973120 0 127.0.0.1:51836 127.0.0.1:8080 ESTABLISHED 13045/haproxy tcp 5971968 0 127.0.0.1:58516 127.0.0.1:8080 ESTABLISHED 13045/haproxy ... If we restart the swift_haproxy and swift_proxy_server containers then the problem goes away, and comes back over a few minutes. Where should we be looking for the root cause of this issue?

2 4

[TripleO] Proposing Brendan Shephard and Takashi Kajinami
by James Slagle 23 Jun '22

23 Jun '22

I'm formally proposing that we add Brendan Shephard and Takashi Kajinami to the core reviewers team for TripleO. Takashi is already considered core on puppet-tripleo, and I'm proposing we expand that to all of TripleO, and likewise for Brendan. They both have been contributing and reviewing for a little while now, and I feel it's time to add them to the team. Please +1 or let me know any concerns before Friday June 15th. Thanks! -- -- James Slagle --

15 15

[TripleO] Gate blocker - tempest test error - 'Failed to attach network adapter device'
by Ronelle Landy 23 Jun '22

23 Jun '22

Hello All, We have a new gate blocker on tripleo-ci-centos-9-standalone, scenario-010 and possibly other jobs. The jobs fail tempest test: tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic Details of the failure are in: https://bugs.launchpad.net/tripleo/+bug/1978969. We will reply to this thread as soon as we have more information and/or a fix. Please hold rechecks for now, Thank you, TripleO CI

1 2

Re: [kolla-ansible][xena] Facing network issue when providing SR-IOV support
by Rodolfo Alonso Hernandez 23 Jun '22

23 Jun '22

Hello Harshit: You need first to fix your underlying network configuration. If the interfaces created on "sriovnet1" can't talk to each other this is because your network is blocking this traffic. Check your TOR switches to enable/allow this VLAN range. Regards. On Thu, Jun 23, 2022 at 9:42 AM Harshit Mishra <harshit(a)voereir.com> wrote: > Hello Rodolfo, > > Thanks for your support. > > If the VMs are spawned without any issue, that could be a problem in the > underlying network deployment. When sending traffic from a VM with an > SR-IOV port, try to capture the traffic in the physical function. Please > check the physical network connected to the SR-IOV network cards allow VLAN > traffic in 1000:1009 (according to your configuration). > > Network I have configured of VLAN type in a given range. > > openstack network show 4cacd198-29c3-47b3-bf77-39f1d01c9a22 -c > provider:network_type -c provider:physical_network -c > provider:segmentation_id > +---------------------------+-----------+ > | Field | Value | > +---------------------------+-----------+ > | provider:network_type | vlan | > | provider:physical_network | sriovnet1 | > | provider:segmentation_id | 1002 | > +---------------------------+-----------+ > > > Note: I forget to add that Intra-communication between the VM's working > fine deployed on same HOST but inter-communication not working. > One more thing IP address is not assigning to interfaces of VM. We have to > configure static IP address manually. > > Please find below incoming traffic flow on PF. > > > # tcpdump -i enp8s0f1 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on enp8s0f1, link-type EN10MB (Ethernet), capture size 262144 > bytes > 12:39:28.584000 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from fa:16:3e:88:f5:3e (oui Unknown), length 285 > 12:39:39.183491 IP6 fe80::a236:9fff:fe24:803a > ip6-allrouters: ICMP6, > router solicitation, length 16 > 12:39:49.660269 IP6 fe80::a236:9fff:fe53:e598.5240 > ff02::15a.5240: UDP, > length 221 > 12:39:49.660897 IP6 fe80::a236:9fff:fe53:e59a.5240 > ff02::15a.5240: UDP, > length 221 > 12:39:54.105381 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from a0:36:9f:d8:0d:a8 (oui Unknown), length 293 > 12:39:54.897051 LLDP, length 46 > 12:39:56.281671 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 3c:fd:fe:cd:06:71 (oui Unknown), length 293 > 12:40:06.286310 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from a0:36:9f:d8:0d:aa (oui Unknown), length 293 > 12:40:15.039416 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 3c:fd:fe:cd:06:70 (oui Unknown), length 293 > 12:40:19.675902 IP6 fe80::a236:9fff:fe53:e598.5240 > ff02::15a.5240: UDP, > length 221 > 12:40:19.676390 IP6 fe80::a236:9fff:fe53:e59a.5240 > ff02::15a.5240: UDP, > length 221 > 12:40:25.708972 LLDP, length 46 > 12:40:29.288242 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from fa:16:3e:c4:3f:4f (oui Unknown), length 285 > 12:40:33.008653 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from fa:16:3e:88:f5:3e (oui Unknown), length 285 > > > > Another question: do the VMs with SR-IOV port receive the DHCP reply? If > so, at least you know the compute to controller communication is working > (assuming the DHCP agent is on the controller). > > No, VMs not receiving DHCP reply, you can refer above logs. Yes, DHCP > agent is on controller. > > Kindly let me know anything else is required. > > Thanks! > > Regards, > Harshit Mishra > > ------------------------------ > *From:* Rodolfo Alonso Hernandez <ralonsoh(a)redhat.com> > *Sent:* Wednesday, June 22, 2022 6:46 PM > *To:* Harshit Mishra <harshit(a)voereir.com> > *Subject:* Re: [kolla-ansible][xena] Facing network issue when providing > SR-IOV support > > Hello Harshit: > > If the VMs are spawned without any issue, that could be a problem in the > underlying network deployment. When sending traffic from a VM with an > SR-IOV port, try to capture the traffic in the physical function. Please > check the physical network connected to the SR-IOV network cards allow VLAN > traffic in 1000:1009 (according to your configuration). > > Another question: do the VMs with SR-IOV port receive the DHCP reply? If > so, at least you know the compute to controller communication is working > (assuming the DHCP agent is on the controller). > > Regards. > > On Wed, Jun 22, 2022 at 2:17 PM Harshit Mishra <harshit(a)voereir.com> > wrote: > > Hi! > > > I have deployed Openstack Xena using kolla-ansible (v13.0.1) on a > multi-node setup (1 controller+network, multiple computes). > > > > On this cluster I would like to have support for normal, as well as direct > (SR-IOV) vNIC types. > > > > I have done all the pre-requirement like configure VF on SR-IOV network > interface. > > > > In the current deployment, I have created two physnets, one for flat > network (called physnet1 on br-ex), and one for SR-IOV (called sriovnet1 on > Intel 10G 2P X520 card). I am creating one network of VXLAN type for normal > vNIC, and one of VLAN type on sriovnet1 (called sriov_network) for direct > vNIC. > > > > Mapping of PF with provider in sriov-agent.ini: > > > > # cat /etc/kolla/neutron-sriov-agent/sriov_agent.ini > > [sriov_nic] > > physical_device_mappings = sriovnet1:enp8s0f1 > > exclude_devices = > > > > [securitygroup] > > firewall_driver = neutron.agent.firewall.NoopFirewallDriver > > > > ---------------------------------------------- > > ml2_conf.ini on controller node: > > > > # cat /etc/kolla/neutron-server/ml2_conf.ini > > [ml2] > > type_drivers = flat,vlan,vxlan > > tenant_network_types = vxlan,vlan,flat > > mechanism_drivers = openvswitch,l2population,sriovnicswitch > > extension_drivers = port_security > > > > [ml2_type_vlan] > > network_vlan_ranges = physnet1,sriovnet1:1000:1009 > > > > [ml2_type_flat] > > flat_networks = physnet1,sriovnet1 > > > > [ml2_sriov] > > agent_required = False > > supported_pci_vendor_devs = 8086:10ed > > > > [ml2_type_vxlan] > > vni_ranges = 1:1000 > > > > ---------------------------------------------- > > > > # grep -nr enabled_filters /etc/kolla/nova-scheduler/ > > /etc/kolla/nova-scheduler/nova.conf:13:enabled_filters = > ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,SameHostFilter,DifferentHostFilter,AggregateInstanceExtraSpecsFilter,PciPassthroughFilter > > > > ---------------------------------------------- > > > > # grep passthrough /etc/kolla/nova-compute/nova.conf > > passthrough_whitelist = [{"physical_network": "sriovnet1", "devname": > "enp8s0f1"}] > > > > > > The interfaces on VMs from normal vNICs are able to communicate > inter-compute. The same is not working for the direct vNICs belonging to > the sriov_network. I have tried multiple config changes, but none seem to > work. > > > > Please help in solving this issue, or suggest a different way of achieving > this if this is wrong or not optimal. > > > > Thanks! > > Regards, > Harshit Mishra > >

1 0

Re: 504 Gateway time out error while loading OpenStack Projects
by Eugen Block 23 Jun '22

23 Jun '22

Please keep the responses in the list so others can see your responses, too, and chime in with their comments. How is your dashboard configured regarding cache? This is our config (/srv/www/openstack-dashboard/openstack_dashboard/local/local_settings.d/_100_local_settings.py): CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 'LOCATION': [ '<IP1>:11211', '<IP2>:11211', ] } } Our memcached config has both localhost and its management IP: MEMCACHED_PARAMS="-U 0 -m 64 -l 127.0.0.1,<IP1> -p 11211 -c 4096" The reason for that is we noticed performance improvements when we replaced the list of control nodes for all the services and point to localhost instead: # before #memcached_servers = controller01:11211,controller02:11211 # after memcached_servers = localhost:11211 Zitat von Adivya Singh <adivya1.singh(a)gmail.com>: > Hello, > > My setting in memcache looks like this, because it is default taken by > ansible > > -d > -v > -U 0 > -m 1024 > -p 11211 > -u memcache > -l 172.29.x.X > -c 4096 > -t 4 > > So should i change the time out perimeter to something else > > Regards > Adivya Singh > > On Wed, Jun 15, 2022 at 8:53 PM Maysa De Macedo Souza <mdemaced(a)redhat.com> > wrote: > >> Hello, >> >> Maybe increasing the value of a setting like >> memcache_pool_conn_get_timeout can help? >> >> Cheers, >> Maysa. >> >> On Wed, Jun 15, 2022 at 2:05 PM Eugen Block <eblock(a)nde.ag> wrote: >> >>> Hi, >>> >>> I remember having a similar issue a few years back in an older >>> openstack release, probably Ocata. We had difficulties loading *all* >>> instances in the admin tab in Horizon dashboard. It turned out to be a >>> memcached misconfiguration. I don't recall the details, unfortunately. >>> But I'd start with memcached. >>> >>> >>> Zitat von Adivya Singh <adivya1.singh(a)gmail.com>: >>> >>> > hi Team, >>> > >>> > We have Xena release installed on Ubuntu Openstack, Lately we are >>> getting >>> > "504 Gateway Timeout error ", As the we moved from 1 node to 3 node Open >>> > Stack >>> > i do not see any error in haproxy , neither there is a time out when i >>> ping >>> > external-VIP-IP configured. >>> > >>> > Apache 2 are also loaded, tried to delete the Horizon Container and >>> created >>> > it again, but no errors, Still the same errors. >>> > >>> > Any guesses on that >>> > >>> > Regards >>> > Adivya Singh >>> >>> >>> >>> >>>

1 0

Neutron/OVN + IPv6
by Tiago Pires 23 Jun '22

23 Jun '22

Hi all, I am trying to figure out how to enable workloads on overlay to use IPv6 addresses and communicate with external networks. I have to use Neutron ML2/OVN in my scenario and I have doubts regarding how the external networks(Internet) can know how to reach the VMs using IPv6 address behind a regular neutron router. I was checking this link https://cloudbau.github.io/openstack/neutron/networking/2016/05/17/neutron-… that uses the BGP speaker on neutron in order to advertise the /64 subnets to a border router, that option should work fine but Neutron/BGP Speaker is not supported with OVN as I could check on the documentation. How are you using IPv6 integration (Neutron/OVN) to advertise the /64 subnets? Tiago Pires

4 4

R: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi
by Molka Gharbaoui 23 Jun '22

23 Jun '22

3 4