March 2020 - openstack-discuss - lists.openstack.org

oslo.cache 2.1.0 breaks oslo_cache.memcache_pool
by Radosław Piliszek 06 Mar '20

06 Mar '20

Please be informed that oslo.cache 2.1.0 breaks oslo_cache.memcache_pool Kolla-Ansible gate is already RED and a quick codesearch revealed other deployment methods might be in trouble soon as well. This does not affect devstack/tempest as they use dogpile.cache.memcached instead. The error is TypeError: __init__() got an unexpected keyword argument 'dead_retry' For details see: https://bugs.launchpad.net/oslo.cache/+bug/1866008 -yoctozepto

3 7

Re: [CINDER] Distributed storage alternatives
by Burak Hoban 06 Mar '20

06 Mar '20

Hi guys, We use Dell EMC VxFlex OS, which in its current version allows for free use and commercial (in version 3.5 a licence is needed, but its perpetual). It's similar to Ceph but more geared towards scale and performance etc (it use to be called ScaleIO). Other than that, I know of a couple sites using SAN storage, but a lot of people just seem to use Ceph. Cheers, Burak ------------------------------ Message: 2 Date: Thu, 13 Feb 2020 18:20:29 +0100 From: Ignazio Cassano <ignaziocassano(a)gmail.com> To: Alfredo De Luca <alfredo.deluca(a)gmail.com> Cc: openstack-discuss <openstack-discuss(a)lists.openstack.org> Subject: Re: [CINDER] Distributed storage alternatives Message-ID: <CAB7j8cXLQWh5fx-E9AveUEa6OncDwCL6BOGc-Pm2TX4FKwnUKg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello Alfredo, I think best opensource solution is ceph. As far as commercial solutions are concerned we are working with network appliance (netapp) and emc unity. Regards Ignazio Il Gio 13 Feb 2020, 13:48 Alfredo De Luca <alfredo.deluca(a)gmail.com> ha scritto: > Hi all. > we 'd like to explore storage back end alternatives to CEPH for > Openstack > > I am aware of GlusterFS but what would you recommend for distributed > storage like Ceph and specifically for block device provisioning? > Of course must be: > > 1. *Reliable* > 2. *Fast* > 3. *Capable of good performance over WAN given a good network back > end* > > Both open source and commercial technologies and ideas are welcome. > > Cheers > > -- > *Alfredo* > > _____________________________________________________________________ The information transmitted in this message and its attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses. _____________________________________________________________________

3 3

CPU Topology confusion
by Satish Patel 06 Mar '20

06 Mar '20

Folks, We are running openstack with KVM and i have noticed kvm presenting wrong CPU Tolopoly to VM and because of that we are seeing bad performance to our application. This is openstack compute: # lstopo-no-graphics --no-io Machine (64GB total) NUMANode L#0 (P#0 32GB) + Package L#0 + L3 L#0 (25MB) L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 PU L#0 (P#0) PU L#1 (P#20) L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 PU L#2 (P#1) PU L#3 (P#21) This is VM running on above compute # lstopo-no-graphics --no-io Machine (59GB total) NUMANode L#0 (P#0 29GB) + Package L#0 + L3 L#0 (16MB) L2 L#0 (4096KB) + Core L#0 L1d L#0 (32KB) + L1i L#0 (32KB) + PU L#0 (P#0) L1d L#1 (32KB) + L1i L#1 (32KB) + PU L#1 (P#1) L2 L#1 (4096KB) + Core L#1 L1d L#2 (32KB) + L1i L#2 (32KB) + PU L#2 (P#2) L1d L#3 (32KB) + L1i L#3 (32KB) + PU L#3 (P#3) if you noticed P#0 and P#1 has own (32KB) cache per thread that is wrong presentation if you compare with physical CPU. This is a screenshot of AWS vs Openstack CPU Topology and looking at openstack its presentation is little odd, is that normal? https://imgur.com/a/2sPwJVC I am running CentOS7.6 with kvm 2.12 version.

3 8

OSC future (formerly [glance] Different checksum between CLI and curl)
by Albert Braden 06 Mar '20

06 Mar '20

