October 2020 - openstack-discuss - lists.openstack.org

OpenStack user survey data available?
by Bernd Bausch 23 Oct '20

23 Oct '20

Is there a way to get access to raw user survey data? Some of the graphical data on the analytics page <https://www.openstack.org/analytics> is unreadable, in particular information about Neutron's drivers: The analytics FAQ tells me to contact heidijoy(a)openstack.org <mailto:heidijoy@openstack.org> for questions, but email to this address bounces back. 550 5.1.1 <heidijoy(a)openstack.org>: Email address could not be found, or was misspelled (G8) Thanks much, Bernd

5 9

[tripleo] TripleO CI Summary: Unified Sprint 34
by Rafael Folco 23 Oct '20

23 Oct '20

Greetings, The TripleO CI team has just completed **Unified Sprint 34** (Oct 02 thru Oct 22). The following is a summary of completed work during this sprint cycle: In the last sprint we had two major goals: #1 OpenStack Victoria release preparation and #2 Docker.io removal from upstream CI #1 OpenStack Victoria release preparation Integration and component pipelines have been created and prepared for the stable/victoria branching. Periodic jobs, promotion, configuration and monitoring changes have been merged in order to run victoria pipelines and promote builds. Upstream jobs will be branched in the next sprint. https://hackmd.io/sasvoKjTSkabGlFOTkK_kw #2 Docker.io removal from upstream CI Standalone, multinode, undercloud and upgrade jobs have been converted in consumers of the new content provider job. With this new dependency relation, artifacts are not pulled from external sources like docker.io. Instead, container images and rpm packages are built in the provider job using local registries, pulled to the consumer, and then discarded. https://hackmd.io/vRMVeZXZRgK5Vxqi6ENUDg Jobs across all TripleO repositories have been switched to the new content provider job. There are still changes in flight to make this happen for stable branches and CentOS7 jobs. This work should be completed in the next week. Content provider changes (80+): https://review.opendev.org/#/q/topic:new-ci-job Upstream promotions [1] Ruck/Rover recorded notes [2]. The planned work for the next sprint is to complete the work started in the previous sprint, and focuses on: - Finish switching to content provider on stable branches and CentOS7 jobs. - Branch upstream stable/victoria jobs. The Ruck and Rover for this sprint are Sagi Shnaidman (sshnaidm) and Sandeep Yadav (ysandeep). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in hackmd [3]. Thanks, --rfolco [1] http://dashboard-ci.tripleo.org/d/HkOLImOMk/upstream-and-rdo-promotions?org… [2] https://hackmd.io/1qxCqYzATfudl1cKvaQ8-w [3] https://hackmd.io/a_PhAlijTr-KTWHzGuf3qQ

1 0

[CloudKitty][ptg] PTG next week
by Rafael Weingärtner 23 Oct '20

23 Oct '20

Hi, Thanks to all of you who proposed some topics for our meeting at the PTG. I hope you are all enjoying the virtual summit this week. Next week is the virtual PTG, an event where we will reflect on the past release cycle and look forward to the next release, Wallaby, and beyond. The CloudKitty discussions at the PTG are organized in Etherpad [1]. The PTG meeting is free to attend, but please register [2] and add your name to the Etherpad. If you can't make all of the sessions, but are interested in specific topics, add your name to the topic to request an IRC ping. I am looking forward to seeing you all next week. Cheers, Rafael [1] https://etherpad.opendev.org/p/cloudkitty-ptg-wallaby [2] https://october2020ptg.eventbrite.com -- Rafael Weingärtner

1 0

[Diversity][PTG] Diversity and Inclusion WG at the PTG - Divisive Language
by Amy Marrich 23 Oct '20

23 Oct '20

The Diversity and Inclusion WG will be holding a PTG session Monday from 15:00-17:00 UTC. We will be using Meetpad[0] atleast to start but will change to Zoom if needed. Based on feedback [2] during the Forum session we will be working on providing a more comprehensive list of words and possible alternatives vs the original plan to leave this aspect within the technical groups. Thanks, Amy Marrich (spotz) 0 - https://meetpad.opendev.org/wallaby-ptg-diversity 1 - https://etherpad.opendev.org/p/wallaby-ptg-diversity 2 - https://etherpad.opendev.org/p/vSummit2020__DivisiveLanguage

1 0

Re: VM stuck in hard_reboot state
by Fabian Zimmermann 23 Oct '20

23 Oct '20

