April 2021 - openstack-discuss - lists.openstack.org

dynamic vendor data and cloud-init
by Manish Mahalwal 20 Apr '21

20 Apr '21

Hi All, I am working with OpenStack Pike and cloud-init 21.1. I am able to successfully pass dynamic vendor data to the config drive of an instance. However, cloud-init 21.1 just reads all the 'x' bytes of the vendor_data2.json but it doesn't execute the contents of the json. Although, static vendor data works perfectly fine and the YAML file in the JSON is executed as expected by cloud-init 21.1 * Now, the person who wrote the code for handling dynamic vendordata in cloud-init (https://github.com/canonical/cloud-init/pull/777) says that the JSON cloud-init expects is of the form: > {"cloud-init": "#cloud-config\npackage_upgrade: True\npackages:\n - > black\nfqdn: cloud-overridden-by-vendordata2.example.org."} > * I believe that the JSON should have another outer key (as mentioned here https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/v…) which is the name of the microservice specified in nova.conf file and that the inner key should be cloud-init. In nova.conf: vendordata_dynamic_targets=name1@ http://example.com,name2@http://example2.com <http://example.com,name2@http//example2.com> { > "name1": { > "cloud-init": "#cloud-config\n..." > }, > "name2": { > "cloud-init": "#cloud-config\n..." > } > } >>Who is right and who is wrong? To read more on this please go through the following: https://bugs.launchpad.net/cloud-init/+bug/1841104

2 3

[neutron] bug deputy report for week of 2021-04-12
by Bence Romsics 20 Apr '21

20 Apr '21

Hi Neutron Team, We had the following new bugs last week: Critical * https://bugs.launchpad.net/neutron/+bug/1923633 Neutron-tempest-plugin scenario jobs failing due to metadata issues gate failure, Slawek and Rodolfo added extra logs and are analyzing them High * https://bugs.launchpad.net/neutron/+bug/1923453 and * https://bugs.launchpad.net/neutron/+bug/1923870 Some Neutron commands do not initilize privsep fix merged: https://review.opendev.org/c/openstack/neutron/+/786272 fix in the gate: https://review.opendev.org/c/openstack/neutron/+/786282 * https://bugs.launchpad.net/neutron/+bug/1924789 Since the migration to new engine facade, some operations that shouldn't be executing within a txn, are logging a "session semantic violated" warning unassigned Medium * https://bugs.launchpad.net/neutron/+bug/1923700 Report correct error when external DNS(designate) recordset quota limit exceeds fix proposed (waiting for neutron-lib release): https://review.opendev.org/c/openstack/neutron/+/786175 Low * https://bugs.launchpad.net/neutron/+bug/1923423 l3_router.service_providers DriverController's _attrs_to_driver is not py3 compatible fix merged: https://review.opendev.org/c/openstack/neutron/+/785830 Stable * https://bugs.launchpad.net/neutron/+bug/1924315 [stable/rocky] neutron-tempest-plugin-scenario-openvswitch-iptables_hybrid-rocky job fails gate failure, fix proposed: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/786657 * https://bugs.launchpad.net/neutron/+bug/1923412 [stable/stein] Tempest fails with unrecognized arguments: --exclude-regex gate failure, unassigned * https://bugs.launchpad.net/neutron/+bug/1923644 OVN agent delete support should be backported to pre-wallaby releases backport with many dependencies, recommended for stable reviewers Neutron-Dynamic-Routing * https://bugs.launchpad.net/neutron/+bug/1924237 TypeError when formating IP address for BGP plugin fix merged: https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/786371 micro-RFE * https://bugs.launchpad.net/neutron/+bug/1923592 [Routed networks] Router routes to other segment CIDRs should have a gateway IP Edit still following up with the triage: * https://bugs.launchpad.net/neutron/+bug/1924776 [ovn] use of address scopes does not automatically disable router snat * https://bugs.launchpad.net/neutron/+bug/1924765 [ovn] fip assignment to instance via router with snat disabled is broken * https://bugs.launchpad.net/neutron/+bug/1922089 [ovn] enable_snat cannot be disabled once enabled Cheers, Bence

1 0

[Multi-arch SIG] success to run full tempest tests on Arm64 env. What's next?
by Rico Lin 19 Apr '21

19 Apr '21

