July 2021 - openstack-discuss - lists.openstack.org

How the add public ip address to access dashboard
by Salman Sheikh 07 Jul '21

07 Jul '21

Hi all, Suppose in LAN the dashboard is accessible on 192.168.0.3/dashboard, if we want to access it on the internet public ip for ex:124.124.222.34. How can we do this, so it can be accessible through both ips192.168.0.3 and 124.124.22.34. And how we can remove /dashboard from the url. so it can be accessible on 192.168.0.3 instead of 192.168.0.3/dashboard. Kind regards

1 0

PXE in Oracle VM Virtual Box
by Adivya Singh 07 Jul '21

07 Jul '21

Hi Team, is there any individual link for setup a PXE in Oracle VM Virtual Box I have setup the Network boot as first priority but once the VM comes up, it is giving me below error "No Such boot or media error, i can understand the error, but not able to get the correct steps to rectify this error Regards Adivya Singh

1 0

[all][policy] Disable & making policy rule's default change warning configurable
by Ghanshyam Mann 06 Jul '21

06 Jul '21

Hello Everyone, While implementing the new secure RBAC (scope and new defaults), you might have noticed the lot of warnings in the log and sometime failing jobs also due to size of logs. Then you had to disable those via "suppress_default_change_warnings" variable on policy enforcer. The oslo policy log the warnings if the default value of policy rule (if not overridden) is changed, so there are warnings for every policy rule on every API request, everytime policy is initialized which end up a lot of warnings (thousands) in log. It might be happening in production also. Many projects have disabled it via hardcoded "suppress_default_change_warnings". But there is no way for the operator to disable/enable these warnings (enable in case they would like to check the new policy RBAC). To handle it on oslo policy side and generically for all the projects I am planning to: 1. Disable it by default in oslo policy side itself. 2. Make it configurable so that operator can enable it on need basis. NOTE: This proposal is about warnings for default value change, not for the policy name change. I have submitted this proposal in gerrit too - https://review.opendev.org/c/openstack/oslo.policy/+/799539 Please let me know your opinon on this? -gmann

2 2

[Ironic] Vendor-neutral Disk names
by Mahnoor Asghar 06 Jul '21

06 Jul '21

Dear all, There is [a proposal][1] in the metal3-io/baremetal-operator repository to extend the hardware RAID configuration to support ‘physical_disks’ and ‘controller’ fields in the 'target_raid_config' section. The user should be able to specify the disks for RAID configuration, in a vendor-agnostic way. (This requirement comes from the Airship project.) The names of the disks should be indicative of the physical location of the disks within the server. An algorithm to construct disk names is therefore needed, for this purpose. One possible algorithm was found in the [inventory module][2] of the [Redfish Tacklebox scripts][3]. To construct a disk name, it uses Redfish properties, specifically the ‘Drive’ resource> ‘Physical Location’ object> ‘Part Location’ property> ‘Service Label’ property. ([Link][4] to code) ([Link][5] to Redfish ‘Drive’ resource) If this property is empty, the resource type (String uptil the first dot encountered in the @odata.type field), and the ‘Id’ properties of the Drive resource are used to construct the disk name. ([Link][6] to code) For example, if the 'Drive'.'Physical Location'.'Part Location'.'Service Label' field is ‘Disk.Bay1.Slot0’, this is what the disk name will be. If this field is empty, and the resource name is ‘Drive’ and the resource ‘Id’ is ‘Disk.Bay1.Slot0’, the disk name will be: ‘Drive: Disk.Bay1.Slot0’. We would like to understand the values different vendors give in: - ‘Drive’ resource> ‘Physical Location’ object> ‘Part Location’ property> ‘Service Label’ property - The resource type for a Drive (@odata.type field) - The ‘Id’ property of the Drive resource Also, it would be helpful to understand the existing logic used by vendors to construct the disk names, including the (Redfish or other) properties used. This is so that a consensus can be reached for an algorithm to construct disk names. Any suggestions are welcome, thank you so much! [1]: https://github.com/metal3-io/metal3-docs/pull/148 [2]: https://github.com/DMTF/Redfish-Tacklebox/blob/master/redfish_utilities/inv… [3]: https://github.com/DMTF/Redfish-Tacklebox [4]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce4… [5]: https://redfish.dmtf.org/schemas/v1/Drive.v1_12_1.json [6]: https://github.com/DMTF/Redfish-Tacklebox/blob/e429f70a79cfe288756618498ce4… Best regards, Mahnoor Asghar Software Design Engineer xFlow Research Inc. mahnoor.asghar(a)xflowresearch.com www.xflowresearch.com

4 6

[TripleO] next irc meeting Tuesday 06 July @ 1400 UTC in OFTC #tripleo
by Marios Andreou 06 Jul '21

