July 2019 - openstack-discuss - lists.openstack.org

[nova][ptg] Shanghai attendance
by Eric Fried 11 Jul '19

11 Jul '19

We (nova) need to let the foundation know about our planned presence at the Shanghai PTG for the U release. To that end, I've seeded an etherpad [1]. If you are a contributor or operator with an interest in nova, please add your name to the Attendance section, even (especially) if you know you are not attending. I need this information by the beginning of August, even if it's tentative. Thanks! efried [1] https://etherpad.openstack.org/p/nova-shanghai-ptg

6 8

openstack-sdk API - Get all flavors for all projects.
by Laurent Dumont 10 Jul '19

10 Jul '19

Hi everyone, I'm trying to map the relationship between projects, host-aggregate and computes. I'm trying to find a way to use the Openstack Python SDK in order to list all existing flavors and the "access_project_ids" seems to be the best way to see which project is associated with the flavor. That said, it seems that the python SDK does not expose the value when querying using "get_flavor". Anyone know of way of getting the information from the SDK? Thanks!

1 0

[tc] agenda for Technical Committee Meeting 11 July 2019 @ 1400 UTC
by Thierry Carrez 10 Jul '19

10 Jul '19

TC Members, Our next meeting will be this Thursday, 11 July at 1400 UTC in #openstack-tc. I'll be your chair and we'll rely on mugsie to keep the GIF game level high. This email contains the agenda for the meeting, based on the content of the wiki [0]. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee * Follow up on past action items ** Health check changes: asettle to update community (done), fungi to update wiki (done), mugise to update yaml file with liasons and mnaser to update the tooling ** Help-most-needed list: AlanClark and zaneb to update investment opportunities document [0] https://etherpad.openstack.org/p/2019-upstream-investment-opportunities-ref… [1] https://review.opendev.org/#/c/657447/ ** Goal selection: lbragstad to prune the community-goals etherpad [2] https://etherpad.openstack.org/p/community-goals ** Pop-up teams: ttx to define pop-up teams [3] https://review.opendev.org/#/c/661356/ [4] https://review.opendev.org/#/c/661983/5 ** SIG governance: tc-members to review goal, popup, and SIG project etherpad [5] https://etherpad.openstack.org/p/explain-team-formate-differentiate ** Review PTL Guide: asettle ttx ricolin to sync up and review the PTL section of the project teams guide to improve the PTL experience [6] https://review.opendev.org/#/c/665699/ * Active initiatives ** Python 3: mnaser to sync up with swift team on python3 migration and mugsie to sync with dhellmann or release-team to find the code for the proposal bot ** Forum follow-up: ttx to organise Milestone 2 forum meeting with tc-members ** Make goal selection a two-step process (needs reviews at https://review.opendev.org/#/c/667932/) * Update on U release naming process * What are retired repos ? Regards, -- Thierry Carrez (ttx)

1 0

[openstack-dev] [neutron] [ptg] Start planning for the PTG in Shanghai
by Miguel Lavalle 10 Jul '19

10 Jul '19

Dear Neutrinos, We need to help the Foundation to plan for the the PTG in Shanghai. To that end, I have created an etherpad to start collecting the names of the team members who plan to attend and also topics to be discussed during our meetings: https://etherpad.openstack.org/p/Shanghai-Neutron-Planning I need to respond back to the Foundation's survey by August 11th. So it will be very helpful if all of you who plan to be in Shanghai add your names and irc nicks to the "Attendees" section no later than August 4th. This deadline doesn't apply to the proposed topics section. For that, we have more time. Regards Miguel

1 0

[horizon] django-pyscss unmaintained?
by Thomas Goirand 10 Jul '19

10 Jul '19

Hi, As I'm maintaining python-django-pyscss in Debian, I've noticed that there's no commit since 2015 on the Github repository, and no pypi release either. I've sent a new pull request here: https://github.com/fusionbox/django-pyscss/pull/45 so that pyscss continues to pass unit tests with Django 2.2, but I have very little hope for it to be merged, as the previous pull request for Django 1.11 was never merged. Is it time to take over the project? Can someone from the Horizon team get in touch with the previous maintainer? Cheers, Thomas Goirand (zigo)

2 1

[ironic] Shanghai PTG/Forum
by Julia Kreger 10 Jul '19

10 Jul '19

Greetings fellow ironic contributors! I've created an initial planning/discussion etherpad for the upcoming Shanghai summit[0]. I need a count of contributors that intend to attend with-in the next few weeks. If you plan on or intend to attend, please indicate so on the etherpad. I look forward to ideas and items for discussion! -Julia [0]: https://etherpad.openstack.org/p/PVG-Ironic-Planning

1 0

[placement] mascot/logo live
by Chris Dent 10 Jul '19

10 Jul '19

https://www.openstack.org/project-mascots has been updated to have the Placement mascot/logo. Here's a sample: https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c0… Thanks very much to the Foundation and their designers for making this happen. In case you missed the discussion [1] about this a while back, we know it looks a bit cranky. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/thread.htm… -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[devstack] Deploy issue on Ubuntu 16.04.
by Guannan GN2 Sun 10 Jul '19

10 Jul '19

