- openstack-discuss - lists.openstack.org

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

04 Mar '20

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

1 0

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

04 Mar '20

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

1 0

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

04 Mar '20

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

4 7

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

04 Mar '20

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

4 6

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

04 Mar '20

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

5 8

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

04 Mar '20

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

1 0

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

04 Mar '20

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

3 4

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

04 Mar '20

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

1 0

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

04 Mar '20

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

2 1

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

03 Mar '20

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

1 0

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

03 Mar '20

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

2 1

[glance] Different checksum between CLI and curl
by gaetan.trellu＠incloudus.com 03 Mar '20

03 Mar '20

Hi guys, Does anyone know why the md5 checksum is different between the "openstack image save" CLI and "curl" commands? During the image creation a checksum is computed to check the image integrity, using the "openstack" CLI match the checksum generated but when "curl" is used by following the API documentation[1] the checksum change at every "download". Any idea? Thanks, Gaëtan [1] https://docs.openstack.org/api-ref/image/v2/index.html?expanded=download-bi…

12 21

[all][PTL][tc] U Community Goal: Project PTL & Contrib Docs Update #4
by Kendall Nelson 03 Mar '20

03 Mar '20

Hello! The decision has been made and the template has been merged[1] with the actual governance update well on its way to being accepted as well[2][3]. With that in mind, its time to get down to business! If You Haven't Started ================= You're in luck! Nothing has to change, just run the cookie cutter[8] and make whatever changes you need to the template and get it added to the repos for your project. Also, please keep the task tracker in StoryBoard up to date[4] as you work. If You Had 'Completed' it before Update #2 ================================ Go and check out the governance change[2] and the template[1] to make sure there isn't anything you did differently-- depending on when you 'completed' the goal, you might have some changes to make to be in line with the current (and presumably final) completion criteria. And, as always, please make sure to keep the tasks in StoryBoard up to date[4]. Previous updates if you missed them[5][6][7]. If you have any questions, please let me know. If you need help with reviewing, please feel free to add me as a reviewer. We can still get this done in time! Thanks, -Kendall (diablo_rojo) [1] Cookie Cutter Change https://review.opendev.org/#/c/708672/ [2] Governance Goal Change https://review.opendev.org/#/c/709617/ [3] Governance Goal Change Typo Fix https://review.opendev.org/#/c/710332 <https://review.opendev.org/#/c/710332/1> [4] StoryBoard Tracking: https://storyboard.openstack.org/#!/story/2007236 [5]Update #1: http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012364… [6] Update #2: http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012570… [7] Update 3: http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012784… [8] Cookiecutter Template: https://opendev.org/openstack/cookiecutter/src/branch/master/%7b%7bcookiecu…

1 0

[openstack-helm] Virtual Midcycle - March 2020
by Gage Hugo 03 Mar '20

03 Mar '20

Hello everyone, The openstack-helm team is looking to host a virtual midcycle this month to discuss a variety of topics in a more focused group via video conferencing. We have started an etherpad to track anyone who wishes to attend as well as any topics that want to be discussed. https://etherpad.openstack.org/p/osh-virtual-ptg-2020-03 Also there is a doodle poll to determine a time-slot in the next few weeks for the best time, we will try to choose the best time-slot based on the number of available people, please check it out here: https://doodle.com/poll/g6uvdb4rbad9s8gb We will update the etherpad to track any changes in meeting schedule, as well as when we find a web conference tool that works best. - Gage

1 0

Trouble with large RAM VMs - (formerly RE: Virtio memory balloon driver)
by Albert Braden 03 Mar '20

03 Mar '20