As an openstack operator I was pretty ecstatic to hear that the assortment of clients would be replaced by a single client. I would be disappointed to find that a component would not integrate and would continue to use a separate client. This would be a step backward IMO. The discussion about microversions goes over my head, but I would hope to see the developers get together and solve the issue and continue working toward integration. -----Original Message----- From: Radosław Piliszek <radoslaw.piliszek(a)gmail.com> Sent: Monday, March 2, 2020 9:07 AM To: openstack-discuss <openstack-discuss(a)lists.openstack.org> Subject: Re: [glance] Different checksum between CLI and curl Folks, sorry to interrupt but I think we have diverged a bit too much from the subject. Only last Gaetan message is on topic here. Please switch to new subject to discuss OSC future. -yoctozepto pon., 2 mar 2020 o 18:03 Tim Bell <tim.bell(a)cern.ch> napisał(a): > > > > On 2 Mar 2020, at 16:49, Dmitry Tantsur <dtantsur(a)redhat.com> wrote: > > Hi, > > On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano(a)redhat.com> wrote: >> >> On Monday, 2 March 2020 10:54:03 CET Mark Goddard wrote: >> > On Mon, 2 Mar 2020 at 06:28, Abhishek Kekane <akekane(a)redhat.com> wrote: >> > > Hi Gaëtan, >> > > >> > > Glance team doesn't recommend to use OSC anymore. >> > > I will recommend you to check the same behaviour using >> > > python-glanceclient. >> > >> > That's not cool - everyone has switched to OSC. It's also the first >> > time I've heard of it. >> > >> > > From the end user perspective, we’ve had positive feedback on the convergence to OSC from our cloud consumers. > > There has been great progress with Manila to get shares included (https://urldefense.proofpoint.com/v2/url?u=https-3A__review.opendev.org_-23… ) and it would be a pity if we’re asking our end users to understand all of the different project names and inconsistent options/arguments/syntax. > > We had hoped for a project goal to get everyone aligned on OSC but there was not consensus on this, I’d still encourage it to simplify the experience for OpenStack cloud consumers. > > Tim > >

16 25

[osc][sdk] Merging OpenStack SDK and OpenStack Client teams
by Monty Taylor 06 Mar '20

06 Mar '20

Hey everybody, I’d like to propose merging the SDK and OSC teams. We already share an IRC channel, and already share a purpose in life. In OSC we have a current goal of swapping out client implementation for SDK, and we’re Already ensuring that SDK does what it needs to do to facilitate that goal. We also already share PTG space, and have requested a shared set of time at the upcoming Denver PTG. So really the separation is historical not practical, and these days having additional layers of governance is not super useful. I propose that we do a simple merge of the teams. This means the current SDK cores will become cores on OSC, and as most of the OSC cores are already SDK cores, it means the SDK team gains amotoki - which is always a positive. Dean hasn’t had time to spend on OSC quite a bit, sadly, and while we remain hopeful that this will change, we’re slowly coming to terms with the possibility that it might not. With that in mind, I’ll serve as the PTL for the new combined team until the next election. Monty

9 9

[trove][charm] RabbitMQ Connection Error
by tolga＠etom.cloud 05 Mar '20

05 Mar '20

2 1

[ansible-sig][kolla][openstack-ansible][osc][sdk][tripleo] OpenStack modules broken in Ansible 2.8.9
by Mark Goddard 05 Mar '20

05 Mar '20

Hi, The 2.8.9 release of Ansible has a regression [1] which breaks the OpenStack modules. I've proposed a simple fix, hopefully it will be included in a 2.8.10 release soon but in the meantime you may need to blacklist 2.8.9. [1] https://github.com/ansible/ansible/issues/68042 [2] https://github.com/ansible/ansible/pull/68043 Cheers, Mark

3 2

[sdk] Additions and subtractions from core team
by Monty Taylor 05 Mar '20

05 Mar '20

Heya, With the previous email about merging OSC and SDK teams, I’d also like to propose the following changes to the SDK core team (keeping in mind that likely means the core team of both OSC and SDK real soon now) Adds: Akihiro Motoki - The only OSC core not in sdk-core. amotoki should really be a core in all projects anyway Sean McGinnis - Sean has been reviewing things as a stable branch maint in both SDK and OSC, and as such has shown a good tendency to help things along when needed and to not approve things when he doesn’t know what’s up. Subtractions: All of these people are awesome, but they’re all long gone: Brian Curtin Clint Byrum Everett Toews Jamie Lennox Jesse Noller Ricardo Carillo Cruz Richard Theis Rosario Di Somma Sam Yaple Terry Howe Monty

5 5

[training-labs] Current training lab for Rocky not working on Windows
by Mike Manning 05 Mar '20

05 Mar '20

Hello, I've attempted to install the training-labs for the Rocky release onto my Windows 10 laptop on VirtualBox 6.0, but it is not working properly. The windows batch files are not functioning properly, and at least one reason is that the shell scripts that the batch files are copying are using "ifup" and "ifdown" which are not supported in Ubuntu 18.04. This one issue seems to imply that the scripts and batch files may need some review. Also, after install the ifupdown package on the system, the batch files and shell scripts still get hung up often on the existence of a file named "done" that never gets created. Can someone help me with this installation of the training-labs software in preparation for the COA exam? Mike Manning mike243512(a)gmail.com

1 0

[neutron][drivers team] Meeting 06.03.2020 cancelled
by Slawek Kaplonski 05 Mar '20

05 Mar '20

Hi Neutrinos, Due to lack of agenda lets cancel tomorrow’s drivers meeting. Lets meet as usually next week on Friday 13.03.2020. But, as You have now one hour of “free” time tomorrow (:D) I would like to ask You to take a look and help triaging one new RFE: https://bugs.launchpad.net/neutron/+bug/1865889 I’m not the best expert in routed networks, so I would really like if Miguel, Brian and others could take a look at this :) Thx in advance. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[MicroStack] Beta updates and strict (devmode) confinement on edge
by Pete Vander Giessen 05 Mar '20

05 Mar '20

Hi all, It has been a little while since I’ve posted any MicroStack news. MicroStack is a base set of OpenStack services, bundled into a snap. It’s intended for OpenStack workload development (as opposed to development of OpenStack itself), and also contains some experimental features geared toward edge clouds. We’ve just released a new MicroStack beta, with preview support for clustering (e.g., running a control plane node along with several compute nodes). You can install it with: sudo snap install --classic --beta microstack There are some known issues with refreshes from the current beta version of the snap to the new version. You may need to reinstall MicroStack if you’re running the current beta. To address some issues running MicroStack on non LTS Ubuntu distros, as well as lay the groundwork for a smoother refresh/upgrade process going forward, we’re working on making MicroStack into a strictly confined snap! If you’re feeling brave, you can try the (almost) strictly confined snap in developer mode with the following invocation: sudo snap install --devmode --edge microstack Work to put together a completely confined version of the snap, with no need for the devmode flag, is ongoing. You can find more information about MicroStack at https://microstack.run, and talk to the devs either on this mailing list, or on IRC: freenode #openstack-snaps .

1 0

NovaVMware - vCenter / DevStack - ERROR
by Kevin Puusild 05 Mar '20

05 Mar '20

Hello i have written here before but i didn't get any help so i try again. Current Setup: Ubuntu 18.04 Server with 1 vCenter + 1 ESXi i am trying to setup DevStack with vCenter as a hypervisor (not ESXI) following this wiki article: https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide to prepare to setup my devstack and following this wiki articel https://docs.openstack.org/devstack/latest/ too (compaining these two articles) *localrc* file is containing below information: ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-cpu,n-net,n-cond,n-sch,n-novnc,n-cauth,rabbit,mysql,horizon VIRT_DRIVER=vsphere VMWAREAPI_IP=#MY_VCENTER_IP VMWAREAPI_USER=#MY_VCENTER_ADMINISTRATOR_USER VMWAREAPI_PASSWORD=#MY_VCENTER_ADMINISTRATOR_PASSWORD VMWAREAPI_CLUSTER=#MY_VCENTER_CLUSTER_NAME DATABASE_PASSWORD=nova RABBIT_PASSWORD=nova SERVICE_TOKEN=nova SERVICE_PASSWORD=nova ADMIN_PASSWORD=nova HOST_IP=#MY_DEVSTACK_MACHINE_IP after running *stack.sh* script i get following error: ++functions:wait_for_compute:448 hostname +functions:wait_for_compute:448 compute_hostname=devstack +functions:wait_for_compute:450 timeout 60 bash -x ++functions:wait_for_compute:450 hostname +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +:: ID= +:: [[ '' == '' ]] +:: sleep 1 +:: [[ vsphere = \f\a\k\e ]] ++:: openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host devstack --service nova-compute -c ID -f value +functions:wait_for_compute:450 rval=124 +functions:wait_for_compute:462 time_stop wait_for_service +functions-common:time_stop:2330 local name +functions-common:time_stop:2331 local end_time +functions-common:time_stop:2332 local elapsed_time +functions-common:time_stop:2333 local total +functions-common:time_stop:2334 local start_time +functions-common:time_stop:2336 name=wait_for_service +functions-common:time_stop:2337 start_time=1582790249013 +functions-common:time_stop:2339 [[ -z 1582790249013 ]] ++functions-common:time_stop:2342 date +%s%3N +functions-common:time_stop:2342 end_time=1582790309198 +functions-common:time_stop:2343 elapsed_time=60185 +functions-common:time_stop:2344 total=7679 +functions-common:time_stop:2346 _TIME_START[$name]= +functions-common:time_stop:2347 _TIME_TOTAL[$name]=67864 +functions:wait_for_compute:464 [[ 124 != 0 ]] +functions:wait_for_compute:465 echo 'Didn'\''t find service registered by hostname after 60 seconds' Didn't find service registered by hostname after 60 seconds +functions:wait_for_compute:466 openstack --os-cloud devstack-admin --os-region RegionOne compute service list +functions:wait_for_compute:468 return 124 +lib/nova:is_nova_ready:1 exit_trap +./stack.sh:exit_trap:533 local r=124 ++./stack.sh:exit_trap:534 jobs -p +./stack.sh:exit_trap:534 jobs= +./stack.sh:exit_trap:537 [[ -n '' ]] +./stack.sh:exit_trap:543 '[' -f /tmp/tmp.8iR1neh89b ']' +./stack.sh:exit_trap:544 rm /tmp/tmp.8iR1neh89b +./stack.sh:exit_trap:548 kill_spinner +./stack.sh:kill_spinner:443 '[' '!' -z '' ']' +./stack.sh:exit_trap:550 [[ 124 -ne 0 ]] +./stack.sh:exit_trap:551 echo 'Error on exit' Error on exit +./stack.sh:exit_trap:553 type -p generate-subunit +./stack.sh:exit_trap:554 generate-subunit 1582789174 1136 fail +./stack.sh:exit_trap:556 [[ -z /opt/stack/logs ]] +./stack.sh:exit_trap:559 /usr/bin/python3.6 /devstack/devstack/tools/worlddump.py -d /opt/stack/logs World dumping... see /opt/stack/logs/worlddump-2020-02-27-075831.txt for details +./stack.sh:exit_trap:568 exit 124 -- Kevin Puusild

1 0

[stable][heat] Nominating Rabi Mishra for heat-stable-maint
by Zane Bitter 05 Mar '20

05 Mar '20

Rabi has been a core reviewer on Heat for more than 4 years, and is a former PTL. In that time he's done hundreds of backports: https://review.opendev.org/#/q/owner:ramishra%2540redhat.com+branch:%22%255… (Only two of which we ended up deciding not to merge, the last of which was in 2016.) As well as a good number of reviews: https://review.opendev.org/#/q/reviewedby:ramishra%2540redhat.com+branch:%2… Rabi also maintains a downstream distribution of Heat, so he is fully aware of the pain that backporting inappropriate changes can cause. He is well aware of the stable branch guidelines and is, if anything, more conservative than I am in applying them. I'm 100% confident he will not be approving any feature backports. I'll be spending some extended time away from a keyboard in the near future, so it's important that we increase the bus factor (from 1) of heat-stable-maint team members. thanks, Zane.

3 2

[oslo][infra] OpenDev git repo for oslo.policy missing commit
by Ben Nemec 05 Mar '20

05 Mar '20

Found a weird thing today. The OpenDev oslo.policy repo[0] is missing [1]. Even stranger, I see it on the Github mirror[2]. Any idea what happened here? -Ben 0: https://opendev.org/openstack/oslo.policy/commits/branch/master 1: https://review.opendev.org/#/c/708212/ 2: https://github.com/openstack/oslo.policy/commits/master

2 2

[policy][keystone][nova][cyborg][barbican][neutron][manila][cinder] Policy Popup team progress report
by Colleen Murphy 05 Mar '20

05 Mar '20

This is an update on the progress made within the Policy Popup team[1] so far this cycle. [1] https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… Why This Is Important ===================== Separating system, domain, and project-scope APIs and providing meaningful default roles is critical to facilitating secure cloud deployments and to fulfilling OpenStack's vision as a fully self-service infrastructure provider[2]. Until all projects have completed this policy migration, the "reader" role that exists in keystone is dangerously misleading, and the `[oslo_policy]/enforce_scope` option has limited usefulness as long as projects lack uniformity in how an administrator can use scoped APIs. [2] https://governance.openstack.org/tc/reference/technical-vision.html#self-se… Project Progress ================ Nova ---- - Ussuri spec has merged[3] - 28 changes implementing the spec have been merged[4] - 39 additional changes have been proposed and are awaiting review[5] [3] https://review.opendev.org/686058 [4] https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+status:merg… [5] https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+status:open Cyborg ------ - Ussuri spec has merged[6] and a tracking story has been created[7] - 2 changes to implement the spec have been proposed and are awaiting review[8] [6] https://review.opendev.org/699099 [7] https://storyboard.openstack.org/#!/story/2007024 [8] https://review.opendev.org/#/q/project:openstack/cyborg+topic:policy-popup+… Barbican -------- - A table has been created outlining the required policy changes[9] - No patches merged or proposed yet [9] https://wiki.openstack.org/wiki/Barbican/Policy Neutron ------- - No planning document - No patches merged or proposed yet Manila ------ - No planning document - No patches merged or proposed yet Cinder ------ - No planning document - No patches merged or proposed yet How You Can Help ================ If you are a contributor for these teams, please update the popup team wiki page[10] as your project starts to plan and implement policy changes. If you are a cloud operator, please help review the proposed policy rule changes to sanity-check the new scope and role defaults and to help influence these decisions. [10] https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… Reminders ========= - Reach out at any time to the keystone team if you have questions on this popup team's goals. - Colleen still seeking to be replaced as co-chair, please let me know if you're interested.

1 0

[Watcher] Queue watcher_notifications
by Alexandros Soumplis 04 Mar '20

04 Mar '20

Hi all, We are using Watcher on Train and we have noticed a problem with the watcher_notifications queue which fills up with messages from Cinder and watcher-decision-engine seems not to consume them. On the contrary it perfectly consumes nova notifications from the versioned_notifications queue. Any suggestions ? a.

1 0

Upcoming UC meeting: March 5th 2020
by Mohamed Elsakhawy 04 Mar '20

04 Mar '20

Good day everyone, As you may have heard, there is an ongoing discussion for having a single body to encompass both the UC and TC responsibilities, potentially by merging the two bodies. This is still at early stages, and thus to facilitate this discussion we will hold tomorrow's UC meeting using video conferencing to allow all audience to easily share their thoughts and input. The meeting will happen at its normal time "13:30 EST", If you are interested in joining, please use the link below https://hangouts.google.com/u/1/call/q_bcZpCRXgB2_Cak4ycyAEEI Thanks Mohamed --melsakhawy

4 6

[neutron] security group list regression
by James Denton 04 Mar '20

04 Mar '20

Hello all, We recently upgraded an environment from Newton -> Rocky, and have noticed a pretty severe regression in the time it takes the API to return the list of security groups. This environment has roughly 8,000+ security groups, and it takes nearly 75 seconds for the ‘openstack security group list’ command to complete. I don’t have actual data from the same environment running Newton, but was able to replicate this behavior with the following lab environments running a mix of virtual and baremetal machines: Newton (VM) Rocky (BM) Stein (VM) Train (BM) Number of sec grps vs time in seconds: # Newton Rocky Stein Train 200 4.1 3.7 5.4 5.2 500 5.3 7 11 9.4 1000 7.2 12.4 19.2 16 2000 9.2 24.2 35.3 30.7 3000 12.1 36.5 52 44 4000 16.1 47.2 73 58.9 5000 18.4 55 90 69 As you can see (hopefully), the response time increased significantly between Newton and Rocky, and has grown slightly ever since. We don't know, yet, if this behavior can be seen with other 'list' commands or is limited to secgroups. We're currently verifying on some intermediate releases to see where things went wonky. There are some similar recent reports out in the wild with little feedback: https://bugzilla.redhat.com/show_bug.cgi?id=1788749 https://bugzilla.redhat.com/show_bug.cgi?id=1721273 I opened a bug here, too: https://bugs.launchpad.net/neutron/+bug/1865223 Bottom line: Has anyone else experienced similar regressions in recent releases? If so, were you able to address them with any sort of tuning? Thanks in advance, James

4 7

[release][tc][horizon] xstatic repositories marked as deprecated
by Akihiro Motoki 04 Mar '20

04 Mar '20

Hi, I noticed some xstatic repositories [1] under the horizon team are marked as deprecated. They are marked as deprecated in [2] as they were never released, but the actual situation looks different. They are used in horizon requirements and the contents of these repositories are same as those in the corresponding PyPI modules. I guess they were released to PyPI based on the repositories but the horizon team just forgot to push the corresponding tags. I would like to drop 'deprecated' mark from the repositories and move them to the proper situation. Does it make sense? If so, what is the right solution to do this? In my understanding, we need to add tags corresponding to the deliverables and to add deliverable files in the releases repo. What I am not sure is whether we can push a tag to a repository without pushing deliverables to PyPI? Or do we need to create another release to tag them in their repositories? [1] Such xstatic repositories are: - xstatic-bootstrap-datepicker - xstatic-hogan - xstatic-jquery-migrate - xstatic-jquery.quicksearch - xstatic-jquery.tablesorter - xstatic-rickshaw - xstatic-spin [2] https://review.opendev.org/#/c/629889/ Thanks, Akihiro Motoki (irc: amotoki)

5 8

[keystone] Keystone Team Update - Week of 2 February 2020
by Vishakha Agarwal 04 Mar '20

04 Mar '20

# Keystone Team Update - Week of 2 March 2020 ## News ### User Support and Bug Duty Every week the duty is being rotated between the members. The person-in-charge for bug duty for current and upcoming week can be seen on the etherpad [1] [1] https://etherpad.openstack.org/p/keystone-l1-duty ## Open Specs Ussuri specs: https://bit.ly/2XDdpkU Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 4 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 24 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Ussuri Roadmap Stories - Groups in keystone SAML assertion https://tree.taiga.io/project/keystone-ussuri-roadmap/us/33 https://review.opendev.org/#/c/588211/ Add openstack_groups to assertion - Add support for modifying resource options to CLI tool https://tree.taiga.io/project/keystone-ussuri-roadmap/us/53 https://review.opendev.org/#/c/697444/ Adding options to user cli * Special Requests https://review.opendev.org/#/c/710734/ Correcting api-ref for users ## Bugs This week we opened 1 new bug and closed 1. Bugs opened (1) Bug #1865121 (keystone:Undecided): 'openstack token issue' command doesn't issue token for MFA enabled user - Opened by Abhishek Sharma M https://bugs.launchpad.net/keystone/+bug/1865121 Bugs closed (1) Bug #1865121 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1865121 ## Milestone Outlook https://releases.openstack.org/ussuri/schedule.html Feature proposal freeze is NEXT WEEK (March 9- March 16). Spec implementations that are not submitted or still in a WIP state by the end of the week will need to be postponed until next cycle unless we agree on an exception. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

[nova] [neutron] multiple fixed_ip
by Arnaud Morin 04 Mar '20

04 Mar '20

Hello all, I was doing some tests to create a server using nova API. My objective is to create a server with one port but multiples IPs (one IPv4 and one IPv6). If I understand well the neutron API, I can create a port using the fixed_ips array parameter [1] Unfortunately, on nova side, it seems to only accept a string with only one ip (fixed_ip) [2] Is it mandatory for me to create the port with neutron? Or is there any trick that I missed on nova API side? Thanks! [1] https://docs.openstack.org/api-ref/network/v2/?expanded=create-port-detail#… [2] https://docs.openstack.org/api-ref/compute/?expanded=create-server-detail#c… -- Arnaud Morin

3 4

[neutron] Review priorities for RFEs
by Slawek Kaplonski 04 Mar '20

04 Mar '20

Hi neutrinos, I just went through patches related to our RFEs which we want to merge before Ussuri-3 and I set them review priority flag. You can find them at [1]. If I missed any patch related to any of those RFEs, please let me know by email or on IRC. And please try to review those patches if possible ;) Thx in advance. [1] https://tinyurl.com/vezk6n6 — Slawek Kaplonski Senior software engineer Red Hat

