- openstack-discuss - lists.openstack.org

[ptl] Wallaby Release Community Meeting
by helena＠openstack.org 14 Apr '21

14 Apr '21

12 25

[cinder] Bug deputy report for week of 2021-04-14
by Sofia Enriquez 14 Apr '21

14 Apr '21

Hello, This is a bug report from 2021-04-07 to 2021-04-14. You're welcome to join the next Cinder Bug Meeting later today. Weekly on Wednesday at 1500 UTC in #openstack-cinder Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Critical:- High: - Medium: - https://bugs.launchpad.net/cinder/+bug/1922920 "Incorrect volume usage notifications on migration". Assigned to Gorka Eguileo. - https://bugs.launchpad.net/cinder/+bug/1923830 "Backup of in-use volume using temp snapshot messes up quota usage". Assigned to Gorka Eguileo. - https://bugs.launchpad.net/cinder/+bug/1923829 " Backup of in-use volume using temp snapshot messes up quota usage". Assigned to Gorka Eguileo. - https://bugs.launchpad.net/cinder/+bug/1923828 " Snapshot quota usage sync counts temporary snapshots". Assigned to Gorka Eguileo. Low:- Undecided: - https://bugs.launchpad.net/cinder/+bug/1922939 "Volume backup deletion leaves orphaned files on object storage". Unassigned Regards, Sofi -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @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>

1 0

Openstack External Network connectivity assistance
by Chris Lyons 14 Apr '21

14 Apr '21

All, I am working on getting a private Openstack cloud set up to support a project I am planning. I have the install complete and do not get any errors and I can connect to hosted VM’s but the VM’s cannot connect to the internet. I have checked OVS logs and it looks like packets are being dropped. I have 2 network nodes and 1 compute node. All are using centos 8. The nodes have 3 NIC’s; NIC 1 is for the internal network and has no connectivity outside of the Openstack cluster; NIC’s 2 & 3 have external & internet connectivity (behind another router/firewall). The br-int,br-ex,and br-tun exist on all nodes. Here is where I think I see packets being dropped: [root@compute01 ~]# docker exec openvswitch_vswitchd ovs-dpctl show -s system@ovs-system: lookups: hit:38597645 missed:256444 lost:0 flows: 38 masks: hit:40505463 total:5 hit/pkt:1.04 port 0: ovs-system (internal) RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 aborted:0 carrier:0 collisions:0 RX bytes:0 TX bytes:0 port 1: br-ex (internal) RX packets:0 errors:0 dropped:566073 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 aborted:0 carrier:0 collisions:0 RX bytes:0 TX bytes:0 port 2: eth2 RX packets:60413543 errors:0 dropped:384 overruns:0 frame:0 TX packets:11059 errors:0 dropped:0 aborted:0 carrier:0 collisions:0 RX bytes:43092601338 (40.1 GiB) TX bytes:1099133 (1.0 MiB) port 3: br-int (internal) RX packets:0 errors:0 dropped:539653 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 aborted:0 carrier:0 collisions:0 RX bytes:0 TX bytes:0 port 4: br-tun (internal) RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 aborted:0 carrier:0 collisions:0 RX bytes:0 TX bytes:0 port 5: qr-317618cc-cc (internal) RX packets:14050 errors:0 dropped:0 overruns:0 frame:0 TX packets:4164 errors:0 dropped:0 aborted:0 carrier:0 collisions:0 RX bytes:900953 (879.8 KiB) TX bytes:318526 (311.1 KiB) port 6: vxlan_sys_4789 (vxlan: packet_type=ptap) RX packets:0 errors:? dropped:? overruns:? frame:? TX packets:0 errors:? dropped:? aborted:? carrier:? collisions:? RX bytes:0 TX bytes:0 port 7: qvoa777fa8d-fb RX packets:3259 errors:0 dropped:0 overruns:0 frame:0 TX packets:13643 errors:0 dropped:0 aborted:0 carrier:0 collisions:0 RX bytes:193660 (189.1 KiB) TX bytes:1126219 (1.1 MiB) port 8: fg-cbe0bbae-e9 (internal) RX packets:518682 errors:0 dropped:24 overruns:0 frame:0 TX packets:4386 errors:0 dropped:0 aborted:0 carrier:0 collisions:0 RX bytes:145164850 (138.4 MiB) TX bytes:328630 (320.9 KiB) port 9: qvo83a439a5-52 RX packets:2642 errors:0 dropped:0 overruns:0 frame:0 TX packets:9553 errors:0 dropped:0 aborted:0 carrier:0 collisions:0 RX bytes:308479 (301.2 KiB) TX bytes:718738 (701.9 KiB) port 10: qvo5fe2d158-f0 …. I would appreciate any ideas or assistance. Id be willing to pay for help as well. Horizon console is at https://app-external.lyonsgroup.family user: support pwd: default

2 1

[all][elections][tc] TC Vacancy Special Election voting ends soon
by Jeremy Stanley 14 Apr '21

14 Apr '21

We are coming down to the last hours for voting in the TC Vacancy special election. Voting ends Apr 15, 2021 23:45 UTC. Search your gerrit preferred email address[0] for the following subject: Poll: April 2021 Special Technical Committee Election That is your ballot and links you to the voting application. Please vote. If you have voted, please encourage your colleagues to vote. Candidate statements are linked to the names of all confirmed candidates: https://governance.openstack.org/election/#xena-tc-candidates What to do if you don't see the email and have a commit in at least one of the official project teams' deliverable repositories[1]: * check the trash of your gerrit Preferred Email address[0], in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from an official deliverable repo[1] and email the election officials[2]. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Please vote! Thank you, [0] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent. [1] https://opendev.org/openstack/governance/src/commit/892c4f3a851428cf41bab57… [2] https://governance.openstack.org/election/#election-officials -- Jeremy Stanley on behalf of the OpenStack Technical Elections Officials

1 0

[glance] Xena PTG schedule
by Abhishek Kekane 14 Apr '21

14 Apr '21

Hello All, Greetings!!! Xena PTG is around the corner and if you haven't already registered, please do so as soon as possible [1]. I have created a Virtual PTG planning etherpad [2] and also added day wise topics along with timings we are going to discuss. Kindly let me know if you have any concerns with allotted time slots. We also have some slots open on Tuesday, Thursday and Friday for unplanned discussions. So please feel free to add your topics if you still haven't added yet. As a reminder, these are the time slots for our discussion. Tuesday 20 April 2021 1400 UTC to 1700 UTC Wednesday 21 April 2021 1400 UTC to 1700 UTC Thursday 22 April 2021 1400 UTC to 1700 UTC Friday 23 April 2021 1400 UTC to 1700 UTC We will be using bluejeans for our discussion, kindly try to use it once before the actual discussion. The meeting URL is mentioned in etherpad [2] and will be the same throughout the PTG. [1] https://april2021-ptg.eventbrite.com/ [2] https://etherpad.opendev.org/p/xena-glance-ptg Thank you, Abhishek

1 0

[tripleo][ci] long queues, ceph / scenario001 issue
by Wesley Hayutin 14 Apr '21

14 Apr '21

Greetings, FYI.. https://bugs.launchpad.net/tripleo/+bug/1923529 The ceph folks and CI are working together to successfully transition ceph from octopus to pacific. At the moment any scenario001 job will fail. To ease the transition, we're proposing [1] Please note: If you have a change in the gate that triggers scenario001 I will be rebasing or adding a depends-on w/ [1] to ensure the gate is not reset multiple times today. The gate queue will probably peak well over 26hr today.. so please lay off the workflows a bit. Your patience is appreciated! [1] https://review.opendev.org/c/openstack/tripleo-common/+/786053

2 1

[cinder] Requesting reviews for mTLS support in client
by Jay Faulkner 14 Apr '21

14 Apr '21