Dear all, I'm glad to tell everyone that we finally succeeded to build Devstack and run full tempest tests on it [1]. As the test build result shows [2], the job is stable enough to run. For earlier 13+ job results. (will do more recheck later) One Timeout, and two failure cases (Which are targeted by increase `BUILD_TIMEOUT` to 900 secs). The job `devstack-platform-arm64` runs around 2.22 hrs to 3.04 hrs, which is near two times slower than on x86 environment. It's not a solid number as the performance might change a lot with different cloud environments and different hardware. But I think this is a great chance for us to make more improvements. At least now we have a test job ready (Not merged yet) for you to do experiments with. And we should also add suggestions to Multi-arch SIG documentation so once we make improvements, other architecture can share the efforts too. *So please join us if you are also interested in help tuning the performance :)* *Also, we need to discuss what kind of way we should run this job, should we separate it into small jobs? Should we run it as a periodic job? voting?* *On the other hand, I would hope to collect more ideas on how we should move forward.* *Please provide your idea for this on our Xena PTG etherpad* *https://etherpad.opendev.org/p/xena-ptg-multi-arch-sig <https://etherpad.opendev.org/p/xena-ptg-multi-arch-sig>* Our PTG is scheduled around 4/20 Tuesday from 07:00-08:00 and 15:00-16:00 (UTC time) If you plan to join our PTG, feel free to update our PTG etherpad to suggest other topics. And our Meeting time is scheduled biweekly on Tuesday (host on demand) Please join our IRC #openstack-multi-arch [1] https://review.opendev.org/c/openstack/devstack/+/708317 [2] https://zuul.openstack.org/builds?job_name=devstack-platform-arm64+ *Rico Lin* OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack

3 2

[Multi-arch SIG][PTG] Multi-arch SIG PTG 07:00 and 15:00 UTC today!
by Rico Lin 19 Apr '21

19 Apr '21

Dear all Multi-arch SIG will have our PTG session from 07:00-08:00 and 15:00-16:00 (UTC time) Feel free to join us PTG: http://ptg.openstack.org/ptg.html Etherpad: https://etherpad.opendev.org/p/xena-ptg-multi-arch-sig *Rico Lin* OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack

1 0

[ptg][swift][ops] Operator feedback session 21 Apr 13:00-14:00 UTC
by Timothy Burke 19 Apr '21

19 Apr '21

Later this week, the Swift community will have an operator feedback session during one of our PTG slots [0]. If you're running a swift cluster, large or small, we'd love to see you there! As we've done in the past [1], we'll have an etherpad going [2] -- feel free to start filling it in and adding discussion items today! Even if you won't make the meeting, we'd appreciate your feedback. Looking forward to hearing from you! Tim [0] 21 Apr at 1300 UTC in https://www.openstack.org/ptg/rooms/ocata [1] https://wiki.openstack.org/wiki/Swift/Etherpads#List_of_Ops_Feedback_Etherp… [2] https://etherpad.opendev.org/p/swift-xena-ops-feedback

1 0

[tacker] PTG meeting
by Yasufumi Ogawa 19 Apr '21

19 Apr '21

Hi team, As a reminder, we will have PTG meeting from 6am UTC (3pm JST/KST) today [1]. You can find the link of room from here [2]. I'd like to skip irc meeting this week without if we have something to discuss after the meeting. [1] https://etherpad.opendev.org/p/tacker-xena-ptg [2] http://ptg.openstack.org/ptg.html Thanks, Yasufumi

1 0

[ops][nova][victoria] Migrate cross CPU?
by DHilsbos＠performair.com 19 Apr '21

19 Apr '21

All; I seem to have generated another issue for myself... I built our Victoria cloud initially on Intel Atom servers. We recently received the first of our AMD Epyc (7002 series) servers, which are intended to take over the Nova Compute responsibilities. I've had success in the past doing live migrates, but live migrating from one of the Atom servers to the new server fails, with an error indicating CPU compatibility problems. Ok, I can understand that. My problem is that I don't seem to understand the openstack server migrate command (non-live). It doesn't seem to do anything, whether the instance is Running or Shut Down. I can't find errors in the logs from the API / conductor / scheduler host. I also can't find an option to pass to the openstack server start command which requests a specific host. Can I get these existing instances moved from the Atom servers to the Epyc server(s), or do I need to recreate them to do this? Thank you, Dominic L. Hilsbos, MBA Director - Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com

2 8

cinder + Unity
by Albert Shih 19 Apr '21

19 Apr '21