1 0

Re: [lists.openstack.org代发][nova] ask some questions about flavor
by Brin Zhang(张百林) 04 Mar '20

04 Mar '20

Items: [lists.openstack.org代发][nova] ask some questions about flavor Hi,all: > I have two questions about the flavor. One is the property "OS-FLV-DISABLED:disabled" defined when we created the flavor, but there is no method to change the property. And I see a patch about this [1], but it is abandoned. So I want to know our community how > to consider this function. "OS-FLV-DISABLED:disabled", this is typically only visible to administrative users. I'm not sure if it is worth supporting the modification/update. I think it should be planned in advance for managers. If the specific extra spec bound to flavor is only used as a dedicated flavor. > Another one is when we call the "list-migrations" api, why we receive the new_instance_type_id and old_instance_type_id in response of list_migrations should be internal value for the migration-type is "resize"[2]? Maybe the value should be exposed on REST > API, so that we can know which is the old flavor. In microversion 2.23 we support to show “migration-type” in the List Migrations API [1][2], I think you call List Migrations REST API is not add the “OpenStack-API-Version” or “X-OpenStack-Nova-API-Version”, right？ And you can get the list migrations filter by “migration-type” (enum in: evacuation, live-migration, migration (cold), resize), as the call such as: http://192.168.2.11/compute/v2.1/os-migrations?migration_type=resize that show what migration type what you want. [1] API changes: https://docs.openstack.org/api-ref/compute/?expanded=list-migrations-detail… [2] microverion 2.3: https://docs.openstack.org/nova/latest/reference/api-microversion-history.h… > Can you tell me more about this? Thank you very much. Ref: [1]:https://review.opendev.org/#/c/61291/ [2]:https://review.opendev.org/#/c/588481/<https://review.opendev.org/#/c/588481/4> Best Regards Rambo