06 Jul '21

Reminder the next TripleO irc meeting is today Tuesday 06 July 1400 UTC in OFTC irc channel #tripleo. agenda: https://wiki.openstack.org/wiki/Meetings/TripleO one-off items: https://etherpad.opendev.org/p/tripleo-meeting-items (feel free to add any tripleo status/ongoing work etc to the etherpad). Our last meeting was on Jun 22 - you can find logs @ http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-06-22-14.… Hope you can make it on Tuesday, regards, marios

1 0

[wallaby][nova] CPU topology and NUMA Nodes
by Ammad Syed 06 Jul '21

06 Jul '21

Hi, I am using openstack wallaby on ubuntu 20.04 and kvm. I am working to make optimized flavor properties that should provide optimal performance. I was reviewing the document below. https://docs.openstack.org/nova/wallaby/admin/cpu-topologies.html I have two socket AMD compute node. The workload running on nodes are mixed workload. My question is should I use default nova CPU topology and NUMA node that nova deploys instance by default OR should I use hw:cpu_sockets='2' and hw:numa_nodes='2'. Which one from above provide best instance performance ? or any other tuning should I do ? The note in the URL (CPU topology sesion) suggests that I should stay with default options that nova provides. Currently it also works with libvirt/QEMU driver but we don’t recommend it in production use cases. This is because vCPUs are actually running in one thread on host in qemu TCG (Tiny Code Generator), which is the backend for libvirt/QEMU driver. Work to enable full multi-threading support for TCG (a.k.a. MTTCG) is on going in QEMU community. Please see this MTTCG project <http://wiki.qemu.org/Features/tcg-multithread> page for detail. Ammad

5 9

[wallaby][neutron][ovn] Low network performance between instances on different compute nodes using OVN Geneve tunnels
by Malik Obaid 06 Jul '21

06 Jul '21