I successfully blacklisted the "memory balloon" driver in a VM image and found that another driver is choking on the large memory. The guys in #centos think it might be the USB or PS/2 drivers. Since these are kernel drivers they cannot be blacklisted; the only way to not load them is to not call them. On the hypervisor in /etc/libvirt/qemu/<instance-name>.xml I see this: <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> I tried removing those lines, but it looks like the XML file is re-created whenever I stop and start the VM. In nova.conf I see "#pointer_model = usbtablet" If I set "pointer_model = <None>" on the HV and then restart nova, I see this in the log: 2020-03-03 11:05:17.233 228915 ERROR nova ConfigFileValueError: Value for option pointer_model is not valid: Valid values are [None, ps2mouse, usbtablet], but found '<None>' If I set "pointer_model = None" then I see this: 2020-03-03 11:06:24.761 229290 ERROR nova ConfigFileValueError: Value for option pointer_model is not valid: Valid values are [None, ps2mouse, usbtablet], but found 'None' What am I missing? # # Generic property to specify the pointer type. # # Input devices allow interaction with a graphical framebuffer. For # example to provide a graphic tablet for absolute cursor movement. # # If set, the 'hw_pointer_model' image property takes precedence over # this configuration option. # # Possible values: # # * None: Uses default behavior provided by drivers (mouse on PS2 for # libvirt x86) # * ps2mouse: Uses relative movement. Mouse connected by PS2 # * usbtablet: Uses absolute movement. Tablet connect by USB # # Related options: # # * usbtablet must be configured with VNC enabled or SPICE enabled and SPICE # agent disabled. When used with libvirt the instance mode should be # configured as HVM. # (string value) # Possible values: # <None> - <No description provided> # ps2mouse - <No description provided> # usbtablet - <No description provided> pointer_model = None -----Original Message----- From: Albert Braden Sent: Wednesday, February 5, 2020 9:34 AM To: openstack-discuss(a)lists.openstack.org Subject: RE: Virtio memory balloon driver When I start and stop the giant VM I don't see any evidence of OOM errors. I suspect that the #centos guys may be correct when they say that the "Virtio memory balloon" device is not capable of addressing that much memory, and that I must disable it if I want to create VMs with 1.4T RAM. Setting "mem_stats_period_seconds = 0" doesn't seem to disable it. How are others working around this? Is anyone else creating Centos 6 VMs with 1.4T or more RAM?

1 0

[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 02 Mar '20

02 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 02 Mar '20

02 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 01 Mar '20

01 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 27 Feb '20

27 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 27 Feb '20

27 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 27 Feb '20

27 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

[all][PTL][tc] U Community Goal: Project PTL & Contrib Docs Update #3
by Kendall Nelson 27 Feb '20

27 Feb '20

Hello! There is some debate about where the content of the actual docs should live. This grew out of the discussion about how to setup the includes so that the correct info shows up where we want it. 'Correct' in that last sentence being where the debate is. There are two main schools of thought: 1. All the content of the docs should live in the top level CONTRIBUTING.rst and the sphinx glue should live in doc/source/contributor/contributing.rst. A patch has already been merged for this approach[1]. There is also a patch to update the goal to match[2]. This approach keeps all the info in one place so that if things change in the future, its easier to keep things straight. All the content is also more easily discoverable when looking at a repo in GitHub (or similar) or checking out the code because it is at the top most level of the repo and not hidden in the docs sub directory. 2. The new patch[3] says that the content should live in /doc/source/contributor/contributing.rst and a skeleton with only the most important version should live in the top level CONTRIBUTING.rst. This approach argues that people don't want to read a wall of text when viewing the code on GitHub (or similar) or checking it out and looking at the top level CONTRIBUTING.rst and as such only the important details should be kept in that file. These important details being that we don't accept patches in github and where to report bugs (both of which are included in the larger format of the content). So what do people think? Which approach do they prefer? I am anxious to get this settled ASAP so that projects have time to complete the goal in time. Previous updates if you missed them[4][5]. Please feel free to add other ideas or make corrections to my summaries of the approaches if I missed things :) -Kendall (diablo_rojo) [1] Merged Template Patch (school of thought 1): https://review.opendev.org/#/c/708511/ [2] Goal Update Patch: https://review.opendev.org/#/c/707736/ [3] Current Template Patch (school of thought 2): https://review.opendev.org/#/c/708672/ [4] Update #1: http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012364… [5] Update #2: http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012570…

6 7

[oslo][cache] oslo.cache hardening
by Moises Guimaraes de Medeiros 27 Feb '20

27 Feb '20

