- openstack-discuss - lists.openstack.org

[kuryr] Job running open resolver
by corvus＠inaugust.com 03 Mar '20

03 Mar '20

Hi, The openstack-infra team received a report from one of our infrastructure donors that a gate job run by Kuryr is running a DNS resolver open to the Internet. This is dangerous as, if discovered, it can be used as part of DNS reflection attacks. The community and our infrastructure donors share an interest in avoiding misuse of our resources. Would you please look into whether this job is perhaps opening its iptables ports too liberally, and whether that can be avoided? The job is kuryr-kubernetes-tempest-containerized-ovn, and the build which triggered the alerting system is this one: https://zuul.opendev.org/t/openstack/build/166301f57b21402d8d8443bb1e17f970 Thanks, Jim

3 2

[Swift] Errno 13 Permission denied writing objects xattr while upgrading from Kilo to Queens
by Gui Maluf 03 Mar '20

03 Mar '20

Hi all, I'm struggling with something really wierd. 3 weeks ago I started upgrading my Keystone + Swift Ubuntu environment from Kilo to Queens. So I moved from Ubuntu 14.04 to 18.04. I can create new accounts and containers. But no objects. I think between Mitaka and Newton my storages started to throw Permission Denied error while writing object metadata. I saw that the piece of python code where I getting problem was changed in Rocky version and in hope of getting things fixed I've upgraded storage version. But the error persists. http://paste.openstack.org/show/790217/ I've check everything I could, user, permissions, mount options. But I still getting this error. I wrote a python script for creating files and writing metadata within the swift mount with swift user and everything works fines. Don't know what to do anymore. This is a "dev" environment with two storages only and a few disks. Since I'm planning to do in the production environment I'm quite scared if this happens again. Thanks in advance -- *guilherme* \n11 \t *maluf*

2 1

[idea] voting procedure and the choice's engineering
by Herve Beraud 03 Mar '20

03 Mar '20

Hello openstacker, I proposed a new openstack/idea to open discussion about how we should decide, when, and for what purpose, and the methods and tools to help us in this task. https://review.opendev.org/#/c/710107/ This document is not a "well finished document" but more a draft to open the debate and to help us to make the decisions better. I referenced some methods and tools. If some of you are interested by this topic then do not hesitate to leave comments and push changes on this document. Communities are driven by choices and decisions, Openstack is a community, let's decide how to choose on Openstack. -- 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-----

1 0

oslotest no longer pulls in stestr
by Ben Nemec 03 Mar '20

03 Mar '20

Hi all, We just released [0], which removes stestr as a requirement for oslotest. As a result, if you were relying on oslotest to pull in stestr you are most likely broken now. We did check for this situation before making the change, but it seems we missed at least one project so I'm sending this out in case anyone else is affected. The fix is to explicitly list stestr in your test-requirements (oslotest doesn't actually need stestr, so it's not the right place for the requirement to live). Reply here or ping us in #openstack-oslo with any questions. Thanks. -Ben 0: https://review.opendev.org/#/c/615826

1 0

[all] oslotest 4.0 drops the moxstubout and functional modules, stestr dependency
by Stephen Finucane 03 Mar '20

03 Mar '20

Per $subject, the 'oslotest.moxstubout' modules has been removed in oslotest 4.0 and we no longer include 'stestr' in our list of dependencies. I think I've resolved all issues in the 'openstack/' namespaced projects, but if not the remedies are to either switch to mock or explicitly included 'stestr' in your 'test-requirements.txt' file, respectively. We've also removed the 'oslotest.functional' module, but there do not appear to have been any users of this module. Stephen

1 0

[queens][neutron][fwaas_v2] PENDING_UPDATE
by Ignazio Cassano 03 Mar '20

03 Mar '20

Hello All, I installed firewall v2 on queens based on centos 7. I create a firewall group policy and a firewall group rulle with that policy. The firewall results ACTIVE AND UP and INACTIVE When I ttry to apply the firewall group to an instance port : openstack firewall group set --port c7c8be58-35de-47fe-87db-39bbd681db8b fwg1 It does not works and goes in pending update status. L3 agent log reports: Could not load neutron_fwaas.services.firewall.drivers.linux.iptables_fwaas_v2.IptablesFwaasDriver But the file esists I am using firewall_driver = openvswitch Please, whai is wrong ? I read Supports L2 firewalling (VM ports) was planned for ocata and I am on queens. Please, help me. Ignazio