Hi all, A few of us here at Verizon Media have been working to ensure all services can support authenticating with mTLS certificate and key. We've had success with this, and if you've reviewed patches related to this, thank you! There's still an outstanding patch for python-cinderclient that has not gotten attention. It has +1s from contributors across the community, but hasn't gotten any core review attention. It's a trivial change, adding support for mTLS certificate passing for server version requests. The bug is here: https://bugs.launchpad.net/python-cinderclient/+bug/1915996 and the code is here: https://review.opendev.org/c/openstack/python-cinderclient/+/776311. If there are any concerns about this change, please let us know on the gerrit change itself, or feel free to reach out to me on IRC (JayF in #openstack-ironic, among many others). We have been successfully running this code downstream for a while, and hope to share the added mTLS love with the rest of the community. Thanks, Jay Faulkner

1 0

[qa][heat][stable] grenade jobs with tempest plugins on stable/train broken
by Ghanshyam Mann 14 Apr '21

14 Apr '21

Hello Everyone, I capped stable/stein to use the Tempest 26.0.0 which means grenade jobs that run the tests from tempest plugins started using the Tempest 26.0.0. But the constraints used in Tempest virtual env are mismatched between when Tempest virtual env was created and when tests are run from grenade or grenade plugins scripts. Due to these two different constraint used, tox recreate the tempest virtual env which remove all already installed tempest plugins and their deps and it fails to run the smoke tests. This constraints mismatch issue occurred in stable/train and I standardized these for devstack based jobs - https://review.opendev.org/q/topic:%2522standardize-tempest-tox-constraints… But this issue is occurring for grenade jobs that do not run the tests via run-tempest role (run-tempest role take care of constraints things). Rabi observed this in threat grenade jobs today. I have reported this as a bug in LP[1] and making it standardize from the master branch so that this kind of issue does not occur again when any stable branch starts using the non-master Tempest. Please don't recheck if your grenade job is failing with the same issue and wait for the updates on this ML thread. [1] https://bugs.launchpad.net/grenade/+bug/1922597 -gmann

1 1

[infra][cinder][neutron][qa] neutron-grenade failures on stable/train
by Brian Rosmaita 13 Apr '21

13 Apr '21

The neutron-grenade job on stable/train has been mostly failing since 8 April: https://zuul.opendev.org/t/openstack/builds?job_name=neutron-grenade&branch… I spot-checked a few and it looks like the culprit is "Could not open requirements file: [Errno 2] No such file or directory: '/opt/stack/requirements/upper-constraints.txt'". See: - https://zuul.opendev.org/t/openstack/build/421f7d57bc234119963edf3e9101ca43… - https://zuul.opendev.org/t/openstack/build/915395d34fa34e99a6ec544ad1d3141b… - https://zuul.opendev.org/t/openstack/build/9eaacc244047408d9e2d9ed09529ff3f… The last 2 neutron-grenade jobs on openstack/devstack have passed, but there don't look to have been any changes in the devstack repo stable/train since 10 March, so I'm not sure if that was luck or if the QA team has made a change to get the job working. Any ideas? thanks, brian

3 3

Diversity and Inclusion Social Hour Sponsored by RDO at the PTG
by Amy Marrich 13 Apr '21

13 Apr '21

On behalf of the RDO Community, please join us for an hour of Trivia on Thursday April 22 at 17:00 UTC. We will have trivia related to OpenStack and the other OIF projects as well as the cities we've held events. Time permitting we'll have some Pop Culture trivia as well. Prizes for the first 3 placings and registration is Free! https://eventyay.com/e/5f05de57 Amy (spotz)

1 0

[edge][ptg] Edge WG sessions at the PTG
by Ildiko Vancsa 13 Apr '21

13 Apr '21

Hi, I’m reaching out to you to draw your attention to the Edge Computing Group’s agenda for the PTG next week. We are having a couple of cross-project and cross-community discussions next week as well as discussing topics around use cases and reference architectures which can be a good input for most OpenStack project teams as well. Our agenda is the following: * Monday (April 19) * 1400 UTC - Intro and Agenda bashing * 1415 UTC - Use cases * 1500 UTC - ETSI MEC cross-community session * Tuesday (April 20) * 1400 UTC - Storage discussion * 1430 UTC - Applications and underlying network transport * 1500 UTC - Reference architectures * Wednesday * 1300 UTC - StarlingX cross-project session * 1400 UTC - Akraino cross-community session * 1500 UTC - GSMA cross-community session For more detailed information about the above topics please see our etherpad: https://etherpad.opendev.org/p/ecg-ptg-april-2021 Please let me know if you have additional topics for the sessions next week or if you have questions to the items on the agenda. Thanks and Best Regards, Ildikó (IRC: ildikov on Freenode)

1 0

[tact-sig][dev][infra][qa] Join OpenDev and the TaCT SIG at the PTG
by Clark Boylan 13 Apr '21

13 Apr '21

The PTG is next week, and OpenDev is participating alongside the OpenStack TaCT SIG. We are going to try something a bit different this time around, which is to treat the time as office hours rather than time for our own projects. We will be meeting on April 22 from 14:00 - 16:00 UTC and 22:00 - 00:00 UTC in https://meetpad.opendev.org/apr2021-ptg-opendev. Join us if you would like to: * Start contributing to either OpenDev or the TaCT sig. * Debug a particular job problem. * Learn how to write and review Zuul jobs and related configs. * Learn about specific services or how they are deployed. * And anything else related to OpenDev and our project infrastructure. Feel free to add your topics and suggest preferred times for those topics here: https://etherpad.opendev.org/p/apr2021-ptg-opendev. This etherpad corresponds to the document that will be auto loaded in our meetpad room above. I will also be around next week and will try to keep a flexible schedule. Feel free to reach out if you would like us to join discussions as they happen. See you there, Clark

1 0

Join Us Live for the Wallaby Release Community Meeting
by helena＠openstack.org 13 Apr '21

13 Apr '21