Hi team, I meet some problem when deploying devstack(from https://github.com/openstack/devstack master branch) on Ubuntu 16.04. It seems something is wrong with placement-api error message as following: curl -g -k --noproxy '*' -s -o /dev/null -w '%{http_code}%' http://10.240.24.138/placement [[503 == 503]] [ERROR] /opt/stack/devstack/lib/placement:156 placement-api did not start However when I check its status using "systemctl status devstack@placement-api", it is active and running. I also change to "stein" branch and try to deploy again, but still meet the same problem. Does someone meet similar issue before or could someone help me to debug this issue? Below is my local.conf file. Thank you! local.conf: #################################################### [[local|localrc]] # Credentials ADMIN_PASSWORD=password DATABASE_PASSWORD=password RABBIT_PASSWORD=password SERVICE_PASSWORD=password SERVICE_TOKEN=password SWIFT_HASH=password SWIFT_TEMPURL_KEY=password GIT_BASE=${GIT_BASE:-https://git.openstack.org} # A clean install every time RECLONE=yes # Enable Ironic plugin IRONIC_USING_PLUGIN=true enable_plugin ironic git://github.com/openstack/ironic # Enable Tempest enable_service tempest # Disable nova novnc service, ironic does not support it anyway. disable_service n-novnc # Enable Swift for the direct deploy interface. enable_service s-proxy enable_service s-object enable_service s-container enable_service s-account enable_service placement-api enable_service placement-client # Disable Horizon disable_service horizon # Disable Cinder disable_service cinder c-sch c-api c-vol # Swift temp URL's are required for the direct deploy interface SWIFT_ENABLE_TEMPURLS=True # Tempest related options BUILD_TIMEOUT=3000 IRONIC_CALLBACK_TIMEOUT=3000 POWER_TIMEOUT=600 SERVICE_TIMEOUT=600 TEMPEST_PLUGINS+=' /opt/stack/ironic-tempest-plugin' # Ironic related options IRONIC_IS_HARDWARE=true VIRT_DRIVER=ironic IRONIC_HW_NODE_CPU=1 IRONIC_HW_NODE_RAM=4096 IRONIC_HW_NODE_DISK=20 IRONIC_BAREMETAL_BASIC_OPS=True DEFAULT_INSTANCE_TYPE=baremetal # Enable additional hardware types, if needed. IRONIC_ENABLED_HARDWARE_TYPES=ipmi,fake-hardware,xclarity # Don't forget that many hardware types require enabling of additional # interfaces, most often power and management: IRONIC_ENABLED_MANAGEMENT_INTERFACES=ipmitool,fake,xclarity IRONIC_ENABLED_POWER_INTERFACES=ipmitool,fake,xclarity # The 'ipmi' hardware type's default deploy interface is 'iscsi'. # This would change the default to 'direct': #IRONIC_DEFAULT_DEPLOY_INTERFACE=direct # Change this to alter the default driver for nodes created by devstack. # This driver should be in the enabled list above. IRONIC_DEPLOY_DRIVER=ipmi # The parameters below represent the minimum possible values to create # functional nodes. #IRONIC_VM_SPECS_RAM=1280 #IRONIC_VM_SPECS_DISK=10 # Size of the ephemeral partition in GB. Use 0 for no ephemeral partition. IRONIC_VM_EPHEMERAL_DISK=0 # By default, DevStack creates a 10.0.0.0/24 network for instances. # If this overlaps with the hosts network, you may adjust with the # following. PUBLIC_NETWORK_GATEWAY=10.240.24.1 FLOATING_RANGE=10.240.24.0/24 FIXED_RANGE=10.0.0.0/24 HOST_IP=10.240.24.138 SERVICE_HOST=$HOST_IP FIXED_NETWORK_SIZE=256 # Neutron options Q_USE_PROVIDERNET_FOR_PUBLIC=True PUBLIC_INTERFACE=ens9 OVS_PHYSICAL_BRIDGE=br-ens9 PUBLIC_BRIDGE=br-ens9 OVS_BRIDGE_MAPPINGS=public:br-ens9 ALLOCATION_POOL=start=10.0.0.30,end=10.0.0.100 # Log all output to files LOGFILE=/opt/stack/devstack.log LOGDIR=/opt/stack/logs IRONIC_VM_LOG_DIR=/opt/stack/ironic-bm-logs #################################################### Best Regards, Guannan

3 2

[auto-scaling] Auto-scaling SIG update
by Rico Lin 10 Jul '19

10 Jul '19

It has been two months after Summit and PTG [3], and we now have collected some use cases [1], and general documents for auto-scaling [2] (Great thanks to Joseph Davis and Adam Spiers). *Use Cases needed* We need more use cases from all, for autoscaling on/with OpenStack. For example, autoscaling k8s on OpenStack is already a thing, so IMO we need to put some words in use cases too. *Help to improve documents* Please check our new document and help to improve it if you think of any. *Join us* We have IRC channel and meeting so please join us in irc: #openstack-auto-scaling so we can hear you and you can help us. *Add request to our StoryBoard* If you have any feature requests or WIP plan, you can use our storyboard[4] as root trace for them all like request for `Integrate Monasca and Senlin`. *Open for bug?* One question I would like to bring to the team is should we open our storyboard[4] for bug collection? We have some good hands from multiple teams, who can help with bugs. And like feature requests, a top-level story for a bug should be very helpful, but what we need from the reporter in order to get better information about that bug, and also what part should we help? IMO we can make sure bug are well documented, trace bug progress (from top-level view), and help to raise attention(in ML and in events). Would like to hear more opinions on this. *PTG* I already sign up for half-day PTG schedule(as the team still under developing, I would not expect that we need more for now), so I see you all there if you will be there too! [1] https://docs.openstack.org/auto-scaling-sig/latest/use-cases.html [2] https://docs.openstack.org/auto-scaling-sig/latest/theory-of-auto-scaling.h… [3] https://etherpad.openstack.org/p/DEN-auto-scaling-SIG [4] https://storyboard.openstack.org/#!/project/openstack/auto-scaling-sig [5] https://storyboard.openstack.org/#!/story/2005627 -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

2 1

[tc] Assuming control of GitHub organizations
by Jim Rollenhagen 10 Jul '19

10 Jul '19

Hi, The opendev team reached out to me about handing off administrative access of the "openstack" and related organizations on GitHub. They think it would be best if the TC took control of that, or at least took control of delegating that access. In general, the goal here is to support OpenStack's presence and visibility on GitHub. Per Jim Blair: > In the long run, this shouldn't entail a lot of work, generally creating new > repos on GitHub to accept mirroring from opendev systems, performing renames, > handling transfer requests when repos move out of the openstack namespace, > setting and updating descriptions, and curating the list of pinned > repositories. In the short term, we have some archiving and moving to do.[0] Do TC members want to manage this, or should we delegate? One thing to figure out is how to grant that access. The opendev team uses a shared account with two-factor authentication provided by a shared shell account. This mitigates accidental pushes or settings changes when an admin is using their usual GitHub account. The TC (or its delegates) probably doesn't have a shared shell account to do this with. Some options: * each admin creates a second GitHub account for this purpose use a shared * account without 2FA use a shared account with 2FA, share the one time secret * with everyone to configure their own token generator use personal accounts * but be very careful Thoughts on these options? [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006829.html // jim

8 15

[image-encryption][nova][cinder][glance][barbican]Image Encryption popup team meeting
by Josephine Seifert 10 Jul '19

10 Jul '19

Hello, starting with next week, there will be a weekly meeting on *Monday, 13 UTC *[1]**for the Image Encryption popup team. Please feel free to join us :) Greetings Josephine [1] http://eavesdrop.openstack.org/#Image_Encryption_Popup-Team_Meeting

1 0

[watcher] nova cdm builder performance optimizations - summary
by Matt Riedemann 10 Jul '19

10 Jul '19

I wanted to summarize a series of changes which have improved the performance of the NovaClusterDataModel builder for audits across single and multiple cells (in the CERN case) by a factor of 20-30%. There were initially three changes involved (in order): 1. https://review.opendev.org/#/c/659688/ - Optimize NovaClusterDataModelCollector.add_instance_node Reports on that patch alone said it fixed a regression introduced in Stein with scoped audits: "I checked this patch on the my test environment on the stable/stein branch. I have more than 1000 virtual servers (some real, some dummy). Previously, in the stable/rocky branch, the time to build a cluster was about 15-20 minutes, in the Stein branch there was a regression and the time increased to 90 minutes. After this patch, the build time is only 2 minutes." That change was backported to stable/stein. 2. - https://review.opendev.org/#/c/661121/ - Optimize hypervisor API calls (which requires https://review.opendev.org/#/c/659886/) As noted that change requires a patch to python-novaclient if you are looking to backport the change. We can't backport that upstream because of the python-novaclient dependency since it would require bumping the minimum required version of the library on a stable branch which is against stable branch policy (minimum version of library dependencies are more or less frozen on stable branches). That change also requires configuring watcher with: [nova_client] api_version = 2.53 # or greater; train now requires at least 2.56 3. - https://review.opendev.org/#/c/662089/ - Optimize NovaHelper.get_compute_node_by_hostname This optimizes code used to build/update the nova CDM during notification processing and also fixes a bug about looking up the compute service properly. After those three changes were merged, Corne Lukken (Dantali0n) started doing scale and performance testing with and without the changes in a CERN 5-cell test cluster. Corne identified a regression for which Canwei Li determined the root cause and chenker fixed: 4. https://review.opendev.org/#/c/668100/ - Reduce the query time of the instances when call get_instance_list() With that fix applied Corne reported the overall improvement of 20-30% when building the nova CDM during an audit in various scenarios. The actual performance numbers will be sent later as part of a thesis Corne is working on. I want to thank Dantali0n, licanwei and chenker for all of their help with this series of improvements. -- Thanks, Matt

2 1

[nova][ironic] Lock-related performance issue with update_resources periodic job
by Jason Anderson 09 Jul '19

09 Jul '19

Hey OpenStackers, I work on a cloud that allows users to reserve and provision bare metal instances with Ironic. We recently performed a long-overdue upgrade of our core components, all the way from Ocata up through Rocky. During this, we noticed that instance build requests were taking 4-5x (!!) as long as before. We have two deployments, one with ~150 bare metal nodes, and another with ~300. These are each managed by one nova-compute process running the Ironic driver. After investigation, the root cause appeared to be contention between the update_resources periodic task and the instance claim step. There is one semaphore "compute_resources" that is used to control every access within the resource_tracker. In our case, what was happening was the update_resources job, which runs every minute by default, was constantly queuing up accesses to this semaphore, because each hypervisor is updated independently, in series. This meant that, for us, each Ironic node was being processed and was holding the semaphore during its update (which took about 2-5 seconds in practice.) Multiply this by 150 and our update task was running constantly. Because an instance claim also needs to access this semaphore, this led to instances getting stuck in the "Build" state, after scheduling, for tens of minutes on average. There seemed to be some probabilistic effect here, which I hypothesize is related to the locking mechanism not using a "fair" lock (first-come, first-served) by default. Our fix was to drastically increase the interval this task runs at--from every 1 minute to every 12 hours. We only provision bare metal, so my rationale was that the periodic full resource sync was less important and mostly helpful for fixing weird things where somehow Placement's state got out of sync with Nova's somehow. I'm wondering, after all this, if it makes sense to rethink this one-semaphore thing, and instead create a per-hypervisor semaphore when doing the resource syncing. I can't think of a reason why the entire set of hypervisors needs to be considered as a whole when doing this task, but I could very well be missing something. TL;DR: if you have one nova-compute process managing lots of Ironic hypervisors, consider tweaking the update_resources_interval to a higher value, especially if you're seeing instances stuck in the Build state for a while. Cheers, Jason Anderson Cloud Computing Software Developer Consortium for Advanced Science and Engineering, The University of Chicago Mathematics & Computer Science Division, Argonne National Laboratory

5 11

[scientific-sig] IRC today
by Stig Telfer 09 Jul '19

09 Jul '19

