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

[neutron] bug deputy report January 11th to 17th
by Miguel Lavalle 18 Jan '21

18 Jan '21

Hi, Here is this week's bugs deputy report: Critical ====== https://bugs.launchpad.net/neutron/+bug/1911128 Neutron with ovn driver failed to start on Fedora. Needs owner Medium ====== https://bugs.launchpad.net/neutron/+bug/1911153 [FT] DB migration "test_walk_versions" failing frequently. Owner ralonsoh https://bugs.launchpad.net/neutron/+bug/1911214 Scenario test test_multiple_ports_secgroup_inheritance fails in ovn scenario job. Needs owner https://bugs.launchpad.net/neutron/+bug/1910946 ovs is dead but ovs agent is up. Owner Norman Shen. Patch https://review.opendev.org/c/openstack/neutron/+/770058 https://bugs.launchpad.net/neutron/+bug/1911462 Optimize "PortForwarding" OVO loading. Owner Rodolofo Alonso. Patch: https://review.opendev.org/c/openstack/neutron/+/770654 https://bugs.launchpad.net/neutron/+bug/1911925 [FT] "test_read_queue_change_state" failing to initialize the keepalived-state-change monitor. Owner Rodolfo Alonso. Patch https://review.opendev.org/c/openstack/neutron/+/770950 https://bugs.launchpad.net/neutron/+bug/1911927 [FT] "test_add_and_remove_multiple_ips" failing while decoding the JSON file returned by "ip_monitor". Owner Rodolfo Alonso. Patch https://review.opendev.org/c/openstack/neutron/+/770983 https://bugs.launchpad.net/neutron/+bug/1911132 OVN mech driver - can't find Logical_Router errors. Needs owner RFE === https://bugs.launchpad.net/neutron/+bug/1911126 [RFE][L3] add ability to control router SNAT more granularly. Under discussion https://bugs.launchpad.net/neutron/+bug/1911864 [DHCP] AgentBinding for network will be created no matter the state

1 0

[$nova] [$horizon] openstack host show statistics
by Nagaraj Akkina 18 Jan '21

18 Jan '21

Hello, Openstack host show compute-host, shows more memory allocated to instances than actual physical memory, although the memory allocation ratio is 1.0 in nova.conf, the same is also shown in horizon dashboard hypervisor statistics. We can see this in many compute nodes in the cluster. Also these statistics does not match with free -g or cat /proc/meminfo. For Example : Memory_mb | compute-node23 | (total) | 257915 | | compute-node23 | (used_now) | 271360 | | compute-node23 | (used_max) | 267264 | How to avoid misleading statistics, also which statistics are actually correct? versions : openstack : Stein nova : 2:19.3.0-0ubuntu1~cloud0 Regards, Akkina

2 1

[nova] MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION bumps in Wallaby
by Lee Yarwood 17 Jan '21

17 Jan '21

Hello all, We are once again looking to increase the minimum and next minimum versions of libvirt and QEMU in the libvirt virt driver. These were previously increased late in the Victoria cycle: MIN_LIBVIRT_VERSION = (5, 0, 0) MIN_QEMU_VERSION = (4, 0, 0) NEXT_MIN_LIBVIRT_VERSION = (6, 0, 0) NEXT_MIN_QEMU_VERSION = (4, 2, 0) libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION https://review.opendev.org/c/openstack/nova/+/746981 I am now proposing the following updates to these versions in Wallaby: MIN_LIBVIRT_VERSION = (6, 0, 0) MIN_QEMU_VERSION = (4, 2, 0) NEXT_MIN_LIBVIRT_VERSION = (7, 0, 0) NEXT_MIN_QEMU_VERSION = (5, 2, 0) libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION https://review.opendev.org/c/openstack/nova/+/754700 libvirt v6.0.0 and QEMU 4.2.0 being supported by the three LTS releases supported by the Wallaby release of OpenStack [1][2]. libvirt v7.0.0 and QEMU 5.2.0 being slightly aspirational for the next minimum versions at this point but given current releases for both projects they seem appropriate for the time being. Please let me know ideally in the review if there are any issues with this increase. Regards, [1] https://governance.openstack.org/tc/reference/runtimes/wallaby.html [2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

3 2

[all] https://github.com/OpenStackweb/openstack-org
by Kanevsky, Arkady 16 Jan '21

16 Jan '21

Looking at out current website code I wonder if we should 1. Reword to be OpenInfra not just OpenStack or even move to new repo for OpenInfraWeb? 2. Keep it to be dedicated to OpenStack and create a parent Web for OpenInfra. That parent page will point to all projects under OpenInftastructure umbrella? In related question, should we also create openinfra-discuss mail list? Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell EMC office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

2 1

[oslo][release] etcd3gw release model - series vs independent
by Herve Beraud 15 Jan '21

15 Jan '21

Greetings Osloers, etcd3gw was moved under the Oslo team's scope a few months ago [1][2]. This project hasn't yet been released by us and we should choose to release it either during Wallaby or to make it an independent [3] project. I didn't see significant changes merged since the project transition, so I think we could directly adopt the independent model for etcd3gw. However I want first to discuss this with all the core maintainers before and then I'll act accordingly. Notice that Wallaby Milestone 2 is next week, so it could be a good time for us to decide to continue with a coordinated series or to adopt the independent model directly. Let me know what you think about that. Thanks, [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016457.h… [2] https://governance.openstack.org/tc/reference/projects/oslo.html#etcd3gw [3] https://releases.openstack.org/reference/release_models.html#independent -- 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-----

3 2

[tripleo] next irc meeting Tuesday Jan 19 @ 1400 UTC in #tripleo
by Marios Andreou 15 Jan '21

15 Jan '21

Reminder that the next TripleO irc meeting is: ** Tuesday 19th January at 1400 UTC in #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to hilight at https://etherpad.opendev.org/p/tripleo-meeting-items This can include recently completed things, ongoing review requests, blocking issues, or anything else tripleo you'd like to share. Our last meeting was on Jan 05 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-01-05-14.… Hope you can make it on Tuesday, thanks, marios

1 0

[tripleo] TripleO CI Summary: Unified Sprint 37 and 38
by Bhagyashri Shewale 15 Jan '21

15 Jan '21

Greetings, The TripleO CI team has just completed **Unified Sprint 36 and 37** (Dec 04 to Jan 13). The following is a summary of completed work during this sprint cycle: - Component standalone-upgrade added to tripleo component: 1. https://review.rdoproject.org/zuul/builds?job_name=periodic-tripleo-ci-cent… - Docs https://review.opendev.org/c/openstack/tripleo-docs/+/767375 https://docs.openstack.org/tripleo-docs/latest/ci/stages-overview.html - Reduce content-providers in upgrade job layouts: https://review.opendev.org/q/topic:reduce-content-providers - Improve tripleo-upgrade repo job coverage: https://review.opendev.org/q/topic:tripleo-upgrade-provider-jobs-coverage - (content providers) remove registry_ip_address: https://bugs.launchpad.net/tripleo/+bug/1904565 https://review.opendev.org/c/openstack/tripleo-ci/+/764359 - Build report for container builds and content provider jobs: https://review.opendev.org/q/topic:%2522build-report%2522+(status:merged) - Added a build report for the container builds and content provider jobs: https://review.opendev.org/q/topic:%2522build-report%2522+(status:merged) - Promoter configuration fix: https://review.rdoproject.org/r/#/c/28014/ - rpm diff comparison script added to dependency jobs logs: https://github.com/rdo-infra/ci-config/commit/bf829ed2b7bda23d85d5128907147… - centos 8 stream: - rpm comparison skip list was updated with release delivery's help: https://github.com/rdo-infra/ci-config/commit/ca144362ee520dbd6e89f1e23dcb8… - branch jobs were added: victoria, ussuri, train - dependency lines now run with a controller job for rpm comparisons - working to get the stream jobs running on stream nodes https://bugs.launchpad.net/tripleo/+bug/1910791 https://review.rdoproject.org/zuul/builds?pipeline=openstack-dependencies-c… - Provisioning via metalsmith in 16.2 and created a new job for it in 16.2 component pipeline https://review.opendev.org/c/openstack/tripleo-ci/+/769469 - Stable version of scenario manager. Apart from that, https://review.opendev.org/c/openstack/tempest/+/766472 https://review.opendev.org/c/openstack/tempest/+/766015 - Writing unit test cases for the cockpit (telegraf container and moving scipts from py2 to py3 directory). https://review.rdoproject.org/r/#/c/30492/ - Done https://review.rdoproject.org/r/#/c/31442/ - Work in progress - Working on Promoter Stuff (Get familiar with the new promoter code). https://review.rdoproject.org/r/#/c/31318/ - Done - Released 1.2.1 version of Openstack Ansible collections: https://opendev.org/openstack/ansible-collections-openstack - Released 1.4.0 and 1.4.1 versions of Podman Ansible collections: https://github.com/containers/ansible-podman-collections - Created OSP 13 and OSP 16.2 jobs in CI that run Openstack Ansible collections tests to ensure collections work on these OSP versions. - Enable dracut list installed modules https://review.opendev.org/c/openstack/diskimage-builder/+/766232 - Collect dnf module related infos - https://review.opendev.org/c/openstack/ansible-role-collect-logs/+/768595 - still working on finishing copy-quay role: https://review.rdoproject.org/r/#/c/31395/ - Bugs related to os_tempest that is affecting upgrade jobs: https://bugs.launchpad.net/tripleo/+bug/1911020 - add test command on tempest-skip list and documentation https://review.opendev.org/c/openstack/openstack-tempest-skiplist/+/754994 Upstream promotions [1] NEXT SPRINT =========== - Bring the new promoter code online - Dependency pipeline - tripleo repos (As a design discussion for this sprint) - openstack Health for TripleO - Ruck and Rover - Akahat|rover - sshnaidm|ruck Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. [1]: http://dashboard-ci.tripleo.org/d/HkOLImOMk/upstream-and-rdo-promotions?org… Sprint 37 and 38 ruck/rover notes: https://hackmd.io/R0kCgz_7SHSix_cNgoC9pg Thanks and Regards, Bhagyashri Shewale

1 0

Trying to resolve 2 deprecation warnings
by shubjero 15 Jan '21

15 Jan '21

Hi all, I am trying to resolve two deprecation warnings which I've not been able to locate exactly what package or file is causing them. We are running OpenStack Train on Ubuntu 18.04 The log entries are found in /etc/apache2/cinder_error.log : 2021-01-06 15:54:05.332604 /usr/lib/python3/dist-packages/oslo_context/context.py:108: DeprecationWarning: Policy enforcement is depending on the value of is_admin. This key is deprecated. Please update your policy file to use the standard policy values. 2021-01-06 15:54:20.147590 /usr/lib/python3/dist-packages/webob/acceptparse.py:1051: DeprecationWarning: The behavior of AcceptValidHeader.best_match is currently being maintained for backward compatibility, but it will be deprecated in the future, as it does not conform to the RFC. Any help on what needs to be changed/removed/updated/upgraded would be appreciated. Thanks! Jared Ontario Institute for Cancer Research

2 1

Openstack stein TLS configuration with combined method of interfaces
by roshan anvekar 15 Jan '21

15 Jan '21

Hello, Openstack version: stein Deployment method: kolla-ansible I am trying to set up TLS for Openstack endpoint. I have chosen combined method of vip address where I supply only kolla_internal_vip_address and network_interface details. I do not enable external kolla vip address. After this I set up kolla_enable_tls_external: 'yes' and pass the kolla_external_fqdn_cert certificates. The installation is successful but I see that http link opens but https:// endpoint does not open at all. Is as good as not available. Any reason for this? Regards, Roshan

2 1

[RDO][CentOS] RDO plans to move to CentOS Stream
by Alfredo Moralejo Alonso 15 Jan '21

15 Jan '21

Hi, As you know, CentOS announced recently that they will be focusing on CentOS Stream [1] and that CentOS Linux 8 will be EOL at the end of 2021 [2]. In order to align with this change, the RDO project is adapting the roadmap for the current and upcoming releases: - RDO Wallaby (ETA is end of April 2021 [3]) will be built, tested and released only for CentOS 8 Stream. - RDO CloudSIG repos for Victoria and Ussuri will be updated and tested for both CentOS Stream and CentOS Linux 8 until end of 2021 and then continue on CentOS Stream. - In the upcoming weeks, we will create new RDO CloudSIG repos for Victoria and Ussuri for CentOS Stream 8. - RDO Trunk repositories (aka DLRN repos) will be built and tested using CentOS 8 Stream for all releases currently using CentOS Linux 8 (starting with Train). If you are interested in the details about these plans and how we plan to implement it, we've created a blog post [4]. Don't hesitate to ask us in the ML or in the #rdo channel on freenode if you have questions or suggestions about this. We are also organizing a video AMA about RDO and CentOS Stream on Thursday Jan 21 1600 UTC in the RDO Meet room https://meet.google.com/uzo-tfkt-top On behalf of RDO, Alfredo [1] https://centos.org/distro-faq/ [2] https://blog.centos.org/2020/12/future-is-centos-stream/ [3] https://releases.openstack.org/ [4] https://blogs.rdoproject.org/2021/01/rdo-plans-to-move-to-centos-stream/

3 4

[rpm-packaging]release] Update our deliverables accordingly to the SIG governance model
by Herve Beraud 15 Jan '21