2 2

[goals][Drop Python 2.7 Support] Week R-10 Update
by Ghanshyam Mann 03 Mar '20

03 Mar '20

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" at end of R-10 week. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… Highlights: ======== * We already passed the deadline but still work is not completed on this. * Few tempest plugins are failing. * I request projects again to merge the passing patches asap. Project wise status and need reviews: ============================ Phase-1 status: All the OpenStack services have dropped the python2.7. Phase-2 status: * Few Tempest plugins are still not merged. I am debugging a few failing plugins with the project team. ** tempest plugins are passing and ready to merge. *** barbican-tempest-plugin: https://review.opendev.org/#/c/704083/ *** cyborg-tempest-plugin: https://review.opendev.org/#/c/704076/ *** magnum-tempest-plugin: https://review.opendev.org/#/c/704069/ *** congress-tempest-plugin: https://review.opendev.org/#/c/694437/ *** heat-tempest-plugin: https://review.opendev.org/#/c/704225/ *** kuryr-tempest-plugin: https://review.opendev.org/#/c/704072/ ** Failing plugins which need debugging and more work: *** trove-tempest-plugin: https://review.opendev.org/#/c/692041/ *** ironic-tempest-plugin: https://review.opendev.org/#/c/704093/ * Started pushing the required updates on deployment projects. ** Completed or no updates required: *** Openstack-Chef - not required *** Packaging-Rpm - Done *** Puppet Openstack- Done ** In progress: *** Openstack Charms *** Openstackansible - In-progress. centos7 jobs are failing on few projects. ** Waiting from projects team to know the status: *** Openstack-Helm (Helm charts for OpenStack services) *** Tripleo (Deployment service) * Open review: https://review.opendev.org/#/q/topic:drop-py27-support+status:open Phase-3 status: This is audit and requirement repo work which is not started yet. I will start this once all the phase-2 work mentioned above is completed. How you can help: ============== - Review the patches. Push the patches if I missed any repo. -gmann

1 0

[tripleo] centos-8 status
by Wesley Hayutin 03 Mar '20

03 Mar '20

Greetings everyone! First off, apologies for using hackmd in this case for our status. We will be moving to a fully non-hosted open source version asap. We have been making significant progress with CentOS-8 based jobs in TripleO Ussuri, our full status is here [1]. You will see tripleo-ci-centos-8 standalone jobs hitting your reviews. If you find any issues please just treat the same as any other bug and open a launchpad w/ "alert" set to the tag. Thanks for everybody's hard work and patience as we get the rest of the jobs running smoothly in the upstream. [1] https://hackmd.io/HrQd03c9SxOMtFPFrq50tg?view

1 0

Virtualenv (and Tox) broken when run under python<3.6
by Clark Boylan 02 Mar '20

02 Mar '20

A recent release of importlib-resources (1.1.0) no longer works on python2.7 or python3.5. The issue is they import typing's ContextManager which didn't exist until python3.6 [0]. This means that python2 jobs and python3.5 jobs are currently unhappy if they need virtualenv. Unfortunately, many of our jobs use tox which uses virtualenv. One workaround being investigated [1] is to install importlib-resources==1.0.2 which does not try to use typing's ContextManager. If this is confirmed to work we will want to consider adding this change to the base job so that all jobs don't have to fix it separately. Note the version of python here is the one used to run virtualenv not the version of python being installed into the virtualenv. This means python3.6 running virtualenv to create a python2 virtualenv should be fine. But python3.5 running virtualenv to create a python3.6 env would not be fine. [0] https://gitlab.com/python-devs/importlib_resources/issues/83 [1] https://review.opendev.org/#/c/710729/ Clark

1 2

[TaskFlow] running multiple engines on a shared thread
by Sachin Laddha 02 Mar '20

02 Mar '20