Hi All - We have a Scientific SIG IRC meeting coming up at 2100 UTC (about 15 minutes time) in channel #openstack-meeting. Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_July_9th_2019 If you’d like to add anything to the agenda, come along to the meeting and bring it up. Cheers, Stig

1 0

[tripleo] [cisco] [bigswitch] [midonet] Composable Services for Neutron plugins
by Emilien Macchi 09 Jul '19

09 Jul '19

With that thread I'm hoping to reach out some of the folks who were involved in TripleO services for some of the Neutron plugins like Cisco, Bigswitch and Midonet. Some of them still use ExtraConfig interface which isn't super ideal. I'm willing to help convert them into composable services but I'll need help on the reviews and more importantly the actual testing. If you're in CC and can help, good please let me know. If you're not involved anymore, please give me a name if possible. If you were involved and know the plugin doesn't need maintenance, let me know as well, it'll save me time. I started with the Cisco UCSM: https://review.opendev.org/669931 -- Emilien Macchi

1 0

[cinder][stable-maint] July releases from the stable branches
by Brian Rosmaita 09 Jul '19

09 Jul '19

I've posted release patches for the stable branches: https://review.openstack.org/#/q/topic:cinderproject-july-2019 Notes on what is/isn't being released are on the etherpad: https://etherpad.openstack.org/p/cinder-releases-tracking I have a question about the semver for the cinder stable/stein release; it's noted on the patch: https://review.opendev.org/669771 cheers, brian

2 1

[Glance][PTL] Vacation time
by Erno Kuvaja 09 Jul '19

09 Jul '19

Hi all, I'll be away for couple of weeks. I'll be back Wed 24th of July. - Erno "jokke" Kuvaja

1 0

[docs][fuel][infra][ironic][neutron][charms][openstack-ansible][solum][tc] proper retirement of repos
by Mohammed Naser 09 Jul '19

09 Jul '19

Hi everyone, One of the issue that we recently ran into was the fact that there was some inconsistency about merging retirement of repositories inside governance without the code being fully removed. In order to avoid this, I've made a change to our governance repository which will enforce that no code exists in those retired repositories, however, this has surfaced that some repositories were retired with some stale files, some are smaller littler files, some are entire projects still. I have compiled a list for every team, with the repos that are not properly retired that have extra files (using this change which should eventually +1 once we fix it all: https://review.opendev.org/669549) [Documentation] openstack/api-site has extra files, please remove: .gitignore, .zuul.yaml, LICENSE, api-quick-start, api-ref, bindep.txt, common, doc-tools-check-languages.conf, firstapp, test-requirements.txt, tools, tox.ini, www [Documentation] openstack/faafo has extra files, please remove: .gitignore, CONTRIBUTING.rst, LICENSE, Vagrantfile, bin, contrib, doc, etc, faafo, requirements.txt, setup.cfg, setup.py, test-requirements.txt, tox.ini [fuel] openstack/fuel-agent has extra files, please remove: .gitignore, LICENSE, MAINTAINERS, cloud-init-templates, contrib, debian, etc, fuel_agent, requirements.txt, run_tests.sh, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [fuel] openstack/fuel-astute has extra files, please remove: .gitignore, .rspec, .ruby-version, Gemfile, LICENSE, MAINTAINERS, Rakefile, astute.gemspec, astute.service, astute.sysconfig, bin, bindep.txt, debian, examples, lib, mcagents, run_tests.sh, spec, specs, tests [fuel] openstack/fuel-library has extra files, please remove: .gitignore, CHANGELOG, Gemfile, LICENSE, MAINTAINERS, Rakefile, debian, deployment, files, graphs, logs, specs, tests, utils [fuel] openstack/fuel-main has extra files, please remove: .gitignore, 00-debmirror.patch, LICENSE, MAINTAINERS, Makefile, config.mk, fuel-release, iso, mirror, packages, prepare-build-env.sh, report-changelog.sh, repos.mk, requirements-fuel-rpm.txt, requirements-rpm.txt, rules.mk, sandbox.mk, specs [fuel] openstack/fuel-menu has extra files, please remove: .gitignore, MAINTAINERS, MANIFEST.in, fuelmenu, run_tests.sh, setup.py, specs, test-requirements.txt, tox.ini [fuel] openstack/fuel-mirror has extra files, please remove: .gitignore, .mailmap, MAINTAINERS, perestroika, tox.ini [fuel] openstack/fuel-nailgun-agent has extra files, please remove: .gitignore, Gemfile, LICENSE, MAINTAINERS, Rakefile, agent, debian, nailgun-agent.cron, nailgun-agent.gemspec, run_tests.sh, specs [fuel] openstack/fuel-ostf has extra files, please remove: .gitignore, LICENSE, MAINTAINERS, MANIFEST.in, etc, fuel_health, fuel_plugin, ostf.service, pylintrc, requirements.txt, run_tests.sh, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [fuel] openstack/fuel-qa has extra files, please remove: .coveragerc, .gitignore, .pylintrc, .pylintrc_gerrit, MAINTAINERS, core, doc, fuel_tests, fuelweb_test, gates_tests, packages_tests, pytest.ini, run_system_test.py, run_tests.sh, system_test, tox.ini, utils [fuel] openstack/fuel-ui has extra files, please remove: .eslintignore, .eslintrc.yaml, .gitignore, LICENSE, MAINTAINERS, fixtures, gulp, gulpfile.js, karma.config.js, npm-shrinkwrap.json, package.json, run_real_plugin_tests.sh, run_real_plugin_tests_on_real_nailgun.sh, run_ui_func_tests.sh, specs, static, webpack.config.js [fuel] openstack/fuel-virtualbox has extra files, please remove: .gitignore, MAINTAINERS, actions, clean.sh, config.sh, contrib, drivers, dumpkeys.cache, functions, iso, launch.sh, launch_16GB.sh, launch_8GB.sh [fuel] openstack/fuel-web has extra files, please remove: .gitignore, LICENSE, MAINTAINERS, bin, build_docs.sh, debian, docs, nailgun, run_tests.sh, specs, systemd, tools, tox.ini [fuel] openstack/shotgun has extra files, please remove: .coveragerc, .gitignore, .testr.conf, CONTRIBUTING.rst, HACKING.rst, LICENSE, MAINTAINERS, MANIFEST.in, bin, etc, requirements.txt, setup.cfg, setup.py, shotgun, specs, test-requirements.txt, tox.ini [fuel] openstack/fuel-dev-tools has extra files, please remove: .coveragerc, .gitignore, .mailmap, .testr.conf, CONTRIBUTING.rst, HACKING.rst, LICENSE, MAINTAINERS, babel.cfg, contrib, doc, fuel_dev_tools, openstack-common.conf, requirements.txt, setup.cfg, setup.py, test-requirements.txt, tox.ini, vagrant [fuel] openstack/fuel-devops has extra files, please remove: .coveragerc, .gitignore, .pylintrc, .pylintrc_gerrit, LICENSE, MAINTAINERS, bin, devops, doc, run_tests.sh, samples, setup.cfg, setup.py, test-requirements.txt, tox.ini [fuel] openstack/fuel-docs has extra files, please remove: .gitignore, Makefile, _images, _templates, common_conf.py, conf.py, devdocs, examples, glossary, index.rst, make.bat, plugindocs, requirements.txt, setup.cfg, setup.py, tox.ini, userdocs [fuel] openstack/fuel-nailgun-extension-cluster-upgrade has extra files, please remove: .coveragerc, .gitignore, AUTHORS, LICENSE, MANIFEST.in, bindep.txt, cluster_upgrade, conftest.py, nailgun-test-settings.yaml, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [fuel] openstack/fuel-nailgun-extension-iac has extra files, please remove: .gitignore, LICENSE, MANIFEST.in, doc, fuel_external_git, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [fuel] openstack/fuel-nailgun-extension-converted-serializers has extra files, please remove: .coveragerc, .gitignore, LICENSE, MANIFEST.in, bindep.txt, conftest.py, converted_serializers, nailgun-test-settings.yaml, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [fuel] openstack/fuel-octane has extra files, please remove: .coveragerc, .gitignore, .mailmap, Gemfile, Gemfile.lock, HACKING.rst, LICENSE, MAINTAINERS, MANIFEST.in, Rakefile, bindep.txt, deploy, deployment, docs, misc, octane, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tox.ini [fuel] openstack/fuel-upgrade has extra files, please remove: .gitignore [fuel] openstack/tuning-box has extra files, please remove: .coveragerc, .gitignore, .mailmap, .testr.conf, CONTRIBUTING.rst, HACKING.rst, LICENSE, MAINTAINERS, MANIFEST.in, TODO, alembic.ini, babel.cfg, bindep.txt, doc, examples, openstack-common.conf, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini, tuning_box [fuel] openstack/fuel-plugins has extra files, please remove: .gitignore, CHANGELOG.md, CONTRIBUTING.rst, HACKING.rst, LICENSE, MAINTAINERS, examples, fuel_plugin_builder, requirements.txt, run_tests.sh, setup.cfg, setup.py, test-requirements.txt, tox.ini [fuel] openstack/fuel-plugin-murano has extra files, please remove: .gitignore, LICENSE, components.yaml, deployment_scripts, deployment_tasks.yaml, docs, environment_config.yaml, functions.sh, metadata.yaml, node_roles.yaml, pre_build_hook, releasenotes, repositories, test-requirements.txt, tox.ini, volumes.yaml [fuel] openstack/fuel-plugin-murano-tests has extra files, please remove: .gitignore, murano_plugin_tests, openrc.default, requirements.txt, tox.ini, utils [fuel] openstack/fuel-specs has extra files, please remove: .gitignore, .testr.conf, LICENSE, doc, images, policy, requirements.txt, setup.cfg, setup.py, specs, tests, tools, tox.ini [fuel] openstack/fuel-stats has extra files, please remove: .gitignore, LICENSE, MAINTAINERS, MANIFEST.in, analytics, collector, migration, requirements.txt, setup.py, test-requirements.txt, tools, tox.ini [fuel] openstack/python-fuelclient has extra files, please remove: .gitignore, .testr.conf, MAINTAINERS, MANIFEST.in, fuelclient, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [Infrastructure] opendev/puppet-releasestatus has extra files, please remove: .gitignore [ironic] openstack/python-dracclient has extra files, please remove: .gitignore, CONTRIBUTING.rst, HACKING.rst, LICENSE, doc, dracclient, requirements.txt, setup.cfg, setup.py, test-requirements.txt, tox.ini [neutron] openstack/networking-calico has extra files, please remove: .coveragerc, .gitignore, .mailmap, .testr.conf, .zuul.yaml, CONTRIBUTING.rst, HACKING.rst, LICENSE, MANIFEST.in, RELEASING.md, babel.cfg, debian, devstack, doc, networking_calico, playbooks, requirements.txt, rpm, setup.cfg, setup.py, test-requirements.txt, tox.ini [neutron] openstack/networking-l2gw has extra files, please remove: .coveragerc, .gitignore, .testr.conf, .zuul.yaml, CONTRIBUTING.rst, HACKING.rst, LICENSE, MANIFEST.in, babel.cfg, bindep.txt, contrib, debian, devstack, doc, etc, lower-constraints.txt, networking_l2gw, openstack-common.conf, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [neutron] openstack/networking-l2gw-tempest-plugin has extra files, please remove: .gitignore, .zuul.yaml, CONTRIBUTING.rst, HACKING.rst, LICENSE, babel.cfg, contrib, doc, networking_l2gw_tempest_plugin, requirements.txt, setup.cfg, setup.py, test-requirements.txt, tox.ini [neutron] openstack/networking-onos has extra files, please remove: .coveragerc, .gitignore, .mailmap, .pylintrc, .testr.conf, CONTRIBUTING.rst, HACKING.rst, LICENSE, PKG-INFO, TESTING.rst, babel.cfg, devstack, doc, etc, lower-constraints.txt, networking_onos, package, rally-jobs, releasenotes, requirements.txt, setup.cfg, setup.py, test-requirements.txt, tools, tox.ini [neutron] openstack/neutron-vpnaas has extra files, please remove: .coveragerc, .gitignore, .mailmap, .pylintrc, .stestr.conf, .zuul.yaml, CONTRIBUTING.rst, HACKING.rst, LICENSE, TESTING.rst, babel.cfg, devstack, doc, etc, lower-constraints.txt, neutron_vpnaas, playbooks, rally-jobs, releasenotes, requirements.txt, setup.cfg, setup.py, test-requirements.txt, tools, tox.ini [OpenStack Charms] openstack/charm-ceph has extra files, please remove: .gitignore [OpenStackAnsible] openstack/openstack-ansible-os_monasca has extra files, please remove: tests, tox.ini [solum] openstack/solum-infra-guestagent has extra files, please remove: .coveragerc, .gitignore, .mailmap, .testr.conf, CONTRIBUTING.rst, HACKING.rst, LICENSE, MANIFEST.in, babel.cfg, config-generator, doc, etc, requirements.txt, setup.cfg, setup.py, solum_guestagent, test-requirements.txt, tox.ini I'd like to kindly ask the affected teams to help out with this, or any member of our community is more than welcome to push a change to those repos and work with the appropriate teams to help land it. Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