Hi, I am using Openstack Wallaby release with OVN on Ubuntu 20.04. My environment consists of 2 compute nodes and 1 controller node. ovs_version: "2.15.0" Ubuntu Kernel Version: 5.4.0-77-generic I am observing Network performance between instances on different compute nodes is slow. The network uses geneve tunnels.The environment is using 10Gbps network interface cards. However, iperf between instances on different compute nodes attains only speeds between a few hundred Mbit/s and a few Gb/s. Both instances are in the same tenant network. Note: iperf results between both compute nodes (hypervisors) across the geneve tunnel endpoints is perfect 10 Gbps. Below are the results of iperf commands. *iperf server:* 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc fq_codel state UP group default qlen 1000 link/ether fa:16:3e:4b:1d:29 brd ff:ff:ff:ff:ff:ff inet 192.168.100.111/24 brd 192.168.100.255 scope global dynamic ens3 valid_lft 42694sec preferred_lft 42694sec inet6 fe80::f816:3eff:fe4b:1d29/64 scope link valid_lft forever preferred_lft forever root@vm-01:~# iperf3 -s Server listening on 5201 Accepted connection from 192.168.100.69, port 45542 [ 5] local 192.168.100.111 port 5201 connected to 192.168.100.69 port 45544 [ 8] local 192.168.100.111 port 5201 connected to 192.168.100.69 port 45546 [ ID][Role] Interval Transfer Bitrate Retr Cwnd [ 5][RX-S] 0.00-1.00 sec 692 MBytes 5.81 Gbits/sec [ 8][TX-S] 0.00-1.00 sec 730 MBytes 6.12 Gbits/sec 0 3.14 MBytes [ 5][RX-S] 1.00-2.00 sec 598 MBytes 5.01 Gbits/sec [ 8][TX-S] 1.00-2.00 sec 879 MBytes 7.37 Gbits/sec 0 3.14 MBytes [ 5][RX-S] 2.00-3.00 sec 793 MBytes 6.65 Gbits/sec [ 8][TX-S] 2.00-3.00 sec 756 MBytes 6.34 Gbits/sec 0 3.14 MBytes [ 5][RX-S] 3.00-4.00 sec 653 MBytes 5.48 Gbits/sec [ 8][TX-S] 3.00-4.00 sec 871 MBytes 7.31 Gbits/sec 0 3.14 MBytes [ 5][RX-S] 4.00-5.00 sec 597 MBytes 5.01 Gbits/sec [ 8][TX-S] 4.00-5.00 sec 858 MBytes 7.20 Gbits/sec 0 3.14 MBytes [ 5][RX-S] 5.00-6.00 sec 734 MBytes 6.16 Gbits/sec [ 8][TX-S] 5.00-6.00 sec 818 MBytes 6.86 Gbits/sec 0 3.14 MBytes [ 5][RX-S] 6.00-7.00 sec 724 MBytes 6.06 Gbits/sec [ 8][TX-S] 6.00-7.00 sec 789 MBytes 6.60 Gbits/sec 0 3.14 MBytes [ 5][RX-S] 7.00-8.00 sec 735 MBytes 6.18 Gbits/sec [ 8][TX-S] 7.00-8.00 sec 835 MBytes 7.02 Gbits/sec 0 3.14 MBytes [ 5][RX-S] 8.00-9.00 sec 789 MBytes 6.62 Gbits/sec [ 8][TX-S] 8.00-9.00 sec 845 MBytes 7.09 Gbits/sec 0 3.14 MBytes [ 5][RX-S] 9.00-10.00 sec 599 MBytes 5.02 Gbits/sec [ 8][TX-S] 9.00-10.00 sec 806 MBytes 6.76 Gbits/sec 0 3.14 MBytes [ ID][Role] Interval Transfer Bitrate Retr [ 5][RX-S] 0.00-10.00 sec 6.75 GBytes 5.80 Gbits/sec receiver [ 8][TX-S] 0.00-10.00 sec 7.99 GBytes 6.87 Gbits/sec 0 sender Server listening on 5201 *Client side:* root@vm-03:~# iperf3 -c 192.168.100.111 --bidir Connecting to host 192.168.100.111, port 5201 [ 5] local 192.168.100.69 port 45544 connected to 192.168.100.111 port 5201 [ 7] local 192.168.100.69 port 45546 connected to 192.168.100.111 port 5201 [ ID][Role] Interval Transfer Bitrate Retr Cwnd [ 5][TX-C] 0.00-1.00 sec 700 MBytes 5.87 Gbits/sec 0 3.13 MBytes [ 7][RX-C] 0.00-1.00 sec 722 MBytes 6.06 Gbits/sec [ 5][TX-C] 1.00-2.00 sec 594 MBytes 4.98 Gbits/sec 0 3.13 MBytes [ 7][RX-C] 1.00-2.00 sec 883 MBytes 7.41 Gbits/sec [ 5][TX-C] 2.00-3.00 sec 796 MBytes 6.67 Gbits/sec 0 3.13 MBytes [ 7][RX-C] 2.00-3.00 sec 752 MBytes 6.31 Gbits/sec [ 5][TX-C] 3.00-4.00 sec 654 MBytes 5.49 Gbits/sec 0 3.13 MBytes [ 7][RX-C] 3.00-4.00 sec 876 MBytes 7.35 Gbits/sec [ 5][TX-C] 4.00-5.00 sec 598 MBytes 5.01 Gbits/sec 0 3.13 MBytes [ 7][RX-C] 4.00-5.00 sec 853 MBytes 7.16 Gbits/sec [ 5][TX-C] 5.00-6.00 sec 734 MBytes 6.15 Gbits/sec 0 3.13 MBytes [ 7][RX-C] 5.00-6.00 sec 818 MBytes 6.86 Gbits/sec [ 5][TX-C] 6.00-7.00 sec 726 MBytes 6.09 Gbits/sec 0 3.13 MBytes [ 7][RX-C] 6.00-7.00 sec 793 MBytes 6.65 Gbits/sec [ 5][TX-C] 7.00-8.00 sec 734 MBytes 6.15 Gbits/sec 0 3.13 MBytes [ 7][RX-C] 7.00-8.00 sec 831 MBytes 6.97 Gbits/sec [ 5][TX-C] 8.00-9.00 sec 788 MBytes 6.61 Gbits/sec 0 3.13 MBytes [ 7][RX-C] 8.00-9.00 sec 845 MBytes 7.09 Gbits/sec [ 5][TX-C] 9.00-10.00 sec 600 MBytes 5.03 Gbits/sec 0 3.13 MBytes [ 7][RX-C] 9.00-10.00 sec 805 MBytes 6.76 Gbits/sec [ ID][Role] Interval Transfer Bitrate Retr [ 5][TX-C] 0.00-10.00 sec 6.76 GBytes 5.81 Gbits/sec 0 sender [ 5][TX-C] 0.00-10.00 sec 6.75 GBytes 5.80 Gbits/sec receiver [ 7][RX-C] 0.00-10.00 sec 7.99 GBytes 6.87 Gbits/sec 0 sender [ 7][RX-C] 0.00-10.00 sec 7.99 GBytes 6.86 Gbits/sec receiver iperf Done. --------------------------------------------------------------------------------------------------------- *ovs-vsctl show on compute node1:* root@kvm01-a1-khi01:~# ovs-vsctl show 88e6b984-44dc-4f74-8a9a-891742dbbdbd Bridge br-eth1 Port ens224 Interface ens224 Port patch-provnet-440be99a-c347-4458-b7c1-6c0e6155eee9-to-br-int Interface patch-provnet-440be99a-c347-4458-b7c1-6c0e6155eee9-to-br-int type: patch options: {peer=patch-br-int-to-provnet-440be99a-c347-4458-b7c1-6c0e6155eee9} Port br-eth1 Interface br-eth1 type: internal Bridge br-int fail_mode: secure datapath_type: system Port tapde98b2d4-a0 Interface tapde98b2d4-a0 Port ovn-f51ef9-0 Interface ovn-f51ef9-0 type: vxlan options: {csum="true", key=flow, remote_ip="172.16.30.3"} bfd_status: {diagnostic="No Diagnostic", flap_count="1", forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up, state=up} Port tap348fc6dc-3a Interface tap348fc6dc-3a Port br-int Interface br-int type: internal Port tap6d4d8e02-c0 Interface tap6d4d8e02-c0 error: "could not open network device tap6d4d8e02-c0 (No such device)" Port patch-br-int-to-provnet-440be99a-c347-4458-b7c1-6c0e6155eee9 Interface patch-br-int-to-provnet-440be99a-c347-4458-b7c1-6c0e6155eee9 type: patch options: {peer=patch-provnet-440be99a-c347-4458-b7c1-6c0e6155eee9-to-br-int} Port tap247fe5b2-ff Interface tap247fe5b2-ff ------------------------------------------------------------------------------------------------------ *ovs-vsctl show on compute node2:* root@kvm03-a1-khi01:~# ovs-vsctl show 24ce6475-89bb-4df5-a5ff-4ce58f2c2f68 Bridge br-eth1 Port patch-provnet-440be99a-c347-4458-b7c1-6c0e6155eee9-to-br-int Interface patch-provnet-440be99a-c347-4458-b7c1-6c0e6155eee9-to-br-int type: patch options: {peer=patch-br-int-to-provnet-440be99a-c347-4458-b7c1-6c0e6155eee9} Port br-eth1 Interface br-eth1 type: internal Port ens224 Interface ens224 Bridge br-int fail_mode: secure datapath_type: system Port patch-br-int-to-provnet-440be99a-c347-4458-b7c1-6c0e6155eee9 Interface patch-br-int-to-provnet-440be99a-c347-4458-b7c1-6c0e6155eee9 type: patch options: {peer=patch-provnet-440be99a-c347-4458-b7c1-6c0e6155eee9-to-br-int} Port tap2b0bbf7b-59 Interface tap2b0bbf7b-59 Port ovn-650be8-0 Interface ovn-650be8-0 type: vxlan options: {csum="true", key=flow, remote_ip="172.16.30.1"} bfd_status: {diagnostic="No Diagnostic", flap_count="1", forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up, state=up} Port tap867d2174-83 Interface tap867d2174-83 Port tapde98b2d4-a0 Interface tapde98b2d4-a0 Port br-int Interface br-int type: internal -------------------------------------------------------------------------------------------------------- I would really appreciate any input in this regard. Thank you. Regards, Malik Obaid