Hi, We are using taskflow to execute workflows. Each workflow is executed by a separate thread (using engine.run() method). This is limiting our capability to execute maximum number of workflows that can run in parallel. It is limited by the number of threads there in the thread pool. Most of the time, the workflow tasks are run by agents which could take some time to complete. Each engine is alive and runs on a dedicated thread. Is there any way to reuse or run multiple engines on one thread. The individual tasks of these engines can run in parallel. I came across iter_run method of the engine class. But not sure if that can be used for this purpose. Any help is highly appreciated.

2 3

[neutron] bug deputy report for 2020-02-24 week
by Takashi Yamamoto 02 Mar '20

02 Mar '20

2020-02-24 week Someone familiar with these topics need to investigate DHCP agent: https://bugs.launchpad.net/neutron/+bug/1864711 DHCP port rescheduling causes ports to grow, internal DNS to be broken WSGI: https://bugs.launchpad.net/neutron/+bug/1864418 has wrong with use apache to start neutron api in docker container L3 agent: https://bugs.launchpad.net/neutron/+bug/1864963 loosing connectivity to instance with FloatingIP randomly API server performance: https://bugs.launchpad.net/neutron/+bug/1865223 [scale issue] regression for security group list between Newton and Rocky+ RFE https://bugs.launchpad.net/neutron/+bug/1864841 Neutron -> Designate integration does not consider the dns pool for zone Medium https://bugs.launchpad.net/neutron/+bug/1864822 Openvswitch Agent - Connexion openvswitch DB Broken Low https://bugs.launchpad.net/neutron/+bug/1864374 ml2 ovs does not flush iptables switching to FW ovs OVN-specific stuff High https://bugs.launchpad.net/neutron/+bug/1864620 [OVN] neutron_tempest_plugin.scenario.test_security_groups.NetworkSecGroupTest.test_multiple_ports_portrange_remote often fails Medium https://bugs.launchpad.net/neutron/+bug/1864833 [OVN] Functional tests start with OVSDB binary 2.9 instead 2.12 https://bugs.launchpad.net/neutron/+bug/1864639 [OVN] UpdateLRouterPortCommand and AddLRouterPortCommand needs to specify network Wishlist https://bugs.launchpad.net/neutron/+bug/1864640 [Ussuri] Neutron API writes to the Southbound DB

1 0

Retiring openstack/faafo repository
by Andreas Jaeger 01 Mar '20

01 Mar '20

This repo was part of the first-app document that was retired last year as part of the api-site retirement work. Thus, I'm retiring the openstack/faafo repository now. Patches are pushed with topic:retire-faafo, starting at https://review.opendev.org/710652 Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

1 0

[all] Moving towards OpenDev
by Mohammed Naser 29 Feb '20

29 Feb '20

Hi everyone, The OpenStack infrastructure team has helped build an extremely powerful set of tools which we use on a daily basis in order to build OpenStack. You may have noticed that Open Infrastructure projects (such as Zuul, StarlingX, Airship, etc) have leveraged these tools as well as they found them to be extremely powerful and useful to build software by leveraging our four opens. As you might have noticed, there has been many references to OpenDev and it's time that we split off the infrastructure team to it's own separate community with governance and the OpenStack infrastructure team will continue to help work with the OpenDev team in order to keep our lights running (and most likely, those two teams will be the same at the start, but the idea is hoping that one or both grow separately). I'd like to invite our community to please look at the following two patches and leave your comments. Regardless how you feel about this, we'd really appreciate if you can leave a review (-1 or +1) just to show some sort of acknowledgment and help signal that the community is aware of this upcoming change. I'm certainly very excited about it. :) https://review.opendev.org/#/c/710020/ https://review.opendev.org/#/c/703488/ Thanks everyone! Regards, Mohammed

3 3

[tripleo] openstack-train mirror for CentOS aarch64
by Lenny Verkhovsky 28 Feb '20

28 Feb '20

Hi, I see that there is no openstack-train repo for aarch64 for CentOS[1] This repo is also used by kolla project. Who maintains it and if there are any plans for adding train repo? [1] http://mirror.centos.org/altarch/7/cloud/aarch64/ Best Regards Lenny Verkhovsky Mellanox Technologies<http://www.mellanox.com/> office:+972 74 712 92 44 irc:lennyb