8 11

neutron netns arp issue
by Satish Patel 09 Jul '19

09 Jul '19

Hello, I am deploying openstack-ansible with octavia and i can see neutron created network for lb-mgmt-net which also created dhcp namespace for that network which is in vlan27 so far everything good so for testing i have created vm and it didn't get IP address so i have started troubleshooting and i found my namespace sending arp request but not getting reply back. [root@ostack-infra-2-2 ~]# ip netns exec qdhcp-2b94d9df-dd49-45b5-a992-63fee27bfa77 ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ns-5604eec1-20@if132: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether fa:16:3e:c2:b3:4d brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 172.27.12.3/21 brd 172.27.15.255 scope global ns-5604eec1-20 valid_lft forever preferred_lft forever inet 169.254.169.254/16 brd 169.254.255.255 scope global ns-5604eec1-20 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fec2:b34d/64 scope link valid_lft forever preferred_lft forever This is my linuxbridge [root@ostack-infra-2-2 ~]# brctl show brq2b94d9df-dd bridge name bridge id STP enabled interfaces brq2b94d9df-dd 8000.16d25dbea2cc no br-vlan.27 tap5604eec1-20 on same controller node "ostack-infra-2-2" i have br-lbaas network which has same VLAN 27 subnet IP. now when i ping from dhcp-namespace to outside host on same vlan 27, i can see ARP going out and remote host replying back but my reply coming on br-lbaas interface. [root@ostack-infra-2-2 ~]# ip netns exec qdhcp-2b94d9df-dd49-45b5-a992-63fee27bfa77 ping 172.27.8.4 PING 172.27.8.4 (172.27.8.4) 56(84) bytes of data. >From 172.27.12.3 icmp_seq=1 Destination Host Unreachable >From 172.27.12.3 icmp_seq=2 Destination Host Unreachable on other terminal i am running tcpdump on br-lbaas and i am seeing remote host ARP reply coming on that interface but not going to br-vlan.27 which neutron created. [root@ostack-infra-2-2 network-scripts]# tcpdump -i br-lbaas -nn tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br-lbaas, link-type EN10MB (Ethernet), capture size 262144 bytes 22:41:38.920858 ARP, Reply 172.27.8.4 is-at 32:7c:a1:91:79:7c, length 46 22:41:39.922167 ARP, Reply 172.27.8.4 is-at 32:7c:a1:91:79:7c, length 46 22:41:40.924052 ARP, Reply 172.27.8.4 is-at 32:7c:a1:91:79:7c, length 46 Do you think i can't create two same subnet bridge on same host?

1 0

[Neutron] NUMA aware VxLAN
by Guo, Ruijing 09 Jul '19

09 Jul '19

Hi, Existing neutron ML2 support one VxLAN for tenant network. In NUMA case, VM 0 can be created in node 0 and VM 1 can be created in node 1 and VxLAN is in node 0. VM1 need to cross node, which cause some performance downgrade. Does someone have this performance issue? Does Neutron community have plan to enhance it? Thanks, -Ruijing

3 2

[keystone] Virtual Midcycle Planning
by Colleen Murphy 08 Jul '19

08 Jul '19

Hi team, As discussed in today's meeting, we will be having a virtual midcycle some time around milestone 2. We'll do two days with one three-hour session (with breaks) each day. We will do this over a video conference session, details of how to join will follow closer to the event. I've started a brainstorming etherpad: https://etherpad.openstack.org/p/keystone-train-midcycle-topics Please add discussion topics or hacking ideas to the etherpad and I will try to sort them. We need to decide on when exactly to hold the midcycle. I've created a doodle poll: https://doodle.com/poll/wr7ct4uhpw82sysg Please select times and days that you're available and then we'll try to schedule two back-to-back days (or at least two days in the same week) for the midcycle. Let me know if you have any questions or concerns. Colleen

1 1

[oslo] oslo.config /castellan poster review
by Moises Guimaraes de Medeiros 08 Jul '19

08 Jul '19