Hi everyone, I'm a total newbie with openstack, currently I'm trying to put a POC with a Unity storage element, 4 computes, and few servers (cinder, keystone, glance, neutron, nova, placement and horizon). I think my keystone, glance, placement are working (at least they past the test). Currently I'm trying to make cinder working with my Unity (480), the objectif are to use iSCSI. Here the configuration of my /etc/cinder/cinder.conf [DEFAULT] rootwrap_config = /etc/cinder/rootwrap.conf api_paste_confg = /etc/cinder/api-paste.ini iscsi_helper = tgtadm volume_name_template = volume-%s volume_group = cinder-volumes verbose = True auth_strategy = keystone state_path = /var/lib/cinder lock_path = /var/lock/cinder volumes_dir = /var/lib/cinder/volumes enabled_backends = unity transport_url = rabbit://openstack:XXXXXX@amqp-cloud.private.FQDN/openstack auth_strategy = keystone debug = True verbose = True [database] connection = mysql+pymysql://cinder:XXXXXXX@mariadb-cloud.private.FQDN/cinder [keystone_authtoken] www_authenticate_uri = http://keystone.private.FQDN:5000/v3 auth_url = http://keystone.private.FQDN:5000 identity_uri = http://keystone.private.FQDN:5000 memcached_servers = memcached-cloud.private.FQDN:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = cinder password = XXXXXX [oslo_concurrency] lock_path = /var/lib/cinder/tmp [unity] # Storage protocol storage_protocol = iSCSI # Unisphere IP san_ip = onering-remote.FQDN # Unisphere username and password san_login = openstack san_password = "XXXXX" # Volume driver name volume_driver = cinder.volume.drivers.dell_emc.unity.Driver # backend's name volume_backend_name = Unitiy_ISCSI unity_io_ports = *_enp1s0 unity_storage_pool_names = onering When I'm trying to create a storage through a openstack volume create volumetest --type thick_volume_type --size 100 I don't even see (with tcpdump) the cinder server trying to connect to onering-remote.FQDN Inside my /var/log/cinder/cinder-scheduler.log I have 2021-04-19 18:06:56.805 21315 INFO cinder.scheduler.base_filter [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee b1d58ebae6b84f7586ad63b94203d7ae - - -] Filtering removed all hosts for the request with volume ID '06e5f07d-766f-4d07-b3bf-6153a2cf6abd'. Filter results: AvailabilityZoneFilter: (start: 0, end: 0), CapacityFilter: (start: 0, end: 0), CapabilitiesFilter: (start: 0, end: 0) 2021-04-19 18:06:56.806 21315 WARNING cinder.scheduler.filter_scheduler [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee b1d58ebae6b84f7586ad63b94203d7ae - - -] No weighed backend found for volume with properties: {'id': '5f16fc1f-76ff-41ee-8927-56925cf7b00f', 'name': 'thick_volume_type', 'description': None, 'is_public': True, 'projects': [], 'extra_specs': {'provisioning:type': 'thick', 'thick_provisioning_support': 'True'}, 'qos_specs_id': None, 'created_at': '2021-04-19T15:07:09.000000', 'updated_at': None, 'deleted_at': None, 'deleted': False} 2021-04-19 18:06:56.806 21315 INFO cinder.message.api [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee b1d58ebae6b84f7586ad63b94203d7ae - - -] Creating message record for request_id = req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 2021-04-19 18:06:56.811 21315 ERROR cinder.scheduler.flows.create_volume [req-4808cc9d-b9c3-44cb-8cae-7503db0b0256 f5e5c9ea20064b17851f07c276d71aee b1d58ebae6b84f7586ad63b94203d7ae - - -] Failed to run task cinder.scheduler.flows.create_volume.ScheduleCreateVolumeTask;volume:create: No valid backend was found. No weighed backends available: cinder.exception.NoValidBackend: No valid backend was found. No weighed backends available It seem (for me) cinder don't try to use unity.... Any help ? Regards -- Albert SHIH Observatoire de Paris Heure local/Local time: Mon Apr 19 08:01:37 PM CEST 2021

1 0

[victoria][neutron][ovn] Iperf3 Retransmits
by Ammad Syed 19 Apr '21

19 Apr '21