The Wallaby release is here (whoop! whoop!) and the Community Meeting for it will be hosted by Technical Committee members, Ghanshyam Mann and Kendall Nelson, this Thursday, April 15th at 14:00 UTC (9:00 AM CST). The meeting will be a live session via Zoom [1] as well as live-streamed to YouTube [2]. The meeting will be kicked off with some exciting news from the OpenInfra Foundation and will be followed by updates from PTLs. The Community Meeting agenda is as follows: Wallaby Overview - Ghanshyam Mann & Kendall Nelson Cinder Update - Brian Rosmaita Neutron Update - Slawek Kaplonski Ironic Update - Julia Kreger Nova Update - Balazs Gibizer Cyborg Update - Xin-Ran Wang Masakari Update - Radosław Piliszek Manila Update - Goutham Pacha Ravi Live Q&A session - Ghanshyam Mann & Kendall Nelson PTLs that are presenting: Please make sure your slides are turned in to me EOD (Tuesday, April 13th). Let me know if you have any other questions. Cheers, Helena [1] [ https://zoom.us/j/94881181840?pwd=cmc2Wk1wYlcwNnVOTk9lYWQxVlRadz09 ]( https://zoom.us/j/94881181840?pwd=cmc2Wk1wYlcwNnVOTk9lYWQxVlRadz09 ) [2] [ https://www.youtube.com/channel/UCQ74G2gKXdpwZkXEsclzcrA ]( https://www.youtube.com/channel/UCQ74G2gKXdpwZkXEsclzcrA )

1 0

[PTG] vPTG April 2021 PTGBot, Etherpads, & IRC
by Kendall Nelson 13 Apr '21

13 Apr '21

Hello! We just wanted to take a second to point out a couple things as we all get ready for the PTG. Firstly, the PTGBot is up to date and ready to go-- as are the autogenerated etherpads! You can see the schedule page, etherpads, etc here[1]. If you/your team have already created an etherpad, please feel free to use the PTGBot[2] to override the default, auto-generated one. Secondly, but perhaps more importantly, with the migration to being more inclusive of projects outside of just openstack, we will be using the #openinfra-events IRC channel! The redirect is in place so you should automatically get sent to the right channel if you try to join the old one. And one more plug: Please register! Its free and important for getting the zoom information, etc. Thanks! -The Kendalls (diablo_rojo & wendallkaters) [1] PTG Website www.openstack.org/ptg [2] PTGbot Etherpad Override Command: https://github.com/openstack/ptgbot#etherpad [3] PTG Registration: https://april2021-ptg.eventbrite.com

1 0

[openstack-ansible] OSA Meeting Poll
by Dmitriy Rabotyagov 13 Apr '21

13 Apr '21

Hi! We haven't changed OSA meeting time for a while and stick with the current option (Tuesday, 16:00 UTC) for a while. So we decided it's time to make a poll regarding preferred time for OSA meetings since list of the interested parties and circumstances might have changed since picking meeting time. You can find the poll via link [1]. Poll is open till Monday, April 12 2021. Please, make sure you vote before this time. [1] https://doodle.com/poll/m554dx4mrsideuzi/ -- Kind Regards, Dmitriy Rabotyagov

1 3

[OSSN-0089] Missing configuration option in Secure Live Migration guide leads to unencrypted traffic
by Josephine Seifert 13 Apr '21

13 Apr '21

Missing configuration option in Secure Live Migration guide leads to unencrypted traffic -------------------------------------------------------------------------------------------------------------------- ### Summary ### The guide to enable secure live migration with QEMU-native tls on nova compute nodes missed an important config option. Without this option a hard-coded part in nova is triggerd which sets the default route to TCP instead of TLS. This leads to an unecrypted migration of the ram without throwing any kind of Error. ### Affected Services / Software ### Nova / Victoria, Ussuri, Train, Stein (might also be affected: Rocky, Queens, Pike, Ocata) ### Discussion ### In the OpenStack guide to setup secure live migration with QEMU-native tls there are a few configuration options given, which have to be applied to nova compute nodes. After following the instructions and setting up everything it seems to work as expected. But after checking that libvirt is able to use tls using tcpdump to listen on the port for tls while manually executing libvirt commands, the same check for live migration of an instance through openstack fails. Listening on the port for unencrypted tcp-traffic shows that OpenStack still uses the unencrypted TCP path instead of the TLS one for the migration. The reason for this is a patch from Ocata which adds the calculation of the live-migration-uri in code: https://review.opendev.org/c/openstack/nova/+/410817/ The config parameter ``live_migration_uri`` was deprecated in favor of ``live_migration_scheme`` and the default set to tcp. This leads to the problem that if none of these two config options are set, libvirt will always use the default tcp connection. To enable QEMU-native TLS to be used in nova one of them has to be set so that a TLS connection can be established. Currently the guide does not show that this is necessary and there was no other documentation indicating that these config options are important for the usage of QEMU-native TLS. As there is no documentation which recognizes this and it is hard to find this problem as the migration happens even without those config option set - not stating that it is still unencrypted, it might have been unrecognized in various deployments, which followed the guide. ### Recommended Actions ### For deployments using secure live migration with QEMU-native TLS: 1. Check the config of all nova compute nodes. The ``libvirt`` section needs to have either ``live_migration_uri`` (deprecated) or ``live_migration_scheme`` configured. 2. If neither of those config options are present, add ``live_migration_scheme = tls`` to enable the use of the tls connection. #### Patches #### The guide for secure live migration was updated to reflect the necessary configuration options and now has a note, which warns users that not setting all config options may lead into a seemingly working deployment, which still uses unencrypted traffic for the ram-migration. Master(Wallaby): https://review.opendev.org/c/openstack/nova/+/781030 Victoria: https://review.opendev.org/c/openstack/nova/+/781211 Ussuri: https://review.opendev.org/c/openstack/nova/+/782126 Train: https://review.opendev.org/c/openstack/nova/+/782430 Stein: https://review.opendev.org/c/openstack/nova/+/783199 ### Contacts / References ### Author: Josephine Seifert, secustack GmbH This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0089 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1919357 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg

1 0

[ironic] Meetings next week (19-23 April)
by Iury Gregory 13 Apr '21

13 Apr '21

Hello ironicers, Since next week is the PTG, we decided during our upstream meeting today to skip the following meetings: - Upstream Meeting (Monday) - Review Jams (Monday/Tuesday) - SPUC in the APAC time (Friday) because it overlaps with the PTG. Thank you =) -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

2 1

[ceilometer][octavia][Victoria] No metrics from octavia loadbalancer
by Adam Tomas 13 Apr '21

13 Apr '21

Hi, Im trying to get metrics from octavia’s load balancer, but can’t get any (gnocchi metric list | grep loadbalancer not returning anything). How should I configure ceilometer to get metrics from octavia? Ceilometer asks neutron for load balancer metrics, and neutron responses „resource cannot be found” (and that is obvious, because Neutron LBaaS service is deprecated). How to force neutron to get these resources from Octavia? I’ve tried to use [service_providers] service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default in neutron.conf, but it doesn’t work either… Best regards Adam

2 4

[tacker] irc meeting
by Yasufumi Ogawa 13 Apr '21

13 Apr '21

Hi team, I'll be off today's irc meeting, so please skip, or someone host the meeting if any topic. Thanks, Yasufumi

1 0

[Manila][Interop] request for 15-30 min on Xena PTG for Interop
by Kanevsky, Arkady 13 Apr '21

13 Apr '21

Goutham, As chair of OpenStack Interop WG, Interop/Refstack would like 15-30 min on PTG meeting to go over Interop testing and any changes for Manila tempest or tempest configuration in Wallaby cycle or changes planned for Xena. Once on agenda one of the Interop WG person will attend and lead the discussion. Thanks, Arkady Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

2 1

[ironic] No Review Jam Tomorrow
by Iury Gregory 12 Apr '21

12 Apr '21

Hello ironicers! During the upstream meeting today we decided to skip the Review Jam that will happen tomorrow, since we don't have any topics that would require attention. We also skipped the review jam from today (we totally forgot about it). -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

[oslo][security-sig] Please revisit your open vulnerability report
by Jeremy Stanley 12 Apr '21

12 Apr '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following report: keystonemiddleware connections to memcached from neutron-server grow beyond configured values https://launchpad.net/bugs/1883659 Can it be exploited by a nefarious actor, and if so, how? Is it likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

2 6

[ops][cinder][nova] os-brick upcoming releases
by Brian Rosmaita 12 Apr '21

12 Apr '21

Hello operators, You may have heard about a potential data-loss bug [0] that was recently discovered. It has been fixed in the upcoming wallaby release and we are planning to backport to all stable branches and do new os-brick releases from the releasable stable branches. In the meantime, the bug occurs if the multipath configuration option on a compute is changed while volumes are attached to instances on that compute. The possible data loss may occur when the volumes are detached (migration, volume-detach, etc.). Thus, before the new os-brick releases are available, the issue can nonetheless be averted by not making such a configuration change under those circumstances. The new os-brick releases will be: - victoria: 4.0.3 - ussuri: 3.0.6 - train: 2.10.6 The stein, rocky, and queens branches are in Extended Maintenance mode and are no longer released from, but critical fixes are backported to them when possible, though it may take a while before these are merged. [0] https://launchpad.net/bugs/1921381

1 1

[sdk]: compute service create_server method, how to create multiple servers
by dmeng 12 Apr '21

12 Apr '21

Hello there, Hope this email finds you well. We are currently using the openstacksdk for developing our product, and have a question about the openstacksdk compute service create_server() method. We are wondering if the "max_count" attribute is supported by the create_server() method? We tried to create multiple servers by setting the max_count value, but only one server has been created. While when we use the python-novaclient package, novaclient.servers.create() method has the attribute max_count which allows creating multiple servers at once if set the value. So we would like to know is there a similar attribute like "max_count" that could allow us to create multiple servers at once in openstacksdk? Thanks and have a great day! Catherine

3 2

Re: [glance][openstack-ansible] Snapshots disappear during saving
by Oliver Wenz 12 Apr '21

12 Apr '21

