January 2021 - openstack-discuss - lists.openstack.org

[release] Release countdown for week R-12 Jan 18 - Jan 22
by Herve Beraud 15 Jan '21

15 Jan '21

Greetings, Development Focus ----------------- The Wallaby-2 milestone is next week, on 21 January, 2021! Wallaby-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/wallaby/schedule.html for details. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library that has not been otherwise released since milestone 1. PTL's and release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well. A +1 would be appreciated, but if we do not hear anything at all by the end of the week, we will assume things are OK to proceed. Remember that non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. Next week is also the deadline to freeze the contents of the final release. All new 'Wallaby' deliverables need to have a deliverable file in https://opendev.org/openstack/releases/src/branch/master/deliverables and need to have done a release by milestone-2. Changes proposing those deliverables for inclusion in Wallaby have been posted, please update them with an actual release request before the milestone-2 deadline if you plan on including that deliverable in Wallaby, or -1 if you need one more cycle to be ready. Upcoming Deadlines & Dates -------------------------- Wallaby-2 Milestone: 21 January, 2021 -- 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

Cannot login to Built trovestack image
by Ryan Price-King 14 Jan '21

14 Jan '21

Hi, I am having problems with the image being deployed correctly with nova, but the communication to the guestagent is timing out and i am stuck in build stage. ./trovestack build-image ubuntu bionic true ubuntu Also with that, I dont know which mysql version it is building. I am assuming it is 5.7.29. I cannot diagnose as i cannot login to the guest image instance. I assume the user is ubuntu, but i cannot login with any password that i have tried. Can you tell me what username/password to login to the instance by console in openstack please. Regards, Ryan

2 5

[nova] workarounds and operator experience around bug 1522307/1908133
by Rodrigo Barbieri 14 Jan '21

14 Jan '21

Hi Nova folks and OpenStack operators! I have had some trouble recently where while using the "images_type = rbd" libvirt option my ceph cluster got filled up without I noticing and froze all my nova services and instances. I started digging and investigating why and how I could prevent or workaround this issue, but I didn't find a very reliable clean way. I documented all my steps and investigation in bug 1908133 [0]. It has been marked as a duplicate of 1522307 [1] which has been around for quite some time, so I am wondering if any operators have been using nova + ceph in production with "images_type = rbd" config set and how you have been handling/working around the issue. Thanks in advance! [0] https://bugs.launchpad.net/nova/+bug/1908133 [1] https://bugs.launchpad.net/nova/+bug/1522307 -- Rodrigo Barbieri MSc Computer Scientist OpenStack Manila Core Contributor Federal University of São Carlos

3 6

[ironic] virtual midcycle
by Julia Kreger 14 Jan '21

14 Jan '21

Greetings awesome humans, We in the lands of baremetal and irony (err... Ironic, but you get the idea) have been discussing having a virtual midcycle in the next few weeks to help sort through some items and enable us to prioritize the remainder of the development cycle. I've created an etherpad[0], and a doodle poll[1]. Please keep in mind we have active contributors across the globe at this time, so if anyone feels like we need more time windows, please let me know. I'm hoping to schedule the midcycle by early next week. Additional topics are welcome on the etherpad. We will use that to identify how much time we should try and schedule. Thanks everyone! [0] https://etherpad.opendev.org/p/ironic-wallaby-midcycle [1] https://doodle.com/poll/y9afrz6hhq7s23km?utm_source=poll&utm_medium=link

1 0

Getting CPU Utilization null value
by ahsan ashraf 14 Jan '21

14 Jan '21

Hi Team, I have been using openstack apis and have following issue: - API used: /servers/{server_id}/diagnostics - API version: v2.1 Problem: Couldn't get utilization value of my server it is showing null even i have applied stress on the cpu API Result: { "state": "running", "driver": "libvirt", "hypervisor": "kvm", "hypervisor_os": "linux", "uptime": 10020419, "config_drive": false, "num_cpus": 2, "num_nics": 1, "num_disks": 2, "disk_details": [ { "read_bytes": 983884800, "read_requests": 26229, "write_bytes": 7373907456, "write_requests": 574537, "errors_count": -1 }, { "read_bytes": 3215872, "read_requests": 147, "write_bytes": 0, "write_requests": 0, "errors_count": -1 } ], "cpu_details": [ { "id": 0, "time": 12424380000000, "utilisation": null }, { "id": 1, "time": 12775460000000, "utilisation": null } ], "nic_details": [ { "mac_address": "fa:16:3e:0e:c7:f2", "rx_octets": 943004980, "rx_errors": 0, "rx_drop": 0, "rx_packets": 4464445, "rx_rate": null, "tx_octets": 785254710, "tx_errors": 0, "tx_drop": 0, "tx_packets": 4696786, "tx_rate": null } ], "memory_details": { "maximum": 2, "used": 2 } } Regards, Muhammad Ahsan

3 2

