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

[neutron]Drivers meeting agenda - 22.01.2021
by Slawek Kaplonski 21 Jan '21

21 Jan '21

Hi, Agenda for tomorrow's drivers meeting is at [1]. We have one RFE ready to discuss: - https://bugs.launchpad.net/neutron/+bug/1911126 We also have 2 new things which are now triaging, so please take a look at them if You have some time and ask questions if You have any: - https://bugs.launchpad.net/neutron/+bug/1912460 - https://bugs.launchpad.net/neutron/+bug/1911864 [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[Octavia] Network issue between amphora and health manager port
by CHANU ROMAIN 21 Jan '21

21 Jan '21

Hello, I try to install Octavia and i'm facing an issue with octavia-health- manager-listen-port interface. I use Openstack Ussuri on Ubuntu 18.04 with linuxbridge plugin I followed this procedure: https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#insta… When I try to create my loadbalancer I got this error: WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='10.244.3.243', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fe1ec077080>: Failed to establish a new connection: [Errno 113] No route to host',)) From my interface "o-hm0" I cannot ping 10.244.3.243 but if I try to ping from DHCP namespace it works fine. I think the problem is my "octavia-health-manager-listen-port" port appears "DOWN" when I list every ports. I figured out than Neutron didnt update iptables rules, probably because the interface is DOWN but if I add these rules: iptables -A neutron-linuxbri-FORWARD -m physdev --physdev-out o-bhm0 -- physdev-is-bridged -m comment --comment "Accept all packets when port is trusted." -j ACCEPT iptables -A neutron-linuxbri-FORWARD -m physdev --physdev-in o-bhm0 -- physdev-is-bridged -m comment --comment "Accept all packets when port is trusted." -j ACCEPT Amphora is able to communication with health manager port then the loadbalancer becomes UP but now I got this WARNING: 2021-01-21 15:27:21.230 2999834 WARNING octavia.amphorae.drivers.health.heartbeat_udp [-] Health Manager experienced an exception processing a heartbeat message from ('10.244.3.243', 30684). Ignoring this packet. Exception: 'NoneType' object has no attribute 'encode' I guess it's all about the port being stuck in DOWN state. Do you have any input how to configure this port? Best regards, Romain

2 1

[monasca][release] Abandoning monasca-ceilometer and monasca-log-api?
by Herve Beraud 21 Jan '21

21 Jan '21

Dear Monasca team, The release team noticed an inconsistency between the Monasca team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). Indeed, monasca-ceilometer and monasca-log-api were released in train but not released in ussuri nor victoria. Do you think that they should be deprecated (abandoned) in governance? Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] 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-----

3 4

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

21 Jan '21

Hi everyone, Here’s the agenda for our weekly TC meeting. It will happen tomorrow (Thursday the 21st) at 1500 UTC in #openstack-tc and I will be your chair. If you can’t attend, please put your name in the “Apologies for Absence” section https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting # ACTIVE INITIATIVES * Follow up on past action items * Audit SIG list and chairs (diablo_rojo) * Add Resolution of TC stance on the OpenStackClient (diablo_rojo) - https://review.opendev.org/c/openstack/governance/+/759904 * Gate performance and heavy job configs (dansmith) - http://paste.openstack.org/show/jD6kAP9tHk7PZr2nhv8h/ * Audit and clean-up tags (gmann) - 'supports-api-interoperability' tag - Manila request: https://review.opendev.org/c/openstack/governance/+/770859 * infra-core team (mnaser / diablo_rojo) - Stepping up to help with review load that will be new to everyone * Dropping lower-constraints testing from all projects (gmann) - http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.… * Decide on OpenSUSE in testing runtime (gmann) - https://review.opendev.org/c/openstack/devstack/+/769884 * Define 2021 upstream investment opportunities - https://review.opendev.org/c/openstack/governance/+/771707 * Open Reviews - https://review.opendev.org/q/project:openstack/governance+is:open Thank you Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[OpenStackSDK][release] Abandoning js-openstack-lib?
by Herve Beraud 21 Jan '21

21 Jan '21

Dear OpenStackSDK team, The release team noticed an inconsistency between the OpenStackSDK team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). Indeed, js-openstack-lib (added January 9, 2020) was never released yet and was not ready for ussuri or victoria. maybe we should abandon this instead of waiting? Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] 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-----

2 2