Hi Dmitriy, I checked nginx logs on the keystone container and there was no obvious error: ontainer-6f64e2e1 nginx: 192.168.110.211 - - [12/Apr/2021:13:25:56 +0000] "HEAD / HTTP/1.0" 300 0 "-" "osa-haproxy-healthcheck" Apr 12 13:26:07 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:07 +0000] "POST /v3/auth/tokens HTTP/1.1" 201 316 "-" "openstack_auth keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.8.5" Apr 12 13:26:07 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:07 +0000] "POST /v3/auth/tokens HTTP/1.1" 401 109 "-" "openstack_auth keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.8.5" Apr 12 13:26:07 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:07 +0000] "GET /v3/users/e4e88b0e800e4a79905a586738c32bf1/projects HTTP/1.1" 200 768 "-" "python-keystoneclient" Apr 12 13:26:08 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:08 +0000] "POST /v3/auth/tokens HTTP/1.1" 201 6779 "-" "openstack_auth keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.8.5" Apr 12 13:26:08 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:08 +0000] "GET / HTTP/1.1" 300 270 "-" "python-novaclient keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.8.5" Apr 12 13:26:08 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:08 +0000] "POST /v3/auth/tokens HTTP/1.1" 201 6779 "-" "python-novaclient keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.8.5" Apr 12 13:26:08 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:08 +0000] "GET / HTTP/1.1" 300 270 "-" "python-novaclient keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.8.5" Apr 12 13:26:08 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:08 +0000] "POST /v3/auth/tokens HTTP/1.1" 201 6779 "-" "python-novaclient keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.8.5" Apr 12 13:26:08 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.211 - - [12/Apr/2021:13:26:08 +0000] "HEAD / HTTP/1.0" 300 0 "-" "osa-haproxy-healthcheck" Apr 12 13:26:08 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.100 - - [12/Apr/2021:13:26:08 +0000] "GET /v3/auth/tokens HTTP/1.1" 200 6779 "-" "python-keystoneclient" Apr 12 13:26:18 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.28 - - [12/Apr/2021:13:26:18 +0000] "GET /v3/auth/tokens HTTP/1.1" 200 6779 "-" "python-keystoneclient" Apr 12 13:26:18 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.100 - - [12/Apr/2021:13:26:18 +0000] "GET /v3/auth/tokens HTTP/1.1" 200 6779 "-" "python-keystoneclient" Apr 12 13:26:19 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:19 +0000] "GET /v3/users/e4e88b0e800e4a79905a586738c32bf1/projects HTTP/1.1" 200 768 "-" "python-keystoneclient" Apr 12 13:26:20 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:20 +0000] "GET /v3 HTTP/1.1" 200 255 "-" "openstack_dashboard keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.8.5" Apr 12 13:26:20 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.211 - - [12/Apr/2021:13:26:20 +0000] "HEAD / HTTP/1.0" 300 0 "-" "osa-haproxy-healthcheck" Apr 12 13:26:21 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:21 +0000] "GET /v3/users/e4e88b0e800e4a79905a586738c32bf1/projects HTTP/1.1" 200 768 "-" "python-keystoneclient" Apr 12 13:26:24 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:24 +0000] "GET / HTTP/1.1" 300 270 "-" "python-novaclient keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.8.5" Apr 12 13:26:24 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:24 +0000] "POST /v3/auth/tokens HTTP/1.1" 201 6779 "-" "python-novaclient keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.8.5" Apr 12 13:26:25 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.100 - - [12/Apr/2021:13:26:25 +0000] "GET /v3/auth/tokens HTTP/1.1" 200 6779 "-" "python-keystoneclient" Apr 12 13:26:27 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:27 +0000] "GET / HTTP/1.1" 300 270 "-" "python-novaclient keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.8.5" Apr 12 13:26:28 infra1-keystone-container-6f64e2e1 nginx[13641]: infra1-keystone-container-6f64e2e1 nginx: 192.168.110.250 - - [12/Apr/2021:13:26:28 +0000] "POST /v3/auth/tokens HTTP/1.1" 201 6779 "-" "python-novaclient keystoneauth1/4.2.1 python-requests/2.23.0 CPython/3.8.5" I also noticed, that glance logs show the keystone_authtoken message even when I successfully create a snapshot (e.g. for a cirros instance). So could this be a nova problem afterall? I'm confused why there's a NotImplementedError in the nova logs: http://paste.openstack.org/show/804398/ Kind regards, Oliver > ------------------------------ > > Message: 2 > Date: Fri, 09 Apr 2021 08:24:53 +0300 > From: Dmitriy Rabotyagov <noonedeadpunk(a)ya.ru> > To: "openstack-discuss(a)lists.openstack.org" > <openstack-discuss(a)lists.openstack.org> > Subject: Re: [glance][openstack-ansible] Snapshots disappear during > saving > Message-ID: <500221617945664(a)mail.yandex.ru> > Content-Type: text/plain; charset="utf-8" > > An HTML attachment was scrubbed... > URL: > <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210409…> >

1 0

MAAS dhcpd issue
by toky0 12 Apr '21

12 Apr '21

Hi, Just started a maas+juju deployment on bare metal. I’m facing some errors while PXE booting[1]. Any leads ? Regards, Sami [1] Mar 22 09:57:13 maas kernel: [ 1885.666813] audit: type=1400 audit(1616407033.279:95): apparmor="DENIED" operation="open" profile="snap.maas.supervisor" name="/etc/gss/mech.d/" pid=1131 comm="python3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Mar 22 09:57:22 maas dhcpd[3861]: DHCPDISCOVER from 4c:52:62:44:0c:bb via eno1: network vlan-5002: no free leases Mar 22 09:57:37 maas systemd[1]: systemd-timedated.service: Succeeded. Mar 22 09:57:43 maas kernel: [ 1915.677372] audit: type=1400 audit(1616407063.291:96): apparmor="DENIED" operation="open" profile="snap.maas.supervisor" name="/etc/gss/mech.d/" pid=1132 comm="python3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Mar 22 09:58:13 maas dhcpd[3861]: DHCPDISCOVER from 4c:52:62:44:13:f3 via eno1 Mar 22 09:58:13 maas dhcpd[3861]: DHCPOFFER on 192.168.202.10 to 4c:52:62:44:13:f3 via eno1 Mar 22 09:58:15 maas dhcpd[3861]: DHCPDISCOVER from 4c:52:62:44:13:f3 via eno1 Mar 22 09:58:15 maas dhcpd[3861]: DHCPOFFER on 192.168.202.10 to 4c:52:62:44:13:f3 via eno1 Mar 22 09:58:17 maas dhcpd[3861]: DHCPDISCOVER from 4c:52:62:44:13:f3 via eno1 Mar 22 09:58:17 maas dhcpd[3861]: DHCPOFFER on 192.168.202.10 to 4c:52:62:44:13:f3 via eno1 Mar 22 09:58:21 maas dhcpd[3861]: DHCPDISCOVER from 4c:52:62:44:13:f3 via eno1 Mar 22 09:58:21 maas dhcpd[3861]: DHCPOFFER on 192.168.202.10 to 4c:52:62:44:13:f3 via eno1 Mar 22 09:59:13 maas kernel: [ 2005.666324] audit: type=1400 audit(1616407153.280:97): apparmor="DENIED" operation="open" profile="snap.maas.supervisor" name="/etc/gss/mech.d/" pid=1134 comm="python3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Mar 22 09:59:43 maas kernel: [ 2035.667450] audit: type=1400 audit(1616407183.280:98): apparmor="DENIED" operation="open" profile="snap.maas.supervisor" name="/etc/gss/mech.d/" pid=1134 comm="python3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

3 2

[edge][cinder][manila][swift][tripleo] Storage at the edge discussions at the PTG
by Ildiko Vancsa 12 Apr '21

12 Apr '21

Hi, I’m reaching out to draw your attention to the Edge Computing Group sessions on the PTG in less than two weeks. We are still formalizing our agenda, but we have storage identified as one of the topics that the working group would like to discuss. It would be great to have the session also as a continuation to earlier discussions that we had on previous PTGs with relevant OpenStack project contributors. We have a few cross-community sessions scheduled already, but we still have some flexibility in our agenda to schedule this topic so the most people who are interested in participating can join. Our available options are: * Monday (April 19) between 1400 UTC and 1500 UTC * Tuesday (April) between 1400 UTC and 1600 UTC __Please let me know if you or your project would like to participate and if you have a time slot difference from the above.__ Thanks and Best Regards, Ildikó (IRC ildikov on Freenode)