2 1

[nova] ask some questions about flavor
by Rambo 04 Mar '20

04 Mar '20

Hi,all:         I have two questions about the flavor. One is the property "OS-FLV-DISABLED:disabled" defined when we created the flavor, but there is no method to change the property. And I see a patch about this [1], but it is abandoned. So I want to know our community how to consider this function.          Another one is when we call the "list-migrations" api, why we receive the new_instance_type_id and old_instance_type_id in response of list_migrations should be internal value for the migration-type is "resize"[2]? Maybe the value should be exposed on REST API, so that we can know which is the old flavor.          Can you tell me more about this? Thank you very much. Ref: [1]:https://review.opendev.org/#/c/61291/ [2]:https://review.opendev.org/#/c/588481/ Best Regards Rambo

1 0

[all] Announcing OpenStack Wallaby!
by Sean McGinnis 04 Mar '20

04 Mar '20

That's right - we have the W name already. No months on end of referring to "the W release" as we start making long term plans. Wallaby https://en.wikipedia.org/wiki/Wallaby Wallabies are native to Australia, which at the start of this naming period was experiencing unprecedented wild fires. This name has passed the legal vetting phase and we are good to go. Full results of the naming poll can be found here: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_60b98f102c5d08d5 As a reminder, the way we choose a release name had several changes this time around. Full details of the current release process can be found here: https://governance.openstack.org/tc/reference/release-naming.html There were a lot of great names proposed. I think removing the geographical restriction has been a good move. Thank you to everyone who proposed ideas for this release cycle. Happy stacking! Sean

2 1