[ops][nova][designate] Does anyone rely on fully-qualified instance names?
by Stephen Finucane 14 Jan '21

14 Jan '21

When attaching a port to an instance, nova will check for DNS support in neutron and set a 'dns_name' attribute if found. To populate this attribute, nova uses a sanitised version of the instance name, stored in the instance.hostname attribute. This sanitisation simply strips out any unicode characters and replaces underscores and spaces with dashes, before truncating to 63 characters. It does not currently replace periods and this is the cause of bug 1581977 [1], where an instance name such as 'ubuntu20.04' will fail to schedule since neutron identifies '04' as an invalid TLD. The question now is what to do to resolve this. There are two obvious paths available to us. The first is to simply catch these invalid hostnames and replace them with an arbitrary hostname of format 'Server-{serverUUID}'. This is what we currently do for purely unicode instance names and is what I've proposed at [2]. The other option is to strip all periods, or rather replace them with hyphens, when sanitizing the instance name. This is more predictable but breaks the ability to use the instance name as a FQDN. Such usage is something I'm told we've never supported, but I'm concerned that there are users out there who are relying on this all the same and I'd like to get a feel for whether this is the case first. So, the question: does anyone currently rely on this inadvertent "feature"? Cheers, Stephen [1] https://launchpad.net/bugs/1581977 [2] https://review.opendev.org/c/openstack/nova/+/764482

9 23

Enabling KVM on Openstack Inbox
by open infra 14 Jan '21

14 Jan '21

Hi (This mail has been sent to the community mailing list already, and I was suggested to reach out to this mailing list.) I have enabled KVM after deploying openstack single node setup. Following entries has been added to /etc/nova/nova.conf and then restart libvirtd.service and openstack-nova-compute.servic. compute_driver = libvirt.LibvirtDriver [libvirt] virt_type=kvm #virt_type=qemu # lsmod | grep kvm kvm_intel 188740 0 kvm 637289 1 kvm_intel irqbypass 13503 1 kvm I have disabled qemu in nova config and restarted the entire box (including the base OS and the VM where I deployed Openstack. But still no luck. $ openstack hypervisor list +----+------------------------+-----------------+----------------+-------+ | ID | Hypervisor Hostname | Hypervisor Type | Host IP | State | +----+------------------------+-----------------+----------------+-------+ | 1 | openstack.centos.local | QEMU | 192.168.122.63 | up | +----+------------------------+-----------------+----------------+-------+ I still can see Hypervisor Type as QEMU, when I issue openstack hypervisor list command.

2 2

[release] Status: RED - pip resolver issue with publish-openstack-releasenotes-python3
by Herve Beraud 14 Jan '21

14 Jan '21

Dear release managers, We are currently experiencing an issue with the new pip resolver in our release job (publish-openstack-releasenotes-python3), so, please hold all the release's validations for now. Indeed, today we faced an issue [1][2] during the releasing tripleo-image-elements [3]. The problem here is that this repos haven't doc/requirements.txt file and by default in this case zuul will use the test-requirements.txt file to pull requirements [4] This requirements file contains extra requirements like flake8 that collided with those allowed in our job environment and so the new pip resolver fails to install these requirements and the job exits in error. All the repo who fit the same conditions (no doc/requirements.txt available) will fail too. We've almost identified all of these repos [5], I'll get the full list to you in a while. In parallel, fungi (Jeremy Stanley) will bring this topic on the zuul side too, to see if we can add something there to override this rule (test-requirements.txt as the default case). Thanks for reading [1] https://zuul.opendev.org/t/openstack/build/d82e8c8db7754394907459895f3f58fa [2} http://paste.openstack.org/show/801385/ [3] https://review.opendev.org/c/openstack/releases/+/768237 [4] https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-sphinx/ta… [5] http://paste.openstack.org/show/801396/ -- 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-----

5 9

[magnum][api] Error system library fopen too many open files with magnum-auto-healer
by Ionut Biru 14 Jan '21

14 Jan '21

Hi guys, I have an issue with magnum api returning an error after a while: Server-side error: "[('system library', 'fopen', 'Too many open files'), ('BIO routines', 'BIO_new_file', 'system lib'), ('x509 certificate routines', 'X509_load_cert_crl_file', 'system lib')]" Log file: https://paste.xinu.at/6djE/ This started to appear after I enabled the template auto_healing_controller = magnum-auto-healer, magnum_auto_healer_tag = v1.19.0. Currently, I only have 4 clusters. After that the API is in error state and doesn't work unless I restart it. -- Ionut Biru - https://fleio.com

4 23

[neutron] Drivers meeting agenda for 15.01.2021
by Slawek Kaplonski 14 Jan '21

14 Jan '21

Hi, For tomorrow's drivers meeting we have one new RFE to discuss: * https://bugs.launchpad.net/neutron/+bug/1911126 Spec for that is proposed already: https://review.opendev.org/c/openstack/neutron-specs/+/770540 See You on the meeting tomorrow :) -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0