2 2

[neutron] bug deputy report Abril 5th to 11th
by Miguel Lavalle 12 Apr '21

12 Apr '21

Hi, Here is this week's bugs deputy report: Critical ====== https://bugs.launchpad.net/neutron/+bug/1922563 [UT] py38 CI job failing frequently with TIMED_OUT. In progress. Proposed patch https://review.opendev.org/c/openstack/neutron/+/784771 High ==== https://bugs.launchpad.net/neutron/+bug/1922684 Functional dhcp agent tests fails to spawn metadata proxy. In progress. Proposed fix https://review.opendev.org/c/openstack/neutron/+/784903 https://bugs.launchpad.net/neutron/+bug/1923198 custom kill scripts don't works after migration to privsep. In progress. Proposed fix https://review.opendev.org/c/openstack/neutron/+/785638 https://bugs.launchpad.net/neutron/+bug/1923201 neutron-centos-8-tripleo-standalone in periodic queue runs Neutron from Victroria release. In progress. Proposed fix https://review.opendev.org/c/openstack/neutron/+/785660 Medium ====== https://bugs.launchpad.net/neutron/+bug/1922653 [L3][Port forwarding] multiple floating_ip:port to same internal fixed_ip:port (N-to-1 rule support). Waiting for owner, although it seems Liu Yulong might work on it https://bugs.launchpad.net/neutron/+bug/1922824 [ovn] external port always be scheduled on a single gateway. Needs owner https://bugs.launchpad.net/neutron/+bug/1922892 "ebtables-nft" returns error 4 when a new chain is created. . Needs owner https://bugs.launchpad.net/neutron/+bug/1922919 [FT] BaseOVSTestCase retrieving the wrong min BW queue/qos. In progress. Proposed patch https://review.opendev.org/c/openstack/neutron/+/785158 https://bugs.launchpad.net/neutron/+bug/1922934 [OVN] LSP register race condition with two controllers. In progress. Owner ralonsoh https://bugs.launchpad.net/neutron/+bug/1922923 OVS port issue. Liu Yulong suggested a solution. Awaiting update from submitter https://bugs.launchpad.net/neutron/+bug/1923083 python 3.9 failures. Confirmed. haleyb suggested a work around, which submitter reported as successful. Seems haleyb will work on a fix https://bugs.launchpad.net/neutron/+bug/1923161 DHCP notification could be optimized. In progress. Proposed patch: https://review.opendev.org/c/openstack/neutron/+/785581 RFE === https://bugs.launchpad.net/neutron/+bug/1922716 [RFE] BFD for BGP Dynamic Routing

1 0

[release] Release countdown for week R-0 Apr 12 - Apr 16
by Herve Beraud 10 Apr '21

10 Apr '21

Development Focus ----------------- We will be releasing the coordinated OpenStack Wallaby release next week, on Wednesday, 14 April, 2021. Thanks to everyone involved in the Wallaby cycle! We are now in pre-release freeze, so no new deliverable will be created until final release, unless a release-critical regression is spotted. Otherwise, teams attending the virtual PTG should start to plan what they will be discussing there, by creating and filling team etherpads. You can access the list of PTG etherpads at: http://ptg.openstack.org/etherpads.html General Information ------------------- On release day, the release team will produce final versions of deliverables following the cycle-with-rc release model, by re-tagging the commit used for the last RC. A patch doing just that will be proposed. PTLs and release liaisons should watch for that final release patch from the release team. While not required, we would appreciate having an ack from each team before we approve it on the 14th, so that their approval is included in the metadata that goes onto the signed tag. Upcoming Deadlines & Dates -------------------------- Final Wallaby release: 14 April, 2021 Xena virtual PTG: 19 - 23 April, 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

[all][tc] What's happening in Technical Committee: summary 9th April, 21
by Ghanshyam Mann 09 Apr '21

09 Apr '21

Hello Everyone, Here is this week's summary of the Technical Committee activities. If you feel this email is lengthy and can take time to read, I tried to categorize the topic for an easy read and should not take more than 5 min of your time. 1. What we completed this week: ========================= Project updates: ------------------- ** Keystone is switched to DPL model[1]. ** Mistral is switched to DPL model[2]. ** Made devstack-plugin-(amqp1|kafka) branchless[3] ** Deprecated project/deliverables: 1. networking-midonet[4] 2. monasca-transform[5] 3. monasca-analytics[6] 4. monasca-ceilometer[7] 5. monasca-log-api[7] Other updates: ------------------ ** PTL assignment for Xena cycle leaderless projects: We have finished the leader assignments for the leaderless project for Xena cycle[8]. Total 8 projects were leaderless in Xena election. PTL assigned to 6 projects, and 2 projects (Keystone and Mistral) adopted DPL model. ** Radosław Piliszek(yoctozepto) is vice-chair of TC for Xena cycle. ** Prepared the Community newsletter: "OpenStack project news" for this month[9]. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-04-08-15.00.log.html * We will have next week's meeting on April 15th, Thursday 15:00 UTC. 3. Activities In progress: ================== Open Reviews ----------------- * No open reviews this week[10]. This is good progress by TC this week. Gate performance and heavy job configs ------------------------------------------------ * dansmith sent the progress on ML[11], and there is a good improvement on gate utilization. Thanks to dansmith for keep monitoring it and collecting the data. Election for one Vacant TC seat ------------------------------------- Voting is started for one open seat for TC and open until April 15, 2021 23:45 UTC. You might have got the email with the voting link; if not please read the instruction in the email from fungi[12]. PTG ----- TC is planning to meet in PTG for Thursday 2 hrs and Friday 4 hrs, details are in etherpad[13], feel free to add topic you would like to discuss with TC in PTG. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[13]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [14] 3. Office hours: The Technical Committee offers two office hours per week in #openstack-tc [15]: * Tuesday at 0100 UTC * Wednesday at 1500 UTC 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://review.opendev.org/c/openstack/governance/+/784102 [2] https://review.opendev.org/c/openstack/governance/+/782195 [3] https://review.opendev.org/c/openstack/governance/+/784544 [4 ]https://review.opendev.org/c/openstack/governance/+/783799 [5] https://review.opendev.org/c/openstack/governance/+/783624 [6] https://review.opendev.org/c/openstack/governance/+/783659 [7] https://review.opendev.org/c/openstack/governance/+/783657 [8] https://etherpad.opendev.org/p/xena-leaderless [9] https://etherpad.opendev.org/p/newsletter-openstack-news [10] https://review.opendev.org/q/project:openstack/governance+status:open [11] http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021534.ht… [12] http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021718.ht… [13] https://etherpad.opendev.org/p/tc-xena-ptg [14] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [15] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [16] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[kolla] PTG
by Mark Goddard 09 Apr '21

09 Apr '21

Hi, Just a reminder that it's the Kolla Xena PTG from 19th - 21st April. Anyone is welcome to attend, but please add your name to the Etherpad [1], and follow the instructions to sign up. If there is something you would like to discuss, please add it to the list of topics. Thanks, Mark [1] https://etherpad.opendev.org/p/kolla-xena-ptg

1 0

[kolla] PTL on holiday next week
by Mark Goddard 09 Apr '21

09 Apr '21

Hi, I'll be on holiday next week. Please keep in mind the current feature freeze and aim for stabilisation of the code and preparation for RC1 & branching. Let's aim to branch in the week beginning 19th April. Please also remember it's the PTG in the same week. Remember to add topics to the PTG Etherpad [1] as they come up in discussion or your thoughts. [1] https://etherpad.opendev.org/p/kolla-xena-ptg Thanks, Mark

1 0

[kolla] RHEL based container image
by Tony Liu 09 Apr '21

09 Apr '21

Hi, Given [1], RHEL based container is supported on RHEL 8 by Kolla. Where can I get RHEL based container images? I see CentOS and Ubuntu based images on docker hub, but can't find RHEL based images. [1] https://docs.openstack.org/kolla-ansible/ussuri/user/support-matrix.html Thanks! Tony