Hi, This week I'll be presenting a poster about oslo.config's castellan driver at EuroPython. I'd like to ask y'all interested in the subject to take a look at my poster. I'm planning to print it this Tuesday and I still have some spare space to fit a bit more. The latest version is available at: https://ep2019.europython.eu/media/conference/slides/m7RV4BB-protecting-sec… Thanks a lot! -- Moisés Guimarães Software Engineer Red Hat <https://www.redhat.com> <https://red.ht/sig>

4 3

[docs] Retire openstack/docs-specs
by Stephen Finucane 08 Jul '19

08 Jul '19

Hey, I'm proposing retiring docs-specs [1][2]. This hasn't been used in some time since most of our documentation now lives in individual project repositories and any work that would span these multiple projects would likely exist as a community goal, documented in those relevant repositories. I do not intend for the existing content to be removed - it simply won't be possible to add new specs. Let me know if anyone has a reason not to do this. If not, we'll get a move on with this next week. Stephen [1] https://opendev.org/openstack/docs-specs [2] https://review.opendev.org/#/c/668853/

2 1

[neutron] Bug deputy report (week starting on 2019-07-01)
by Bernard Cafarelli 08 Jul '19

08 Jul '19

Hi Neutrinos, time for a new cycle of bug deputy rotation, which means I was on duty last week, checking bugs up to 1835663 included Quite a few bugs in that list worth a read and further discussion: * port status changing to UP when changing the network name (and possible fallout on DHCP issues) * API currently allowing to set gateway outside of the subnet * How to handle external dependencies recommended version bumps (pyroute bump in queens fixing a memory leak) * possible issue in IPv6 address renewal since we started cleaning the dnsmasq leases file Critical: * Wrong endpoints config with configure_auth_token_middleware - https://bugs.launchpad.net/bugs/1834849 Removal of devstack deprecated option broke designate scenario job Fix merged: https://review.opendev.org/668447 High: * [Queens] Memory leak in pyroute2 0.4.21 - https://bugs.launchpad.net/neutron/+bug/1835044 we need a newer pyroute version Patches on requirements with DNM neutron one for testing in progress: https://review.opendev.org/668676 and https://review.opendev.org/668677 openstack-discuss thread: http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007545.html * Bulk-created ports ignore binding_host_id property - https://bugs.launchpad.net/neutron/+bug/1835209 Issue on bulk port creation work Fix in progress: https://review.opendev.org/#/c/665516/ * flood flow in br-tun table22 incorrect - https://bugs.launchpad.net/neutron/+bug/1835163 Linked to https://bugs.launchpad.net/neutron/+bug/1834979 (see below), this can cause hard to trace l2pop and dhcp issues No owner Medium: * Add ipam.utils.check_gateway_invalid_in_subnet unit tests - https://bugs.launchpad.net/neutron/+bug/1835448 Shows proper usage after bug https://bugs.launchpad.net/neutron/+bug/1835344 (see in Opinion section) Review in progress: https://review.opendev.org/669210 * Port status becomes active after updating network/subnet - https://bugs.launchpad.net/neutron/+bug/1834979 The port of a turned off VM will show as UP after a network modification (reproducer with network name) No owner * Some L3 RPCs are time-consuming especially get_routers - https://bugs.launchpad.net/neutron/+bug/1835663 Probably worth discussing in performance meeting? Incomplete: * Restart dhcp-agent cause IPv6 vm can't renew IP address, will lost minutes or hours - https://bugs.launchpad.net/neutron/+bug/1835484 Cleaning IPv6 addresses from dnsmasq leases file ( https://bugs.launchpad.net/neutron/+bug/1722126) apparently causes VM to loose its address on renewal Waiting for detailed logs, but if ipv6 experts can chime in Opinion: * neutron doesn't check the validity of gateway_ip as a subnet had been created - https://bugs.launchpad.net/neutron/+bug/1835344 How to handle gateway IP outside of the subnet? Discussion in the bug and related review: https://review.opendev.org/669030 Duplicate: * QoS plugin slows down get_ports operation - https://bugs.launchpad.net/neutron/+bug/1835369 Was filled close to https://bugs.launchpad.net/bugs/1834484 Regards, -- Bernard Cafarelli

1 1

[TripleO] Using TripleO standalone with ML2/OVS
by Slawek Kaplonski 08 Jul '19

08 Jul '19

Hi, I was trying to use TripleO standalone for development work in the way how Emilien described it in [1] and indeed it works quite well. Thx Emilien. But now, I’m trying to find out the way how to deploy it with Neutron using ML2/OVS instead of default in TripleO ML2/OVN. And I still don’t know how to do it :/ I know it’s my fault but maybe someone can help me with this and tell me what exactly options I should change there to deploy it with other Neutron backend? Thx in advance for any help. [1] https://my1.fr/blog/developer-workflow-with-tripleo/ — Slawek Kaplonski Senior software engineer Red Hat

3 2

[ops] [nova] [placement] Mismatch between allocations and instances
by Massimo Sgaravatto 08 Jul '19

08 Jul '19

I tried to check the allocations on each compute node of a Ocata cloud, using the command: curl -s ${PLACEMENT_ENDPOINT}/resource_providers/${UUID}/allocations -H "x-auth-token: $TOKEN" | python -m json.tool I found that, on a few compute nodes, there are some instances for which there is not a corresponding allocation. On another Rocky cloud, we had the opposite problem: there were allocations also for some instances that didn't exist anymore. And this caused problems since we were not able to use all the resources of the relevant compute nodes: we had to manually remove the fwrong" allocations to fix the problem ... I wonder why/how this problem can happen ... And how can we fix the issue ? Should we manually add the missing allocations / manually remove the wrong ones ? Thanks, Massimo

3 3

[qa][ptg][nova][cinder][keystone][neutron][glance][swift][placement] How to make integrated-gate testing (tempest-full) more stable and fast
by Ghanshyam Mann 07 Jul '19

07 Jul '19

Current integrated-gate jobs (tempest-full) is not so stable for various bugs specially timeout. We tried to improve it via filtering the slow tests in the separate tempest-slow job but the situation has not been improved much. We talked about the Ideas to make it more stable and fast for projects especially when failure is not related to each project. We are planning to split the integrated-gate template (only tempest-full job as first step) per related services. Idea: - Run only dependent service tests on project gate. - Tempest gate will keep running all the services tests as the integrated gate at a centeralized place without any change in the current job. - Each project can run the below mentioned template. - All below template will be defined and maintained by QA team. I would like to know each 6 services which run integrated-gate jobs 1."Integrated-gate-networking" (job to run on neutron gate) Tests to run in this template: neutron APIs , nova APIs, keystone APIs ? All scenario currently running in tempest-full in the same way ( means non-slow and in serial) Improvement for neutron gate: exlcude the cinder API tests, glance API tests, swift API tests, 2."Integrated-gate-storage" (job to run on cinder gate, glance gate) Tests to run in this template: Cinder APIs , Glance APIs, Swift APIs, Nova APIs and All scenario currently running in tempest-full in the same way ( means non-slow and in serial) Improvement for cinder, glance gate: excluded the neutron APIs tests, Keystone APIs tests 3. "Integrated-gate-object-storage" (job to run on swift gate) Tests to run in this template: Cinder APIs , Glance APIs, Swift APIs and All scenario currently running in tempest-full in the same way ( means non-slow and in serial) Improvement for swift gate: excluded the neutron APIs tests, - Keystone APIs tests, - Nova APIs tests. Note: swift does not run integrated-gate as of now. 4. "Integrated-gate-compute" (job to run on Nova gate) tests to run is : Nova APIs, Cinder APIs , Glance APIs ?, neutron APIs and All scenario currently running in tempest-full in same way ( means non-slow and in serial) Improvement for Nova gate: excluded the swift APIs tests(not running in current job but in future, it might), Keystone API tests. 5. "Integrated-gate-identity" (job to run on keystone gate) Tests to run is : all as all project use keystone, we might need to run all tests as it is running in integrated-gate. But does keystone is being unsed differently by all services? if no then, is it enough to run only single service tests say Nova or neutron ? 6. "Integrated-gate-placement" (job to run on placement gate) Tests to run in this template: Nova APIs tests, Neutron APIs tests + scenario tests + any new service depends on placement APIs Improvement for placement gate: excluded the glance APIs tests, cinder APIs tests, swift APIs tests, keystone APIs tests Thoughts on this approach? The important point is we must not lose the coverage of integrated testing per project. So I would like to get each project view if we are missing any dependency (proposed tests removal) in above proposed templates. - https://etherpad.openstack.org/p/qa-train-ptg -gmann

7 11

how to install masakari on centos 7
by Vu Tan 07 Jul '19

07 Jul '19