2 1

[security] Security SIG Newsletter - Feb 2020
by Gage Hugo 28 Feb '20

28 Feb '20

#Month Feb 2020 - Security SIG Meeting Info: http://eavesdrop.openstack.org/#Security_SIG_meeting - Weekly on Thursday at 1500 UTC in #openstack-meeting - Agenda: https://etherpad.openstack.org/p/security-agenda - https://security.openstack.org/ - https://wiki.openstack.org/wiki/Security-SIG #Updates - The Security SIG has recently updated the reporting guidelines for private security bugs to now have a max timeframe of 90 days for embargos (excluding unusual circumstances). We have begun marking all existing private bugs to go public after 90 days from the date that it was updated. - - The Security SIG has reached out about obtaining a room/timeslot for the Vancouver PTG. We will be requesting a spot, likely just a shorter timeslot due to a small amount of given interest. However we should be able to have time to discuss any topics brought forward. The first OSSA of the year was released this month, for more details check out the link below. #VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - OSSA-2020-001 was released: https://security.openstack.org/ossa/OSSA-2020-001.html

1 0

[kuryr] macvlan driver looking for an owner
by Roman Dobosz 28 Feb '20

28 Feb '20

Hi, Recently we migrated most of the drivers and handler to OpenStackSDK, instead of neutron-client[1], and have a plan to drop neutron-client usage. One of the drivers - MACVLAN based interfaces for nested containers - wasn't migrated due to lack of confidence backed up with sufficient tempest tests. Therefore we are looking for a maintainer, who will take care about both - migration to the openstacksdk (which I can help with) and to provide appropriate environment and tests. In case there is no interest on continuing support for this driver we will deprecate it and remove from the source tree possibly in this release. [1] https://review.opendev.org/#/q/topic:bp/switch-to-openstacksdk -- Cheers, Roman Dobosz gryf@freenode

2 2

[release] Release countdown for week R-10, March 2-6
by Sean McGinnis 28 Feb '20

28 Feb '20

General Information ------------------- The following cycle-with-intermediary deliverables have not done any intermediary release yet during this cycle. The cycle-with-rc release model is more suited for deliverables that plan to be released only once per cycle. As a result, we have proposed[1] to change the release model for the following deliverables: freezer karbor networking-baremetal neutron-fwaas-dashboard, neutron-vpnaas-dashboard senlin-dashboard tacker-horizon [1] https://review.opendev.org/#/q/topic:ussuri-cwi PTLs and release liaisons for each of those deliverables can either +1 the release model change, or propose an intermediary release for that deliverable. In absence of answer by the end of R-10 week we'll consider that the switch to cycle-with-rc is preferable. We are now past the published date for the stable/rocky branch to enter the Extended Maintenance phase: https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… A set of patches have been proposed for all cycle-based deliverables in rocky to tag the last release as "rocky-em". After this point, no more official releases will be done. Please acknowledge any patches for your team if you have not already done so, or let us know if there are some last minute patches on their way to merging that we should hold for. https://review.opendev.org/#/q/status:open+project:openstack/releases+branc… Any patches not acknowledged by March 5 will be assumed to be OK and we will process any remaining patches. We also published a proposed release schedule for the upcoming Victoria cycle. Please check out the separate thread: http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012735… Upcoming Deadlines & Dates -------------------------- Non-client library freeze: April 2 (R-6 week) Client library freeze: April 9 (R-5 week) Ussuri-3 milestone: April 9 (R-5 week) OpenDev+PTG Vancouver: June 8-11

1 0

[RDO][tripleo][kolla][puppet] Moving CentOS8 master dependencies repo in RDO
by Alfredo Moralejo Alonso 28 Feb '20

28 Feb '20

Hi, In the next hours we are moving RDO to a new Dependencies repo for CentOS8 master based on new CBS (CentOS Build System) builds. We have tested this new repo for all the projects that we know use it (kolla, packstack, puppet-openstck-integration and tripleo) and we have a plan to make the transition non-disrupting so we expect not to affect gates on any project by modifying [1] in several steps. Let us know if you notice abnormal behavior so that we can fix any issue that may arise or even revert the change if needed. Best regards, Alfredo [1] https://trunk.rdoproject.org/centos8-master/delorean-deps.repo