3 3

[TripleO] next irc meeting Tuesday Apr 13 @ 1400 UTC in #tripleo
by Marios Andreou 09 Apr '21

09 Apr '21

Reminder that the next TripleO irc meeting is: ** Tuesday 13 April 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 highlight at https://etherpad.opendev.org/p/tripleo-meeting-items This can be recently completed things, ongoing review requests, blocking issues, or anything else tripleo you want to share. Our last meeting was on Mar 30 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-03-30-14.… Hope you can make it on Tuesday, regards, marios

1 0

[dev][cinder][keystone] Properly consuming system-scope in cinder
by Lance Bragstad 09 Apr '21

09 Apr '21

Hey folks, As I'm sure some of the cinder folks are aware, I'm updating cinder policies to include support for some default personas keystone ships with. Some of those personas use system-scope (e.g., system-reader and system-admin) and I've already proposed a series of patches that describe what those changes look like from a policy perspective [0]. The question now is how we test those changes. To help guide that decision, I worked on three different testing approaches. The first was to continue testing policy using unit tests in cinder with mocked context objects. The second was to use DDT with keystonemiddleware mocked to remove a dependency on keystone. The third also used DDT, but included changes to update NoAuthMiddleware so that it wasn't as opinionated about authentication or authorization. I brought each approach in the cinder meeting this week where we discussed a fourth approach, doing everything in tempest. I summarized all of this in an etherpad [1] Up to yesterday morning, the only approach I hadn't tinkered with manually was tempest. I spent some time today figuring that out, resulting in a patch to cinderlib [2] to enable a protection test job, and cinder_tempest_plugin [3] that adds the plumbing and some example tests. In the process of implementing support for tempest testing, I noticed that service catalogs for system-scoped tokens don't contain cinder endpoints [4]. This is because the cinder endpoint contains endpoint templating in the URL [5], which keystone will substitute with the project ID of the token, if and only if the catalog is built for a project-scoped token. System and domain-scoped tokens do not have a reasonable project ID to use in this case, so the templating is skipped, resulting in a cinder service in the catalog without endpoints [6]. This cascades in the client, specifically tempest's volume client, because it can't find a suitable endpoint for request to the volume service [7]. Initially, my testing approaches were to provide examples for cinder developers to assess the viability of each approach before committing to a protection testing strategy. But, the tempest approach highlighted a larger issue for how we integrate system-scope support into cinder because of the assumption there will always be a project ID in the path (for the majority of the cinder API). I can think of two ways to approach the problem, but I'm hoping others have more. First, we remove project IDs from cinder's API path. This would be similar to how nova (and I assume other services) moved away from project-specific URLs (e.g., /v3/%{project_id}s/volumes would become /v3/volumes). This would obviously require refactoring to remove any assumptions cinder has about project IDs being supplied on the request path. But, this would force all authorization information to come from the context object. Once a deployer removes the endpoint URL templating, the endpoints will populate in the cinder entry of the service catalog. Brian's been helping me understand this and we're unsure if this is something we could even do with a microversion. I think nova did it moving from /v2/ to /v2.0/, which was technically classified as a major bump? This feels like a moon shot. Second, we update cinder's clients, including tempest, to put the project ID on the URL. After we update the clients to append the project ID for cinder endpoints, we should be able to remove the URL templating in keystone, allowing cinder endpoints to appear in system-scoped service catalogs (just like the first approach). Clients can use the base URL from the catalog and append the admin project ID before putting the request on the wire. Even though the request has a project ID in the path, cinder would ignore it for system-specific APIs. This is already true for users with an admin role on a project because cinder will allow you to get volumes in one project if you have a token scoped to another with the admin role [8]. One potential side-effect is that cinder clients would need *a* project ID to build a request, potentially requiring another roundtrip to keystone. Thoughts? [0] https://review.opendev.org/q/project:openstack/cinder+topic:secure-rbac [1] https://etherpad.opendev.org/p/cinder-secure-rbac-protection-testing [2] https://review.opendev.org/c/openstack/cinderlib/+/772770 [3] https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/772915 [4] http://paste.openstack.org/show/802117/ [5] http://paste.openstack.org/show/802097/ [6] https://opendev.org/openstack/keystone/src/commit/c239cc66615b41a0c09e031b3… [7] http://paste.openstack.org/show/802092/ [8] http://paste.openstack.org/show/802118/

4 8

[Interop][Refstack] this Friday meeting
by Kanevsky, Arkady 09 Apr '21

09 Apr '21

Team, This Friday is Good Friday and some people have a day off. Should we cancel this week meeting? Please, respond so we can see if we will have quorum. Thanks, Arkady Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

5 6

[neutron][all] Tempest jobs running on rocky and queens branches are broken
by Slawek Kaplonski 09 Apr '21

09 Apr '21

Hi, I noticed it mostly in the neutron jobs but it seems that it's true also for other projects for jobs which still runs on Ubuntu 16.04. I Neutron case those are all jobs on stable/rocky and stable/queens branches. Due to [1] those jobs will end up with POST_FAILURE. So please don't recheck Your patches if You have such errors until that bug will be fixed. I think that gmann has or is working on fix for that. [1] https://bugs.launchpad.net/devstack/+bug/1923042 -- Slawek Kaplonski Principal Software Engineer Red Hat

2 1

Re: [Release-job-failures] Release of openstack/eslint-config-openstack for ref refs/tags/4.1.0 failed
by Herve Beraud 09 Apr '21

09 Apr '21

FYI Looks similar to that story: - http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021002.ht… - http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021217.ht… I proposed a patch to move to nodejs10 all our projects that depend on nodejs: https://review.opendev.org/c/openstack/project-config/+/785353 When this patch will be merged I think that this job could be reenqueued. Le jeu. 8 avr. 2021 à 11:10, <zuul(a)openstack.org> a écrit : > Build failed. > > - release-openstack-javascript > https://zuul.opendev.org/t/openstack/build/4062ea0df4e74565b9f8b443e550c0fd > : RETRY_LIMIT in 3m 53s > - announce-release https://zuul.opendev.org/t/openstack/build/None : > SKIPPED > - openstack-upload-github-mirror > https://zuul.opendev.org/t/openstack/build/2e9b658e70f340818cafefa88c5044e2 > : SUCCESS in 41s > > _______________________________________________ > 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-----

2 3

[ironic] APAC-Europe SPUC time?
by Dmitry Tantsur 09 Apr '21

09 Apr '21

Hi folks! The initial SPUC datetime was for 10am UTC, which was 11am for us in central Europe, now is supposed to be 12pm. On one hand, I find it more convenient to have SPUC at 11am still, on the other - I have German classes at this time for a few months starting mid-April. What do you think? Should we keep it in UTC, i.e. 12pm for us in Europe? Will that work for you Jacob? 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

3 2

[telemetry][cyborg][heat][monasca][tacker][keystone][release] Last minute RC to land fixes
by Herve Beraud 09 Apr '21

09 Apr '21

Hello teams listed above, We identified fixes and significant changes in your repos so we proposed last minute RC to allow you to release them before the final release. Your teams patches are available here: https://review.opendev.org/q/topic:%22wallaby-final-rc%22 Deadline is today, please validate them ASAP to have a chance to see these fixes released. Patches without response from PTLs/liaisons will be abandoned. After this point final release for RC projects will be started. Notice that RC changes should be on stable/wallaby and not on master, all projects are now branched so your master branches are now for Xena purpose. Thank you for your understanding. -- 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 1

[neutron] Neutron, nftables support and other fantastic beasts
by Rodolfo Alonso Hernandez 09 Apr '21

09 Apr '21