Hi, I would like to use Masakari and I'm having trouble finding a step by step or other documentation to get started with. Which part should be installed on controller, which is should be on compute, and what is the prerequisite to install masakari, I have installed corosync and pacemaker on compute and controller nodes, , what else do I need to do ? step I have done so far: - installed corosync/pacemaker - install masakari on compute node on this github repo: https://github.com/openstack/masakari - add masakari in to mariadb here is my configuration file of masakari.conf, do you mind to take a look at it, if I have misconfigured anything? [DEFAULT] enabled_apis = masakari_api # Enable to specify listening IP other than default masakari_api_listen = controller # Enable to specify port other than default masakari_api_listen_port = 15868 debug = False auth_strategy=keystone [wsgi] # The paste configuration file path api_paste_config = /etc/masakari/api-paste.ini [keystone_authtoken] www_authenticate_uri = http://controller:5000 auth_url = http://controller:5000 auth_type = password project_domain_id = default user_domain_id = default project_name = service username = masakari password = P@ssword [database] connection = mysql+pymysql://masakari:P@ssword@controller/masakari

1 0

[masakari] Run masakari-hostmonitor into Docker container
by gaetan.trellu＠incloudus.com 06 Jul '19

06 Jul '19

Hi, I'm integrating Masakari into Kolla and Kolla Ansible projects but I'm facing an issue related to masakari-hostmonitor. Based on masakari-monitors code[1], "systemctl status" command is used to check if pacemaker, pacemaker-remote and corosync are running. Having systemd running into Docker container is not the best solution. Does any of you has been able to run masakari-monitor into Docker container ? Thanks for your help. Gaëtan - [1] https://github.com/openstack/masakari-monitors/blob/26d558333d9731ca06da09b…

3 2

[neutron][requirements] Pyroute2 stable/queens upper version (0.4.21) has a memory leak
by Rodolfo Alonso 06 Jul '19

06 Jul '19