2 3

[openstack-ansible][osa] Wallaby has been released with 23.0.0
by Dmitriy Rabotyagov 06 Jul '21

06 Jul '21

Hi everyone! We're happy to announce, that OpenStack-Ansible project has finally released stable/wallaby version with tag 23.0.0. This release includes more then 700 changes from over 50 contributors. And I'd love to thank everyone who made this release happen! The major changes since Victoria are: - Added experimental support of Debian Bullseye (11) and CentOS 8 Stream - Significantly improved workflow and status of Cloudkitty, Trove and Zun roles - Added PKI role, that generates local CA, so self-signed certificates will be trusted inside deployment - nspawn containers support has been removed For the full log of the changes, please reffer to the project Release Notes [1] [1] https://docs.openstack.org/releasenotes/openstack-ansible/wallaby.html -- Kind Regards, Dmitriy Rabotyagov

1 0

[nova] spec review day
by Balazs Gibizer 06 Jul '21

06 Jul '21

Hi, During the today's meeting it came up that we should have a spec review day around M1 (and later one more before M2). As M1 is 27th of May, I propose to do a spec review day on 25th of May, which is a Tuesday. Let me know if the timing does not good for you. The rules are the usual. Let's use this day to focus on open specs, trying to reach agreement on as many thing as possible with close cooperation during the day. Cheers, gibi

1 3

[release][murano] PTL validation
by Herve Beraud 06 Jul '21

06 Jul '21

Hello, Just a heads up about this patch https://review.opendev.org/c/openstack/releases/+/797996 Please can you validate this patch? Thanks in advance. -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0