Hi, I am using openstack victoria and neutron with ovn latest releases. I was trying to assess network performance between the vms first. I have created two ubuntu 20.04 VMs installed iperf3 in them and executed a bidirectional test between VMs. The instance are on same network and network type is geneve. Both VMs are on same host. I have tested by keeping VM to different compute hosts, but results are same. Here are the results. root@iperf3-1:~# iperf3 -c 192.168.100.50 --bidir Connecting to host 192.168.100.50, port 5201 [ 5] local 192.168.100.120 port 53156 connected to 192.168.100.50 port 5201 [ 7] local 192.168.100.120 port 53158 connected to 192.168.100.50 port 5201 [ ID][Role] Interval Transfer Bitrate Retr Cwnd [ 5][TX-C] 0.00-1.00 sec 311 MBytes 2.61 Gbits/sec 407 1.41 MBytes [ 7][RX-C] 0.00-1.00 sec 627 MBytes 5.26 Gbits/sec [ 5][TX-C] 1.00-2.00 sec 1.07 GBytes 9.18 Gbits/sec 2638 1.71 MBytes [ 7][RX-C] 1.00-2.00 sec 778 MBytes 6.53 Gbits/sec [ 5][TX-C] 2.00-3.00 sec 1.14 GBytes 9.75 Gbits/sec 603 1.98 MBytes [ 7][RX-C] 2.00-3.00 sec 922 MBytes 7.73 Gbits/sec [ 5][TX-C] 3.00-4.00 sec 1.00 GBytes 8.62 Gbits/sec 594 2.16 MBytes [ 7][RX-C] 3.00-4.00 sec 935 MBytes 7.84 Gbits/sec [ 5][TX-C] 4.00-5.00 sec 988 MBytes 8.29 Gbits/sec 2431 1.42 MBytes [ 7][RX-C] 4.00-5.00 sec 932 MBytes 7.82 Gbits/sec [ 5][TX-C] 5.00-6.00 sec 879 MBytes 7.37 Gbits/sec 599 991 KBytes [ 7][RX-C] 5.00-6.00 sec 996 MBytes 8.36 Gbits/sec [ 5][TX-C] 6.00-7.00 sec 721 MBytes 6.05 Gbits/sec 389 1.10 MBytes [ 7][RX-C] 6.00-7.00 sec 963 MBytes 8.08 Gbits/sec [ 5][TX-C] 7.00-8.00 sec 901 MBytes 7.56 Gbits/sec 33 1.54 MBytes [ 7][RX-C] 7.00-8.00 sec 1.02 GBytes 8.79 Gbits/sec [ 5][TX-C] 8.00-9.00 sec 889 MBytes 7.44 Gbits/sec 376 1.33 MBytes [ 7][RX-C] 8.00-9.00 sec 1.14 GBytes 9.78 Gbits/sec [ 5][TX-C] 9.00-10.00 sec 671 MBytes 5.64 Gbits/sec 1017 984 KBytes [ 7][RX-C] 9.00-10.00 sec 975 MBytes 8.19 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID][Role] Interval Transfer Bitrate Retr [ 5][TX-C] 0.00-10.00 sec 8.44 GBytes 7.25 Gbits/sec 9087 sender [ 5][TX-C] 0.00-10.00 sec 8.44 GBytes 7.25 Gbits/sec receiver [ 7][RX-C] 0.00-10.00 sec 9.13 GBytes 7.84 Gbits/sec 7914 sender [ 7][RX-C] 0.00-10.00 sec 9.12 GBytes 7.84 Gbits/sec receiver Here is the xmldump of instance interface. <interface type='bridge'> <mac address='fa:16:3e:02:bc:33'/> <source bridge='br-int'/> <virtualport type='openvswitch'> <parameters interfaceid='73e9f047-70de-4d9f-a656-e311dd54975f'/> </virtualport> <target dev='tap73e9f047-70'/> <model type='virtio'/> <driver name='vhost' queues='8'/> <mtu size='1442'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> My overlay network IP interface mtu is 1500. Please advise if there is any network performance tuning required ? -- Regards, Syed Ammad Ali

1 0

[nova] Nominate sean-k-mooney for nova-specs-core
by Stephen Finucane 19 Apr '21

19 Apr '21

Hey, Sean has been working on nova for what seems like yonks now. Each cycle, they spend a significant amount of time reviewing proposed specs and contributing to discussions at the PTG. This is important work and their contributions provide everyone with a deep pool of knowledge on all things networking and hardware upon which to draw. I think the nova project would benefit from their addition to the specs core reviewer team and I therefore propose we add Sean to nova- specs-core. Assuming there are no objections, I'll work with gibi to add Sean to nova-specs- core next week. Cheers, Stephen

9 9