Hello folks: As reported in [1], we have found a memory leak in Pyroute stable/queens upper version (0.4.21). This memory leak is reproducible both with Python 2.7 and Python 3.6 (I didn't test 3.5 or 3.7). The script used is [2]. Using "pmap" to read the process memory map (specifically the "total" value), we can see an increase of several MB per minute. This problem is not present in version 0.5.2 (stable/rocky upper-requirements) I know that in stable releases, the policy established [3] is only to modify those external libraries in case of security related issues. This is not exactly a security breach but can tear down a server along the time. I submitted a patch to bump the version in stable/queens [4] and another one to test this change in the Neutron CI [5]. Is it possible to merge [4]? Regards. [1] https://bugs.launchpad.net/neutron/+bug/1835044 [2] http://paste.openstack.org/show/753759/ [3] https://docs.openstack.org/project-team-guide/stable-branches.html [4] https://review.opendev.org/#/c/668676/ [5] https://review.opendev.org/#/c/668677/

2 1

[keystone] Keystone Team Update - Week of 1 July 2019
by Colleen Murphy 06 Jul '19

06 Jul '19

# Keystone Team Update - Week of 1 July 2019 ## News ### Midcycle Planning If you have not already done so, please participate in the scheduling poll[1] and contribute topic ideas[2] for the virtual midcycle. We will select a date next week and start preparing the agenda. [1] https://doodle.com/poll/wr7ct4uhpw82sysg [2] https://etherpad.openstack.org/p/keystone-train-midcycle-topics ### Oslo.limit Walkthrough We used this week's office hours session to walk through the new proposals for the oslo.limit interface, which Lance nicely summarized[3]. [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007487.html ## Open Specs Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh We still have three Train specs that needs to be updated or reviewed prior to the Milestone 2 deadline. ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 14 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 43 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 5 new bugs and closed none. Bugs opened (5) Bug #1835299 (keystone:Low) opened by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1835299 Bug #1835303 (keystoneauth:Undecided) opened by Ben Nemec https://bugs.launchpad.net/keystoneauth/+bug/1835303 Bug #1835103 (oslo.limit:Low) opened by Lance Bragstad https://bugs.launchpad.net/oslo.limit/+bug/1835103 Bug #1835104 (oslo.limit:Low) opened by Lance Bragstad https://bugs.launchpad.net/oslo.limit/+bug/1835104 Bug #1835106 (oslo.limit:Low) opened by Lance Bragstad https://bugs.launchpad.net/oslo.limit/+bug/1835106 ## Milestone Outlook https://releases.openstack.org/train/schedule.html Spec freeze is in 3 weeks, closely followed by feature proposal freeze. If you are working on a feature, even if the spec is not approved yet, don't hesitate to propose some code ahead of the deadline. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[all][release] PTL on Vacation July 6-14
by Tony Breeds 06 Jul '19

06 Jul '19

Hi All, Just a very quick note to say I'll be AFK for the next week. The only visible change could be that stable releases are delayed a little. As always if it's urgent nothing stops the release team from approving things in my absence Yours Tony.

1 0

[release] Release countdown for week R-14, July 8-12
by Tony Breeds 06 Jul '19

06 Jul '19

Hi folks, Development Focus ----------------- The Train-2 milestone will happen in three weeks, on July 25. Train-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/train/schedule.html for details. General Information ------------------- Please remember that libraries need to be released at least once per milestone period. At milestone 2, the release team will propose releases for any library that has not been otherwise released since milestone 1. Other non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. At milestone-2 we also freeze the contents of the final release. If you have a new deliverable that should be included in the final release, you should make sure it has a deliverable file in https://opendev.org/openstack/releases/src/branch/master/deliverables/train . You should request a beta release (or intermediary release) for those new deliverables by milestone-2. We understand some may not be quite ready for a full release yet, but if you have something minimally viable to get released it would be good to do a 0.x release to exercise the release tooling for your deliverables. See the MembershipFreeze description for more details: https://releases.openstack.org/train/schedule.html#t-mf Upcoming Deadlines & Dates -------------------------- Train-2 Milestone: July 25 (R-12 week) Yours Tony.

1 0

[goal][python3] Train unit tests weekly update (goal-10)
by Corey Bryant 06 Jul '19

06 Jul '19

This is the goal-10 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 10 weeks remaining for completion of Train community goals [2]. == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. For complete details please see [1]. == Ongoing Work == Patches have been submitted for all applicable projects except for: OpenStack Charms, Puppet OpenStack, Quality Assurance, Release Management, tripleo. Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-train+is:open Failing patches: https://review.openstack.org/#/q/topic:python3-train+status:open+(+label:Ve… Patch automation scripts needing review: https://review.opendev.org/#/c/666934 == Completed Work == Merged patches: https://review.openstack.org/#/q/topic:python3-train+is:merged == How can you help? == Please take a look at the failing patches and help fix any failing unit tests for your projects. Python 3.7 unit tests will be self-testing in Zuul. If you're interested in helping submit patches, please let me know. == Reference Material == [1] Goal description: https://governance.openstack.org/tc/goals /train/python3-updates.html [2] Train release schedule: https://releases.openstack.org/train/schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/story/2005924 Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… Thanks, Corey

1 0

[nova] consoleauth token ttl
by William Lima Reiznautt 05 Jul '19

05 Jul '19

Hello folks, Some known about this configuration token_ttl on [consoleauth] section: Is it on second or minutes ? At documentation is not information. Sorry the question here. -- -- William Lima Reiznautt IC/UNICAMP - Telefone: +55 (19) 3521-5915 --- chavepgp: http://www.ic.unicamp.br/~william/william.pgp

2 1

[nova] type-PCI vs type-PF vs type-VF
by Mauricio Tavares 05 Jul '19

05 Jul '19

Quick questions: 1. Is there some official documentation comparing them? Only thing I found so far was https://mohamede.com/2019/02/07/pci-passthrough-type-pf-type-vf-and-type-pc… 2. Am I correct to assume (I seem to do a lot of that; be afraid) that when nova starts populating the database entry for a given physical node (say a computer node or a ironic baremetal node) it looks through the pci list and decides what type of device (type-PCI, type-PF, or type-VF) it is? What is the criteria? 3. https://mohamede.com/2019/02/07/pci-passthrough-type-pf-type-vf-and-type-pc… implies that nova sees the 3 different types, well, differently where it will try hard to virtualize type-PF and type-VF and really really wants me to setup sr-iov on them ( https://docs.openstack.org/nova/latest/admin/pci-passthrough.html seem to also want sr-iov) really . Is that correct?

2 1

[placement] db query analysis
by Chris Dent 05 Jul '19

05 Jul '19

One of the queries that has come up recently with placement performance is whether there may be opportunities to gain some improvement by making fewer queries to the db. That is: * are there redundant queries * are there places where data is gathered in multiple queries that could be in one (or at least fewer) * are there queries that are not doing what we think to that end I've done some analysis of logs produced when [placement_database]/connection_debug is set to 50 (which dumps SQL queries to the INFO log). The collection of queries made during a single request to GET /allocation_candidates is at http://paste.openstack.org/show/753183/ The data set is a single resource resource provider of the same form as used in the placement-perfload job (where 1000 providers are used). Only 1 is used in this case as several queries use 'IN' statements that list all the resource provider ids currently in play, and that gets dumped to the log making it inscrutable. I've noted in the paste where this happens. Each block of SQL is associated with the method that calls it. The queries are in the order they happen. One query that happens three times (once for each resource class requested) is listed once. Observations: * The way we use IN could be improved using a bindparam: https://docs.sqlalchemy.org/en/13/core/sqlelement.html?highlight=expanding%… * That we use IN in that fashion at all, where we are carrying lists of rp ids around and making multiple queries, instead of one giant one, might be an area worth exploring. * There are a couple of places where get get a trait id (via name) in a separate query from using the trait id. * What can you see? Please have a look to see if anything looks odd, wrong, etc. Basically what we're after is trying to find things that violate our expectations. Note that this is just one of several paths through the database. When there are sharing or nested providers things change. I didn't bother to do a more complex set of queries at this time as it seemed starting simple would help us tease out how best to communicate these sorts of things. Related to that, I've started working on a nested-perfload at https://review.opendev.org/665695 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

2 2

[placement] update 19-26
by Chris Dent 05 Jul '19

05 Jul '19

HTML: https://anticdent.org/placement-update-19-26.html Pupdate 19-26. Next week is R-15, two weeks until Train milestone 2. # Most Important The [spec for nested magic](https://docs.openstack.org/placement/latest/specs/train/approved/200… merged and significant progress has been made in the implementation. That work is nearly ready to merge (see below), after a few more reviews. Once that happens one of our most important tasks will be experimenting with that code to make sure it fully addresses the uses cases, has proper documentation (including "how do I use this?"), and is properly evaluated for performance and maintainability. # What's Changed * The implementation for mappings in allocation candidates had a bug which Eric [found](https://review.opendev.org/668302) and fixed and then I realized there was a [tidier way to do it](https://review.opendev.org/668724). This then led to the `same_subtree` work needing to manage less information, because it was already there. * The spec for [Consumer Types](https://docs.openstack.org/placement/latest/specs/train/approved/200… merged and work [has started](https://review.opendev.org/669170). * We're using os-traits 0.15.0 now. * There's a [framework in place](https://review.opendev.org/665695) for nested resource provider peformance testing. We need to update the provider topology to reflect real world situations (more on that below). * The `root_required` query parameter on `GET /allocation_candidates` has been merged as [microversion 1.35](https://docs.openstack.org/placement/latest/placement-api-microversio…. * I've sent [an email](http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007… announcing my intent to not go to the Shangai (or any other) summit, and what changes that could imply for how Placement does the PTG. # Specs/Features All placement specs have merged. Thanks to everyone for the frequent reviews and quick followups. We've been maintaining some good velocity. Some non-placement specs are listed in the Other section below. # Stories/Bugs (Numbers in () are the change since the last pupdate.) There are 23 (3) stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement). 0 (0) are [untagged](https://storyboard.openstack.org/#!/worklist/580). 2 (-2) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 5 (0) are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 11 (0) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 4 (1) are [docs](https://storyboard.openstack.org/#!/worklist/637). If you're interested in helping out with placement, those stories are good places to look. * Placement related nova [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 16 (0). * Placement related nova [in progress bugs](https://goo.gl/vzGGDQ) on launchpad: 4 (-1). # osc-placement osc-placement is currently behind by 11 microversions. * <https://review.opendev.org/666542> Add support for multiple member_of. # Main Themes ## Nested Magic These are the features required by modern nested resource provider use cases. We've merged mappings in allocation candidates and `root_required`. `same_subtree` and resourceless request groups are what's left and they are in: * <https://review.opendev.org/668376> Support `same_subtree` queryparam ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. * <https://review.opendev.org/#/q/topic:bp/support-consumer-types> ## Cleanup Cleanup is an overarching theme related to improving documentation, performance and the maintainability of the code. The changes we are making this cycle are fairly complex to use and are fairly complex to write, so it is good that we're going to have plenty of time to clean and clarify all these things. As mentioned above, one of the important cleanup tasks that is not yet in progress is updating the [gabbit](https://opendev.org/openstack/placement/src/branch/master/gate/gabb… that creates the nested topology that's used in nested performance testing. The topology there is simple, unrealistic, and doesn't sufficiently exercise the several features that may be used during a query that desires a nested response. Recently I've been seeing that the `placement-perfload` job is giving results that vary between `N` and `N*2` (usually .5 and 1 seconds) and the difference that I can discern is the type of CPUs being presented by the host (same number of CPUs (8) but different type). This supports something we've been theorizing for a while: when dealing with large result sets we are CPU bound processing the several large result sets returned by the database. Further profiling required… Another cleanup that needs to start is satisfying the community wide goal of [PDF doc generation](https://storyboard.openstack.org/#!/story/2006110). # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. There are three [os-traits changes](https://review.opendev.org/#/q/project:openstack/os-traits+status:… being discussed. And one [os-resource-classes change](https://review.opendev.org/#/q/project:openstack/os-resource-classe…. # Other Service Users New discoveries are added to the end. Merged stuff is removed. Anything that has had no activity in 4 weeks has been removed. * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.openstack.org/650188> nova-spec: Allow compute nodes to use DISK_GB from shared storage RP * <https://review.opendev.org/659233> Cyborg: Placement report * <https://review.opendev.org/662229> helm: WIP: add placement chart * <https://review.opendev.org/656023> Nova: Use OpenStack SDK for placement * <https://review.opendev.org/612497> Nova: Spec: Provider config YAML file * <https://review.opendev.org/634551> libvirt: report pmem namespaces resources by provider tree * <https://review.opendev.org/660852> Nova: Remove PlacementAPIConnectFailure handling from AggregateAPI * <https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports> Nova: support move ops with qos ports * <https://review.opendev.org/664689> Nova: get_ksa_adapter: nix by-service-type confgrp hack * <https://review.opendev.org/664862> OSA: Add nova placement to placement migration * <https://review.opendev.org/657796> Nova: Defaults missing group_policy to 'none' * <https://review.opendev.org/666202> Blazar: Create placement client for each request * <https://review.opendev.org/668930> tempest: Define the Integrated-gate-networking gate template * <https://review.opendev.org/669309> tempest: Define the Integrated-gate-placement gate template * <https://review.opendev.org/668263> Nova: Restore RT.old_resources if ComputeNode.save() fails * <https://review.opendev.org/669188> Remove assumption of http error if consumer not exists * <https://review.opendev.org/669253> TripleO: Add new parameter NovaSchedulerLimitTenantsToPlacementAggregate * <https://review.opendev.org/669252> puppet-nova: Expose limit_tenants_to_placement_aggregate parameter * <https://review.opendev.org/667952> nova: Support filtering of hosts by forbidden aggregates * <https://review.opendev.org/669079> blazar: Send global_request_id for tracing calls * <https://review.opendev.org/667417> nova: Implement update_provider_tree for hyperv * <https://review.opendev.org/668639> watcher: Improve Compute Data Model * <https://review.opendev.org/#/q/topic:bp/pre-filter-disabled-computes> Nova: pre filter disable computes * <https://review.opendev.org/668252> Nova: Update HostState.\*\_allocation_ratio earlier # End This space left intentionally blank. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[Mistral] Guaranteed notification delivery
by Лапин Артем 05 Jul '19

05 Jul '19

Good day, please look at https://blueprints.launchpad.net/mistral/+spec/guaranteed-notifies. I would like to know your opinion about this feature.

1 0

[horizon] PTL on vacation
by Ivan Kolodyazhny 05 Jul '19

05 Jul '19

Hi team, I'll be on a vacation until July, 19th with a very limited internet connection. During the last weekly meeting [1] we agreed to skip the next two. I'll try to check my mail during the PTO but for any issues, I recommend to ask our great core team [2] via emails or IRC. [1] http://eavesdrop.openstack.org/meetings/horizon/2019/horizon.2019-07-03-15.… [2] https://review.opendev.org/#/admin/groups/43,members Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 0

[kolla] Proposing yoctozepto as core
by Mark Goddard 05 Jul '19

05 Jul '19

Hi, I would like to propose adding Radosław Piliszek (yoctozepto) to kolla-core and kolla-ansible-core. While he has only recently started working upstream in the project, I feel that he has made some valuable contributions already, particularly around improving and maintaining CI. His reviews generally provide useful feedback, sometimes in advance of Zuul! Core team - please vote, and consider this my +1. I will keep this vote open for a week or until all cores have responded. Cheers, Mark

5 5

[kolla][kayobe] vote: kayobe as a kolla deliverable
by Mark Goddard 05 Jul '19

05 Jul '19

Hi, In the most recent kolla meeting [1] we discussed the possibility of kayobe becoming a deliverable of the kolla project. This follows on from discussion at the PTG and then on here [3]. The two options discussed are: 1. become a deliverable of the Kolla project 2. become an official top level OpenStack project There has been some positive feedback about option 1 and no negative feedback that I am aware of. I would therefore like to ask the kolla community to vote on whether to include kayobe as a deliverable of the kolla project. The electorate is the kolla-core and kolla-ansible core teams, excluding me. The opinion of others in the community is also welcome. If you have questions or feedback, please respond to this email. Once you have made a decision, please respond with your answer to the following question: "Should kayobe become a deliverable of the kolla project?" (yes/no) Thanks, Mark [1] http://eavesdrop.openstack.org/meetings/kolla/2019/kolla.2019-06-19-15.00.l… [2] https://etherpad.openstack.org/p/kolla-train-ptg [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006901.html

4 6

[horizon] Unable to boot instance from volume if image size doesn't fit in flavor root disk size
by Krzysztof Klimonda 05 Jul '19

05 Jul '19

Hi, In order to avoid creating spurious flavors just to match image size requirements, I’d like to be able to spawn instances from volume even if the flavor disk is too small - this is possible via CLI/API but Horizon doesn’t let me launch the instance unless either flavor root disk is sized correctly, or the root disk size is 0(?). Is that a bug in Horizon, or is there something that I’m missing? Regards, -Chris

2 1

[placement] [tc] PTL not going to summit?
by Chris Dent 04 Jul '19

04 Jul '19

I've decided [1] that I'm going to resist going to tech conferences and summits in particular by air travel, unless it becomes an existential issue. For a variety of reasons described in [1] and the two other posts it links to. I know for some people that this will present some concerns about my efficacy as PTL of placement, so I thought I better mention it sooner than later so we can make some decisions on how we want to proceed: * Should I take myself out of the running for U PTL? In which case we need to get a shadow warmed up. * If I'm not there, but still PTL, should we still hold the usual regularly placement things (project update and onboarding, PTG things)? In which case we need to prepare chairs/moderators for those sessions. Given my positions on the exclusive properties of conferences, I'd prefer that we turn update and onboarding activities into asynchronous, document-oriented affairs that anyone can utilize at any time, not just those wanting and able to go to summit. Similarly, given how useful the placement pre-PTG was for Train, the very small amount of time spent discussing placement issues in person in Denver, and the team's strategy of focusing on a relatively small number of changes, I'm not certain we need "time" in Shanghai. We can spread that work out. Thoughts or questions from anyone? [1] https://anticdent.org/remote-maintainership.html -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

5 4

[Glance] No meeting today 4th of July
by Erno Kuvaja 04 Jul '19

04 Jul '19

Hi all, We had no proposed agenda for today so Happy Independence Day for all our American fellows and we will have meeting again next Thu the 11th. Best, Erno jokke Kuvaja

1 0

[magnum][queens] kume master error in clout-init-output.log
by Ignazio Cassano 04 Jul '19

04 Jul '19

Hi All, I 've just installed openstack kolla queens and wen I try to run a kubernetes cluster, the master node reports the following in the cloud init log file: Cloud-init v. 0.7.9 running 'modules:config' at Wed, 03 Jul 2019 18:57:19 +0000. Up 20.40 seconds. + CA_FILE=/etc/pki/ca-trust/source/anchors/openstack-ca.pem + '[' -n '' ']' /var/lib/cloud/instance/scripts/part-007: line 57: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-007: line 70: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-007: line 86: /etc/etcd/etcd.conf: No such file or directory Cloud-init v. 0.7.9 running 'modules:final' at Wed, 03 Jul 2019 18:57:21 +0000. Up 21.93 seconds. 2019-07-03 18:59:23,121 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-007 [1] The image I am using is suggested in the openstack documentation: $ wget https://download.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-2… The volume driver is cinder and the docker storage driver is overlay. The docker volume size is 5 GB and THE VOLUME SIZE OF THE FLAVOR IS 20gb. Seems image is missing some packeages :-( Anyone could help me, please ? Ignazio

3 6

[neutron][ci] Gate broken
by Slawek Kaplonski 04 Jul '19

04 Jul '19

Hi, Currently we have broken our functional and fullstack jobs due to patch [1] merged in Devstack. So functional and fullstack jobs are finishing with RETRY_LIMIT now. Fix is already proposed in [2]. So if Your patch failed on those jobs now, please don’t recheck it until [2] will be merged. [1] https://review.opendev.org/#/c/619562/ [2] https://review.opendev.org/#/c/669067/ — Slawek Kaplonski Senior software engineer Red Hat

1 1

[Mistral] PTL is on vacation till July 17
by Renat Akhmerov 04 Jul '19

04 Jul '19

Hi, Just letting you know that I’ll be on vacation till July 17. With all the urgent requests/issue please contact Dougal Matthews (d0gal), Oleg Ovcharuk (vgoleg) or Adriano Petrich (apetrich). Thanks Renat Akhmerov @Nokia

1 0

reply: [lists.openstack.org][nova] API updates week 19-26
by Brin Zhang(张百林) 04 Jul '19

04 Jul '19

> Spec Ready for Review: 5. Add flavor group https://review.opendev.org/#/c/663563/ Brin Zhang Hello Everyone, Please find the Nova API updates of this week. API Related BP : ============ COMPLETED: 1. Support adding description while locking an instance: - https://blueprints.launchpad.net/nova/+spec/add-locked-reason Code Ready for Review: ------------------------------ 1. Add host and hypervisor_hostname flag to create server - Topic: https://review.opendev.org/#/q/topic:bp/add-host-and-hypervisor-hostname-fla g-to-create-server+(status:open+OR+status:merged) - Weekly Progress: patch is updated with review comment. ready for re-review. I will re-review it tomorrow. 2. Specifying az when restore shelved server - Topic: https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-s helved-server+(status:open+OR+status:merged) - Weekly Progress: Review comments is fixed and ready to re-review. 3. Nova API cleanup - Topic: https://review.opendev.org/#/c/666889/ - Weekly Progress: Code is up for review. A lot of files changed but should be ok to review. I have pushed a couple of patches for missing tests of previous microversions. 4. Detach and attach boot volumes: - Topic: https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+OR +status:merged) - Weekly Progress: No Progress Spec Ready for Review: ----------------------------- 1. Nova API policy improvement - Spec: https://review.openstack.org/#/c/547850/ - PoC: https://review.openstack.org/#/q/topic:bp/policy-default-refresh+(status:ope n+OR+status:merged) - Weekly Progress: Under review and updates. 2. Support for changing deleted_on_termination after boot -Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: No update this week. 3. Support delete_on_termination in volume attach api -Spec: https://review.openstack.org/#/c/612949/ - Weekly Progress: No updates this week. 4. Add API ref guideline for body text - ~8 api-ref are left to fix. Previously approved Spec needs to be re-proposed for Train: --------------------------------------------------------------------------- 1. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-n ames - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-nam es+(status:open+OR+status:merged) 2. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(s tatus:open+OR+status:merged) Bugs: ==== No progress report in this week too. I will start the bug triage next week. NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes. -gmann

1 0

tripleO undercloud import failing in stein
by Ruslanas Gžibovskis 04 Jul '19

04 Jul '19

Hi team, I am using CentOS7 with repos installed from stein package (centos-openstack-stein) in CentOS7. I just enable rdo-trunk-stein-tested because undercloud install do not work from centos-openstack-stein due to unable to mount some path, found that it is known and was fixed in stein tested. so I succeeded to boot and build everything. but when I use "time openstack --debug overcloud node import setup/hosts.yaml" step, it stops at: HTTP POST https://undercloud_public_host:13989/v2/executions 201 Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: 55f14621-cabd-4783-a611-d5b822ad0833 Waiting for messages on queue 'tripleo' with no timeout. I can reach iDRAC over ssh, and I can boot Physical HW to PXE. Physical HW state do not change, it do not change power state. current state is poweroff of physical hosts I am adding. any ideas? more info can be found here: https://ask.openstack.org/en/question/122870/valueerror-no-json-object-coul… -- Ruslanas Gžibovskis +370 6030 7030

1 0