Hi all, Whenever deploying a service inside a network, basic security concerns come to mind: Is the network trusted? Can we send data in plaintext? Is the service available only to those intended to use it? Can the service itself or others have access to the data? That is no exception for caching servers and a while ago, me and Lance Bragstad started a discussion about this topic. *Possible solutions* *Protecting data in transit using TLS* Requires a backend with TLS support. Since version 1.5.13, Memcached supports authentication and encryption via TLS. This feature requires: OpenSSL 1.1.0 or later; A Memcached client with TLS support; A Memcached server built using ./configure --enable-tls. Encrypting the traffic protects the data in transit from reading and tampering. The complexity impact is that each Memcached server will need a valid certificate. The performance impact is the TLS overhead itself. Performing client authentication protects the server from unauthorized read and write operations. The complexity impact is that each Memcached client will need a valid certificate. The performance impact is bigger due to the extra steps to authenticate both sides. This approach doesn't protect the data held in memory by Memcached in any other way. *Authentication using SASL* Requires a backend with SASL support. Since version 1.4.3, Memcached supports authentication via SASL. This feature requires: A Memcached client with SASL support; A Memcached server built using ./configure --enable-sasl. This approach protects the server from unauthorized read and write operations. The complexity and performance impact is according to SASL usage. This approach doesn't protect the data in transit or held in memory by Memcached in any other way. *Encrypting data before storing* Requires *NO* extra features in the backend. This approach consists of encrypting the data before sending it to the caching servers. The complexity impact is dealing with key sharing for the encryption/decryption process. The performance impact depends on the algorithms used for encryption. This approach protects the data both in transit and held in memory by caching servers, but the key sharing is more prone to setup errors than the TLS or the SASL approach. --- After considering the possible solutions, we decided to tackle the TLS path first. We did an initial analysis of oslo.cache backends that use Memcached together with Hervé Beraud here: https://etherpad.openstack.org/p/oslo-cache-tls-support-worksheet Since python-binary-memcached already has SASL support, we thought it to be a good first candidate to implement TLS support and last month I had it merged here: https://github.com/jaysonsantos/python-binary-memcached/pull/211 We are now looking for more people interested in the discussion and help to push changes forward. -- Moisés Guimarães Software Engineer Red Hat

1 0

[neutron] Shared tenant network allow duplicate IP's?
by Adam Peacock 27 Feb '20

27 Feb '20

Hey folks, So I caught wind from a friend/colleague that allowing duplicate IP's in each tenant was now only achievable by creating a separate tenant network+subnet and assigning them separately to each individual tenant. This doesn't seem right to me and it doesn't scale. *Looking for this:* - tenant-network-id = abc (shared) - tenant1 - vm1: 10.0.0.10 - tenant2 - vm1: 10.0.0.10 Am I missing something and this setup is no longer supported? I hope I'm wrong but I can't find documentation that speaks to this specifically so would appreciate a link if anyone has it handy. Thanks! //adam *Adam Peacock* Principal Architect Office: +1-916-794-5706

4 4

[ptl][release][stable][EM] Extended Maintenance - Rocky
by Elõd Illés 27 Feb '20

27 Feb '20

Hi, In less than one month Rocky is planned to enter into Extended Maintenance phase [1] (estimated date: 2020-02-24). I have generated the list of *open* and *unreleased* changes in *stable/rocky* for the follows-policy tagged repositories [2]. These lists could help the teams, who are planning to do a final release on Rocky before moving stable/rocky branches to Extended Maintenance. Feel free to edit them! * At the transition date the Release Team will tag the latest (Rocky) releases of repositories with *rocky-em* tag. * After the transition stable/rocky will be still open for bugfixes, but there won't be any official releases. NOTE: teams, please focus on wrapping up your libraries first if there is any concern about changes, in order to avoid any broken releases! Thanks, Előd [1] https://releases.openstack.org/ [2] https://etherpad.openstack.org/p/rocky-final-release-before-em

4 5

[ops] nova wsgi config
by Arnaud Morin 27 Feb '20

27 Feb '20

Hey all, I am trying to configure apache as a WSGI. Is there any other documentation than this: https://docs.openstack.org/nova/stein/user/wsgi.html Is there any recommendations? Thanks in advance! -- Arnaud Morin

4 7

Cinder / Nova - Select cinder backend based on nova availability zone?
by Tony Pearce 27 Feb '20

27 Feb '20