2 1

[keystone] [keystonemiddleware] [neutron] [keystone_authtoken] auth_url not available via oslo_config
by Justin Cattle 28 Feb '20

28 Feb '20

Hi, I'm reaching out for help with a strange issue I've found. Running openstack queens, on ubuntu xenial. We have a bunch of different sites with the same set-up, recently upgraded from mitaka to queens. However, on this one site, after the upgrade, we cannot start neutron-server. The reason is, that the ml2 plugin throws an error because it can't find auth_url from the keystone_authtoken section of neutron.conf. However, it is there in the file. The ml2 plugin is calico, it fails with this error: 2020-02-20 20:14:22.495 2964911 ERROR networking_calico.plugins.ml2.drivers.calico.mech_calico [-] Exception in function %s: TypeError: expected string or buffer 2020-02-20 20:14:22.495 2964911 ERROR networking_calico.plugins.ml2.drivers.calico.mech_calico Traceback (most recent call last): 2020-02-20 20:14:22.495 2964911 ERROR networking_calico.plugins.ml2.drivers.calico.mech_calico File "/usr/lib/python2.7/dist-packages/networking_calico/logutils.py", line 21, in wrapped 2020-02-20 20:14:22.495 2964911 ERROR networking_calico.plugins.ml2.drivers.calico.mech_calico return fn(*args, **kwargs) 2020-02-20 20:14:22.495 2964911 ERROR networking_calico.plugins.ml2.drivers.calico.mech_calico File "/usr/lib/python2.7/dist-packages/networking_calico/plugins/ml2/drivers/calico/mech_calico.py", line 347, in _post_fork_init 2020-02-20 20:14:22.495 2964911 ERROR networking_calico.plugins.ml2.drivers.calico.mech_calico auth_url=re.sub(r'/v3/?$', '', auth_url) + 2020-02-20 20:14:22.495 2964911 ERROR networking_calico.plugins.ml2.drivers.calico.mech_calico File "/usr/lib/python2.7/re.py", line 155, in sub 2020-02-20 20:14:22.495 2964911 ERROR networking_calico.plugins.ml2.drivers.calico.mech_calico return _compile(pattern, flags).sub(repl, string, count) 2020-02-20 20:14:22.495 2964911 ERROR networking_calico.plugins.ml2.drivers.calico.mech_calico TypeError: expected string or buffer When you look at the code, this is because neither auth_url or is found in cfg.CONF.keystone_authtoken. The config defintely exists. I have copied the neutron.conf config from a working site, same error. I have copied the entire /etc/neutron directory from a working site, same error. I have check with strace, and /etc/neutron/neutron.conf is the only neutron.conf being parsed. Here is the keystone_authtoken part of the config: [keystone_authtoken] auth_uri=https://api-srv-cloud.host.domain:5000 region_name=openstack memcached_servers=1.2.3.4:11211 auth_type=password auth_url=https://api-srv-cloud.host.domain:5000 username=neutron password=xxxxxxxxxxxxxxxxxxxxxxxxx user_domain_name=Default project_name=services project_domain_name=Default I'm struggling to understand how the auth_url config is really registered in via oslo_config. I found an excellent exchagne on the ML here: https://openstack.nimeyo.com/115150/openstack-keystone-devstack-confusion-a… This seems to indicate auth_url is only registered if a particular auth plugin requires it. But I can't find the plugin code that does it, so I'm not sure how/where to debug it properly. If anyone has any ideas, I would really appreciate some input or pointers. Thanks! Cheers, Just -- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

5 7

[keystone] Keystone Team Update - Week of 24 February 2020
by Vishakha Agarwal 28 Feb '20

28 Feb '20