[all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-16 Update
by Ghanshyam Mann 20 Jan '21

20 Jan '21

Hello Everyone, Please find the week's R-16 updates on 'Migrate RBAC Policy Format from JSON to YAML' community-wide goals. Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… Progress: ======= * Projects completed: 5 * Projects left to merge the patches: 25 * Projects left to push the patches: 2 (horizon and Openstackansible) * Projects do not need any work: 17 Updates: ======= * I have pushed the patches for all the required service projects. ** Because of many services gate is already broken for lower constraints job, these patches might not be green in the test results. I request projects to fix the gate so that we can merge this goal work before m-2. ** There are many project tests where CONF object was not fully initialized before the policy is init. This was working till now as policy init did not use the CONF object but oslo_policy 3.6.0 onwards it needs fully initialized CONF object during init only. ** Aodh work for this goal is blocked because it needs oslo_policy 3.6.0 but gnocchi is capped for oslo_policy 3.4.0 [1] - https://review.opendev.org/c/openstack/aodh/+/768499 * Horizon and Openstackansible work is pending to use/deploy the YAML formatted policy file. I will start exploring this next week or so. [1] https://github.com/gnocchixyz/gnocchi/blob/e19fda590c7f7f07f1df0ba93177df07… Merry Christmas and Happy Holidays! -gmann

6 11

[cinder] wallaby new driver status
by Brian Rosmaita 20 Jan '21

20 Jan '21

At today's Cinder meeting [0] we discussed the unmerged proposed drivers (3 volume drivers, 1 backup driver) in light of tomorrow's new driver merge deadline. Here's a summary of what we decided: 1. s3 cinder backup driver https://review.opendev.org/c/openstack/cinder/+/746561 The code looks basically OK but the driver hasn't been independently tested. There's a proposed CI job but it currently isn't passing. ==> plan: aim for two +2s on the patch before the merge deadline, but hold off on merging until we have confirmation that the driver works, hopefully but the CI working by next week (Thursday 28 January). 2. TOYOU ACS5000 driver https://review.opendev.org/c/openstack/cinder/+/767290/ Code is looking good and they've been good about quickly revising patches. The CI is running and driver is passing tempest and cinder-tempest-plugin tests, though it's not reporting reliably on patches. They've agreed to get their CI responding properly by milestone-3. ==> plan: the requested revisions haven't been major, so this is looking good for tomorrow's deadline. We anticipate that the CI situation will be corrected by M-3. 3. Ceph iSCSI driver https://review.opendev.org/c/openstack/cinder/+/662829 Code is looking good but the CI isn't passing yet. ==> plan: this is an important community driver so we're extending the deadline two weeks to 5 February. 4. Kioxia Kumoscale driver (and brick changes) https://review.opendev.org/c/openstack/cinder/+/768574 https://review.opendev.org/c/openstack/os-brick/+/768575 https://review.opendev.org/c/openstack/os-brick/+/768576 Kioxia reports that their CI is up though it's not reporting yet. This is a large change and the cinder team review bandwidth has been low this cycle, but with the other drivers (mostly) done at this point, we should be able to get faster reviews on these. ==> plan: new driver merge extension to 8 Feb, that is, code merged and CI running and reporting by that date to be included in wallaby. cheers, brian [0] http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-01-20-14.00…

1 0

Requesting help with OpenStack configuration files
by Bessghaier, Narjes 20 Jan '21

20 Jan '21

Dear OpenStack team, I’m a Ph.D. student in software engineering at the ETS Montreal, University of Quebec working on the quality and configuration of web-based software systems. I’m particularly interested in analyzing configuration files from different OpenStack files. One of the main challenges I am currently facing is the proper identification of configuration files. I’m mostly confused between the python files used for production and the python files used for configuration. I am kindly requesting your precious help with the following questions: 1- How to distinguish between python files used for configuration and python files used for production? It will be very helpful if there are some configuration-based patterns (eg, textual patterns or expressions) that we can find in python files to help us distinguish between source code and configuration files? 2- Certain python files use the oslo_config to access and define configuration options. Could "all" these python files be considered as configuration files? For example, the following python file of the keystone project: keystone/keystone/conf/auth.py, is it considered a source code or configuration file? 3- Why are there different source code and configuration repositories for OpenStack projects (eg, nova and puppet-nova)? For instance, does the OpenStack-nova service have some configuration files in its repository and have the puppet-nova as a separate configuration repository as well? Thank you very much in advance for your time and your help! Kind regards, Narjes Bessghaier Narjes Bessghaier Ph.D student in Software Engineering École de Technologie Supérieure (ETS)| University of Quebec Montreal, Canada narjes.bessghaier.1(a)ens.etsmtl.ca<mailto:yasmine.makroum.1@ens.etsmtl.ca>

3 4

[masakari] Masakari Team Meeting - the schedule
by Radosław Piliszek 20 Jan '21

20 Jan '21

Hello, Folks! I have realised the Masakari Team Meeting is to run on even weeks [1]. However, anyone who created the meeting record in their calendar (including me) has likely gotten the meeting schedule in odd weeks this year (because last year finished with an odd week and obviously numbering also starts on odd: the 1). So I have run the first meeting this year the previous week but someone came for the meeting this week. :-) According to the "new wrong" schedule, the next meeting would be on Jan 19, but according to the "proper" one it would be on Jan 26. I am available both weeks the same so can run either term (or both as well, why not). The question is whether we don't want to simply move to the weekly meeting schedule. We usually don't have much to discuss but it might be less confusing and a better way to form a habit if we met every week. Please let me know your thoughts. [1] http://eavesdrop.openstack.org/#Masakari_Team_Meeting -yoctozepto

2 2

[nova] Selecting PCI devices by their addresses
by Mauricio Tavares 20 Jan '21

20 Jan '21

Stupid question of the day: if I am not mistaken, I can ask nova[1] which pci/pcie devices it knows and where they are. And it will reply with the PCI address for each device it knows of. But, when I want to create flavours so I can create (libvirt-based) instances using them, I cannot tie an alias to a specific pci address; all I can do is say "this pci_alias is for all the pci devices with this vendor_id and product_id that I whitelisted already"[2]. Since libvirt allows me to feed a vm guest the exact pci device I want, could anyone point out which obvious step I am missing here? [1] https://wiki.openstack.org/wiki/Pci-api-support [2] https://docs.openstack.org/nova/latest/admin/pci-passthrough.html#configure…

2 1