Hello Neutrinos: During Wallaby I've been working on enabling "nftables" support in Neutron. The goal was to use the new Netfilter framework replacing the legacy tools ("iptables", "ip6tables", "arptables" and "ebtables"). Because each namespace has its own Netfilter process, isolated from other namespaces, the migration process could be segmented in several tasks: dnat, fip, router, dhcp, metadata, Linux Bridge FW and OVS hybrid FW (I think I'm not missing anything here). When swapping to the new "nftables" framework, we can use the legacy API tools provided. Those tools provide a smooth transition to the new tooling (we found some differences that are now solved). That means we can keep the current code while using "nftables". Please, read [3] before reading the next paragraph, explaining the three "Netfilter" available framework alternatives. I started creating a "nft" (the "nftables" native binary) parser [1] to implement a NFtablesManager class, same as IPtablesManager. But soon I found that the transition to the new API is not that easy. This is not only a matter of creating the equivalent rule in the "nft" API but considering how those rules are handled in "nftables". Other problems found when using the new "nft" API: - The "--checksum-fill" command used in OVN metadata and DHCP namespace has no equivalent in "nft". That means old DHCP servers incorrectly calculating the packet checksum or DKDP environments won't work correctly. - "ipset" tool, used to group IP addresses and reduce the LB FW rule size, can be converted into a "map" [3]. The problem is this is only understood by the new API, not the "nftables" binaries using the legacy API. In a nutshell, what is the current status? We support (a) legacy tools and (b) "nftables" binaries with legacy API. This is the list of patches enabling the second option: - https://review.opendev.org/c/openstack/neutron/+/784913: this problem was affecting LB FW when "ipset" was disabled (merged). - https://review.opendev.org/c/openstack/neutron/+/785177: reorder the "ebtables" rules and prevent execution error 4 with empty chains. - https://review.opendev.org/c/openstack/neutron/+/785144: this patch, on top of the other two, creates two new neutron-tempest-plugin CI jobs, based on "linuxbridge" and "openvswitch-iptables_hybrid", to test the execution with the new binaries. - https://review.opendev.org/c/openstack/neutron/+/775413: this patch tests what is implemented in the previous one but testing those jobs in the "check" queue (it is a DNM patch just for testing). About the third option, to support the native "nft" API, I don't know if now we have the resources (time) and the need for that. This could be discussed again in the next PTG and in this mail too. Regards. [1]https://review.opendev.org/c/openstack/neutron/+/759874 [2] https://review.opendev.org/c/openstack/neutron/+/785137/3/doc/source/admin/… [3] https://review.opendev.org/c/openstack/neutron/+/775413/10/neutron/agent/li…

1 0

RE: [kolla] RHEL based container image (Tony Liu)
by CHALANSONNET Stéphane (Acoss) 09 Apr '21

09 Apr '21

Hello, You need an active subscription RHOSP for doing that , but Kolla was not supported by Redhat unfortunely ... Stéphane Chalansonnet -----Message d'origine----- De : openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Envoyé : jeudi 8 avril 2021 22:04 À : openstack-discuss(a)lists.openstack.org Objet : openstack-discuss Digest, Vol 30, Issue 56 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [Release-job-failures] Release of openstack/eslint-config-openstack for ref refs/tags/4.1.0 failed (Jeremy Stanley) 2. Re: [zun][kuryr][neutron] Missing vxlan ports in br-tun for Zun containers? (Jason Anderson) 3. [edge][cinder][manila][swift][tripleo] Storage at the edge discussions at the PTG (Ildiko Vancsa) 4. Re: [edge][cinder][manila][swift][tripleo] Storage at the edge discussions at the PTG (John Fulton) 5. [kolla] RHEL based container image (Tony Liu) ---------------------------------------------------------------------- Message: 1 Date: Thu, 8 Apr 2021 16:50:37 +0000 From: Jeremy Stanley <fungi(a)yuggoth.org> To: openstack-discuss(a)lists.openstack.org Subject: Re: [Release-job-failures] Release of openstack/eslint-config-openstack for ref refs/tags/4.1.0 failed Message-ID: <20210408165036.6tkcfwwix5ms3ig4(a)yuggoth.org> Content-Type: text/plain; charset="utf-8" On 2021-04-08 11:54:16 +0200 (+0200), Herve Beraud wrote: [...] > I proposed a patch to move to nodejs10 all our projects that depend on > nodejs: > > https://review.opendev.org/c/openstack/project-config/+/785353 > > When this patch will be merged I think that this job could be reenqueued. I reenqueued the tag, but release-openstack-javascript failed on a different problem. NPM complains that there's already a eslint-config-openstack 4.0.1 published which can't be overwritten, but the tag is for 4.1.0... someone should probably update the version parameter in eslint-config-openstack's package.json file, which means it'll need another release tagged anyway (4.1.1?). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210408…> ------------------------------ Message: 2 Date: Thu, 8 Apr 2021 17:00:19 +0000 From: Jason Anderson <jasonanderson(a)uchicago.edu> To: openstack-discuss <openstack-discuss(a)lists.openstack.org> Subject: Re: [zun][kuryr][neutron] Missing vxlan ports in br-tun for Zun containers? Message-ID: <0A70CB1A-35AA-4782-8BF3-496080E47341(a)uchicago.edu> Content-Type: text/plain; charset="utf-8" As usual, “rubber ducking” the openstack-discuss list yielded fruit. It turns out that I didn’t have the l2population mechanism driver enabled. I thought this was optional for some reason. It looks like enabling this and restarting the neutorn-openvswitch-agent has fixed connectivity! /Jason > On Apr 8, 2021, at 11:20 AM, Jason Anderson <jasonanderson(a)uchicago.edu> wrote: > > Hello stackers, > > I’m interested in using zun to launch containers and assign floating IPs via neutron to those containers. I am deploying zun, kuryr-libnetwork, and neutron with kolla-ansible on the Train release. I’ve configured neutron with one physical network and I’d like to use a VXLAN overlay for tenant networks. > > What works: > - I can launch containers on a neutron tenant network, they start successfully, they get an IP and can reach each other if they’re co-located on a single host. > - I can create all my neutron networks, routers, subnets, without (obvious) errors. > - I can update security groups on the container and see the iptables rules updated appropriately. > - I can directly create Docker networks using the kuryr driver/type. > > What doesn’t work: > - I can’t see any vxlan ports on the br-tun OVS bridge > - I can’t access the exposed container ports from the control/network > node via the router netns > - Because of that, I can’t assign floating IPs because NAT effectively > won’t work to reach the containers > > The fact that there are no ports on br-tun is supicious, but I’m not sure how this is supposed to work. I don’t see anything weird in neutron-openvswitch-agent logs but those logs are quite noisy and I’m not sure what to look for. > > Has anybody deployed such a setup / are there limitations I should know about? > > Thank you! > > > Jason Anderson > > DevOps Lead, Chameleon > > --- > > Department of Computer Science, University of Chicago Mathematics and > Computer Science, Argonne National Laboratory > jasonanderson(a)uchicago.edu > ------------------------------ Message: 3 Date: Thu, 8 Apr 2021 19:18:54 +0200 From: Ildiko Vancsa <ildiko.vancsa(a)gmail.com> To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Subject: [edge][cinder][manila][swift][tripleo] Storage at the edge discussions at the PTG Message-ID: <0A7B1EBD-0715-43ED-B388-A2011D437DD0(a)gmail.com> Content-Type: text/plain; charset=utf-8 Hi, I’m reaching out to draw your attention to the Edge Computing Group sessions on the PTG in less than two weeks. We are still formalizing our agenda, but we have storage identified as one of the topics that the working group would like to discuss. It would be great to have the session also as a continuation to earlier discussions that we had on previous PTGs with relevant OpenStack project contributors. We have a few cross-community sessions scheduled already, but we still have some flexibility in our agenda to schedule this topic so the most people who are interested in participating can join. Our available options are: * Monday (April 19) between 1400 UTC and 1500 UTC * Tuesday (April) between 1400 UTC and 1600 UTC __Please let me know if you or your project would like to participate and if you have a time slot difference from the above.__ Thanks and Best Regards, Ildikó (IRC ildikov on Freenode) ------------------------------ Message: 4 Date: Thu, 8 Apr 2021 13:39:45 -0400 From: John Fulton <johfulto(a)redhat.com> To: Ildiko Vancsa <ildiko.vancsa(a)gmail.com> Cc: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Subject: Re: [edge][cinder][manila][swift][tripleo] Storage at the edge discussions at the PTG Message-ID: <CAE66OMCQWZFB+7SM1amzRr1Vq3pOm=fEgtQTuHLh0=0PPXy-sQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Thu, Apr 8, 2021 at 1:21 PM Ildiko Vancsa <ildiko.vancsa(a)gmail.com> wrote: > Hi, > > I’m reaching out to draw your attention to the Edge Computing Group > sessions on the PTG in less than two weeks. > > We are still formalizing our agenda, but we have storage identified as > one of the topics that the working group would like to discuss. It > would be great to have the session also as a continuation to earlier > discussions that we had on previous PTGs with relevant OpenStack project contributors. > > We have a few cross-community sessions scheduled already, but we still > have some flexibility in our agenda to schedule this topic so the most > people who are interested in participating can join. Our available > options > are: > > * Monday (April 19) between 1400 UTC and 1500 UTC > * Tuesday (April) between 1400 UTC and 1600 UTC > I'm not available Monday but could join Tuesday. I'd be curious to hear what others are doing with Storage on the Edge and could share some info on how TripleO does it. John > > __Please let me know if you or your project would like to participate > and if you have a time slot difference from the above.__ > > Thanks and Best Regards, > Ildikó > (IRC ildikov on Freenode) > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210408…> ------------------------------ Message: 5 Date: Thu, 8 Apr 2021 20:04:04 +0000 From: Tony Liu <tonyliu0592(a)hotmail.com> To: "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Subject: [kolla] RHEL based container image Message-ID: <MWHPR08MB2382486467C9EE24247052B9BD749(a)MWHPR08MB2382.namprd08.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi, Given [1], RHEL based container is supported on RHEL 8 by Kolla. Where can I get RHEL based container images? I see CentOS and Ubuntu based images on docker hub, but can't find RHEL based images. [1] https://docs.openstack.org/kolla-ansible/ussuri/user/support-matrix.html Thanks! Tony ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 30, Issue 56 *************************************************