Apologies in advance if this seems trivial but I am looking for some direction on this and I may have found a bug while testing also. Some background - I have 2 physical hosts which I am testing with (host1, host2) and I have 2 separate cinder backends (backend1, backend2). Backend1 can only be utilised by host1. Same for backend2 - it can only be utilised by host2. So they are paired together like: host1:backend1 host2:backend2 So I wanted to select a Cinder storage back-end based on nova availability zone and to do this when creating an instance through horizon (not creating a volume directly). Also I wanted to avoid the use of metadata input on each instance create or by using metadata from images (such as cinder_img_volume_type) [2] . Because I can foresee a necessity to then have a number of images which reference each AZ or backend individually. - Is it possible to select a backend based on nova AZ? If so, could anyone share any resources to me that could help me understand how to achieve it? Because I failed at achieving the above, I then decided to use one way which had worked for me in the past, which was to use the image metadata "cinder_img_volume_type". However I find that this is not working. The “default” volume type is selected (if cinder.conf has it) or if no default, then `__DEFAULT__` is being selected. The link at [2] states that first, a volume type is used based on the volume type selected and if not chosen/set then the 2nd method is "cinder_img_volume_type" from the image metadata and then the 3rd and final is the default from cinder.conf. I have tested with fresh deployment using Kayobe as well as RDO’s packstack. Openstack version is *Train* Steps to reproduce: 1. Install packstack 2. Update cinder.conf with enabled_backends and the [backend] 3. Add the volume type to reference the backend (for reference, I call this volume type `number-1`) 4. Upload an image and add metadata `cinder_img_volume_type` and the name as mentioned in step 3: number-1 5. Try and create an instance using horizon. Source = image and create new volume 6. Result = volume type / backend as chosen in the image metadata is not used and instance goes into error status. After fresh-deploying the RDO Packstack, I enabled debug logs and tested again. In the cinder-api.log I see “"volume_type": null,” and then the next debug log immediately after logged as “Create volume request body:” has “volume_type': None”. I was searching for a list of the supported image metadata, in case it had changed but the pages seem empty one rocky/stein/train [3] or not yet updated. Selecting backend based on nova AZ:: I was searching how to achieve this and I came across this video on the subject of AZs [1]. Although it seems only in the context of creating volumes (not with creating instances with volume from an image, for example). I have tried creating a host aggregate in nova, with AZ name `host1az`. I've also created a backend in Cinder (cinder.conf) with `backend_availability_zone = host1az`. But this does not appear to achieve the desired result, either and the cinder api logs are showing “"availability_zone": null” during the volume create part of the launch instance from Horizon. I also tried setting RESKEY [3] in the volume type, but again similar situation seen; although I dont think this option is the correct context for what I am attempting. Could anyone please nudge me in the right direction on this? Any pointers appreciated at this point. Thanks in advance. References: [1] https://www.youtube.com/watch?v=a5332_Ew9JA [2] https://docs.openstack.org/cinder/latest/cli/cli-manage-volumes.html [3] https://docs.openstack.org/cinder/train/contributor/api/cinder.api.schemas.… [4] https://docs.openstack.org/cinder/rocky/admin/blockstorage-availability-zon… Regards, Tony Pearce

2 4

Networking-vpp 20.01 for VPP 20.01 is now available
by Naveen Joy (najoy) 26 Feb '20

26 Feb '20

Hello All, We'd like to invite you to try out Networking-vpp 20.01. As many of you may already know, VPP is a fast user space forwarder based on the DPDK toolkit. VPP uses vector packet processing algorithms to minimize the CPU time spent on each packet to maximize throughput. Networking-vpp is a ML2 mechanism driver that controls VPP on your control and compute hosts to provide fast L2 forwarding under Neutron. This latest version of Networking-vpp is updated to work with VPP 20.01. In this release, we've made the below changes: - We've dropped support for Python 2.7 and updated the code to work with Python 3.6 or later. - We've updated the code to be compatible with VPP 20.01 API changes. - We've added VPP API versioning support using 2 data files. They are API whitelist file and API CRC manifest file. At startup, the vpp-agent will check to see if the API signature is compatible with the installed VPP. Also, at runtime, only the whitelisted API calls will be allowed. - We've fixed an issue with the eventlet that caused problems when binding tap interfaces into Linux bridge - We've been doing the usual round of bug fixes, clean-ups and updates. The code will work with VPP 20.01 and the OpenStack Stein release. The README [1] explains how you can try out VPP with Networking-vpp using devstack: the devstack plugin will deploy the mechanism driver and VPP and should give you a working system with a minimum of hassle. We will be continuing our development for VPP's 20.05 release. We welcome anyone who would like to come help us. -- Jerome, Ian & Naveen [1] https://opendev.org/x/networking-vpp/src/branch/master/README.rst

1 0

[nova][neutron] nova scheduling support for routed networks
by Balázs Gibizer 26 Feb '20

26 Feb '20