# Keystone Team Update - Week of 24 February 2020 ## News ### User Support and Bug Duty Every week the duty is being rotated between the members. The person-in-charge for bug duty for current and upcoming week can be seen on the etherpad [2] [2] https://etherpad.openstack.org/p/keystone-l1-duty ## Open Specs Ussuri specs: https://bit.ly/2XDdpkU Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 8 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 22 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Ussuri Roadmap Stories - Groups in keystone SAML assertion https://tree.taiga.io/project/keystone-ussuri-roadmap/us/33 https://review.opendev.org/#/c/588211/ Add openstack_groups to assertion - Add support for modifying resource options to CLI tool https://tree.taiga.io/project/keystone-ussuri-roadmap/us/53 https://review.opendev.org/#/c/697444/ Adding options to user cli ## Milestone Outlook https://releases.openstack.org/ussuri/schedule.html Feature proposal freeze happens in two weeks. Feature freeze follows four weeks after that. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

WSREP: referenced FK check fail after switching to Galera
by Albert Braden 28 Feb '20

28 Feb '20

I switched our dev and qa clusters to Galera, and they seem to work fine, but I see this error in the logs: Feb 27 11:24:08 us01odc-dev1-ctrl1 mysqld[361982]: 2020-02-27 11:24:08 484069 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `neutron`.`provisioningblocks` I googled around and people say that it is a harmless error, but it seems to be time-correlated with creation of VMs that aren't pingable. https://jira.mariadb.org/browse/MDEV-18562 Is this a harmless error? Do I need to look elsewhere for the reason why some VMs fail to return pings?

2 1

Train release notes: deprecated option show_multiple_locations missing?
by Eugen Block 28 Feb '20

28 Feb '20

Hi, I'm currently evaluating our new OpenStack environment (Train), testing the usual scenarios. In the past I've had issues with nova and rbd backend, when the compute nodes used to download rbd images just to re-import them back to the ceph cluster instead of simply cloning an image. The cause was the show_multiple_locations option that was marked deprecated since Pike but in fact it's still necessary. The release notes of Pike, Queens, Rocky and Stein all mention that the workaround is still required: > The show_multiple_locations configuration option remains deprecated > in this release, but it has not been removed. > (It had been > scheduled for removal in the Pike release.) Please keep a watch on > the Glance release notes and the > glance-specs repository to stay > informed about developments on this issue. The Train release notes don't mention this option anymore but my tests show that it's still required to avoid unnecessary rbd exports/imports. Maybe the release notes for Train should be updated to cover this issue. In case I missed any further information that already addresses this I apologize. Best regards, Eugen

2 4

[UX] Contributing to OpenStack's User Interface
by Trang Le 28 Feb '20

28 Feb '20

Dear OpenStack Discussion Team, I am Trang Le, a student at UC Berkeley Extension interested in contributing to OpenStack’s UX/UI. I am currently pursuing a Professional Diploma in UX/UI and would love to contribute to an open-source project and work with experienced engineers. Before, I have also worked at Fujitsu Vietnam in the open-source team, where I learned a lot about OpenStack through training. Let me know if my message could be of interest to you, and I would be happy to discuss further. All the best, Trang Trang Le UC Berkeley Extension - Professional Diploma - UX/UI Design Smith College - Bachelors of Arts - Mathematics and Statistics Phone: +1 (650) 300 9007 Github: https://github.com/trangreyle

5 7

[tripleo]
by Wesley Hayutin 27 Feb '20

27 Feb '20

Greetings, Pending a zuul restart I suggest not rechecking or workflowing +2 patches atm. Probably should lay off submitting patches as well [1]. You can watch the dashboard [2] or follow twitter [3] for the restart notice if you want to. Thanks [1] http://zuul.openstack.org/builds?result=RETRY_LIMIT [2] http://dashboard-ci.tripleo.org/d/cockpit/cockpit?orgId=1&fullscreen&panelI… [3] https://twitter.com/openstackinfra

2 2

[cinder] ussuri virtual mid-cycle 16 march at 12:00 UTC
by Brian Rosmaita 27 Feb '20

27 Feb '20

The poll results are in. As with session one, there was only one time when everyone can meet (apologies to the "if need be" people, thank you for being flexible). Session Two of the Cinder Ussuri virtual mid-cycle will be held: DATE: Monday, 16 March 2020 TIME: 1200-1400 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Please add topics to the planning etherpad: https://etherpad.openstack.org/p/cinder-ussuri-mid-cycle-planning cheers, brian

1 0