15 Jan '21

Dear rpm team fellows, I take off my release PTL cap to discuss with you as a teammate about some inconsistencies in our deliverables. Indeed, last week we noticed some inconsistencies between the rpm-packaging team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo. Since rpm-packaging became a SIG our deliverables [1][2][3] aren't managed by the release team anymore, so we should act accordingly to reflect that. Two choices are available to us: 1) mark these project as "release-model: abandoned" in the governance repo [4]; 2) remove the corresponding files from openstack/releases [1][2][3]. Each choice has pros and cons: - by choosing 1) it will reflect that our projects are abandoned, which is wrong, our projects are still active but not released by the coordinated releases anymore; - by choosing 2) it will reflect that we have always been a SIG, which is wrong too. I personally prefer 2) to allow us to avoid misleading someone by having an abandoned status, indeed, reflecting a SIG is less misleading than reflecting an abandoned project. Here is the list of our deliverables that should be addressed: - renderspec [1] - pymod2pkg [2] - rpm-packaging [3] Any opinion? For further details please take a look to our previous meeting discussion [5]. Thanks for reading, [1] https://opendev.org/openstack/releases/src/branch/master/deliverables/_inde… [2] https://opendev.org/openstack/releases/src/branch/master/deliverables/_inde… [3] https://opendev.org/openstack/releases/src/branch/master/deliverables/walla… [4] https://opendev.org/openstack/governance/src/branch/master/reference/sigs-r… [5] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-re… -- 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