Hi, just forwarding your answer to the list - sorry for not using reply-all :( Is your nova-compute-agent on the hypervisor working as expected? (check the logs, restart) Are you able to reset the state? You should ensure the instance is not running somewhere else! https://docs.openstack.org/ocata/admin-guide/support-compute.html#reset-the… Fabian Am 23.10.20 um 14:16 schrieb Gregory SACRE: > Here they are: > > compute $ virsh list > Id Name State > -------------------- > > compute $ virsh list --all > Id Name State > ------------------------------------ > - instance-00000008 shut off > - instance-00000009 shut off > - instance-00000015 shut off > - instance-00000016 shut off > - instance-00000017 shut off > - instance-0000001c shut off > - instance-0000001d shut off > - instance-0000001e shut off > - instance-0000001f shut off > > controller $ openstack server show mediawiki > +-----------------------------+----------------------------------------------------------+ > | Field | Value > | > +-----------------------------+----------------------------------------------------------+ > | OS-DCF:diskConfig | AUTO > | > | OS-EXT-AZ:availability_zone | nova > | > | OS-EXT-STS:power_state | Running > | > | OS-EXT-STS:task_state | rebooting_hard > | > | OS-EXT-STS:vm_state | active > | > | OS-SRV-USG:launched_at | 2019-08-09T13:43:06.000000 > | > | OS-SRV-USG:terminated_at | None > | > | accessIPv4 | > | > | accessIPv6 | > | > | addresses | wiki-selfservice=172.16.1.54, > 192.168.150.154 | > | config_drive | > | > | created | 2019-08-09T13:32:49Z > | > | flavor | m2.large (7) > | > | hostId | > b8cbd9da0d28d67fff65b88405428269c97d8d27289e2f8ee35f5485 | > | id | 0e3eafb6-1b36-4e03-8548-8a3294d82c65 > | > | image | > | > | key_name | gsa-key > | > | name | mediawiki > | > | project_id | a5f2b77a4a8e499791ee981b991f2df3 > | > | properties | > | > | security_groups | name='teleport' > | > | | name='default' > | > | | name='global_http' > | > | status | HARD_REBOOT > | > | updated | 2020-10-23T08:50:09Z > | > | user_id | 16ea223cee1345dda504c8408c55fb2a > | > | volumes_attached | > id='bdfe4fc6-1e85-4b5d-b9b6-16147fbfc005' | > +-----------------------------+----------------------------------------------------------+ > > Thanks for the help! > > > Sorry for this question, but shouldn't I reply to the mailing list? > I'm new to this mailing list so I'm not 100% sure on the habits (I > have read the mailing list netiquette, but I prefer to ask first :-)) > > > On Fri, Oct 23, 2020 at 12:26 PM Fabian Zimmermann <dev.faz(a)gmail.com> wrote: >> >> Hi, >> >> could you dump the outputs of >> >> virsh list >> virsh list --all >> openstack server show >> >> Fabian >> >> Gregory SACRE <gregory.sacre(a)gmail.com> schrieb am Fr., 23. Okt. 2020, 12:16: >>> >>> Dear all, >>> >>> >>> I've been using Openstack (Ubuntu 18.04 install following Openstack documentation) for about a year in a lab at work. >>> I have one VM running 24/7 with Mediawiki on it (rest is for testing). >>> >>> It has been working fine until I updated packages yesterday. Here is the list of relevant packages that were updated: >>> >>> 2020-10-22 09:44:04 status installed neutron-common:all 2:14.3.1-0ubuntu1~cloud0 >>> 2020-10-22 09:44:06 status installed nova-common:all 2:19.3.1-0ubuntu1~cloud0 >>> 2020-10-22 09:44:12 status installed python3-nova:all 2:19.3.1-0ubuntu1~cloud0 >>> 2020-10-22 09:44:16 status installed python3-neutron:all 2:14.3.1-0ubuntu1~cloud0 >>> 2020-10-22 09:44:25 status installed neutron-linuxbridge-agent:all 2:14.3.1-0ubuntu1~cloud0 >>> 2020-10-22 09:44:29 status installed nova-compute-libvirt:all 2:19.3.1-0ubuntu1~cloud0 >>> 2020-10-22 09:44:35 status installed nova-compute-kvm:all 2:19.3.1-0ubuntu1~cloud0 >>> 2020-10-22 09:45:04 status installed nova-compute:all 2:19.3.1-0ubuntu1~cloud0 >>> >>> Since then, the VM does not respond (ping, ssh...). >>> I could list it (via Web interface or controller command line) and it showed as ACTIVE. >>> I rebooted the server thinking maybe something was stuck. The server came back online, the VM still ACTIVE but cannot connect to it. >>> My next step was to hard reboot the VM. Since then, the VM is in HARD_REBOOT state and would not move from there. I tried to shut it down, restart again the server, but no, nothing changes. When I try to shut it down it says it cannot as it is in hard reboot state. >>> >>> I would at least like to be able to save some stuff that's on it (I know, I should have backed it up before the update...). >>> My Google searches on "openstack vm stuck hard reboot" did not help... >>> >>> Do not hesitate if you need more info. >>> Any help would really be appreciated! >>> >>> >>> Kr, >>> >>> Gregory

1 0

[puppet] Gerrit breach and commit audit
by Takashi Kajinami 23 Oct '20

23 Oct '20

Hello, As suggested by the recent announcement[1], I started walking through the commits for puppet-openstack repos. [1] https://etherpad.opendev.org/p/puppet-gerrit-breach-audit You can find the progress in the etherpad below[2]. [2] https://etherpad.opendev.org/p/puppet-gerrit-breach-audit I'll update this thread once I complete checking all, but I would appreciate your help about some of the repos because we have so many repos here. Thank you, Takashi

2 2

VM stuck in hard_reboot state
by Gregory SACRE 23 Oct '20

23 Oct '20

Dear all, I've been using Openstack (Ubuntu 18.04 install following Openstack documentation) for about a year in a lab at work. I have one VM running 24/7 with Mediawiki on it (rest is for testing). It has been working fine until I updated packages yesterday. Here is the list of relevant packages that were updated: 2020-10-22 09:44:04 status installed neutron-common:all 2:14.3.1-0ubuntu1~cloud0 2020-10-22 09:44:06 status installed nova-common:all 2:19.3.1-0ubuntu1~cloud0 2020-10-22 09:44:12 status installed python3-nova:all 2:19.3.1-0ubuntu1~cloud0 2020-10-22 09:44:16 status installed python3-neutron:all 2:14.3.1-0ubuntu1~cloud0 2020-10-22 09:44:25 status installed neutron-linuxbridge-agent:all 2:14.3.1-0ubuntu1~cloud0 2020-10-22 09:44:29 status installed nova-compute-libvirt:all 2:19.3.1-0ubuntu1~cloud0 2020-10-22 09:44:35 status installed nova-compute-kvm:all 2:19.3.1-0ubuntu1~cloud0 2020-10-22 09:45:04 status installed nova-compute:all 2:19.3.1-0ubuntu1~cloud0 Since then, the VM does not respond (ping, ssh...). I could list it (via Web interface or controller command line) and it showed as ACTIVE. I rebooted the server thinking maybe something was stuck. The server came back online, the VM still ACTIVE but cannot connect to it. My next step was to hard reboot the VM. Since then, the VM is in HARD_REBOOT state and would not move from there. I tried to shut it down, restart again the server, but no, nothing changes. When I try to shut it down it says it cannot as it is in hard reboot state. I would at least like to be able to save some stuff that's on it (I know, I should have backed it up before the update...). My Google searches on "openstack vm stuck hard reboot" did not help... Do not hesitate if you need more info. Any help would really be appreciated! Kr, Gregory

1 0

Keystone with AzureAD as openid provider - JWT token could not be validated
by Robert Duncan 23 Oct '20

23 Oct '20

Found this when trying OS_AUTH_TYPE="v3oidcpassword" For anybody using AzureAD as idp in Keystone, it is not OIDC compliant - surprised? keystone will not validate tokens as they are signed for MS graph API essentially it results in "Apache WWW-Authenticate: Bearer error="invalid_token", error_description="JWT token could not be validated" keystone attempts to validate the tokens from the metadata using whatever if finds in https://login.microsoftonline.com/<tenant-guid>/v2.0/.well-known/openid-configuration<https://login.microsoftonline.com/6edb49c1-bf72-4eea-8b3f-a7fd0a25b68c/v2.0…> or using an Apache variable in wsgi-keystone.conf called OIDCOAuthVerifyJwksUri for example - it will reach here https://login.microsoftonline.com/<tenant-guid>/discovery/v2.0/keys<https://login.microsoftonline.com/6edb49c1-bf72-4eea-8b3f-a7fd0a25b68c/disc…> and find keys - however it won't be able to validate the token as MS inserts a nonce before signing them - i.e. the tokens can only be validated by ms graph additionally, if you try to validate the tokens locally on keystone using Apache variable OIDCOAuthVerifyCertFiles the keys can rotate without warning. The solution is using the app registration portal in Azure and modify the app registration by selecting 'expose an API' and add a scope - then request this scope on the client using apache variable 'OIDCScope' https://medium.com/@abhinavsonkar/making-azure-ad-oidc-compliant-5734b70c43… Rob Duncan. ________________________________ The information contained and transmitted in this e-mail is confidential information, and is intended only for the named recipient to which it is addressed. The content of this e-mail may not have been sent with the authority of National College of Ireland. Any views or opinions presented are solely those of the author and do not necessarily represent those of National College of Ireland. If the reader of this message is not the named recipient or a person responsible for delivering it to the named recipient, you are notified that the review, dissemination, distribution, transmission, printing or copying, forwarding, or any other use of this message or any part of it, including any attachments, is strictly prohibited. If you have received this communication in error, please delete the e-mail and destroy all record of this communication. Thank you for your assistance. ________________________________

1 0

[kuryr][ptg] virtual PTG
by Maysa De Macedo Souza 23 Oct '20

23 Oct '20

Hello, With the PTG approaching, I would like to encourage you to look at the PTG etherpad [1] and add any topics you want to discuss (please mention your name and IRC nickname). Even if you won't be able to attend the PTG, feel free to add the topic so it gets discussed. The Kuryr meeting[2] will happen at 7 UTC-8 UCT on October 27 at the Grizzly room. Cheers, Maysa Macedo [1] https://etherpad.openstack.org/p/wallaby-ptg-kuryr [2] http://ptg.openstack.org/ptg.html

1 0

[manila] PTG Schedule has been updated
by Goutham Pacha Ravi 23 Oct '20

23 Oct '20

Hello Zorillas and all interested stackers, Thanks for making your topic proposals on the planning etherpad [1]. You will notice that [1] has the re-arranged list of topics by their intended time slots. Please take a look and call out any issues you may have against your topics, or topics that may interest you. As is tradition, we won't have time to accommodate the whole schedule, but we'll try to pick up any new topics and languishing issues that haven't made it to the schedule with best effort. If we cannot address them at the PTG, i'll make sure to bring them to our weekly IRC meetings. Please save the bookmark to the live PTG schedule: http://ptg.openstack.org/ptg.html and subscribe to PTG bot updates so you don't miss the action! Looking forward to seeing you all there! Thanks, Goutham [1] https://etherpad.opendev.org/p/wallaby-ptg-manila-planning

1 1

[puppet] Gerrit breach and commit audit
by Tobias Urdin 23 Oct '20

23 Oct '20

Hello, As per the announcement in [1] I have audited all changes to Puppet OpenStack repositories. [1] http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html

1 0

[placement] Train upgrade warning
by CHANU ROMAIN 23 Oct '20

23 Oct '20

Hello, I just did an openstack upgrade, from Stein to Train, OS is Ubuntu 18.04. I followed the procedure but I got a warning as return code (1). Everything works now but i'm affraid one day it will make an upgrade to fail: # placement-status upgrade check +------------------------------------------------------------------+ | Upgrade Check Results | +------------------------------------------------------------------+ | Check: Missing Root Provider IDs | | Result: Success | | Details: None | +------------------------------------------------------------------+ | Check: Incomplete Consumers | | Result: Warning | | Details: There are -15753 incomplete consumers table records for | | existing allocations. Run the "placement-manage db | | online_data_migrations" command. | +------------------------------------------------------------------+ #echo $? => 1 =a t least one check encountered an issue and requires further investigation. This is considered a warning but the upgrade may be OK. Then i tried "placement-manage db online_data_migrations" the command does nothing because negative records Then "placement-manage db sync; echo $?" => 0 So what should I do about these -15753 incomplete consumeurs? Is it normal than nova_api sql backup keep growing? Best regards, Romain

1 0

[OpenStack] OpenStack Victoria for Ubuntu 20.10 and Ubuntu 20.04 LTS
by Corey Bryant 23 Oct '20

23 Oct '20

The Ubuntu OpenStack team at Canonical is pleased to announce the general availability of OpenStack Victoria on Ubuntu 20.10 (Groovy Gorilla) and Ubuntu 20.04 LTS (Focal Fossa) via the Ubuntu Cloud Archive. Details of the Victoria release can be found at: https://www.openstack.org/software/victoria. To get access to the Ubuntu Victoria packages: == Ubuntu 20.10 == OpenStack Victoria is available by default for installation on Ubuntu 20.10. == Ubuntu 20.04 LTS == The Ubuntu Cloud Archive for OpenStack Victoria can be enabled on Ubuntu 20.04 by running the following command: sudo add-apt-repository cloud-archive:victoria The Ubuntu Cloud Archive for Victoria includes updates for: aodh, barbican, ceilometer, cinder, designate, designate-dashboard, glance, gnocchi, heat, heat-dashboard, horizon, ironic, keystone, magnum, manila, manila-ui, masakari, mistral, murano, murano-dashboard, networking-arista, networking-bagpipe, networking-baremetal, networking-bgpvpn, networking-hyperv, networking-l2gw, networking-mlnx, networking-odl, networking-sfc, neutron, neutron-dynamic-routing, neutron-vpnaas, nova, octavia, octavia-dashboard, openstack-trove, trove-dashboard, ovn-octavia-provider, panko, placement, sahara, sahara-dashboard, sahara-plugin-spark, sahara-plugin-vanilla, senlin, swift, vmware-nsx, watcher, watcher-dashboard, and zaqar. For a full list of packages and versions, please refer to: http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/victoria_v… == Reporting bugs == If you have any issues please report bugs using the ‘ubuntu-bug’ tool to ensure that bugs get logged in the right place in Launchpad: sudo ubuntu-bug nova-conductor Thank you to everyone who contributed to OpenStack Victoria. Enjoy and see you in Wallaby! Corey (on behalf of the Ubuntu OpenStack Engineering team)

2 1

[ussuri][ansible][cinder] cinder-api timeout in setup-openstack
by Kiluria 22 Oct '20

22 Oct '20

Hello everyone, first of all, im very new with openstack. Currently i am trying to install my first openstack in a testing System consisting of 6 PCs. But i have some Problems to get it to work. I would be very grateful if someone could help me, to find my Problem. I tried to install Openstack with the Openstack-Ansible Deployment Guide. My Configuration files are: openstack_user_config.yml: http://paste.openstack.org/show/799294/ user_variables.yml : yhttp://paste.openstack.org/show/799295/ But the last Playbook "setup-openstacks" runs on an error. At the Task "os_cinder : Ensure cinder api is available" i get a timeout. It says that HTTP Error 503 and it can not connect to 172.29.236.9:8776 (open-stack-03). There is no port 8776 open on the internal haproxy IP. But the cinder-api.service in the cinder-api container is enabled. And there is even an open Port 8776 in the container. ("ss -tunlp") Does anyone have an idea what I did wrong? Thanks for every answer!

1 0

[neutron] Drivers meeting
by Slawek Kaplonski 22 Oct '20

22 Oct '20

Hi, We have one new RFE [1] proposed by Liu, but as we have PTG next week, I added it to the PTG agenda for discussion (on Thursday). And with that I think we can cancel tomorrow's meeting. Have a great weekend and see You on Monday at PTG :) [1] https://bugs.launchpad.net/neutron/+bug/1900934 -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

Survey on OpenStack Distributors
by foundjem＠ieee.org 22 Oct '20

22 Oct '20

Hello everyone, we are currently conducting a research to analyze how OpenStack distributors contribute changes back upstream. Please consider participating in this survey [1]. Thank you, Armstrong Foundjem Release team, SAIL Laboratory Queen’s University 1. https://forms.gle/QdHybesAuxysWe1i7 <https://forms.gle/QdHybesAuxysWe1i7>

1 0

[charms] Charm CI outage the weekend of Oct 23 - Oct 25
by Frode Nordahl 22 Oct '20

22 Oct '20

Hello fellow hackers, The Charm third party CI will be out this weekend on the back of some maintenance work. We will endeavour to get it back online Monday October 26th. Enjoy your weekend once you get there wherever you are. Cheers! -- Frode Nordahl

1 0

[release] Release countdown for week R-25, Oct 19 - 23
by Herve Beraud 22 Oct '20

22 Oct '20

Welcome back to the release countdown emails! These will be sent at major points in the Wallaby development cycle, which should conclude with a final release on Wednesday, 14 April, 2021. Development Focus -------------------------- At this stage in the release cycle, focus should be on planning the Wallaby development cycle, assessing Wallaby community goals and approving Wallaby specs. General Information -------------------------- Wallaby is a 26 weeks development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/wallaby/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the Victoria release are continued in Wallaby with a similar release model. If you intend to drop a deliverable, or modify its release model, please do so before the Wallaby-1 milestone by proposing a change to the deliverable file at: https://opendev.org/openstack/releases/src/branch/master/deliverables/walla… Upcoming Deadlines & Dates ------------------------------------- Virtual Wallaby PTG: October 26-30 Wallaby-1 milestone: December 3 Hervé Beraud and the entire Release Management Team -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[kolla][ptg] PTG next week
by Mark Goddard 22 Oct '20

22 Oct '20

Hi, I hope you are all enjoying the virtual summit this week. As I'm sure you're all aware, next week is the virtual PTG, an event where we will reflect on the past release cycle and look forward to the next release, Wallaby, and beyond. The Kolla discussions at the PTG are organised via an Etherpad [1], and as we near the event, it is starting to take shape. It's free to attend, but please register [2] and add your name to the Etherpad. If you can't make all of the sessions, but are interested in specific topics, add your name to the topic to request an IRC ping. Look forward to seeing you next week. Cheers, Mark [1] https://etherpad.opendev.org/p/kolla-wallaby-ptg [2] https://october2020ptg.eventbrite.com

1 0

[blazar] PTL away
by Pierre Riteau 22 Oct '20

22 Oct '20

Hello, I'll be away for the next couple of weeks for paternity leave. All Blazar meetings are cancelled in the meantime. Pierre Riteau (priteau)

1 0

Error installing Horizon
by Cristina Mayo 22 Oct '20

22 Oct '20

Hi, I installed Horizon on my Openstack Ussuri cloud and it has worked fine for some months. A few days ago, I had some trouble with python packages (I updated some dependencies by error). I'm trying to reinstall Horizon because it fails but it seems almost impposible to me: # apt install openstack-dashboard Configuring openstack-dashboard (3:18.3.2-0ubuntu0.20.04.2) ... Collecting and compressing static assets... WARNING:root:"dashboards" and "default_dashboard" in (local_)settings is DEPRECATED now and may be unsupported in some future release. The preferred way to specify the order of dashboards and the default dashboard is the pluggable dashboard mechanism (in /usr/share/openstack-dashboard/openstack_dashboard/enabled, /usr/share/openstack-dashboard/openstack_dashboard/local/enabled). Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 204, in fetch_command app_name = commands[subcommand] KeyError: 'collectstatic' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "manage.py", line 25, in <module> execute_from_command_line(sys.argv) File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 381, in execute_from_command_line utility.execute() File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 375, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 211, in fetch_command settings.INSTALLED_APPS File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 79, in __getattr__ self._setup(name) File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 66, in _setup self._wrapped = Settings(settings_module) File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 157, in __init__ mod = importlib.import_module(self.SETTINGS_MODULE) File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1014, in _gcd_import File "<frozen importlib._bootstrap>", line 991, in _find_and_load File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 671, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 783, in exec_module File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed File "/usr/share/openstack-dashboard/openstack_dashboard/settings.py", line 352, in <module> STATICFILES_DIRS += settings_utils.get_xstatic_dirs( File "/usr/share/openstack-dashboard/openstack_dashboard/utils/settings.py", line 288, in get_xstatic_dirs module = import_module(module_name) File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1014, in _gcd_import File "<frozen importlib._bootstrap>", line 991, in _find_and_load File "<frozen importlib._bootstrap>", line 961, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed File "<frozen importlib._bootstrap>", line 1014, in _gcd_import File "<frozen importlib._bootstrap>", line 991, in _find_and_load File "<frozen importlib._bootstrap>", line 961, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed File "<frozen importlib._bootstrap>", line 1014, in _gcd_import File "<frozen importlib._bootstrap>", line 991, in _find_and_load File "<frozen importlib._bootstrap>", line 973, in _find_and_load_unlocked ModuleNotFoundError: No module named 'horizon.xstatic' dpkg: error to process package openstack-dashboard (--configure) E: Sub-process /usr/bin/dpkg returned an error code (1) Thanks in advance, Best

3 2

[tc] Gerrit breach and commit audit
by Ghanshyam Mann 22 Oct '20

22 Oct '20

Hello Everyone, As per the announcement of the Gerrit breach [1], I have audited all repos under the Technical Committee for 1. Suspicious commit 2. Core group list and everything is fine except the one already reported. - https://opendev.org/openstack/governance/src/branch/master/reference/techni… - https://opendev.org/openstack/governance/src/branch/master/reference/user-c… [1] http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html -gmann

2 1

[neutron][ptg] Sessions schedule
by Slawek Kaplonski 22 Oct '20

22 Oct '20

Hi Neutrinos, Thanks for all of You who proposed some topics for our meeting at the PTG. I prepared agenda for that in etherpad [1]. I didn't specify exact time slots for each topics but just moved things around for specific days. We will move through the list of topics and use as much time for each of them as needed. I hope that will work better than scheduled time slots for topic :) Please review that agenda and ping me if You would like to add/change anything there. There is not much time for that but still I can do some changes :) And as it was during last ptg, we are gonna use meetpad [2] for our meetings. Last time it worked fine so I hope it will be like that this time too. If not, we can fallback to zoom during the PTG week. That's all from me for now. Have a great (and safe) weekend and see You on Monday. [1] https://etherpad.opendev.org/p/neutron-wallaby-ptg [2] https://meetpad.opendev.org/neutron-wallaby-ptg -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[oslo][core] gerrit breach and auditing all oslo deliverables [1] since Oct 01
by Herve Beraud 22 Oct '20

22 Oct '20

Hello, As every team we are also concerned by the gerrit breach and we must take a look at our changes during this time frame on all our deliverables [1]. The list of deliverables owned by Oslo is very huge, we need a methodical approach and also external help to check all these repositories. Fortunately oslo was in feature freeze during the majority of this period so I think it will reduce the scope of our investigation to our master branches. Due to the criticality of the problem I propose the following action plan: - first, split our deliverables in group and assign volunteer on them - second, focus us on changes against our scripts, executable files and CI config; - third, inspect documentation; - fourth, inspect other kinds of changes that I missed in previous points. I wrote a script [2][3] to help the release team to extract relevant changes (*.py, *.sh), all the rest (*.yaml, *.rst) have been ignored for now, we could adapt this script to lead our investigation. Example of script usage against our openstack/oslo.messaging repos: ``` $ cd oslo.messaging $ curl https://gist.githubusercontent.com/4383/511359cc2080e06295944c5f40bd1033/ra… | sh ``` Are you interested to follow this action plan? Ben as you are the security liaison are you interested in coordinating these groups/actions? Else any volunteer? Feel free to propose another approach or to propose changes on this one. Please ensure to double check your account activity [4] and make sure nothing is off. Special congrats to Julia Kreger and for her excellent job [5]. Thank you in advance for your help, [1] https://governance.openstack.org/tc/reference/projects/oslo.html#deliverabl… <https://governance.openstack.org/tc/reference/projects/release-management.h…> [2] https://gist.github.com/4383/511359cc2080e06295944c5f40bd1033 [3] https://gist.githubusercontent.com/4383/511359cc2080e06295944c5f40bd1033/ra… [4] http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html [5] http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018148.… -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----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-----

4 6

[tacker] Gerrit breach and commit audit
by Yasufumi Ogawa 22 Oct '20

22 Oct '20

Hi, As announced for the gerrit breach [1], I have audited all repos under Tacker for 1. Suspicious commit 2. Core group list and everything is fine [2]. [1] http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html [2] https://etherpad.opendev.org/p/tacker-gerrit-breach-audit Regards, Yasufumi

1 0

[tripleo][core] gerrit breach and auditing all tripleo commits since Oct 01
by Marios Andreou 22 Oct '20

22 Oct '20

Hi folks, as you are undoubtedly aware, gerrit was down yesterday. There was this email to service-announce [1] with more information about what happened (kudos Julia Kreger who sent [2] where I saw that). There is a list of changes [3] since October 1st that we should audit out of precaution and to be responsible and accountable to our community and users. As you can expect there are a great number of changes. I put a full commit list at [5]. I mined those from [3] - see [4] for info about the 'mining' and even better if someone has time to verify that I didn't miss any repos or commits. Please I need help from all core reviewers. We need to check that the commits in [5] appear valid and correct - remember the concern is for any changes that may have been merged by a compromised account. I propose that we do this via Gerrit and that we leave a comment - 'CHECKED' - on each review that we check? Hopefully we can cover all of these before the end of the week by distributing our efforts. I am open to other suggestions though if folks feel this is better done via some document/spreadsheet etc. Of course as stated in [1] it is a good idea for everyone to double check their account activity and make sure nothing is off, Thank you in advance for your help, marios [1] http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018148.… [3] https://static.opendev.org/project/opendev.org/gerrit-diffs/ [4] https://gist.github.com/marios/a44a55998531354dc3d634dddeadf1c0 [5] https://gist.github.com/marios/d1b774c827769373b67d3988105140dd

4 7

[rpm-packaging] Gerrit breach and commit audit
by Javier Pena 22 Oct '20

22 Oct '20

Hi, Following the recent Gerrit breach report [1], I have gone through the changes in rpm-packaging, renderspec and pymod2pkg, and none of them look suspicious. If you see anything strange, please let me know and we will handle it. Regards, Javier [1] - http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html

1 0

[heat] Gerrit breach and commit audit
by Rico Lin 22 Oct '20

22 Oct '20

Hi All, As suggested by the recent announcement of gerrit breach [1], I have audited all commits for heat repos and confirmed that everything looks good. [1] http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html Sorry for any inconvenience. Also feel free to ping me or any of our core reviewers and ask for review on your patches. Best Regards, -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[tripleo][overcloud] setup 2 bonds for overcloud deployment tripleo
by dangerzone ar 21 Oct '20

21 Oct '20

Hi.. I'm looking help to deploy overcloud (openstack train) as per initial req below:- a) 3 controllers b) 5 computes c) 2 bonds (bond0 - all vlan except for tenant , bond1 - for tenant vlan only) *No external storage and dpdk computes for now as trying to deploy these 3 controllers and 5 computes first. I have gone through openstack web, blogs and some other resources and failed to deploy with success. One of my problems is to identify the right templates to use for my setup and config for 2 bonds above. I have struggled to deploy overcloud for a month without success...I really appreciate your help and support to guide me. Please your help and support is much appreciated. I request help from everybody. Thank you

3 4

packstack unable to handle team devices?
by lejeczek 21 Oct '20

21 Oct '20

Hi guys I'm trying to add a second node, both nodes have team devices for: CONFIG_NEUTRON_OVN_TUNNEL_IF=team1056 and I get packstack to keep failing: ... Preparing Nova Common entries [ DONE ] Preparing Neutron API entries [ ERROR ] ERROR : "Couldn't detect ipaddress of interface team1056 on node 172.24.154.201" Please check log file /var/tmp/packstack/20201021-230211-9q243gpi/openstack-setup.log for more information .. Is this by design or it's just my case and if the latter then how to troubleshoot/workaround it? many thanks, L

1 0

[magnum] Gerrit breach and commit audit
by feilong 21 Oct '20

21 Oct '20

Hi everyone, As per the announcement of the Gerrit breach [1], I have audited all repos under Magnum (magnum, python-magnumclient, magnum-ui and magnum-tempest-plugin) for 1. Suspicious commit 2. Core group list Everything looks OK for me, see https://etherpad.opendev.org/p/magnum-gerrit-breach-audit [1] http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html -- Cheers & Best regards, Feilong Wang (王飞龙) ------------------------------------------------------ Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington ------------------------------------------------------

1 0

Keystone auth method v3oidcpassword throws RESP BODY: Omitted, Content-Type is set to text/html. Only application/json responses have their bodies logged.
by Robert Duncan 21 Oct '20

21 Oct '20

I'm trying to use openID with openstack --versionopenstack 5.2.0 keystoneauth1==3.17.3 keystonemiddleware==7.0.1 python-keystoneclient==3.21.0 I have created an RC file like so : export OS_INTERFACE="public" export OS_AUTH_URL="https://openstack:5000/v3" export OS_IDENTITY_PROVIDER="<my_idp>" export OS_PROTOCOL="openid" export OS_CLIENT_ID="<the -id >" export OS_CLIENT_SECRET="<the secret>" export OS_DISCOVERY_ENDPOINT="https://login.microsoftonline.com/<the-tenant-id>/v2.0/.well-known/openid-configuration" export OS_IDENTITY_API_VERSION="3" export OS_AUTH_TYPE="v3oidcpassword" export OS_USERNAME="<AzureAD user>" # this is the local openstack project id export OS_PROJECT_ID="<The project ID>" # set password by querying user export OS_PASSWORD="" echo "Please enter your O365 Password: " read -sr OS_PASSWORD_INPUT export OS_PASSWORD=$OS_PASSWORD_INPUT all is working on Horizon WebSSO- but I cannot access the API the openstack --debug output shows that I get a token from MS debug info (redacted) command: token issue -> openstackclient.identity.v3.token.IssueToken (auth=True) Auth plugin v3oidcpassword selected auth_config_hook(): {'api_timeout': None, 'verify': True, 'cacert': None, 'cert': None, 'key': None, 'baremetal_status_code_retries': '5', 'baremetal_introspection_status_code_retries': '5', 'image_status_code_retries': '5', 'disable_vendor_agent': {}, 'interface': 'public', 'floating_ip_source': 'neutron', 'image_api_use_tasks': False, 'image_format': 'qcow2', 'message': '', 'network_api_version': '2', 'object_store_api_version': '1', 'secgroup_source': 'neutron', 'status': 'active', 'auth': {'project_id': '516706052ebd4f9a89c0b7d7e075754d'}, 'additional_user_agent': [('osc-lib', '2.0.0')], 'verbose_level': 3, 'deferred_help': False, 'debug': True, 'default_domain': 'default', 'timing': False, 'auth_url': 'https://openstack.*********:5000/v3', 'username': 'r********', 'password': '***', 'identity_provider': '*****', 'protocol': 'openid', 'client_id': '*******', 'client_secret': '***', 'discovery_endpoint': 'https://login.microsoftonline.com/*******/v2.0/.well-known/openid-configura…', 'beta_command': False, 'identity_api_version': '3', 'data_processing_api_version': '1.1', 'container_infra_api_version': '1', 'region_name': '', 'auth_type': 'v3oidcpassword', 'networks': []} Using auth plugin: v3oidcpassword Using parameters {'auth_url': 'https://openstack.******:5000/v3', 'project_id': '516706052ebd4f9a89c0b7d7e07575, 'identity_provider': '*****', 'protocol': 'openid', 'client_id': '********', 'client_secret': '***', 'discovery_endpoint': 'https://login.microsoftonline.com/*******/v2.0/.well-known/openid-configura…', 'username': '*****', 'password': '***'} Get auth_ref REQ: curl -g -i -X GET https://login.microsoftonline.com/*****/v2.0/.well-known/openid-configurati… -H "User-Agent: openstacksdk/0.46.0 keystoneauth1/4.0.0 python-requests/2.22.0 CPython/3.8.2" Starting new HTTPS connection (1): login.microsoftonline.com:443 https://login.microsoftonline.com:443 "GET /******/v2.0/.well-known/openid-configuration HTTP/1.1" 200 1651 RESP: [200] Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Allow-Origin: * Cache-Control: max-age=86400, private Content-Length: 1651 Content-Type: application/json; charset=utf-8 Date: Wed, 21 Oct 2020 09:37:13 GMT P3P: CP="DSP CUR OTPi IND OTRi ONL FIN" Set-Cookie: fpc=AhupGfLmUQlEsKNlR-m0ATg; expires=Fri, 20-Nov-2020 09:37:14 GMT; path=/; secure; HttpOnly; SameSite=None, esctx=*****: domain=.login.microsoftonline.com; path=/; secure; HttpOnly; SameSite=None, x-ms-gateway-slice=estsfd; path=/; secure; samesite=none; httponly, stsservicecookie=estsfd; path=/; secure; samesite=none; httponly Strict-Transport-Security: max-age=31536000; includeSubDomains X-Content-Type-Options: nosniff x-ms-ests-server: 2.1.11154.9 - NEULR2 ProdSlices x-ms-request-id: 0819033b-dcb3-409a-8115-54dc06a31900 RESP BODY: {"token_endpoint":"https://login.microsoftonline.com/*****/oauth2/v2.0/token","token_endpoint_auth_methods_supported":["client_secret_post","private_key_jwt","client_secret_basic"],"jwks_uri":"https://login.microsoftonline.com/****/discovery/v2.0/keys","response_modes_supported":["query","fragment","form_post"],"subject_types_supported":["pairwise"],"id_token_signing_alg_values_supported":["RS256"],"response_types_supported":["code","id_token","code id_token","id_token token"],"scopes_supported":["openid","profile","email","offline_access"],"issuer":"https://login.microsoftonline.com/****/v2.0","request_uri_parameter_supported":false,"userinfo_endpoint":"https://graph.microsoft.com/oidc/userinfo","authorization_endpoint":"https://login.microsoftonline.com/****/oauth2/v2.0/authorize","device_authorization_endpoint":"https://login.microsoftonline.com/*****/oauth2/v2.0/devicecode","http_logout_supported":true,"frontchannel_logout_supported":true,"end_session_endpoint":"https://login.microsoftonline.com/****/oauth2/v2.0/logout","claims_supported":["sub","iss","cloud_instance_name","cloud_instance_host_name","cloud_graph_host_name","msgraph_host","aud","exp","iat","auth_time","acr","nonce","preferred_username","name","tid","ver","at_hash","c_hash","email"],"tenant_region_scope":"EU","cloud_instance_name":"microsoftonline.com","cloud_graph_host_name":"graph.windows.net","msgraph_host":"graph.microsoft.com","rbac_url":"https://pas.windows.net"} REQ: curl -g -i -X POST https://login.microsoftonline.com/******/oauth2/v2.0/token -H "User-Agent: openstacksdk/0.46.0 keystoneauth1/4.0.0 python-requests/2.22.0 CPython/3.8.2" -d '{'username': '*****', 'password': '*****', 'scope': 'openid profile', 'grant_type': 'password'}' https://login.microsoftonline.com:443 "POST /*****/oauth2/v2.0/token HTTP/1.1" 200 3764 RESP: [200] Cache-Control: no-store, no-cache Content-Length: 3764 Content-Type: application/json; charset=utf-8 Date: Wed, 21 Oct 2020 09:37:14 GMT Expires: -1 P3P: CP="DSP CUR OTPi IND OTRi ONL FIN" Pragma: no-cache Set-Cookie: fpc=****; expires=Fri, 20-Nov-2020 09:37:14 GMT; path=/; secure; HttpOnly; SameSite=None, x-ms-gateway-slice=estsfd; path=/; secure; samesite=none; httponly, stsservicecookie=estsfd; path=/; secure; samesite=none; httponly Strict-Transport-Security: max-age=31536000; includeSubDomains X-Content-Type-Options: nosniff x-ms-ests-server: 2.1.11154.9 - WEULR1 ProdSlices x-ms-request-id: 92d66fde-6763-4be2-b1cf-00fd18bc1800 RESP BODY: {"token_type":"Bearer","scope":"email openid profile 00000003-0000-0000-c000-000000000000/User.Read","expires_in":3599,"ext_expires_in":3599,"access_token":"<the access token>","id_token":"<the id token>"} REQ: curl -g -i -X POST https://openstack***:5000/v3/OS-FEDERATION/identity_providers/***/protocols… -H "Authorization: {SHA256}aff774c8663ee647a08aefcea698f8c30e1d1cc8d85a3d55a17cae53defd8955" -H "User-Agent: openstacksdk/0.46.0 keystoneauth1/4.0.0 python-requests/2.22.0 CPython/3.8.2" Starting new HTTPS connection (1): openstack.****:5000 https://openstack.***:5000 "POST /v3/OS-FEDERATION/identity_providers/****/protocols/openid/auth HTTP/1.1" 200 541 RESP: [200] Content-Length: 541 Content-Type: text/html Date: Wed, 21 Oct 2020 09:37:14 GMT Server: Apache RESP BODY: Omitted, Content-Type is set to text/html. Only application/json responses have their bodies logged. Expecting value: line 1 column 1 (char 0) Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cliff/app.py", line 393, in run_subcommand self.prepare_to_run_command(cmd) File "/usr/lib/python3/dist-packages/osc_lib/shell.py", line 493, in prepare_to_run_command self.client_manager.auth_ref File "/usr/lib/python3/dist-packages/osc_lib/clientmanager.py", line 202, in auth_ref self._auth_ref = self.auth.get_auth_ref(self.session) File "/usr/lib/python3/dist-packages/keystoneauth1/identity/v3/federation.py", line 65, in get_auth_ref auth_ref = self.get_unscoped_auth_ref(session) File "/usr/lib/python3/dist-packages/keystoneauth1/identity/v3/oidc.py", line 265, in get_unscoped_auth_ref return access.create(resp=response) File "/usr/lib/python3/dist-packages/keystoneauth1/access/access.py", line 36, in create body = resp.json() File "/usr/lib/python3/dist-packages/requests/models.py", line 897, in json return complexjson.loads(self.text, **kwargs) what's gone wrong? thanks, Rob. ________________________________ The information contained and transmitted in this e-mail is confidential information, and is intended only for the named recipient to which it is addressed. The content of this e-mail may not have been sent with the authority of National College of Ireland. Any views or opinions presented are solely those of the author and do not necessarily represent those of National College of Ireland. If the reader of this message is not the named recipient or a person responsible for delivering it to the named recipient, you are notified that the review, dissemination, distribution, transmission, printing or copying, forwarding, or any other use of this message or any part of it, including any attachments, is strictly prohibited. If you have received this communication in error, please delete the e-mail and destroy all record of this communication. Thank you for your assistance. ________________________________

2 6

[nova] Gerrit breach and commit audit
by Ghanshyam Mann 21 Oct '20

21 Oct '20

Hello Everyone, As per the announcement of the Gerrit breach [1], I have audited all repos under Nova for 1. Suspicious commit 2. Core group list and everything is fine. - https://etherpad.opendev.org/p/nova-gerrit-breach-audit [1] http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html

1 0

[designate] Gerrit breach and commit audit
by Nicolas Bock 21 Oct '20

21 Oct '20

Hi, Herve's script [1] identified the following commits in the designate repository. I second Michael's assessment from earlier that all of those commits are legitimate. Best, Nick Commit to analyze: https://review.opendev.org/#/q/8459ed9460ab492adfd305875c717ebe31bf68f3 Files to analyze: - lower-constraints.txt ------------------------------- Commit to analyze: https://review.opendev.org/#/q/568b559b67b0d9a663172d681fe887bf06feea0a Files to analyze: - tox.ini ------------------------------- Commit to analyze: https://review.opendev.org/#/q/0d277e9cbb42404b1b1082afdfa5bcfc49691e6f Files to analyze: - lower-constraints.txt ------------------------------- Commit to analyze: https://review.opendev.org/#/q/53dcbe8584434c21b1a340763e9ee419dc58117f Files to analyze: - .zuul.yaml ------------------------------- Commit to analyze: https://review.opendev.org/#/q/348771951fa6e9740b629e81227cc0311751a471 Files to analyze: - lower-constraints.txt ------------------------------- Commit to analyze: https://review.opendev.org/#/q/1831a5b1016563681df6905114f0dc95efd24391 Files to analyze: - designate/locale/ko_KR/LC_MESSAGES/designate.po ------------------------------- Commit to analyze: https://review.opendev.org/#/q/19da5d79d5d24dfda31773f70971f640856b10b1 Files to analyze: - releasenotes/source/locale/en_GB/LC_MESSAGES/releasenotes.po ------------------------------- Commit to analyze: https://review.opendev.org/#/q/a0d20514c6ebbfe6b42b989b6192ae77312d3ba7 Files to analyze: - lower-constraints.txt ------------------------------- [1] https://gist.githubusercontent.com/4383/511359cc2080e06295944c5f40bd1033/ra…

1 0

[qa] Gerrit breach and commit audit
by Ghanshyam Mann 21 Oct '20

21 Oct '20

Hello Everyone, As per the announcement of the Gerrit breach [1], I have audited all repos under QA for 1. Suspicious commit 2. Core group list and everything is fine. - https://etherpad.opendev.org/p/qa-gerrit-breach-audit [1] http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html -gmann

1 0

[manila] Gerrit breach and commit audit
by Goutham Pacha Ravi 21 Oct '20

21 Oct '20

Hello Zorillas, I join the list of contributors to thank the infra team for their work in isolating, protecting and fixing the recent vulnerability. I looked through the code changes committed to repositories we maintain and didn't find any malicious code submissions or approvals. If you would like to take a look, here is an Ethercalc with the changes: https://ethercalc.openstack.org/uscp1x7i8ewn Please do respond here in case you notice anything amiss. Thank you! Goutham ---------- Forwarded message --------- From: Ian Wienand <iwienand(a)redhat.com> Date: Tue, Oct 20, 2020 at 5:33 PM Subject: [service-announce] October 20 Gerrit Outage Update To: <service-announce(a)lists.opendev.org> As of this mail, Gerrit access has been restored. Please read on for important information, especially around change verification. Background ----------- On 2020-10-20 at 01:30 a user unexpectedly added a workflow approval to a change that they were not expected to have access to. At 02:06 UTC an alert was raised via IRC. Administrators found the account had added themselves to a core group and made the +W vote. The account was disabled, and removed from the groups it had added itself to by 02:55 UTC. Administrators began to analyse the situation and Gerrit was taken offline at 04:02 UTC to preserve state and allow for analysis. >From this time, administrators were working on log collection and analysis, along with restoring backups for comparison purposes. By around 08:45 UTC it was clear that the privilege escalation had been achieved by gaining control of a Launchpad SSO account with Gerrit administrator privileges. By this time, we had ruled out software vulnerabilities. Logs showed the first unauthorized access of the administrator account in Gerrit on 2020-10-06. Communication with Launchpad admins agrees with this analysis. We saw one session opened as the administrator user to StoryBoard on this same day, but logs show no data was modified or hidden stories viewed. Analysis has been performed on the Gerrit database and git trees from October 1st, pre-dating any known unauthorized access. Access was restored at around 2020-10-21 00:00 UTC Outcomes ----------- The following has been verified: The administrator account used has been disabled and credentials updated We have verified that all group and user addition/removals since Oct 1 are valid. The only invalid additions were made by the compromised administrator account to add a single user account to the Administrators group; and then that account added itself to another known group. The account given administrator privilege has been removed from the groups it added itself to and is disabled. There is no evidence of any unauthorized access via methods other than Gerrit HTTP and Gerrit SSH access. No commits have been pushed to git trees bypassing code review. Every git tree has been compared to the Oct 1 version and all commits have been correctly inserted via Gerrit changes. The version of Gerrit we use stores HTTP API passwords in plain-text. We know that a limited number of passwords were gathered via the HTTP API and it is possible passwords were gathered via the database. We thus have assumed that all HTTP API passwords have been disclosed. This password needs to be explicitly enabled by users, and many users do not have it enabled. Remediation ----------- This leaves us with the following remediation actions: Users should double-check their Launchpad recent activity at https://login.launchpad.net/activity for any suspicious logins. If found, please notify the OpenDev admins in Freenode #opendev and Launchpad admins in #launchpad immediately. All HTTP API passwords have been cleared. If you push changes via HTTPS (instead of typical SSH), are a gertty user, or run a CI system or something else that communicates with the Gerrit HTTP API, you will need to regenerate a password. Any SSH keys added to accounts since 2020-10-01 have been removed. This affects only a limited number of accounts. This is done in an abundance of caution, and we do not believe any accounts had unauthorized SSH keys added We should audit all changes for projects since 2020-10-01. We have no evidence that any account had its ssh keys compromised, thus we can rule out any unauthorized changes being uploaded via SSH. However we can not conclusively rule out that compromised HTTP API passwords were used to push a change through Gerrit. For example, a change could be uploaded that looks like it came from a user, or the API key of a core team member may have been used to approve a change without authorization. Given our extensive analysis we consider it exceedingly unlikely that this vector was used. We have had no notifications of users seeing unexpected changes either uploaded by them, or approved by them in projects they work on. This said, we believe it is important to inform the community of this very unlikely, but still possible, vulnerability of the source code. To this end, we have prepared a list of all changes from the known affected period which should be audited for correctness. These are available at https://static.opendev.org/project/opendev.org/gerrit-diffs/ Team members should browse these changes and make sure they were correctly approved in Gerrit. If any change looks suspicious you should notify OpenDev administrators in Freenode #opendev immediately. Further actions ---------------- We are planning the following for the short term future: The Opendev administrators will be looking at alternative models for Gerrit admin account management. We are already well into planning and testing a coming upgrade to a version of Gerrit which does not store plain-text API keys. Longer term, we've written a spec for replacing Launchpad SSO as our authentication provider. We thank you for your patience during this trying time, and we look forward to returning to supporting the community doing what it does best -- working together to create great things. _______________________________________________ service-announce mailing list service-announce(a)lists.opendev.org http://lists.opendev.org/cgi-bin/mailman/listinfo/service-announce

1 0

[neutron] Same physical NIC for SR-IOV and other mechanism driver
by Gabriel Omar Gamero Montenegro 21 Oct '20

21 Oct '20

Dear all, Is it possible to use the same physical NIC with the SR-IOV mechanism driver together with other mechanism driver like Open vSwitch or Linux Bridge? If this is the case, how should I map the physical NIC for each agent? I only known how to map the NIC separately for each driver; for example: - for the Linux bridge agent: physnet1: eth3, - for the OvS agent: physnet1: br-provider (eth3 is a port of br-provider) - for the SR-IOV agent: physnet1: eth3 Any guide or sample reference about implementing multiple mechanism drivers would be highly appreciated. Thanks in advance, Gabriel Gamero

2 1

Octavia amphora missing network interface
by Dibbo, Alexander (STFC,RAL,SC) 21 Oct '20

21 Oct '20

Hi All, I'm having an issue with my Octavia deployment in Train. When a load balancer is created I can see the amphora get created with an interface on the management network. After a short while an interface is added for our external network. The external network interface never becomes responsive. If I ssh in to the amphora I can only see the management interface present. If I the reboot the amphora, the external interface appears and becomes responsive. Given this it seems like some kind of race condition. I have tried using all of the test amphora images that are published but the centos8 one seems the closest to working. Is anyone familiar with this issue or a fix? Thanks Alex Regards Alexander Dibbo - Cloud Architect / Cloud Operations Group Leader For STFC Cloud Documentation visit https://stfc-cloud-docs.readthedocs.io<https://stfc-cloud-docs.readthedocs.io/> To raise a support ticket with the cloud team please email cloud-support(a)gridpp.rl.ac.uk<mailto:cloud-support@gridpp.rl.ac.uk> To receive notifications about the service please subscribe to our mailing list at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STFC-CLOUD To receive fast notifications or to discuss usage of the cloud please join our Slack: https://stfc-cloud.slack.com/ This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.

3 3

[designate][octavia] Gerrit breach and commit audit - OK
by Michael Johnson 21 Oct '20

21 Oct '20

I did not see any unusual commits on the lists for either the Octavia or Designate repositories. Thanks, Michael

1 0

[charms] Gerrit breach and commit audit
by Frode Nordahl 21 Oct '20

21 Oct '20

Hello all, On the back of the service announcement [0] from OpenDev admins this morning the OpenStack Charms team have performed an audit of the provided commit blobs. We have found everything to be in order for the repositories we manage. The sheet used for tracking has been made available for review [1]. I would like to thank everyone on the team for the prompt response in dealing with this issue, and we want to thank OpenDev for due diligence in handling the situation. Cheers! 0: http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html 1: https://docs.google.com/spreadsheets/d/1jxswC09mPCrtbAchNQBH5_RO95CTEOJ6VUr… -- Frode Nordahl

1 0

Fwd: [ops] [cinder] __DEFAULT__ volume type
by Rajat Dhasmana 21 Oct '20

21 Oct '20

---------- Forwarded message --------- From: Rajat Dhasmana <rdhasman(a)redhat.com> Date: Sat, Oct 17, 2020 at 12:31 AM Subject: Re: [ops] [cinder] __DEFAULT__ volume type To: Massimo Sgaravatto <massimo.sgaravatto(a)gmail.com> Hi Massimo, On Fri, Oct 16, 2020 at 7:42 PM Massimo Sgaravatto < massimo.sgaravatto(a)gmail.com> wrote: > I have recently updated my Cloud from Rocky to Train (I am running Cinder > v. 15.4.0) > I have a question concerning the __DEFAULT__ volume type, that I don't > remember to have seen before. > > Since Train, cinder has decided to discourage untyped volumes (volumes with None volume type) as it doesn't add any value to the volume attributes. To achieve this, we created the __DEFAULT__ type and migrated all untyped volumes to have the __DEFAULT__ type. > Since: > - I have no volumes using this volume type > - I defined in in the [DEFAULT] section of cinder.conf the attribute > "default_volume_type" to a value different than "__DEFAULT___" > > I assume that I can safely delete the __DEFAULT__ volume type > > Is this correct? > > Yes, as long as there are no volumes using it and there is a valid volume type defined with ``default_volume_type`` config in cinder.conf, you can safely delete it. NOTE: ``default_volume_type`` has a default value of ``__DEFAULT__`` to not allow users to further create untyped volumes, if you are deleting this, make sure there is always a valid volume type defined with ``default_volume_type`` in cinder.conf > Thanks, Massimo > Thanks and Regards Rajat Dhasmana

3 5

[glance] Gerrit breach and commit audit
by Abhishek Kekane 21 Oct '20

21 Oct '20

Hi All, As suggested by the recent announcement of gerrit breach [1], I have audited all commits for glance repo (glance, glance_store, glanceclient) and confirmed that everything looks good. [1] http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html Thanks & Best Regards, Abhishek Kekane

1 0

[cinder] Gerrit breach and commit audit
by Brian Rosmaita 21 Oct '20

21 Oct '20

tl;dr The cinder deliverables repos look OK. Thanks to jungleboyj and smcginnis for help in looking them over. As you may have heard, there was a Gerrit breach in the 1 October to yesterday time frame. Here's a link to the analysis of the breach: http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html The infra team has cleared all Gerrit HTTP passwords and removed any ssh keys that were added after the breach. If you are super-paranoid, feel free to look over the commits to any of the cinder deliverables during the time frame of the breach. You can find them here: https://static.opendev.org/project/opendev.org/gerrit-diffs/ Like I said, some of us have looked them over and not noticed anything suspect. What you'd be looking for is that an approval you've made or your +2 vote on an approved patch may have been put there by someone other than you. So if you see your +2 or +W on a patch that you have no memory of actually looking at, that would be considered suspicious activity. (On many levels.) If you notice such a situation, please notify us immediately. cheers, brian

1 0

[Telemetry] Gerrit breach and commit audit
by Matthias Runge 21 Oct '20

21 Oct '20

Hi there, you may have seen the announcement of the gerrit breach[1]. I went through the changes we had in telemetry and I'm confident we were not affected. In any case, if you happen to see something suspicious, please let me know. Matthias [1] http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html

1 0

[nova][live-migration] Nova live-migration fails due to duplicate records in ml2_port_bindings table
by Zhi CZ Chang 21 Oct '20

21 Oct '20

2 1

[horizon] No meetings during the Summit and PTG
by Ivan Kolodyazhny 21 Oct '20

21 Oct '20

He team, As agreed on the last weekly meeting, we'll skip the next two meetings to allow everybody attend OpenInfra Summit and PTG. The next meeting will be on November, 4th Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 0

[Ussuri] [horizon] Cannot Create Port with Fixed IP Address
by Lazuardi Nasution 21 Oct '20

21 Oct '20

Hi, With Ussuri on Ubuntu 20.04, I can create port with fixed IP address by CLI but I cannot do the same by Horizon GUI. I find some error like following on /var/log/apache2/error.log openstack_dashboard.dashboards.project.networks.ports.workflows Failed to create a port for network 91f04dfb-7f69-4050-8b3b-142ee555ae55: dictionary keys changed during iteration By more inspection, I can find that horizon never send that create port request to neutron. So I think it is horizon problem. Is this expected result or is this horizon bug? Is this related to policy? Best regards,

2 2

Re: packstack fails every time - pymysql.err.OperationalError: (1040, 'Too many connections')
by lejeczek 21 Oct '20

21 Oct '20

On 20/10/2020 11:02, Javier Pena wrote: > > Hi guys. > I'm trying to deploy with "packstack --allinone" and > it always (tried ~5 times) fails with: > ... > ERROR : Error appeared during Puppet > run:A.B.C.D_compute.pp > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > pymysql.err.OperationalError: (1040, 'Too many > connections') > You will find full trace in log > /var/tmp/packstack/20201018-183415-ik3ijyw7/manifests/172.24.154.202_compute.pp.log > Please check log file > /var/tmp/packstack/20201018-183415-ik3ijyw7/openstack-setup.log > for more information > > > If some expert might be interested then in > /var/tmp/packstack/20201018-183415-ik3ijyw7/manifests/172.24.154.202_compute.pp.log > .... > Notice: > /Stage[main]/Nova::Compute::Libvirt/Nova_config[DEFAULT/compute_driver]/ensure: > created > Notice: > /Stage[main]/Nova::Compute::Libvirt/Nova_config[vnc/server_listen]/ensure: > created > Notice: > /Stage[main]/Nova::Compute::Libvirt/Nova_config[libvirt/virt_type]/ensure: > created > Notice: > /Stage[main]/Nova::Compute::Libvirt/Nova_config[libvirt/cpu_mode]/ensure: > created > Notice: > /Stage[main]/Nova::Compute::Libvirt/Nova_config[libvirt/inject_password]/ensure: > created > Notice: > /Stage[main]/Nova::Compute::Libvirt/Nova_config[libvirt/inject_key]/ensure: > created > Notice: > /Stage[main]/Nova::Compute::Libvirt/Nova_config[libvirt/inject_partition]/ensure: > created > Notice: > /Stage[main]/Nova::Migration::Libvirt/Nova_config[libvirt/live_migration_uri]/ensure: > created > Notice: > /Stage[main]/Nova::Compute::Libvirt::Services/Service[libvirt]/ensure: > ensure changed 'stopped' to 'running' > Notice: > /Stage[main]/Neutron::Deps/Anchor[neutron::service::begin]: > Triggered 'refresh' from 2 events > Notice: > /Stage[main]/Nova::Deps/Anchor[nova::config::end]: > Triggered 'refresh' from 22 events > Notice: > /Stage[main]/Nova::Deps/Anchor[nova::service::begin]: > Triggered 'refresh' from 1 event > Notice: > /Stage[main]/Nova::Compute/Nova::Generic_service[compute]/Service[nova-compute]/ensure: > ensure changed 'stopped' to 'running' > Notice: > /Stage[main]/Nova::Deps/Anchor[nova::service::end]: > Triggered 'refresh' from 1 event > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > An error has occurred: > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > Traceback (most recent call last): > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/base.py", > line 2262, in _wrap_pool_connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return fn() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", > line 294, in unique_connection > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return _ConnectionFairy._checkout(self) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", > line 751, in _checkout > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > fairy = _ConnectionRecord.checkout(pool) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", > line 483, in checkout > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > rec = pool._do_get() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/impl.py", > line 138, in _do_get > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > self._dec_overflow() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/util/langhelpers.py", > line 68, in __exit__ > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > compat.reraise(exc_type, exc_value, exc_tb) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/util/compat.py", > line 129, in reraise > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > raise value > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/impl.py", > line 135, in _do_get > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return self._create_connection() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", > line 299, in _create_connection > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return _ConnectionRecord(self) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", > line 428, in __init__ > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > self.__connect(first_connect_check=True) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", > line 630, in __connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > connection = pool._invoke_creator(self) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/strategies.py", > line 114, in connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return dialect.connect(*cargs, **cparams) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/default.py", > line 453, in connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return self.dbapi.connect(*cargs, **cparams) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/__init__.py", > line 94, in Connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return Connection(*args, **kwargs) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/connections.py", > line 325, in __init__ > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > self.connect() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/connections.py", > line 599, in connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > self._request_authentication() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/connections.py", > line 861, in _request_authentication > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > auth_packet = self._read_packet() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/connections.py", > line 684, in _read_packet > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > packet.check_error() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/protocol.py", > line 220, in check_error > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > err.raise_mysql_exception(self._data) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/err.py", > line 109, in raise_mysql_exception > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > raise errorclass(errno, errval) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > pymysql.err.OperationalError: (1040, 'Too many > connections') > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > The above exception was the direct cause of the > following exception: > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > Traceback (most recent call last): > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/nova/cmd/manage.py", > line 2777, in main > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > ret = fn(*fn_args, **fn_kwargs) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/nova/cmd/manage.py", > line 1144, in discover_hosts > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > by_service) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/nova/objects/host_mapping.py", > line 256, in discover_hosts > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > cell_mappings = objects.CellMappingList.get_all(ctxt) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/oslo_versionedobjects/base.py", > line 184, in wrapper > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > result = fn(cls, context, *args, **kwargs) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/nova/objects/cell_mapping.py", > line 256, in get_all > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > db_mappings = cls._get_all_from_db(context) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/oslo_db/sqlalchemy/enginefacade.py", > line 1013, in wrapper > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > with self._transaction_scope(context): > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File "/usr/lib64/python3.6/contextlib.py", line 81, in > __enter__ > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return next(self.gen) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/oslo_db/sqlalchemy/enginefacade.py", > line 1063, in _transaction_scope > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > context=context) as resource: > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File "/usr/lib64/python3.6/contextlib.py", line 81, in > __enter__ > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return next(self.gen) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/oslo_db/sqlalchemy/enginefacade.py", > line 658, in _session > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > bind=self.connection, mode=self.mode) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/oslo_db/sqlalchemy/enginefacade.py", > line 418, in _create_session > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > self._start() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/oslo_db/sqlalchemy/enginefacade.py", > line 510, in _start > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > engine_args, maker_args) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/oslo_db/sqlalchemy/enginefacade.py", > line 534, in _setup_for_connection > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > sql_connection=sql_connection, **engine_kwargs) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/debtcollector/renames.py", > line 43, in decorator > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return wrapped(*args, **kwargs) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/oslo_db/sqlalchemy/engines.py", > line 201, in create_engine > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > test_conn = _test_connection(engine, max_retries, > retry_interval) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/oslo_db/sqlalchemy/engines.py", > line 376, in _test_connection > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return engine.connect() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/base.py", > line 2193, in connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return self._connection_cls(self, **kwargs) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/base.py", > line 103, in __init__ > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > else engine.raw_connection() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/base.py", > line 2293, in raw_connection > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > self.pool.unique_connection, _connection > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/base.py", > line 2266, in _wrap_pool_connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > e, dialect, self > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/base.py", > line 1534, in _handle_dbapi_exception_noconnection > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > util.raise_from_cause(newraise, exc_info) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/util/compat.py", > line 383, in raise_from_cause > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > reraise(type(exception), exception, tb=exc_tb, > cause=cause) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/util/compat.py", > line 128, in reraise > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > raise value.with_traceback(tb) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/base.py", > line 2262, in _wrap_pool_connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return fn() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", > line 294, in unique_connection > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return _ConnectionFairy._checkout(self) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", > line 751, in _checkout > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > fairy = _ConnectionRecord.checkout(pool) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", > line 483, in checkout > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > rec = pool._do_get() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/impl.py", > line 138, in _do_get > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > self._dec_overflow() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/util/langhelpers.py", > line 68, in __exit__ > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > compat.reraise(exc_type, exc_value, exc_tb) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/util/compat.py", > line 129, in reraise > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > raise value > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/impl.py", > line 135, in _do_get > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return self._create_connection() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", > line 299, in _create_connection > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return _ConnectionRecord(self) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", > line 428, in __init__ > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > self.__connect(first_connect_check=True) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/pool/base.py", > line 630, in __connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > connection = pool._invoke_creator(self) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/strategies.py", > line 114, in connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return dialect.connect(*cargs, **cparams) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/default.py", > line 453, in connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return self.dbapi.connect(*cargs, **cparams) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/__init__.py", > line 94, in Connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > return Connection(*args, **kwargs) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/connections.py", > line 325, in __init__ > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > self.connect() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/connections.py", > line 599, in connect > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > self._request_authentication() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/connections.py", > line 861, in _request_authentication > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > auth_packet = self._read_packet() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/connections.py", > line 684, in _read_packet > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > packet.check_error() > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/protocol.py", > line 220, in check_error > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > err.raise_mysql_exception(self._data) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > File > "/usr/lib/python3.6/site-packages/pymysql/err.py", > line 109, in raise_mysql_exception > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > raise errorclass(errno, errval) > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > sqlalchemy.exc.OperationalError: > (pymysql.err.OperationalError) (1040, 'Too many > connections') > Notice: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]/returns: > (Background on this error at: http://sqlalche.me/e/e3q8) > Error: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]: > Failed to call refresh: 'nova-manage cell_v2 > discover_hosts' returned 255 instead of one of [0] > Error: > /Stage[main]/Nova::Cell_v2::Discover_hosts/Exec[nova-cell_v2-discover_hosts]: > 'nova-manage cell_v2 discover_hosts' returned 255 > instead of one of [0] > > Hi, > > This might happen if you have a lot of CPUs in your > machine, since Packstack will spawn by default 1 worker > per CPU on every service. In some cases, that is too much > for the default MariaDB open file parameters. > > Can you try adding "--service-workers=2" to your packstack > command-line? Alternatively, you can set the > CONFIG_SERVICE_WORKERS option in your answer file. > Yes! that seems to be the fix for my. Lots of cores in the box is my case. > Regards, > Javier > > Bit discouraging to fail at start but I trust you can > share some good advice. > I'm on Centos8 with ussuri. > Many thanks, L. > >

1 0

[all][tc] Re: divisive language discussion
by Brian Rosmaita 21 Oct '20

21 Oct '20

Hi Ryan, Thank you for your thoughtful email. Apologies for top posting, but I simply want to make a general observation. Hegel postulated a master/slave, not a master/apprentice, dialectic. I think Western culture, at least, has been tainted to the point where on a word association test, the most common association to "master" would be "slave", even if you took the test in a recording studio. (But that's an empirical question and I haven't done any research, it's just a guess.) But what it comes down to for me, is that "master" in "master tape", "headmaster", "master of my domain", etc., is being used metaphorically and not accurately. A "master tape" isn't really a master of all the other tapes, etc. I think the "master" metaphor encourages sloppy thinking, and here I do have some empirical evidence. Take a look at the discussion on this OpenStack Glance review from 2017: https://review.opendev.org/#/c/424752 The original code was using master/slave, and everybody sort of understood what was going on, but it was not in fact accurate, and in addition to purging Hegelianism from Glance, the patch does improve the code and make the relationship more clear. So what's not to like? I don't have a problem removing language whose related metaphors are offensive or exclusionary if it results in a better technical solution. I don't think anyone is proposing that we put up general patches simply replacing 'master' with some other term; the ask is that we do this in a thoughtful way (which will be fought out in gerrit in the usual manner). At least that's how I look at this issue. One more thing and then I will shut up. OpenStack is written in Python partially because it was seen as having a lower barrier to entry than other languages, and would encourage participation and make the community more inclusive. Thus the TC or other appropriate body saying that it's preferred not to use wording identified as oppressive, racist, and sexist by members of our communities doesn't strike me as significantly different from core contributors asking for revisions on patches that write Python code in a non-Pythonic way (that is, using code patterns common in some other programming language, but which are non-idiomatic for Python). I don't mean to minimize your censorship concerns, but I do think they are misplaced. cheers, brian On 10/21/20 12:01 AM, Ryan Taylor wrote: > Hello, > > I was unable to join the session on divisive language today, and there > did not seem to be a recording of the video session, but I wanted to > share some thoughts. I hope you will forgive me for contacting this > email address from the etherpad page. > > Fundamentally, all meaning is symbolic and relational. A word or concept > only has meaning, and can only be defined, in terms of other words and > concepts. That is to say, the meaning of words is highly context-dependent. > > To illustrate my point, please consider the word "owner", and ownership > as a concept: > - generally inoffensive and innocuous > - it is an important meaning that we must be able to express in a > functional language in order to communicate with each other > - has different connotations in different contexts (like most words), > most of which are unrelated to slavery > - not realistically censorable (more to the point, it would be misguided > and futile to attempt to remove it from use) > > However, a slave master and a slave owner are the same thing. Every > logical argument for or against censorship of the word "master" applies > equally to the word "owner", but a reasonable rational person would not > consider "owner" to be an objectionable word. Please genuinely > contemplate this. You may get that "ick" feeling thinking about > ownership of a human being while simultaneously recognizing that this > does not irrevocably taint the word "owner" or the concept of ownership > in general. Careful consideration of this point will reveal that it is > not the words "owner" or "master", nor the concepts of ownership or > mastery, that are problematic - it is the /context/ of these concepts in > relation to slavery that is problematic, when what is owned or mastered > is a human being. > > To further illustrate this point, please consider e.g. master tape, > master copy, digital masters > (https://en.wikipedia.org/wiki/Digital_master > <https://en.wikipedia.org/wiki/Digital_master>), audio mastering, master > of ceremonies, master key, master of arts or science, postmaster, > headmaster/schoolmaster, mastery of a language or musical instrument, > etc. These terms use the general meaning of "master" or "mastery", > which is to have control, authority, importance, or skill, and are not > related to slavery. > > We work in technical and knowledge-based fields. We need concise, rich > technical language to be able to express a wide range of relationships > and interactions in highly complex systems in order to be able to > communicate effectively, without further overloading terms or creating > ambiguity. And our work relies on intelligent rational thought and > decision making. > > Students of history know that anything resembling censorship > (self-censorship or otherwise) or expunging a word from use must be > considered, if at all, with great care and deliberation. > It would be a fallacy to believe that because slavery involved slave > masters, all uses and connotations of the term "master" involve slavery. > Similarly, considering and discussing the terms "master" and "slave" > together on the same basis and in the same context of slavery brings an > implicit bias to the discussion; they should be considered separately. > > I believe the best course of action is to remove the term "slave" and > the context of slavery from code and documentation, while carefully > assessing the context of usage of other words and evaluating them on a > case by case basis. For example, "master node" or "master branch", when > there are no slave nodes or slave branches and no context or implication > of slavery, constitute a valid and accurate non-slavery-related use of > the English word "master" and must be accepted as legitimate uses of > language. > > I hope this may clarify where to draw the line between a genuine effort > to avoid using terms with negative historical connotations that may > cause offense, and censorship in the form of designating words as "bad" > or "problematic" regardless of intent, context or meaning. > > Sincerely, > -rt >

1 0

[tc] weekly update
by Mohammed Naser 21 Oct '20

21 Oct '20

Hi everyone, Here's an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Add gmann liaison preference https://review.opendev.org/758602 - Resetting projects' TC liaisons empty https://review.opendev.org/758600 - Adopting the DPL governance model for oslo https://review.opendev.org/757906 - Implement distributed leadership in tools and schema https://review.opendev.org/757966 - Update TC size https://review.opendev.org/758168 - Add nomination for TC chair https://review.opendev.org/758181 - Appoint Adam Harwell as Octavia PTL https://review.opendev.org/758121 - Appoint XueFeng Liu as Senlin PTL https://review.opendev.org/758122 - Appoint Rafael Weingartner as CloudKitty PTL https://review.opendev.org/758120 - Appoint Frode Nordahl as OpenStack Charms PTL https://review.opendev.org/758119 - Add election schedule exceptions in charter https://review.opendev.org/751941 - Clarify impact on releases for SIGs https://review.opendev.org/752699 - Add assert:supports-standalone https://review.opendev.org/722399 - Select Prvisep as the Wallaby Goal https://review.opendev.org/755590 - Add danms liaison preferences https://review.opendev.org/758822 ## General Changes - Record Wallaby Cycle PTL and TC election results https://review.opendev.org/757971 # Other Reminders - PTG Brainstorming: https://etherpad.opendev.org/p/tc-wallaby-ptg - PTG Registration: https://october2020ptg.eventbrite.com Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0