Hi, There are multiple efforts to add scheduler support to the neutron routed network feature. Matt's effort to have it as a scheduler pre-filter [1] Adam's (rm_work) effort to have this as a a new scheduler hint and a new scheduler filter [2] We had a good discussion on #openstack-nova [3] about the possible way forward with Sean and Adam. Here is a summary and my proposed way forward. Currently booting a server in a routed network setup works iff the neutron port is pre-created with ip_allocation=deferred before the server create. Nova then schedule the server without consider anything about the possible multiple network segments of the port. Neutron will do the segment assignment when the port is bond to the compute host. The problem is that once a port bound to a segment it cannot be bound to another segment as that would change the IP of the port. So if a server is migrated nova should select a destination host where the _same segment_ is available. Therefore we need a way to influence the scheduling based on the assigned segment id of the port. Both [1] and [2] does that based on the fact that neutron creates nova host aggregates for each network segment and those aggregates are mirrored to placement as placement aggregates. For me the pre-filter approach[1] seems better as * it avoids introducing a new scheduler hint * it is not affected by the allocation candidate limit configuration that effect scheduler filters * it allows us to iterate towards an approach where neutron provides the required aggregates of each port via the ports' resource_request attribute The downside of the pre-filter approach is that right now it needs to query the segments for each network / port the server has before the each scheduling. I think we limit such performance impact by making this pre-filter turned off by default via configuration. So a deployment without routed networks does not need to pay this cost. Later this cost can be nullified by extending neutron to specify the needed aggregates in the port's resource_request. I'm now planning to take [1] over from Matt and finish it up by adding functional test and documentation to it. I would also like to raise attention to the tempest patch that adds basic CI coverage for the currently working server create scenario [4]. Cheers, gibi [1] https://review.opendev.org/#/c/656885 [2] https://review.opendev.org/#/c/709280 [3] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… [4] https://review.opendev.org/#/c/665155

2 1

Restarting neutron-l3-agent service
by Grant Morley 26 Feb '20

26 Feb '20

Hi all, We are currently seeing an issue where neutron isn't setting up ports correctly on routers. We think we have narrowed it down to the "neutron-l3-agent" on the neutron nodes that is causing the issue. We are wanting to restart the service but was wondering if doing so it would cause any issues with currently running instances? We have 2 neutron nodes in HA mode ( one active and one standby ). Currently the issue is only affecting newly built instances, so we don't want to restart the service in hours if it is going to cause issues with instances that are currently unaffected. We are running on OpenStack Queens and have built the platform using OSA. Many thanks for any help. Regards,

2 1

[all][tc][uc] Uniting the TC and the UC
by Thierry Carrez 26 Feb '20

26 Feb '20

Hi all, When our current project governance was established in 2012, we defined two separate bodies. The Technical Committee represented developers / code contributors to the open source project(s), while the User Committee represented the operators running the resulting software, as well as users of the APIs. That setup served us well in those early days. The focus on the upstream side was strongly around *development* of code, we did not have that many users, and even less users directly involved in upstream development. A separate User Committee resulted in the formation of an engaged community of users, and ensured that our community in general (and our events in particular) took the needs of operators into account. Fast-forward to 2020: the upstream focus is more on maintenance. We now have a lot of users, and thanks to the efforts of the UC they are increasingly directly involved in the open source project development, with several operators leading upstream project teams directly. There is now limited UC-specific activity, and as such it is struggling to get volunteers to step up for it: nobody nominated themselves for the last round of election. Keeping two separate bodies to represent them maintains the illusion that devs and ops are different breeds, and sometimes discourages operators from running for the TC and more directly influence the shape of the software. If anything, we need more ops representation at the TC, and seeing people like mnaser being elected at (and chairing) the TC was a great experience. I discussed the situation with the current UC members, and we decided it's time to consider having a single "community" and a single body to represent it. That body would tackle the traditional TC tasks (open source project governance and stewardship) but also the UC tasks (user survey, ambassador program...). That body would be elected by contributors, in a large sense that includes the AUC definition. I feel like that would help remove the artificial barriers discouraging users to get more directly involved with software development and maintenance. There are multiple ways to achieve that, in increasing order of complexity and bylaws changes needed: 1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together. 2- Minimal bylaws change Same, but all mentions of the UC would be removed from the bylaws (affecting sections 4.12, 4.14, and Appendix 10). This would require a simple vote by the Board of Directors, and would avoid some confusion and having to formally designate a subset of the TC to respect the letter of the bylaws. 3- Maximal bylaws change Create a new body ("steering committee" for example) replacing the TC and the UC. This would require changing sections 4.1, 4.12, 4.13, 4.14, 4.20, 7.1.b, 7.4, 9.1, 9.2.d, and Appendixes 4 and 10. Section 4.13, 7.1 and 7.4 being heavily protected in the bylaws, they require special votes by each class of Foundation members, probably a multi-year effort. A lot of documentation would also need to be changed in case the TC is renamed. I personally don't think the benefit of the change offsets the large cost of option (3). Given the current vacancy in the UC makeup I would recommend we pursue option 1 immediately (starting at the next TC election in April), and propose minimal bylaws change to the board in parallel (option 2). Thoughts ? -- Thierry Carrez

8 16