[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

Only a few hours left: 2021 Board elections and Bylaws amendments
by Allison Price 14 Jan '21

14 Jan '21

Hi everyone, The 2021 Individual Director elections are currently open. All members who are eligible to vote should have received an email ballot earlier this week. You can review the candidates here: https://www.openstack.org/election/2021-individual-director-election/Candid… <https://www.openstack.org/election/2021-individual-director-election/Candid…>. If you are not currently a member of the Open Infrastructure Foundation, you can join here to vote in next year’s elections: https://openinfra.dev/join <https://openinfra.dev/join> This year, the election includes a set of amendments to the Foundation’s Bylaws. The amendments were approved unanimously by the Foundation Board in 2020. As a member class, the Individual Members must also approve these amendments. You can find more information in this mailing list post by Jonathan Bryce: http://lists.openstack.org/pipermail/foundation/2021-January/002939.html <http://lists.openstack.org/pipermail/foundation/2021-January/002939.html> The deadline to vote is this Friday, January 15 at 1800 UTC / 12pm CST. Please let me know if you have any questions. Allison Allison Price Open Infrastructure Foundation allison(a)openstack.org <mailto:allison@openstack.org>

1 0

[Watcher]stepping down as PTL
by licanwei 14 Jan '21

14 Jan '21

Hi all, For personal reason, I have no time to continue the work for Watcher PTL. My colleage, Chen Ke(irc:chenke) will temporarily replace me as PTL, thank you for your support. thanks, | | licanwei_cn | | 邮箱：licanwei_cn(a)163.com | 签名由网易邮箱大师定制

2 1

[nova] Nova evacuate issue
by Jean-Philippe Méthot 13 Jan '21

13 Jan '21

Hi, We’re running Openstack Rocky on a high-availability setup with neutron openvswitch. The setup has roughly 50 compute nodes and 2 controller nodes. We’ve run into an issue when we’re trying to evacuate a dead compute node where the first instance evacuate goes through, but the second one fails (we evacuate our instances one by one). The reason why the second one fails seems to be because Neutron is trying to plug the port back on the dead compute, as nova instructs it to do. Here’s an example of nova-api log output after compute22 died and we’ve been trying to evacuate an instance. f3839ca64f58ac779f6f810758c0 61e62a49d34a44f9b1161a338a7f1fdd - default default] Creating event network-vif-unplugged:80371c01-930d-4ea2-9d28-14438e948b65 for instance 4aeb7761-cb23-4c51-93dd-79b55afbc7dc on compute22 2021-01-06 13:31:31.750 2858 INFO nova.osapi_compute.wsgi.server [req-4f9b3e17-1a9d-48f0-961a-bbabdf922ad6 0d0ef3839ca64f58ac779f6f810758c0 61e62a49d34a44f9b1161a338a7f1fdd - default default] 10.30.1.224 "POST /v2.1/os-server-external-events HTTP/1.1" status: 200 len: 1091 time: 0.4987640 2021-01-06 13:31:40.145 2863 INFO nova.osapi_compute.wsgi.server [req-abaac9df-7338-4d10-9326-4006021ff54d 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1 HTTP/1.1" status: 302 len: 318 time: 0.0072701 2021-01-06 13:31:40.156 2863 INFO nova.osapi_compute.wsgi.server [req-c393e74b-a118-4a98-8a83-be6007913dc0 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/ HTTP/1.1" status: 200 len: 789 time: 0.0070350 2021-01-06 13:31:43.289 2865 INFO nova.osapi_compute.wsgi.server [req-b87268b7-a673-44c1-9162-f9564647ec33 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/servers/4aeb7761-cb23-4c51-93dd-79b55afbc7dc HTTP/1.1" status: 200 len: 5654 time: 2.7543190 2021-01-06 13:31:43.413 2863 INFO nova.osapi_compute.wsgi.server [req-4cab23ba-c5cb-4dda-bf42-bc452d004783 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/servers/4aeb7761-cb23-4c51-93dd-79b55afbc7dc/os-volume_attachments HTTP/1.1" status: 200 len: 770 time: 0.1135709 2021-01-06 13:31:43.883 2865 INFO nova.osapi_compute.wsgi.server [req-f5e5a586-65f3-4798-b03b-98e01326a00b 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/flavors/574a7152-f079-4337-b1eb-b7eca4370b73 HTTP/1.1" status: 200 len: 877 time: 0.5751688 2021-01-06 13:31:47.194 2864 INFO nova.api.openstack.compute.server_external_events [req-7e639b1f-8408-4e8e-9bb8-54588290edfe 0d0ef3839ca64f58ac779f6f810758c0 61e62a49d34a44f9b1161a338a7f1fdd - default default] Creating event network-vif-plugged:80371c01-930d-4ea2-9d28-14438e948b65 for instance 4aeb7761-cb23-4c51-93dd-79b55afbc7dc on compute22 As you can see, Nova "creates an event" as the virtual interface is unplugged but then immediately creates another event to plug the virtual interface in the same compute node that is dead. However, at the same time, the instance is being created on another compute node. Is this a known bug? I have not found anything about this in the bug database. Additionally, I am not able to reproduce in our staging environment which is smaller and running on Stein. Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc. 4414-4416 Louis B Mayer Laval, QC, H7P 0G1, Canada TEL : +1.514.802.1644 - Poste : 2644 FAX : +1.514.612.0678 CA/US : 1.855.774.4678 FR : 01 76 60 41 43 UK : 0808 189 0423

3 5

[all][dev] Beware how fun the new pip can be
by Radosław Piliszek 13 Jan '21

13 Jan '21

Hiya, Folks! Sharing what I have just learnt about the new pip's solver. pip install PROJECT no longer guarantees to install the latest version of PROJECT (or, well, giving you the ERROR that it cannot do it because something something :-) ). In fact, it will install the latest version *matching other constraints* and do it *silently*. Like it was recently only with Python version (i.e. py3-only would not get installed on py2 - that is cool) but now it moved into any-package territory. As an example, I can give you [1] where we are experimenting with getting some extracurricular package into our containers, notably fluent-logger. The only dep of fluent-logger is msgpack but the latest msgpack (as in upper constraints: 1.0.2, or any 1.x for that matter) is not compatible. However, the pin was introduced in fluent-logger in its 0.9.5 release (0.9.6 is the latest). Guess what pip does? Here is what it does: INFO:kolla.common.utils.openstack-base:Collecting fluent-logger INFO:kolla.common.utils.openstack-base: Downloading http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/1a/f5/e6c30ec… (12 kB) INFO:kolla.common.utils.openstack-base: Downloading http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/d5/cb/19d8385… (12 kB) INFO:kolla.common.utils.openstack-base: Downloading http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/d1/d4/f9b3493… (12 kB) And that's it. Pip is happy, you got your "latest" version. In previous pip one would get the latest version AND a warning. Now just pip's view on what the "latest" version is. I am glad we have upper-constraints which save the day here (forcing the ERROR) but beware of this "in the wild". [1] https://review.opendev.org/c/openstack/kolla/+/759855 -yoctozepto

3 4

[largescale-sig] Next meeting: January 13, 15utc
by Thierry Carrez 13 Jan '21

13 Jan '21

Hi everyone, We'll have our first 2021 Large Scale SIG meeting this Wednesday in #openstack-meeting-3 on IRC, at 15UTC. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210113T15 Our main topic will be to reboot the Large Scale SIG in the new year and get a few work items and contributions planned. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Talk to you all later, -- Thierry Carrez

1 1

Ask for patch review
by 呂良 13 Jan '21

13 Jan '21

Hi, Mr.Ogawa & other members of tacker team: This is Liang Lu, may I invite you to review my patch ? https://review.opendev.org/c/openstack/tacker/+/764138 (now it is retesting but no new patch sets in future) This is a tiny patch fix calling parameter of kubernetes_driver.instantiate_vnf(), however it affects FT(will continuously fail if not merge), so I want to push it and merge it soon. best regards

2 1

ironic-python-agent erase block device failed
by Ankele zhang 13 Jan '21

13 Jan '21

Hi, I have an Rocky OpenStack platform. I used ironic-python-agent-builder to build a ipa.initramfs image. I called the clean API to erase my baremetal node disk. But it was failed. I traced the ipa source code, and got it used 'hdparm -I /dev/sdx' to check if the device is frozen [image: image.png] my device is frozen, then I switched to another SSD, and it's not frozen but it was also failed, [image: image.png] I don't know if I need to erase my bare metal nodes' block devices in product environment. If so, how to make it successful? Ankele

1 0

[heat][tripleo] os-apply-config os-refresh-config os-collect-config project governance
by Marios Andreou 12 Jan '21

12 Jan '21

Hello Heat team o/ as discussed in the thread at [1] TripleO is no longer using os-collect-config, os-refresh-config and os-apply-config as part of the OpenStack deployment. As such we are considering moving these repos to the independent release model. However as pointed out in [1] it seems that Heat is still using these - documented at [2]. Is the Heat community interested in taking over the ownership of these? To be clear what the proposal here is, I posted [3] - i.e. move these projects under the Heat governance. Thanks for your time, thoughts and comments on this, either here or in [3]. If you are NOT interested in owning these then we will likely move them to independent, or possibly even unmaintained/eol (in due course). regards, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019751.… [2] https://docs.openstack.org/heat/latest/template_guide/software_deployment.h… [3] https://review.opendev.org/c/openstack/governance/+/770285

4 4

Re: [nova] unit testing on ppc64le
by aditi Dukle 12 Jan '21

12 Jan '21

2 1

[ironic] question regarding attributes required for a non-admin to boot from volume
by Tzu-Mainn Chen 12 Jan '21

12 Jan '21

Hi, I've been looking into what it would take to allow non-admins to boot from volume. It looks like they'd need to update a node's storage_interface; and if you'd like to boot from an iSCSI volume, then you also need to update a node's capabilities property. Are these fields that we want non-admins to be able to update? If not, is there an alternative that might be possible? Thanks, Tzu-Mainn Chen

2 1

[neutron] bug deputy report (week of Jan 4)
by Akihiro Motoki 12 Jan '21

12 Jan '21

Hi, This is a summary of neutron bugs last week. Sorry for late. It was generally a quiet week. Thanks, Akihiro # Undecided https://bugs.launchpad.net/neutron/+bug/1910474 some times rally test would fail at network scenario due to mysql data base error Undecided It was reported against the queens release and the detail log mentioned in the bug is not available. It looks related to a nested transaction in percona but we are waiting for more information from the reporter. # Unassigned gate failures https://bugs.launchpad.net/neutron/+bug/1910691 In "test_dvr_router_lifecycle_ha_with_snat_with_fips", the HA proxy PID file is not removed reported by ralonsoh. Hope someone interested in it can look into it. # Assigned or In Progress https://bugs.launchpad.net/neutron/+bug/1910213 Live migration doesn't work with OVN and DPDK assigned to jlibosva https://bugs.launchpad.net/neutron/+bug/1910717 "test_set_igmp_snooping_flood" fails because "ports_other_config" is None ralonsoh is working on the fix https://bugs.launchpad.net/bugs/1910334 [OVN]after create port forwarding, floating ip status is not running In Progress, a fix is under review

1 0

[octavia] problems configuring octavia
by Daniel Macdonald 12 Jan '21

12 Jan '21

Happy new year Openstack users and devs! I have been trying on and off for several months to get octavia working but I have yet to have it successfully create a loadbalancer. I have deployed OS bionic-train using the Charms telemetry bundle with the octavia overlay. Openstack is working for creating regular instances but I get various errors when trying to create a loadbalancer. The first issue I feel I should mention is that I am using bind running on our MAAS controller as a DNS server. juju doesn't work if I enable IPv6 under bind yet the octavia charm defaults to using IPv6 for its management network so I have tried creating a IPv4 management network but I'm still having problems. For more details on that please see the comments of this bug report: https://bugs.launchpad.net/charm-octavia/+bug/1897418 Bug #1897418 “feature request: have option to use ipv4 when sett...” : Bugs : OpenStack Octavia Charm<https://bugs.launchpad.net/charm-octavia/+bug/1897418> By default, Octavia charm uses ipv6 for its lb-mgmt-subnet.[1] It would be nice to have the option to choose an ipv4 network from the start instead of deleting the ipv6 network and recreating the ipv4 subnet. Implementation - possible configuration option parameter when deploying. [1] https://opendev.org/openstack/charm-octavia/src/branch/master/src/lib/charm… bugs.launchpad.net Another notable issue I have is that after installing the charms telemetry bundle I have 2 projects call services. How do I know which is the correct one to use for Octavia? Is this following document going to be the best guide for me to follow to complete the final steps required to get Octavia (under Train) working: https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#insta… OpenStack Docs: Install and configure for Ubuntu<https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#insta…> Install and configure for Ubuntu¶. This section describes how to install and configure the Load-balancer service for Ubuntu 18.04 (LTS). docs.openstack.org I'm hoping someone has already written an easy to follow guide to using Octavia with an IPv4 management network using the Charms bundle to do most of the installation work? Thanks [University of Salford] DANIEL MACDONALD Specialist Technical Demonstrator School of Computing, Science & Engineering Room 145, Newton Building, University of Salford, Manchester M5 4WT T: +44(0) 0161 295 5242 D.R.MacDonald(a)salford.ac.uk<https://salfordexchangefarm.salford.ac.uk/owa/redir.aspx?C=xTvsJHwNEL3cOizC…> / www.salford.ac.uk<https://salfordexchangefarm.salford.ac.uk/owa/redir.aspx?C=VZufnsIyPXegmGvP…> [CSE]

2 2

[kolla] Victoria releases available
by Mark Goddard 12 Jan '21

12 Jan '21

Hi, I'm pleased to announce the availability of the first Victoria releases for all Kolla deliverables: * kolla 11.0.0 (https://docs.openstack.org/releasenotes/kolla/victoria.html#relnotes-11-0-0…) * kolla-ansible 11.0.0 (https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html#relnote…) * kayobe 9.0.0 (https://docs.openstack.org/releasenotes/kayobe/victoria.html#relnotes-9-0-0…) Thanks to everyone who contributed to these releases. And now onto Wallaby! Thanks, Mark

1 0

[tosca-parser][tacker] May I ask to push review process of patch 747516 : Support "Implementation" definition as Artifact Name
by 呂良 12 Jan '21

12 Jan '21

Hi Bob, This is Liang from tacker team, in our patch: Implement SOL001 features to MgmtDriver (Ib4ad3eb9) · Gerrit Code Review (opendev.org) <https://review.opendev.org/c/openstack/tacker/+/768091>, we tried to implement in order to allow user use their script by defining 'interface' in vnfd file: …/vnflcm_driver.py · Gerrit Code Review (opendev.org) <https://review.opendev.org/c/openstack/tacker/+/768091/12/tacker/vnflcm/vnf…> in the function above, changes in Support "Implementation" definition as Artifact Name (I192d3649) · Gerrit Code Review (opendev.org) <https://review.opendev.org/c/openstack/tosca-parser/+/747516> , is needed for our implementation, may I ask you to help us push review for an early merge of this patch, appreciate for that! Best regards Liang Lu

1 0

[oslo][TC] Dropping lower-constraints testing
by hberaud 12 Jan '21

12 Jan '21

Hello, As you already surely know, we (the openstack project) currently face some issues with our lower-constraints jobs due to pip's latest resolver feature. By discussing this topic with Thierry Carrez (ttx) from an oslo point of view, we reached the same conclusion that it is more appropriate to drop this kind of tests because the complexity and recurring pain needed to maintain them now exceeds the benefits provided by this mechanismes. Also we should notice that the number of active maintainers is declining, so we think that this is the shortest path to solve this problem on oslo for now and for the future too. In a first time I tried to fix our gates by fixing our lower-constraints project by project but with around ~36 projects to maintain this is a painful task, especially due to nested oslo layers inside oslo himself... I saw the face of the hell of dependencies. So, in a second time I submitted a series of patches to drop these tests [1]. But before moving further with that we would appreciate discussing this with the TC. For now the patches are ready and we just have to push the good button accordingly to our choices (+W or abandon). Normally all the oslo projects that need to be fixed are covered by [1]. Thoughts? Thanks for reading. [1] https://review.opendev.org/q/topic:%22oslo_lc_drop%22+(status:open%20OR%20s… -- 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-----

9 13

[tc] weekly update
by Mohammed Naser 11 Jan '21

11 Jan '21

Hi there, Here's an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Setting Xinran Wang as Cyborg's PTL https://review.opendev.org/c/openstack/governance/+/770075 - molteniron does not make releases https://review.opendev.org/c/openstack/governance/+/769805 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 - Add doc/requirements https://review.opendev.org/c/openstack/governance/+/769696 - Add link to Xena announcement https://review.opendev.org/c/openstack/governance/+/769620 - Add glance-tempest-plugin to Glance https://review.opendev.org/c/openstack/governance/+/767666 - Remove Karbor project team | https://review.opendev.org/c/openstack/governance/+/767056 ## Projects Updates - Deprecate neutron-fwaas and neutron-fwaas-dashboard master branch https://review.opendev.org/c/openstack/governance/+/735828 # Other Reminders - Our next [TC] Weekly meeting is scheduled on January 14th at 1500 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, January 13th, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[Glance] PTL on leaves
by Abhishek Kekane 11 Jan '21

11 Jan '21

Hi All, I'm going on leave from 13th January and will be back on 21st January to attend my sister's wedding. Please direct any issues to the rest of the core team. Thanks & Best Regards, Abhishek Kekane

1 0

[Diversity] Diversity &Inclusion WG Meeting reminder
by Amy Marrich 11 Jan '21

11 Jan '21

The Diversity & Inclusion WG invites members of all OSF projects to our meeting today, at 17:00 UTC in the #openstack-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity-wg-agenda. Please feel free to add any other topics you wish to discuss at the meeting. Thanks, Amy (spotz)

1 0

[nova] unit testing on ppc64le
by Balazs Gibizer 11 Jan '21

11 Jan '21

Hi, We have a bugreport[1] showing that our unit tests are not passing on ppc. In the upstream CI we don't have test capability to run our tests on ppc. But we have the IBM Power KVM CI[2] that runs integration tests on ppc. I'm wondering if IBM could extend the CI to run nova unit and functional tests too. I've added Michael Turek (mjturek(a)us.ibm.com) to CC. Michael is listed as the contact person for the CI. Cheers, gibi [1]https://bugs.launchpad.net/nova/+bug/1909972 [2]https://wiki.openstack.org/wiki/ThirdPartySystems/IBMPowerKVMCI

2 2

[nova] [Ussuri] Unable to perform live block migrations on ephemeral VMs without shared storage
by Justin Goetz 09 Jan '21

09 Jan '21

Hello! Happy new year to everyone! I'm experiencing some trouble in my attempts to get live block migrations working on machines who's boot drives live on ephemeral (local) host storage. Offline (cold) migrations appear to work fine, however, I need live migrations to function with no downtime to the VMs. We're running on OpenStack Ussuri, with Ubuntu 18.04.5 LTS as our hypervisor OS, running libvirt 6.0.0. Below is the following command I'm utilizing to perform the live block migration: openstack server migrate <id> --debug --verbose --live-migration --block-migration The verbose logging of the above command shows no obvious issues, however digging deeper on the hypervisor side, we see some libvirtd errors, and the most telling is this segment here: Jan 08 16:53:02 h5 libvirtd[4118]: Unsafe migration: Migration without shared storage is unsafe Jan 08 16:53:02 h5 nova-compute[130270]: 2021-01-08 16:53:02.860 130270 ERROR nova.virt.libvirt.driver [-] [instance: 72bc9feb-b8f0-45f2-bad4-9cb61c3abff3] Live Migration failure: Unsafe migration: Migration without shared storage is unsafe: libvirt.libvirtError: Unsafe migration: Migration without shared storage is unsafe Full log output is available here: http://paste.openstack.org/show/801525/ Perhaps I'm severely mistaken, but native libvirt should have no problem whatsoever performing live migrations without shared storage on it's own. I've dug into the libvirt side for hours to try and troubleshoot what the system is seeing as "unsafe" (I confirmed disk caching is disabled, as well as no strange custom settings are present), but was unsuccessful. The full output of my VM's QEMU XML file can be viewed here: http://paste.openstack.org/show/801526/ As I couldn't figure out why libvirtd was not seeing the migration as "safe", I attempted to override the libvirt message by attempting to utilize the live_migration_flag and block_migration_flag options in nova.conf to invoke the --unsafe parameter when running the libvirt commands (with the flags VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_UNSAFE,VIR_MIGRATE_NON_SHARED_INC), however I later learned from a previous developers thread on the mailing list from 2016 that both of these options have been depreciated in the later versions of Nova and replaced by the "live_migration_tunnelled" setting in nova.conf. I've ensured my nova.conf files have the live_migration_tunnelled parameter set to "True". However, I have not found any method for passing along the "--unsafe" flag (or any other libvirt flag, in this case) to libvirt from nova.conf from this point on after the depreciation of the live_migration_flag parameters. Any help would be greatly appreciated, from reading around online this seems to be a fairly common setup, I'm baffled at how I've run into this issue across several separate OpenStack clusters at this point. Thank you for reading. -- Justin Goetz Systems Engineer, TeraSwitch Inc. jgoetz(a)teraswitch.com 412-945-7045 (NOC) | 412-459-7945 (Direct)

1 0

how to read ipa source code#ironic-python-agent
by Ankele zhang 08 Jan '21

08 Jan '21

Hi~ I have an OpenStack platform on Rocky, and I used Nova/Keystone/Cinder/Glance/Ceph/Ironic. Recently, I have build my own ironic-python-agent deployment ramdisk and kernel images by ironic-python-agent-builder, the following work is to add my customized raid configuration method to HardwareManager. Before this, I want to read the ipa's source code. But I don't know where is the 'main()' entry. Looking forward to your help. Ankele

3 2

Re: [Release-job-failures] Release of openstack/kolla for ref refs/tags/9.3.0 failed
by Herve Beraud 08 Jan '21

08 Jan '21

Hello, FYI it seems that kolla met docker's new limitation during its release jobs, especially with your publish jobs, I saw that you (the kolla team) already discussed this limitation [1] on the ML. ``` 2021-01-07 17:21:03.396355 | primary | ERROR:kolla.common.utils.base:Error'd with the following message 2021-01-07 17:21:03.396465 | primary | ERROR:kolla.common.utils.base:toomanyrequests: You have reached your pull rate limit. You may increase ``` Three jobs here failed for the same reason. I don't think that reenqueue the failing jobs without a specific action to manage this limitation will help us here. Let us know if we can help us in some manner. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019148… Le jeu. 7 janv. 2021 à 20:41, <zuul(a)openstack.org> a écrit : > Build failed. > > - openstack-upload-github-mirror > https://zuul.opendev.org/t/openstack/build/a64b4c4bc398481f9afffa2ad465a012 > : SUCCESS in 1m 03s > - release-openstack-python > https://zuul.opendev.org/t/openstack/build/2ed64dfcbcaf483abf003cfdf4f25837 > : SUCCESS in 3m 11s > - announce-release > https://zuul.opendev.org/t/openstack/build/84d803d496a2485c983f6233dafcfd71 > : SUCCESS in 4m 07s > - propose-update-constraints > https://zuul.opendev.org/t/openstack/build/d0cac6a077054bc8ba9eb92e56c21799 > : SUCCESS in 4m 15s > - kolla-publish-centos-source > https://zuul.opendev.org/t/openstack/build/5e8f6aa2f56940a7be77a8dfe1c8ecc6 > : SUCCESS in 2h 20m 47s > - kolla-publish-centos-binary > https://zuul.opendev.org/t/openstack/build/8a8a021d9f9c4ca79755b06309710cc7 > : SUCCESS in 1h 56m 32s (non-voting) > - kolla-publish-centos8-source > https://zuul.opendev.org/t/openstack/build/fb6891d3f5e4493b880fce263a92e086 > : SUCCESS in 1h 50m 57s > - kolla-publish-centos8-binary > https://zuul.opendev.org/t/openstack/build/c312c05e5d084fdbb3f372755221f186 > : SUCCESS in 1h 13m 12s (non-voting) > - kolla-publish-debian-source > https://zuul.opendev.org/t/openstack/build/e24c12751b8c4aba881adb6c9ae8dc07 > : SUCCESS in 1h 27m 27s (non-voting) > - kolla-publish-debian-source-aarch64 > https://zuul.opendev.org/t/openstack/build/1ff3b02df53847d0aa54bf12ea7fa666 > : FAILURE in 1h 51m 49s (non-voting) > - kolla-publish-debian-binary > https://zuul.opendev.org/t/openstack/build/012c2de475fe45ea83f1cd8a7420aa6d > : SUCCESS in 1h 15m 15s (non-voting) > - kolla-publish-ubuntu-source > https://zuul.opendev.org/t/openstack/build/88ca21d972514cce954ecb586324fa29 > : FAILURE in 4m 14s > - kolla-publish-ubuntu-binary > https://zuul.opendev.org/t/openstack/build/f3d44e4d1b6c4e9799161b156290b238 > : FAILURE in 4m 19s (non-voting) > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- 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-----

3 3

[ironic] Resuming meetings next week
by Julia Kreger 08 Jan '21

08 Jan '21

Greetings everyone, Now that the Holidays are over, it is time for us to resume meeting on a regular basis. Ironic will resume it's weekly meeting next Monday at 1500 UTC in #openstack-ironic on irc.freenode.net. The agenda can be found on the OpenStack wiki[0]. See you all there! -Julia [0]: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting

1 0

[kolla] [train] Changing default quotas
by Braden, Albert 08 Jan '21

08 Jan '21

I'm trying to change default quotas on a Train kolla POC, and I can change compute, but when I try to change a network quota such as subnets I get an error: (openstack) [root@adjutant-poc openstack]# openstack quota set --class --subnets 2 default Network quotas are ignored since quota class is not supported. When I google around I find some old documents talking about setting neutron quotas in /etc/neutron/neutron.conf but I can't find anything recent, and I don't see any mention of quotas when I look at /etc/neutron/neutron.conf in our neutron_server containers. What is the best way to change neutron default quotas in kolla? I apologize for the nonsense below. So far I have not been able to stop it from being attached to my external emails. I'm working on it. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

2 1

[cinder][tripleo][release] Victoria Cycle-Trailing Release Deadline
by Herve Beraud 08 Jan '21

08 Jan '21

Hello teams with trailing projects, Next week is the Victoria cycle-trailing release deadline [1], and all projects following the cycle-trailing release model must release their Victoria deliverables by 14 January, 2021. The following trailing projects haven't been yet released for Victoria. Cinder: - cinderlib Tripleo: - os-collect-config - os-refresh-config - tripleo-ipsec This is just a friendly reminder to allow you to release these projects in time. Do not hesitate to ping us if you have any questions or concerns. [1] https://releases.openstack.org/wallaby/schedule.html#w-cycle-trail Hervé Beraud (hberaud) and the Release Management Team -- 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-----

2 3

[cinder] review priorities for the next 2 weeks
by Brian Rosmaita 08 Jan '21

08 Jan '21

As discussed at yesterday's cinder weekly meeting, the new driver merge deadline will soon be upon us at the Wallaby-2 milestone in two weeks [0]. Thus, all members of the cinder community should make driver reviews the top priority over the next 2 weeks. There are four drivers proposed for Wallaby that haven't merged yet: 1 - Ceph ISCSI driver https://review.opendev.org/c/openstack/cinder/+/662829 2 - Dell/EMC PowerVault ME Series driver: https://review.opendev.org/c/openstack/cinder/+/758684/ 3 - TOYOU ACS5000 driver: https://review.opendev.org/c/openstack/cinder/+/767290/ 4 - Kioxia KumoScale NVMeoF volume driver: https://review.opendev.org/c/openstack/cinder/+/768574 nvmeof connector mdraid support: https://review.opendev.org/c/openstack/os-brick/+/768575 healing agent: https://review.opendev.org/c/openstack/os-brick/+/768576 Don't forget that the cinder docs contain a helpful checklist for reviewing drivers: https://docs.openstack.org/cinder/latest/contributor/new_driver_checklist.h… If you are waiting for reviews of your driver, it will be helpful for you to review other drivers. You may notice something that you missed or could code differently in your driver, or you may be able to suggest changes based on issues you've come across implementing your driver. Happy reviewing! brian [0] https://releases.openstack.org/wallaby/schedule.html#w-cinder-driver-deadli…

1 0

[cinder] Cinder & Ceph Integration Error: No Valid Backend
by SSelf＠performair.com 08 Jan '21

08 Jan '21

All; We're having problems with our Openstack/Ceph integration. The versions we're using are Ussuri & Nautilus. When trying to create a volume, the volume is created, though the status is stuck at 'ERROR'. This appears to be the most relevant line from the Cinder scheduler.log: 2021-01-07 14:00:38.473 140686 ERROR cinder.scheduler.flows.create_volume [req-f86556b5-cb2e-4b2d-b556-ed07e632289d 824c26c133b34d8b8e84a7acabbe6f91 a983323b5ffc47e18660794cd9344869 - default default] 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 Here is the 'cinder.conf' from our Controller Node: [DEFAULT] # define own IP address my_ip = 10.0.80.40 log_dir = /var/log/cinder state_path = /var/lib/cinder auth_strategy = keystone enabled_backends = ceph glance_api_version = 2 debug = true # RabbitMQ connection info transport_url = rabbit://openstack:<password>@10.0.80.40:5672 enable_v3_api = True # MariaDB connection info [database] connection = mysql+pymysql://cinder:<password>@10.0.80.40/cinder # Keystone auth info [keystone_authtoken] www_authenticate_uri = http://10.0.80.40:5000 auth_url = http://10.0.80.40:5000 memcached_servers = 10.0.80.40:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = cinder password = <password> [oslo_concurrency] lock_path = $state_path/tmp [ceph] volume_driver = cinder.volume.drivers.rbd.RBDDriver volume_backend_name = ceph rbd_pool = rbd_os_volumes rbd_ceph_conf = /etc/ceph/463/ceph.conf rbd_flatten_volume_from_snapshot = false rbd_max_clone_depth = 5 rbd_store_chunk_size = 4 rados_connect_timeout = -1 rbd_user = cinder rbd_exclusive_cinder_pool = true backup_driver = cinder.backup.drivers.ceph backup_ceph_conf = /etc/ceph/300/ceph.conf backup_ceph_user = cinder-backup backup_ceph_chunk_size = 134217728 backup_ceph_pool = rbd_os_backups backup_ceph_stripe_unit = 0 backup_ceph_stripe_count = 0 restore_discard_excess_bytes = true Does anyone have any ideas as to what is going wrong? Thank you, Stephen Self IT Manager Perform Air International sself(a)performair.com www.performair.com

1 1

OpenStack Ansible - Telemetry
by Golasowski Martin 07 Jan '21

07 Jan '21

Dear All, I would like to know which monitoring solution is currently supported by OSA? We are operating a small cloud (~ 6 nodes) and we are interested in collecting performance metrics, events and logs. So, as far as I know, the official OSA solution is ceilometer/aodh/panko with Gnocchi as DB backend. However Gnocchi project seems abandoned at the moment and the grafana plugin is not compatible with latest Grafana. Then there is solution based on collectd with this plugin (https://github.com/signalfx/collectd-openstack <https://github.com/signalfx/collectd-openstack>) with Graphite or InfluxDB as backend. This supports only performance metrics and not the events. Then there are also some Prometheus exporters available, again, metrics only. What do you guys use these days? What would you recommend? Thanks! Best regards, Martin

2 2

[ironic] SPUC in 2021
by Dmitry Tantsur 07 Jan '21

07 Jan '21

Hi folks! I feel like SPUC (our Sanity Preserving Un-Conference) has been very successful in 2020, what do you think about continuing it as before: Friday, 10am UTC (in https://bluejeans.com/643711802) Friday, 5pm UTC (in https://bluejeans.com/313987753) ? Dmitry -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

2 2

[tripleO] Customised Cinder-Volume fails at 'Paunch 5' during overcloud deployment
by Igal Katzir 07 Jan '21

07 Jan '21

Hello all, I am trying to deploy RHOSP16.1 (based on ‘train’ distribution) for Certification purposes. I have build a container for our cinder driver and trying to deploy it. Deployment runs almost till the end and fails at stage when it tries to configure Pacemaker; Here is the last message: "Info: Applying configuration version '1609231063'", "Notice: /Stage[main]/Pacemaker::Corosync/File_line[pcsd_bind_addr]/ensure: created", "Info: /Stage[main]/Pacemaker::Corosync/File_line[pcsd_bind_addr]: Scheduling refresh of Service[pcsd]", "Info: /Stage[main]/Pacemaker::Service/Service[pcsd]: Unscheduling all events on Service[pcsd]", "Info: Class[Pacemaker::Corosync]: Unscheduling all events on Class[Pacemaker::Corosync]", "Notice: /Stage[main]/Tripleo::Profile::Pacemaker::Cinder::Volume_bundle/Pacemaker::Resource::Bundle[openstack-cinder-volume]/Pcmk_bundle[openstack-cinder-volume]: Dependency Pcmk_property[property-overcloud-controller-0-cinder-volume-role] has failures: true", "Info: Creating state file /var/lib/puppet/state/state.yaml", "Notice: Applied catalog in 382.92 seconds", "Changes:", " Total: 1", "Events:", " Success: 1", " Failure: 2", " Total: 3", I have verified that all packages on my container-image (Pacemaker,Corosync, libqb,and pcs) are installed with same versions as the overcloud-controller. But seems that something is still missing, because deployment with the default openstack-cinder-volume image completes successfully. Can anyone help with debugging this? Let me know if more info needed. Thanks in advance, Igal

2 4

[stable][grenade][qa][nova][swift] s-proxy unable to start due to missing runtime deps
by Lee Yarwood 07 Jan '21

07 Jan '21

Hello all, I wanted to raise awareness of the following issue and to seek some feedback on my approach to workaround it: ImportError: No module named keystonemiddleware.auth_token https://bugs.launchpad.net/swift/+bug/1909018 This was introduced after I landed the following devstack backport stopping projects from installing their test-requirements.txt deps: Stop installing test-requirements with projects https://review.opendev.org/q/I8f24b839bf42e2fb9803dc7df3a30ae20cf264eb For the time being to workaround this in various other gates I've suggested that we disable Swift in Grenade on stable/train: zuul: Disable swift services until bug #1909018 is resolved https://review.opendev.org/c/openstack/grenade/+/768224 This finally allowed openstack/nova to pass on stable/train with the following changes to lower-constraints.txt and test-requirements.txt: [stable-only] Cap bandit to 1.6.2 and raise hacking, flake8 and stestr https://review.opendev.org/c/openstack/nova/+/766171/ Are there any objections to disabling Swift in Grenade for the time being on stable/train? Would anyone have any objections to also disabling it on stable/stein via devstack-gate? Many thanks in advance, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

2 4

[neutron] SR-IOV mechanism driver configuration, plugin.ini
by Gabriel Omar Gamero Montenegro 07 Jan '21

07 Jan '21

Dear all, I'm following the OpenStack guide for the implementation of SR-IOV mechanism driver. I'm planning to incorporate this driver to my current OpenStack deployment (Queens). Config SR-IOV Guide: https://docs.openstack.org/neutron/queens/admin/config-sriov.html At point 2, section "Configure neutron-server (Controller)" they said that I have to add the 'plugin.ini' file as a parameter to the neutron-server service. To do this they require to <<edit the appropriate initialization script to configure the neutron-server service to load the plugin configuration file>>: --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini I'd like to know a few things: (1) Which plugin.ini file are talking about? (2) How to set up the neutron-server initialization script to add the plugin.ini file? I understand that this varies between OS distro (I'm currently using Ubuntu 16.04 LTS server) Here are some things I tried... I got the following results executing this command: systemctl status neutron-server.service ● neutron-server.service - OpenStack Neutron Server Loaded: loaded (/lib/systemd/system/neutron-server.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2020-12-29 18:13:50 -05 Main PID: 38590 (neutron-server) Tasks: 44 Memory: 738.8M CPU: 29.322s CGroup: /system.slice/neutron-server.service ├─38590 /usr/bin/python2 /usr/bin/neutron-server --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/ml2_conf.ini --log-file=/var/log/neutron/neutron-server.log ... I see 2 things: (i) When neutron-server is exectured, the following parameters are passed: --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/ml2_conf.ini --log-file=/var/log/neutron/neutron-server.log (ii) The file '/lib/systemd/system/neutron-server.service' is loaded and it has the following content: ... ExecStart=/etc/init.d/neutron-server systemd-start ... This indicates me that it's executing '/etc/init.d/neutron-server' script. So I suppose this is the file indicated to add the parameters of the SR-IOV OpenStack documentation, but I have no idea where to put them. For Red-Hat distros I found this documentation with the following configuration: https://access.redhat.com/documentation/en-us/ red_hat_enterprise_linux_openstack_platform/7/html/networking_guide /sr-iov-support-for-virtual-networking vi /usr/lib/systemd/system/neutron-server.service ... ExecStart=/usr/bin/neutron-server --config-file /usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini --config-file /etc/neutron/plugins/ml2/ml2_conf_sriov.ini --log-file /var/log/neutron/server.log Thanks in advance, Gabriel Gamero

3 2

[neutron] Drivers team meeting agenda
by Slawek Kaplonski 07 Jan '21

07 Jan '21

Hi, Agenda for first drivers team meeting in 2021 is available at [1] We have 3 RFEs to discuss: * https://bugs.launchpad.net/neutron/+bug/1909100 * https://bugs.launchpad.net/neutron/+bug/1900934 For that one there is also spec proposed https://review.opendev.org/c/openstack/neutron-specs/+/768588 and we already discussed that few times. So I think it's time to decide if we want to go with that solution or not :) * https://bugs.launchpad.net/neutron/+bug/1910533 Thx and see You tomorrow on the meeting. [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[kolla-ansible] Upgrading and skipping a release?
by Eric K. Miller 07 Jan '21

07 Jan '21

Hi, We're working on some upgrades of OpenStack deployed with Kolla Ansible (Stein and later), and wasn't sure if it was practical or possible to upgrade, say, from Stein to Victoria, or Train to Victoria, directly, instead of upgrading in 3 steps from Stein->Train->Ussuri->Victoria. Any reason skipping a release will cause any known harm? Anybody done this successfully? Thanks! Eric

2 3

[neutron] Performance impact for attaching Security Group with more number of rules
by Dhanasekar Kandasamy 07 Jan '21

07 Jan '21

Hi, We have an OpenStack Environment with 5000+ VMs running currently. I want to apply some common Security Group to all my running VMs. - Common Security Group (SEC_GRP_COMMON) has around 700 rules. - This Security Group (SEC_GRP_COMMON) has been shared to all the OpenStack Projects using Role-Based Access Control (RBAC). - Wanted to apply this Security Group (SEC_GRP_COMMON) to all the running VMs in the Cloud *Question 1*: With the above scenario, what will happen if I attach this Security Group(with 700+ rules) to all the 5000+ VMs? Will there be any performance issue/impact for the same (CPU utilization, Memory etc. in the Compute Server or Performance issues in application running in the VMs) *Question 2*: Is there any recommendations or benchmark data for maximum number of rules in the Security Group in OpenStack cloud? Thanks, Dhana

2 1

tinyipa cannot boot OS of baremetal node
by Ankele zhang 07 Jan '21

07 Jan '21

Hi~ My Rocky OpenStack platform deployed with official documents, includes Keystone/Cinder/Neutron/Nova and Ironic. I used to boot my baremetal nodes by CoreOS downloaded on https://tarballs.opendev.org/openstack/ironic-python-agent/coreos/files/ <https://tarballs.opendev.org/openstack/ironic-python-agent/coreos/files/cor…> Since I want to customize my own HardwareManager for configuring RAID, I have build TinyIPA image tinyipa.tar.gz and tinyipa.vmlinuz with ironic-python-agent-builder(master branch) and ironic-python-agent(rocky branch). Here are all the products of the build process. [image: image.png] Then I used these two images to create the baremetal node, and boot nova server, but I didn't get the results I wanted, it couldn't enter the ramdisk and always in 'wait call-back' state. as following [image: image.png] I got nothing in /var/log/ironic/ironig-conductor.log and /var/log/nova/nova-compute.log I don't know if these two image (tinyipa.tar.gz and tinyipa.vmlinuz) are valid for Ironic. If not, how can I customize HardwareManager? Looking forward to hearing from you. Ankele

3 3

[neutron] Next step for BGP routed networks over segmented provider infrastructure segments
by Thomas Goirand 06 Jan '21

06 Jan '21

Hi Ryan, and all of the Neutron team, Today, I'm happy to let you know that I've been able to finish the patch and that it's merged: https://review.opendev.org/c/openstack/neutron/+/669395 I also managed to add some docs to Neutron about it: https://docs.openstack.org/neutron/latest/admin/config-bgp-floating-ip-over… We've used it in a pre-production environment, and it just works as expected, it's kind of great. However, there's some feature gaps that would need to be addressed. Namely: - external-gateway of routers aren't advertized - we can't do direct attach of public IPs to VMs - I failed adding IPv6 dual stack to this setup Let me go into more details for each of these 3 points. 1/ No BGP advertizing for the router default gateways When doing: openstack router set --external-gateway <provider-net> <router> we then get this type of port: # openstack port show <UUID> -c binding_vif_details -c binding_vif_type +---------------------+-------------------------------------------------------------------------------------------------------------+ | Field | Value | +---------------------+-------------------------------------------------------------------------------------------------------------+ | binding_vif_details | bridge_name='br-int', connectivity='l2', datapath_type='system', ovs_hybrid_plug='True', port_filter='True' | | binding_vif_type | ovs | +---------------------+-------------------------------------------------------------------------------------------------------------+ which doesn't match the type of port we have for floating IPs: # openstack port show <UUID> -c binding_vif_details -c binding_vif_type +---------------------+---------+ | Field | Value | +---------------------+---------+ | binding_vif_details | | | binding_vif_type | unbound | +---------------------+---------+ and then, the next HOP for the router gateway isn't advertized over BGP. Do you know how we could get neutron-dynamic-routing to do that advertizing, with the next HOP on the network node(s)? Where should that code be patch? Inside Neutron, or in neutron-dynamic-routing? Is this really related to the port type as I've showed above? 2/ No direct attach to VM ports We can't attach a port with an IP network:routed directly to a VM. I tried to add the subnet type "compute:nova" to the floating IP subnet, but that didn't do it: Neutron refuses to attach the port to a VM. Do you know why? How and what and where should we patch Neutron to fix this? 3/ IPv6 dual stack I tried to setup a dual-stack network, and failed. How should this be done? Should we add v6 subnets to segments and one subnet with the type --service-type 'network:router_gateway' as well? This is what I tried but it didn't work for me. Should tenants create their own v6 subnet out of the v6 subnet pool I provisioned as admin? Cheers, Thomas Goirand (zigo) P.S: Please keep my Infomaniak colleagues as Cc.

1 0

failed to launch openstack instance when integrating with odl
by mohammad mighani 06 Jan '21

06 Jan '21

Hi everyone I tried to integrate Openstack train with Opendaylight magnesium and my references were [1] and [2] but after doing all the steps, the instance failed to launch. I changed port_binding_controller in [ml2_odl] section in the ml2_conf.ini file from pseudo-agentdb-binding to legacy-port-binding and then the instance launched but the status of router interfaces was still down. I have a controller node and a compute node. and Opendaylight runs on the controller node. nova-compute.log: INFO nova.virt.libvirt.driver [-] [instance: 975fa79e-6567-4385-be87-9d12a8eb3e94] Instance destroyed successfully. 2021-01-02 12:33:23.383 25919 ERROR vif_plug_ovs.ovsdb.impl_vsctl [req-a0a7ebf0-7e63-4c60-a8d2-07c05f1aa4f4 04c7685a2166481a9ace54eb5e71f6e5 ca28ee1038254649ad133d5f09f7a186 - default default] Unable to execute ['ovs-vsctl', '--timeout=120', '--oneline', '--format=json', '--db=tcp: 127.0.0.1:6640', '--', '--if-exists', 'del-port', 'br-int', 'tap50eb0b68-a4']. Exception: Unexpected error while running command. Command: ovs-vsctl --timeout=120 --oneline --format=json --db=tcp: 127.0.0.1:6640 -- --if-exists del-port br-int tap50eb0b68-a4 Exit code: 1 Stdout: '' Stderr: 'ovs-vsctl: tcp:127.0.0.1:6640: database connection failed (Connection refused)\n': oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. controller ovs: Manager "tcp:192.168.222.48:6640" is_connected: true Bridge br-int Controller "tcp:192.168.222.48:6653" is_connected: true fail_mode: secure Port tune52c5c73a50 Interface tune52c5c73a50 type: vxlan options: {key=flow, local_ip="10.0.0.31", remote_ip="10.0.0.11"} Port br-int Interface br-int type: internal Bridge br-ex Port br-ex Interface br-ex type: internal Port ens160 Interface ens160 ovs_version: "2.13.1" compute ovs: Manager "tcp:192.168.222.48:6640" is_connected: true Bridge br-int Controller "tcp:192.168.222.48:6653" is_connected: true fail_mode: secure Port br-int Interface br-int type: internal Port tun34b3712d975 Interface tun34b3712d975 type: vxlan options: {key=flow, local_ip="10.0.0.11", remote_ip="10.0.0.11"} Port tund5123ce5b8a Interface tund5123ce5b8a type: vxlan options: {key=flow, local_ip="10.0.0.11", remote_ip="10.0.0.31"} ovs_version: "2.13.1"

1 0

[ironic] inspector auto-discovery disabled by default in bifrost
by Jacob Anders 06 Jan '21

06 Jan '21

Hi Ironicers, The Ironic team recently decided to change the default inspector auto-discovery behavior in bifrost. In the past, this feature was enabled by default. However, this was causing issues in deployments where the operators had no intention of using auto-discovery but the IPA somehow booted anyway, causing port conflicts and creating failure modes which were particularly tricky to debug. For this reason, inspector auto-discovery has been disabled by default with this change which merged yesterday: https://review.opendev.org/c/openstack/bifrost/+/762998 This is to make sure that the operators utilising inspector auto-discovery in bifrost are aware of this change and can re-enable inspector discovery if desired. Best regards, Jacob

1 0

[Nova]ask for help: how to plug vif to ovs when ovs is not together with nova-compute
by 付志华 05 Jan '21

05 Jan '21

hello， I encountered some problems in deploying the smart network interface card（SmartNIC）where Nova-compute is not together with OVS. For example, OVS is deployed on the SmartNIC and Nova-compute is on the Host(Compute Node), how does Nova plug the virtual interface of VM to OVS bridge? Does the latest version of openstack support this? Thanks.

2 1

[keystone] No meeting Jan 5
by Nikolla, Kristi 05 Jan '21

05 Jan '21

Hi all, There will be no keystone IRC meeting on Jan 5. Best, Kristi Nikolla

1 0

[tripleo] Package dependencies, podman, dnf modules
by Cédric Jeanneret 05 Jan '21

05 Jan '21

Hello there, Since we introduced Podman instead of Docker in tripleo, we are running after the right version. For now, the version we should use is provided by a specific container-tools module stream (container-tools:2.0). The default stream being container-tools:rhel8, we might end with a deployed undercloud running the wrong podman version, leading to some nice issues, especially in a SELinux-enabled environment. Currently, the main dependency tree is: python3-tripleoclient requires podman That's mostly all. While we can, of course, edit the python3-tripleoclient spec file in order to pin the precise podman version (or, at least, set upper and lower constraints) in order to target the version provided by the right stream, it's not ideal: - package install error will lead to more questions (since ppl might skip doc for #reason) - if we change the target version, we'll need to ensure it's present in a stream (and, well, update the doc if we need to switch the stream) - and probably some other reasons. Since we can NOT depend on a specific stream in rpm (for instance, we can't put "Requires @container-tools:2.0/podman" like we might in ansible), we're a bit stuck. An ugly hack is tested in the spec file[1], using a bash thing in order to check the activated stream, but this is not ideal either, especially since it makes the whole package building/checking fail during the "mock" stage. In order to make it pass, we'd need to modify the whole RDO in order to take into account stream switching. This isn't impossible, but it leads to other concerns, especially when it comes to "hey we need to switch the stream for <module>". And I'm pretty sure no one will want to dig into it, for good reasons ;). This leads to a last possibility: drop the "Requires podman" from tripleo dependency tree, and rely on tripleo-ansible to actually enable the correct module, and install podman. This means podman will be installed during the undercloud deploy, for instance as a host_prep_tasks (step_0). While I'm not that happy with this idea, it's probably not as bad as the other hacks we've tested so far, and would, at last, prevent once for all the usual "it's not working" due to a wrong podman version (and, yes, we get plenty of them, especially in the OSP version). What do you think? Any other way of solving this issue? Remember, we're talking about "ensuring we get the right version, coming from a specific stream" and, especially, "ensure operator can't install the wrong one" (if they don't follow the doc, of if they are using automation that doesn't check actual requirements in the doc"... Thank you for your thoughts! Cheers, C. [1] https://review.rdoproject.org/r/#/c/31411/ -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/

4 6

[qa][tempest] Update language in tempest code base
by Arx Cruz 05 Jan '21

05 Jan '21

Hello, I would like to start a discussion regarding the topic. At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from tempest codebase, such as blacklist, whitelist. We should take the opportunity and do our best to replace outdated terms with their more inclusive alternatives. As you can see in [1] the TripleO project is already working on this initiative, and I would like to work on this as well on the tempest side. Any thoughts? Shall I start with a sepc, adding deprecation warnings? [1] https://review.opendev.org/#/c/740013/1/specs/victoria/renaming_rules.rst Kind regards, -- Arx Cruz Software Engineer Red Hat EMEA <https://www.redhat.com> arxcruz(a)redhat.com @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

6 9

[infra][magnum][ci] Issues installing bashate and coverage
by Spyros Trigazis 05 Jan '21

05 Jan '21

Hello infra, openstack-tox-lower-constraints fails for bashate and coverage. (Maybe more, I bumped bashate and it failed for coverage. I don;t want to waste more resources on our CI) eg https://review.opendev.org/c/openstack/magnum/+/765881 https://review.opendev.org/c/openstack/magnum/+/765979 Do we miss something? Thanks, Spyros

4 6

[Ussuri] Auto shutdown VM
by Deepa KR 05 Jan '21

05 Jan '21

Hi All We have a Openstack setup with the Ussuri Version and I am regularly facing auto shutdown of a few VMs (ubuntu16.04) randomly . If I restart then the instance is back . From logs I was able to see the messages below . WARNING nova.compute.manager [req-2a21d455-ac04-44aa-b248-4776e5109013 813f3fb52c434e38991bb90aa4771541 10b5279cb6f64ca19871f132a2cee1a3 - default default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Received unexpected event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 for instance with vm_state active and task_state None. INFO nova.compute.manager [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] VM Stopped (Lifecycle Event) INFO nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from the hypervisor (4). Updating power_state in the DB to match the hypervisor. syslog:Nov 13 07:01:07 fgshwbucehyp04 nova-compute[2680204]: 2020-11-13 07:01:07.684 2680204 WARNING nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance shutdown by itself. Calling the stop API. Current vm_state: active, current task_state: None, original DB power_state: 1, current VM power_state: 4 nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance is already powered off in the hypervisor when stop is called. nova.virt.libvirt.driver [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance already shutdown. nova.virt.libvirt.driver [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. nova.compute.manager [req-7a0a0d03-e286-42f0-9e36-38a432f236f3 d9ca03b9d0884d51a26a39b6c82f02eb 304d859c43df4de4944ca5623f7f455c - default default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Get console output nova.virt.libvirt.driver [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. I searched a few blogs and forums but couldn't find a solution to it . Few mentioned to add sync_power_state_interval=-1 in /etc/nova/nova.conf .But understood that this will help only when nova stops vm. But in this case vm itself is shutting down (Instance shutdown by itself. Calling the stop API) Also no memory issue in VM nor the hypervisor. Also did apt-get upgrade . It would be great if anyone can shed light to this issue. Regards, Deepa K R Sent from my iPhone

7 15

[SIG] [First Contact] First Meeting of the Year!
by Kendall Nelson 05 Jan '21

05 Jan '21

Hello! We will be holding our meeting tomorrow (at 00:00 UTC in #openstack-upstream-institute) with a pretty short agenda[1] so feel free to add as you see fit! One thing I do want to try is to set some concrete goal or two for this year to work towards. So if you're new to the SIG this is the perfect time to come meet us and get involved! -Kendall (diablo_rojo) [1] https://wiki.openstack.org/wiki/First_Contact_SIG#Meeting_Agenda

1 0

[tc] weekly meeting
by Mohammed Naser 05 Jan '21

05 Jan '21

Hi there, Hope everyone enjoyed the holidays! Here's an update on what happened in the OpenStack TC these past few days. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Add Resolution of TC stance on the OpenStackClient | https://review.opendev.org/c/openstack/governance/+/759904 - Remove Karbor project team | https://review.opendev.org/c/openstack/governance/+/767056 - Add glance-tempest-plugin to Glance | https://review.opendev.org/c/openstack/governance/+/767666 ## Other Reminders - Our next TC Weekly meeting is scheduled for January 7th at 1500 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, January 6th, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[tripleo] next irc meeting Tuesday Jan 05 @ 1400 UTC in #tripleo
by Marios Andreou 04 Jan '21

04 Jan '21

The next TripleO irc meeting is: ** Tuesday 05th January at 1400 UTC in #tripleo. ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add any one-off items you want to hilight at https://etherpad.opendev.org/p/tripleo-meeting-items This can include review requests, blocking issues or to socialise ongoing or planned work, or anything else you want to share. Our last meeting was held on Dec 22nd - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2020/tripleo.2020-12-22-14.… Hope to see you there!

1 0

[swift] Openstack controller/keystone cause not uploading file to swift storage
by Hamidreza Hosseini 04 Jan '21

04 Jan '21

Hi, I've installed swift storage and swift-proxy and keystone for object storage I'm using memcached for caching keystone's data But suddenly in some moments my cpu of keystone servers goes up till 50% (it is apache and keystone proccess) and the swift proxies wouldn't upload anything!!! As I said servers have free cpu and ram and kernel tuned well which parameter should I check for my problem? How can I solve this strange problem?

1 0

some error abount ironic-python-agent-builder
by Ankele zhang 04 Jan '21

04 Jan '21

Hi~ I have an OpenStack platform in Rocky version. I use ironic-python-agent-builder to build a tinyipa image to customing HardwareManager for 'RAID configuration' in Ironic cleaning steps. While I follow the steps ' https://docs.openstack.org/ironic-python-agent-builder/latest/admin/tinyipa…' to build tinyipa image, it occurs error as following: [image: image.png] [image: image.png] so, what the IPA_SOURCE_DIR means? Do I need to download the source code of the ironic-python-agent and copy it to /opt/stack/ before this? Looking forward to your reply. Ankele

2 1

[neutron] Bug deputy report December 28th to January 3rd
by Lajos Katona 04 Jan '21

04 Jan '21

Hi, I was Neutron bug deputy for this week, and it was a really quiet week. Opinion: - https://bugs.launchpad.net/neutron/+bug/1909160 : high cpu usage when listing security groups - The issues is reported from Rocky - On openstack-discuss was some mail about slow security-group API on Stein for example: http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019573… - I checked some rally execution from latest master runs and haven't seen such Happy New Year! Lajos Katona (lajoskatona)

1 0

[neutron] CI meeting - Tuesday 05.01.2021
by Slawek Kaplonski 04 Jan '21

04 Jan '21

Hi, I just found out that I have some internal training tomorrow and will not be able to chair our tomorrow's CI meeting. As this is just second day after holidays season for many of us, lets cancel this one more meeting. If there is anything urgent related to the CI, please ping me on IRC or send me an email about it. See You all on the meeting next week. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[neutron] Team meeting - Tuesday 05.01.2021
by Slawek Kaplonski 04 Jan '21

04 Jan '21

Hi, I just found out that I have some internal training tomorrow and will not be able to chair our tomorrow's team meeting. As this is just second day after holidays season for many of us, lets cancel this one more meeting. See You all on the meeting next week. Happy New Year to all of You :) -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

failed to launch openstack instance when integrate with odl
by john smith 02 Jan '21

02 Jan '21

hello I tried to integrate Openstack train with Opendaylight magnesium and my references were [1] <https://docs.opendaylight.org/projects/netvirt/en/stable-magnesium/openstac…> and [2] <https://files.openstack.org/docs/networking-odl/train/install/installation.…> but after doing all the steps, the instance failed to launch. I changed port_binding_controller in [ml2_odl] section in the ml2_conf.ini file from pseudo-agentdb-binding to legacy-port-binding and then the instance launched but the status of router interfaces was still down. I have a controller node and a compute node. and Opendaylight runs on the controller node. nova-compute.log: INFO nova.virt.libvirt.driver [-] [instance: 975fa79e-6567-4385-be87-9d12a8eb3e94] Instance destroyed successfully. 2021-01-02 12:33:23.383 25919 ERROR vif_plug_ovs.ovsdb.impl_vsctl [req-a0a7ebf0-7e63-4c60-a8d2-07c05f1aa4f4 04c7685a2166481a9ace54eb5e71f6e5 ca28ee1038254649ad133d5f09f7a186 - default default] Unable to execute ['ovs-vsctl', '--timeout=120', '--oneline', '--format=json', '--db=tcp: 127.0.0.1:6640', '--', '--if-exists', 'del-port', 'br-int', 'tap50eb0b68-a4']. Exception: Unexpected error while running command. Command: ovs-vsctl --timeout=120 --oneline --format=json --db=tcp: 127.0.0.1:6640 -- --if-exists del-port br-int tap50eb0b68-a4 Exit code: 1 Stdout: '' Stderr: 'ovs-vsctl: tcp:127.0.0.1:6640: database connection failed (Connection refused)\n': oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. controller ovs: Manager "tcp:192.168.222.48:6640" is_connected: true Bridge br-int Controller "tcp:192.168.222.48:6653" is_connected: true fail_mode: secure Port tune52c5c73a50 Interface tune52c5c73a50 type: vxlan options: {key=flow, local_ip="10.0.0.31", remote_ip="10.0.0.11"} Port br-int Interface br-int type: internal Bridge br-ex Port br-ex Interface br-ex type: internal Port ens160 Interface ens160 ovs_version: "2.13.1" compute ovs: Manager "tcp:192.168.222.48:6640" is_connected: true Bridge br-int Controller "tcp:192.168.222.48:6653" is_connected: true fail_mode: secure Port br-int Interface br-int type: internal Port tun34b3712d975 Interface tun34b3712d975 type: vxlan options: {key=flow, local_ip="10.0.0.11", remote_ip="10.0.0.11"} Port tund5123ce5b8a Interface tund5123ce5b8a type: vxlan options: {key=flow, local_ip="10.0.0.11", remote_ip="10.0.0.31"} ovs_version: "2.13.1"

1 0

[puppet][neutron] Status of networking-cisco and networking-bigswitch
by Takashi Kajinami 02 Jan '21

02 Jan '21

Hello, While cleaning up outdated implementations in puppet-neutron, I noticed that the following 2 plugins are supported by puppet-neutron but the plugins are no longer maintained actively these days. 1) networking-cisco https://opendev.org/x/networking-cisco This repo has not got any updates for these 2 year except fo opendev migration and supports not Python 3.6 but only Python 2.7 and Python 3.5. 2) networking-bigswitch https://opendev.org/x/networking-bigswitch This repo was updated 10 months ago, but doesn't have ussuri and victoria branch created. If I don't hear any plan to keep maintaining these 2 repositories I'll deprecate support for these 2 plugins in this release and remove the support completely in the next cycle. Thank you, Takashi Kajinami

1 0