3 2

[zun][kuryr][neutron] Missing vxlan ports in br-tun for Zun containers?
by Jason Anderson 09 Apr '21

09 Apr '21

Hello stackers, I’m interested in using zun to launch containers and assign floating IPs via neutron to those containers. I am deploying zun, kuryr-libnetwork, and neutron with kolla-ansible on the Train release. I’ve configured neutron with one physical network and I’d like to use a VXLAN overlay for tenant networks. What works: - I can launch containers on a neutron tenant network, they start successfully, they get an IP and can reach each other if they’re co-located on a single host. - I can create all my neutron networks, routers, subnets, without (obvious) errors. - I can update security groups on the container and see the iptables rules updated appropriately. - I can directly create Docker networks using the kuryr driver/type. What doesn’t work: - I can’t see any vxlan ports on the br-tun OVS bridge - I can’t access the exposed container ports from the control/network node via the router netns - Because of that, I can’t assign floating IPs because NAT effectively won’t work to reach the containers The fact that there are no ports on br-tun is supicious, but I’m not sure how this is supposed to work. I don’t see anything weird in neutron-openvswitch-agent logs but those logs are quite noisy and I’m not sure what to look for. Has anybody deployed such a setup / are there limitations I should know about? Thank you! Jason Anderson DevOps Lead, Chameleon --- Department of Computer Science, University of Chicago Mathematics and Computer Science, Argonne National Laboratory jasonanderson(a)uchicago.edu

2 2

Re: [glance][openstack-ansible] Snapshots disappear during saving
by Oliver Wenz 09 Apr '21

09 Apr '21

Hi Dmitriy, > I'm wondering if you see also stack trace in keystone logs? Running 'journalctl' on the keystone container, I don't see any tracebacks. Or is there a specific service I should check? Kind regards, Oliver

2 1

Between openstack and offline IDC, a large intranet and a large second-tier network in the world improve the feasibility of data migration and disaster recovery.
by 赵陈洲 09 Apr '21

09 Apr '21

1 0

migration maybe a iaas service for openstack
by 赵陈洲 09 Apr '21

09 Apr '21

1 0

[Group-based-policy] not able to create the policies
by Mantesh Patil 09 Apr '21

09 Apr '21

Hi, I am deploying devstack Ussuri with GBP (stable/ussuri) on ubuntu 18.04 LTS(Updated the packages), after installation I am able to create the policies as mentioned in the wiki <https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallDevstack>. But after creation, I am not able to list the policies. I am using the following command to list the policies and it is giving a warning "/usr/local/lib/python3.6/dist-packages/keystoneauth1/adapter.py:235: UserWarning: Using keystoneclient sessions has been deprecated. Please update your software to use keystoneauth1. warnings.warn('Using keystoneclient sessions has been deprecated. '" Command1: source admin-openrc.sh *Command2: gbp group-create web * and also getting the following error while creating the group [image: image.png] Command3: *gbp group-list -c name -c tenant_id -f value* Please give the information that how can I get a list of group policies using CLI and new authentication.

1 0

[all][elections][tc] TC Vacancy Special Election Voting Kickoff
by Jeremy Stanley 09 Apr '21

09 Apr '21

TC Vacancy Special Election Nomination period is now over. The four already elected TC members for this term are listed as candidates in the special election, but will not appear on any resulting poll as they have already been officially elected. Only new candidates who are not the four elected TC members for this term will appear on a subsequent poll for the TC vacancy special election. The poll for the TC Vacancy Special Election is now open and will remain open until Apr 15, 2021 23:45 UTC. We are selecting 1 additional TC member, please rank all candidates in your order of preference. You are eligible to vote if you are a Foundation individual member[1] that also has committed to one of the official project teams' deliverable repositories[2] over the Apr 24, 2020 00:00 UTC - Mar 08, 2021 00:00 UTC timeframe (Victoria to Wallaby) or if you are one of the extra-atcs.[3] Please note that in order to confirm contributors are foundation members, the preferred address in Gerrit must also be included in the addresses for the corresponding member profile. What to do if you don't see the email and have a commit in at least one of the official deliverables[2]: * check the trash or spam folder of your gerrit Preferred Email address[4], in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from an official deliverable repo[2] and email the election officials[1]. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Our democratic process is important to the health of OpenStack, please exercise your right to vote. Candidate statements/platforms can be found linked to Candidate names[6]. Happy voting! Thank you, [1] https://www.openstack.org/community/members/ [2] https://opendev.org/openstack/governance/src/commit/892c4f3a851428cf41bab57… [3] Look for the extra-atcs element in [2] [4] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your preferred email. That is where the ballot has been sent. [5] https://governance.openstack.org/election/#election-officials [6] https://governance.openstack.org/election/#xena-tc-candidates -- Jeremy Stanley on behalf of the OpenStack Technical Elections Officials

1 0

[first contact] [SIG] PTG Planning!
by Kendall Nelson 09 Apr '21

09 Apr '21

Hello! I didn't think we would need a ton of time and I tried to pick a time to balance everyone's timezones so we have an hour at 22 UTC on Monday in the Austin room. We have an etherpad that was autogenerated: https://etherpad.opendev.org/p/apr2021-ptg-first-contact Please add topics if you have them and your name if you plan to join us! -Kendall Nelson (diablo_rojo)

1 0

[puppet] Proposing Alan Bishop (abishop) for puppet-cinder core and puppet-glance core
by Takashi Kajinami 08 Apr '21

08 Apr '21

Hello, I'd like to propose Alan Bishop (abishop) for the core team of puppet-cinder and puppet-glance. Alan has been actively involved in these 2 modules for a few years and has implemented some nice features like multiple backend support in glance, cinder s3 backup driver and etc, which expanded adoption of puppet-openstack. He has also provided good reviews on patches for these 2 repos based on his understanding about our code, puppet and serverspec. He is an active contributor to cinder and has deep knowledge about it. In addition He is also a core review in TripleO, which consumes our puppet modules, and mainly covers storage components like cinder and glance, so he is familiar with the way how these two components are deployed and configured. I believe adding him to our board helps us improve our review of these two modules. I'll wait for one week to hear any feedback from other core reviewers. Thank you, Takashi

6 6