- openstack-discuss - lists.openstack.org

[tripleo] Please avoid merge patches for releases before Victoria
by Arx Cruz 27 Nov '20

27 Nov '20

Hello, We need these patches [1] landed first in order to merge other patches, otherwise CI will not be able to properly test it. We have already had two known issues [2] related to this problem, so I ask you for patience while we are merging those patches. [1] https://review.opendev.org/c/openstack/tripleo-quickstart/+/763747 https://review.opendev.org/#/c/763712 [2] https://launchpad.net/bugs/1903033 https://bugs.launchpad.net/tripleo/+bug/1905536 Kind regards, -- Arx Cruz Software Engineer Red Hat EMEA <https://www.redhat.com> arxcruz(a)redhat.com @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 1

[release] Release countdown for week R-20, Nov 23 - Nov 27
by Herve Beraud 26 Nov '20

26 Nov '20

Greetings Everyone! Development Focus ----------------- The Wallaby-1 milestone is next week, on December 03! Project team plans for the Wallaby cycle should now be solidified. General Information ------------------- If you planned to change the release model for any of your deliverables this cycle, please remember to do so ASAP, before milestone-1. Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the Victoria release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Wallaby-1 milestone: December 03 Hervé Beraud (hberaud) and the Release Management Team -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-20 Update
by Ghanshyam Mann 26 Nov '20

26 Nov '20

Hello Everyone, As you all know, 'Migrate RBAC Policy Format from JSON to YAML' is one of the community-wide goals for Wallaby development cycle. I am starting this thread to report the progress of this work. Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… Updates: ======== * Common code of upgrade checks and policy.json file fallback logic is moved from nova to oslo.upgradechecks (in version 1.2.0) and oslo.policy(in version 3.6.0) respectively. ** For upgrade checks, you just need to enable it from the project side. Example: https://review.opendev.org/c/openstack/keystone/+/764240/4/keystone/cmd/sta… ** For olso.policy fallback logic, you just need to bump the min version to 3.6.0. For project who already change the policy_file default in previous releases (like Cinder ) then you can disable this fallback logic via flag 'fallback_to_json_file' * I have started few projects to propose the changes and will continue to do that for other projects too. If you are interested to help, please write it in tracking etherpad [1]. * I am updating the goal documents also for oslo side common code and the latest example. - https://review.opendev.org/c/openstack/governance/+/764261 - This is an example you can refer: https://review.opendev.org/c/openstack/keystone/+/764240 [1] https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml -gmann

1 0

[neutron] Drivers meeting - 27.11.2020
by Slawek Kaplonski 26 Nov '20

26 Nov '20

Hi, As it's Thanksgiving week and Black Friday so our US folks will probably not be there and lets cancel the meeting this week. But we have couple of new RFEs which needs to be triaged: * https://bugs.launchpad.net/neutron/+bug/1905391 * https://bugs.launchpad.net/neutron/+bug/1905295 * https://bugs.launchpad.net/neutron/+bug/1905115 * https://bugs.launchpad.net/neutron/+bug/1900934 So please take some time and help with triaging them so we will be able to discuss them next week hopefully :) Have a great weekend! -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[ptl][release][stable][EM] Extended Maintenance - Stein
by Előd Illés 26 Nov '20

26 Nov '20

Hi, As Victoria was released yesterday and we are in a less busy period, it is a good opportunity to call your attention to the following: In less than a month Stein is planned to enter into Extended Maintenance phase [1] (planned date: 2020-11-11). I have generated the list of *open* and *unreleased* changes in *stable/stein* for the follows-policy tagged repositories [2]. These lists could help the teams, who are planning to do a *final* release on Stein before moving stable/stein branches to Extended Maintenance. Feel free to edit and extend these lists to track your progress! * At the transition date the Release Team will tag the *latest* (Stein) releases of repositories with *stein-em* tag. * After the transition stable/stein 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 the changes, in order to avoid broken releases! Thanks, Előd [1] https://releases.openstack.org [2] https://etherpad.openstack.org/p/stein-final-release-before-em

2 2

[oslo] py-amqp TLS peer authentication
by Moises Guimaraes de Medeiros 26 Nov '20

26 Nov '20

Hi all, This email is about a potential MITM attack, I would like to get some input on my proposed solution. *Disclaimer: I'm not an oslo.messaging expert or even versed in its codebase but I have a good* * number of hours working with TLS already.* Back in September, there was a fix[1] in py-amqp to stop to use deprecated method ssl.wrap_socket. Although I didn't follow anything about oslo.messaging, the PR was brought to my attention by Hervé, another oslo core, who sees me as an SME on TLS among the oslo cores. I didn't follow the entire conversation back then, I was only able to give some quick input, but Hervé was able to finish the PR with the help of another developer. Then earlier this month, another PR[2] was reintroducing a couple of parameters that got dropped in the deprecation fix. At that point it was raised the possibility of a MITM attack in an issue[3] and by reintroducing the dropped parameters, the problem should be fixed. A couple of days went by and I started to have a hunch that there could still be more to fix. I went to py-amqp codebase instead of just looking to the diffs on GitHub and noticed a not straightforward logic on how verify_mode and check_hostname were being set. Today I had time to go back to the py-amqp codebase and rework the _wrap_socket_sni() method. I've put up this PR[4] and it is already failing in my travis[5] for integration tests which make me believe that the client sockets were actually not validating the server certs. There are a few more comments on the fix in the description of PR[4]. [1]: https://github.com/celery/py-amqp/pull/327 [2]: https://github.com/celery/py-amqp/pull/344 [3]: https://github.com/celery/py-amqp/issues/342 [4]: https://github.com/celery/py-amqp/pull/347 [5]: https://travis-ci.com/github/moisesguimaraes/py-amqp/builds/204747399 Thanks, -- Moisés Guimarães Software Engineer Red Hat <https://www.redhat.com> <https://red.ht/sig>

1 0

SFC for OVN
by Lazuardi Nasution 26 Nov '20

26 Nov '20

Hi, By https://docs.openstack.org/neutron/ussuri/admin/config-sfc.html, it is stated that SFC essentially is the SDN version of PBR. On the other side, PBR is supported by OVN. Is there any initiative of Neutron SFC driver for OVN which utilize native PBR support of OVN without having to alternate the OVN itself? For example, for having a port pair of port A to port B for flow classifier of HTTP traffic, we might make PBR which match HTTP traffic from port A address and set the next hop to port B address. The other way which might be used is destination NATing (redirection) on port A for HTTP traffic to port B address. OVN has native support for NAT too, but I think the PBR way is better. Best regards,

1 1

[tc] weekly update & agenda
by Mohammed Naser 26 Nov '20

26 Nov '20

Hi everyone, Here's an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Clarify the requirements for supports-api-interoperability https://review.opendev.org/c/openstack/governance/+/760562 - Add election schedule exceptions in charter https://review.opendev.org/c/openstack/governance/+/751941 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 - Add assert:supports-standalone https://review.opendev.org/c/openstack/governance/+/722399 - Remove assert_supports-zero-downtime-upgrade tag https://review.opendev.org/c/openstack/governance/+/761975 - Add Magpie charm to OpenStack charms https://review.opendev.org/c/openstack/governance/+/762820 - Propose Kendall Nelson for vice chair https://review.opendev.org/c/openstack/governance/+/762014 - Clarify impact on releases for SIGs https://review.opendev.org/c/openstack/governance/+/752699 ## General Changes - Move Placement under Nova's governance https://review.opendev.org/c/openstack/governance/+/760917 ## Other Reminders - Our next [TC] Weekly meeting is scheduled for November 26. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, November 26th, at 0000 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 1

[Freezer][Keystone][Mistral][Monasca][Murano][Openstack-Chef][Openstack-Helm][Openstacksdk][Trove][Watcher][Zun] Action required: Gerrit code audit
by Mohammed Naser 26 Nov '20

26 Nov '20

Hello there, As per the `service-announce` on October 20 regarding Gerrit Outage Update email http://lists.opendev.org/pipermail/service-announce/2020-October/000011.html, all project teams are required to audit changes for projects from 2020-10-01 to 2020-10-21. I'm reaching out to those projects in particular who the TC believes have not completed their audit yet. Let us know if you need any type of assistance in completing the audit. In case you didn’t know you needed to do this, feel free to reach out for support. Regards, Mohammed -- Mohammed Naser VEXXHOST, Inc.

13 14

[all][healthcheck]
by Lajos Katona 26 Nov '20

26 Nov '20

Hi, I send this mail out to summarize the discussion around Healthcheck API on Neutron PTG, and start a discussion how we can make this most valuable to the operators. On the Neutron PTG etherpad this topic is from L114: https://etherpad.opendev.org/p/neutron-wallaby-ptg . Background: oslo_middleware provides /healthcheck API path(see [1]), which can be used to poll by services like haproxy, and gives a plugin mechanism to add some more complicated checks, which can be switched on/off from config. The main questions: - Some common guidance what to present to the operators (if you check [2] and [3] in the comments there are really good questions/concerns) - Perhaps the API SIG has something about healtcheck, just I can't find it. - What to present with and without authentication (after checking again, I am not sure that it is possible to use authentication for the healthcheck) - A way forward can be to make it configurable with default to authenticated, and give the decision to the admin. - During the discussion the agreement was to separate the frontend health from the backend health and use direct indicators (like working db connectivity, and mq connectivity) instead of indirect indicators (like agents' health). Thanks in advance for the feedback. [1] https://docs.openstack.org/oslo.middleware/latest/reference/healthcheck_plu… [2] https://review.opendev.org/731396 [3] https://review.opendev.org/731554 Regards Lajos Katona (lajoskatona)

3 4

[neutron] [nova] [ussuri] IP of the VM at the provider network is different than the one registered at the Openstack controller
by Pavlos Basaras 26 Nov '20

26 Nov '20

Hello, Setup: i follow the main instruction for deploying openstack for learning purposes. I can successfully deploy vms in an internal network, and also connect them to a router that gives internet access using floating ips etc. My setup is based on ubuntu 18. I have virtualbox for deploying controller (10.0.0.11) and compute (10.0.0.31) etc. I have host only adapters at virtual box (dhcp enabled) for the two networks: mgmt: 10.0.0.0/24 and provider 203.0.111.0/24 as per the default instructions, and i use iptables to NAT the vms. Problem: When following the instructions from https://docs.openstack.org/install-guide/launch-instance-provider.html the vm is deployed successfully but the ip that it is assigned is different from the one that the controller has. It seems that there are more than one dhcp instances running? How can i debug this? Any advice? all the best, Pavlos.

2 2

Re: [neutron][openstack-ansible] Instances can only connect to provider-net via tenant-net but not directly
by Oliver Wenz 25 Nov '20

25 Nov '20

> First of all I'd suggest checking `openstack network agent list` and ensure that lxb agent is present there up and healthy. > Next I'd check nova-scheduler log (journalctl eventually) as it might have more insights. linuxbridge agent is up and healthy and the nova-scheduler log doesn't show any errors either > Please check in neutron server logs for the problems with binding port Indeed, running journalctl and grepping for the instance id shows an error (last lines): journalctl -u neutron-server -n 300 | grep 33c662c2-99d6-40fb-a716-118ad8b3b193 Nov 25 15:06:58 infra1-neutron-server-container-cbf4b105 neutron-server[88]: 2020-11-25 15:06:58.738 88 INFO neutron.wsgi [req-e5b7df6c-bfde-438a-bbb1-f2713b63e16b 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - default default] 192.168.110.128,192.168.110.201 "GET /v2.0/ports?device_id=33c662c2-99d6-40fb-a716-118ad8b3b193 HTTP/1.1" status: 200 len: 205 time: 0.3313231 Nov 25 15:07:04 infra1-neutron-server-container-cbf4b105 neutron-server[89]: 2020-11-25 15:07:04.782 89 INFO neutron.wsgi [req-9bdadc77-27d9-4f9d-86b5-349b598b1ba4 eaf8235312004e2da519b54d196f5415 474b7aa9b7894d6782402135c6ef4c2a - default default] 192.168.110.205,192.168.110.201 "GET /v2.0/ports?tenant_id=0f14905dab5546e0adec2b56c0f6be88&device_id=33c662c2-99d6-40fb-a716-118ad8b3b193 HTTP/1.1" status: 200 len: 1084 time: 0.0956030 Nov 25 15:07:05 infra1-neutron-server-container-cbf4b105 neutron-server[89]: 2020-11-25 15:07:05.020 89 INFO neutron.notifiers.nova [-] Nova event response: {'name': 'network-changed', 'server_uuid': '33c662c2-99d6-40fb-a716-118ad8b3b193', 'tag': '1e24a151-bd29-47f8-914b-05c66587541b', 'status': 'completed', 'code': 200} Nov 25 15:07:05 infra1-neutron-server-container-cbf4b105 neutron-server[89]: 2020-11-25 15:07:05.781 89 INFO neutron.wsgi [req-9b729386-4847-4be3-80fa-dce244435ddd eaf8235312004e2da519b54d196f5415 474b7aa9b7894d6782402135c6ef4c2a - default default] 192.168.110.205,192.168.110.201 "GET /v2.0/ports?tenant_id=0f14905dab5546e0adec2b56c0f6be88&device_id=33c662c2-99d6-40fb-a716-118ad8b3b193 HTTP/1.1" status: 200 len: 1084 time: 0.1147285 Nov 25 15:12:12 infra1-neutron-server-container-cbf4b105 neutron-server[89]: 2020-11-25 15:12:12.445 89 INFO neutron.wsgi [req-15cbcb76-04cd-4813-b1f9-d7f6596e14bf 920e739127a14018a55fb4422b0885e7 0f14905dab5546e0adec2b56c0f6be88 - default default] 192.168.110.205,192.168.110.201 "GET /v2.0/ports?device_id=33c662c2-99d6-40fb-a716-118ad8b3b193 HTTP/1.1" status: 200 len: 1085 time: 0.4594653 Nov 25 15:12:14 infra1-neutron-server-container-cbf4b105 neutron-server[83]: 2020-11-25 15:12:14.453 83 WARNING neutron.notifiers.nova [-] Nova event: {'server_uuid': '33c662c2-99d6-40fb-a716-118ad8b3b193', 'name': 'network-vif-deleted', 'tag': '1e24a151-bd29-47f8-914b-05c66587541b', 'status': 'failed', 'code': 422} returned with failed status Kind regards, Oliver

2 1

[qa][cinder][glance][swift] Gate status for swift test failing Bug#1905432
by Ghanshyam Mann 25 Nov '20

25 Nov '20

Hello Everyone, As you have seen that test_create_object_with_transfer_encoding is failing consistently since 20th Nov which is failing integrated-gate-storage and integrated-gate-object-storage jobs. The issue is that Tempest is getting 500 from swift API, I could not find the root cause yet so decided to disable this test for now to unlock the gate. Avoid recheck for this failure until this is merge - https://review.opendev.org/c/openstack/tempest/+/764061 I have filled bug against Tempest and Swift to track it - https://bugs.launchpad.net/swift/+bug/1905432 -gmann

2 1

[ironic] Proposing Steve Baker (stevebaker) for ironic-core
by Julia Kreger 25 Nov '20

25 Nov '20

Greetings everyone, I would like to propose Steve Baker for ironic-core. Steve shifted into focusing on Ironic contribution this year and he has been actively reviewing changes during the Victoria and now Wallaby cycle. He has brought insight, drive, and a curiosity to ask questions. Plus he took on the challenge of removing wsme from Ironic's API which is no small feat. I've run this nomination past the existing cores and everyone responded in full support of doing so. So if there are no objections, I'll add Steve to ironic-core next week. Otherwise, Congratulations Steve! -Julia

3 2

[qa][all] New hacking 4.0.0 is available
by Ghanshyam Mann 25 Nov '20

25 Nov '20

Hello Everyone, Hacking 4.0.0 is available to use now which includes many common checks used in various projects. While upgrading to new hacking you can remove those checks definition from your repo hacking checks. Check release notes to find what all common checks are being moved from the project side to hacking: - https://docs.openstack.org/releasenotes/hacking/unreleased.html#relnotes-4-… -gmann

1 0

[cinder][kayobe][kolla][OSA][tripleo][release] Victoria cycle-trailing release deadline
by Herve Beraud 25 Nov '20

25 Nov '20

Hello teams with deliverables following the cycle-trailing release model! This is just a reminder about wrapping those Victoria trailing deliverables up. A few cycles ago we extended the deadline for cycle-trailing to give more time, so the actual deadline isn't until January 14, 2021: https://releases.openstack.org/wallaby/schedule.html#w-cycle-trail If things are ready sooner than that though, all the better for our downstream consumers. Just for awareness, the following cycle-trailing deliverables will need their final releases at some point in the next few months: cinderlib kayobe kolla-ansible kolla openstack-ansible os-collect-config os-refresh-config tripleo-ipsec Thanks! -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[tripleo][ci] Issues w/ the quay container registry
by Wesley Hayutin 25 Nov '20

25 Nov '20

FYI.. This is impacting jobs atm. https://bugs.launchpad.net/tripleo/+bug/1905592 Will follow up when we're clear. 0/

1 0

[magnum] Can not deploy a cluster using Fedora CoreOS 32
by monadt 25 Nov '20

25 Nov '20

I am trying to use Magnum on Openstack that was deployed using kolla-ansible. The instance is completely private (so floating IPs are only accessible inside a VPN network) - not sure if this is a problem. The deployment looks as follows: Openstack Nodes: Ubuntu 20.04 Kolla-Ansible version: '10.1.0' kolla_base_distro: "ubuntu" openstack_release: "ussuri" I could successfully deploy the required magnum services and created a cluster template using the magnum cli as follows: openstack coe cluster template create kubernetes-cluster-template --image fedora-coreos-32 --external-network public-external --dns-nameserver 1.1.1.1 --master-flavor m1.small --flavor m1.small --docker-storage-driver overlay --coe kubernetes I am using the Fedora CoreOS 32 release (and uploaded the image like this): openstack image create --disk-format=qcow2 --container-format=bare --file=fedora-coreos-32.20201104.3.0-openstack.x86_64.qcow2 --property os_distro='fedora-coreos' fedora-coreos-32 I made sure to set the os_distro as stated in the repository when using fedora coreos. When I now try to create a cluster (openstack coe cluster create kubernetes-cluster --cluster-template kubernetes-cluster-template --master-count 1 --node-count 1 --keypair mykey) all the heat resources start spinning up, but the kube-masters resource will never come up. While debugging it seems to hang during the following step inside the heat-container-agent: + '[' ok = ok ']' + kubectl patch node kubernetes-cluster-flfrufngma6x-master-0 --patch '{"metadata": {"labels": {"node-role.kubernetes.io/master": ""}}}' error: no configuration has been provided, try setting KUBERNETES_MASTER environment variable + echo 'Trying to label master node with node-role.kubernetes.io/master=""' + sleep 5s Trying to label master node with node-role.kubernetes.io/master="" I also didn't find a way to set the KUBERNETES_MASTER environment variable from the outside. I assume there is no other supported distribution given that Fedora Atomic and non-Fedora CoreOS do no longer exist? Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 2

[cinder] wallaby R-18 virtual mid-cycle on 9 december
by Brian Rosmaita 25 Nov '20

25 Nov '20

As voted upon at today's weekly meeting, the Cinder Wallaby R-18 virtual mid-cycle will be held: DATE: WEDNESDAY 9 DECEMBER 2020 TIME: 1400-1600 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Please add topics to the mid-cycle etherpad: https://etherpad.opendev.org/p/cinder-wallaby-mid-cycles cheers, brian

1 0

[neutron][operators][all] Watch out for updates of stable/train and stable/stein releases in Neutron
by Slawek Kaplonski 25 Nov '20

25 Nov '20

Hi, I want to warn all of You about terrible mistake which we made in Neutron some time ago. We backported to stable releases patch [1] which broke update workflow. So if You are now updating Your Stein or Train Neutron to latest version and You will do it as it should be done, so first neutron-server and then agents, Your neutron-ovs-agents will not work properly with newer neutron-server. Details are in reported bug [2] Broken versions are: * for Train 15.2.0 and 15.3.0 * for Stein 14.3.1, 14.4.0 and 14.4.1 We proposed reverts of [1] and those reverts are now in gate. As soon as they will be merged we will release new, fixed versions for both Stein and Train. So if You didn't update to those broken versions yet, please don't do it now and wait for next version with fix. If You already updated and fixed that issue on Your clusters - You will have exactly same problem during next update again. I know it's very bad but unfortunately we don't have any other way to fix that issue. [1] https://review.opendev.org/#/c/744133/ [2] https://bugs.launchpad.net/neutron/+bug/1903531 -- Slawek Kaplonski Principal Software Engineer Red Hat

5 7

[neutron][openstack-ansible] Instances can only connect to provider-net via tenant-net but not directly
by Oliver Wenz 25 Nov '20

25 Nov '20

Hi, Starting instances which are connected directly to a provider network results in an error in my Ussuri cloud. However, I can associate floating IPs for this provider network when I connect instances to it via a tenant network and it works fine. Both nova-compute and neutron-linuxbridge-agent services don't show errors, I only get an error in the instance status: 'code': 500, 'created': '2020-11-25T12:05:42Z', 'message': 'Build of instance 274e0a7d-fb33-430a-986e-74fceae6a36d aborted: Failed to allocate the network(s), not rescheduling.', 'details': 'Traceback (most recent call last): File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 6549, in _create_domain_and_network post_xml_callback=post_xml_callback) File "/usr/lib/python3.6/contextlib.py", line 88, in __exit__ next(self.gen) File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", line 513, in wait_for_instance_event actual_event = event.wait() File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/eventlet/event.py", line 125, in wait result = hub.switch() File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/eventlet/hubs/hub.py", line 298, in switch return self.greenlet.switch() eventlet.timeout.Timeout: 300 seconds During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", line 2378, in _build_and_run_instance accel_info=accel_info) File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 3683, in spawn cleanup_instance_disks=created_disks) File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 6572, in _create_domain_and_network raise exception.VirtualInterfaceCreateException() nova.exception.VirtualInterfaceCreateException: Virtual Interface creation failed During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", line 2200, in _do_build_and_run_instance filter_properties, request_spec, accel_uuids) File "/openstack/venvs/nova-21.1.0/lib/python3.6/site-packages/nova/compute/manager.py", line 2444, in _build_and_run_instance reason=msg) nova.exception.BuildAbortException: Build of instance 274e0a7d-fb33-430a-986e-74fceae6a36d aborted: Failed to allocate the network(s), not rescheduling. ' Any ideas what could cause this? Kind regards, Oliver On 2020-11-25 13:00, openstack-discuss-request(a)lists.openstack.org wrote: > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > or, via email, send a message with subject or body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > > Today's Topics: > > 1. Re: > [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova > enforces that no DB credentials are allowed for the nova-compute > service (Balázs Gibizer) > 2. Re: [ironic] [infra] Making Glean work with IPA for static IP > assignment (Dmitry Tantsur) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 25 Nov 2020 11:13:23 +0100 > From: Balázs Gibizer <balazs.gibizer(a)est.tech> > To: Thomas Goirand <zigo(a)debian.org> > Cc: openstack maillist <openstack-discuss(a)lists.openstack.org> > Subject: Re: > [nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova > enforces that no DB credentials are allowed for the nova-compute > service > Message-ID: <BEKCKQ.PYGQ12VO6AF23(a)est.tech> > Content-Type: text/plain; charset=iso-8859-1; format=flowed > > > > On Mon, Nov 23, 2020 at 13:47, Thomas Goirand <zigo(a)debian.org> wrote: >> On 11/23/20 11:31 AM, Balázs Gibizer wrote: >>> It is still a security problem if nova-compute ignores the config >>> as the >>> config still exists on the hypervisor node (in some deployment >>> scenarios) >> >> Let's say we apply the patch you're proposing, and that nova-compute >> isn't loaded anymore with the db credentials, because it's on a >> separate >> file, and nova-compute doesn't load it. >> >> In such scenario, the /etc/nova/nova-db.conf could still be present >> with >> db credentials filled-in. So, the patch you're proposing is still not >> effective for wrong configuration of nova-compute hosts. > > Obviously we cannot prevent that the deployer stores the DB creds on a > compute host as we cannot detect it in general. But we can detect it if > it is stored in the config the nova-compute reads. I don't know why > should we not make sure to tell the deployer not to do that as it is > generally considered unsafe. > >> >>> From the nova-compute perspective we might be able to >>> replace the [api_database]connection dependency with some hack. E.g >>> to >>> put the service name to the global CONF object at the start of the >>> service binary and depend on that instead of other part of the >>> config. >>> But I feel pretty bad about this hack. >> >> Because of the above, I very much think it'd be the best way to go, >> but >> I understand your point of view. Going to the /etc/nova/nova-db.conf >> and >> nova-api-db.conf thing is probably good anyways. >> >> As for the nova-conductor thing, I very much would prefer if we had a >> clean and explicit "superconductor=true" directive, with possibly some >> checks to display big warnings in the nova-conductor.log file in case >> of >> a wrong configuration. If we don't have that, then at least things >> must >> be extensively documented, because that's really not obvious what's >> going on. > > I agree that superconductor=true would be a more explicit config option > than [api_database]connection. However this would also enforce that > deployers need a separate config file for nova-compute as there neither > superconductor=true nor superconductor=false (meaning it is a cell > conductor) make sense. > >> >> Cheers, >> >> Thomas Goirand (zigo) >> > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 25 Nov 2020 11:54:13 +0100 > From: Dmitry Tantsur <dtantsur(a)redhat.com> > To: Ian Wienand <iwienand(a)redhat.com> > Cc: openstack-discuss <openstack-discuss(a)lists.openstack.org> > Subject: Re: [ironic] [infra] Making Glean work with IPA for static IP > assignment > Message-ID: > <CACNgkFwVhMMxVRK2PkFEkHORRwY4wY49g7G3CpzYwaFzC27Bjw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > Thank you for your input! > > On Wed, Nov 25, 2020 at 3:09 AM Ian Wienand <iwienand(a)redhat.com> wrote: > >> On Tue, Nov 24, 2020 at 11:54:55AM +0100, Dmitry Tantsur wrote: >>> The problem is, I cannot make Glean work with any ramdisk I build. The >> crux >>> of the problem seems to be that NetworkManager (used by default in RHEL, >>> CentOS, Fedora and Debian at least) starts very early, creates the >> default >>> connection and ignores whatever files Glean happens to write afterwards. >> On >>> Debian running `systemctl restart networking` actually helped to pick the >>> new configuration, but I'm not sure we want to do that in Glean. I >> haven't >>> been able to make NetworkManager pick up the changes on RH systems so >> far. >> >> So we do use NetworkManager in the OpenDev images, and we do not see >> NetworkManager starting before glean. >> > > Okay, thanks for confirming. Maybe it's related to how IPA is built? It's > not exactly a normal image after all, although it's pretty close to one. > > >> >> The way it should work is that simple-init in dib installs glean to >> the image. That runs the glean install script (use --use-nm argument >> if DIB_SIMPLE_INIT_NETWORKMANAGER, which is default on centos/fedora) >> which installs two things; udev rules and a systemd handler. >> > > I have checked that these are installed, but I don't know how to verify a > udev rule. > > >> >> The udev is pretty simple [1] and should add a "Wants" for each net >> device; e.g. eth1 would match and create a Wants glean(a)eth1.service, >> which then matches [2] which should write out the ifcfg config file. >> After this, NetworkManager should start, notice the config file for >> the interface and bring it up. >> > > Yeah, I definitely see logging from NetworkManager DHCP before this service > is run (i.e. before the output from Glean). > > >> >>> Do you maybe have any hints how to proceed? I'd be curious to know how >>> static IP assignment works in the infra setup. Do you have images with >>> NetworkManager there? Do you use the simple-init element? >> >> As noted yes we use this. Really only in two contexts; it's Rackspace >> that doesn't have DHCP so we have to setup the interface statically >> from the configdrive data. Other clouds all provide DHCP, which is >> used when there's no configdrive data. >> >> Here is a systemd-analyze from one of our Centos nodes if it helps: >> > >> graphical.target @18.403s >> └─multi-user.target @18.403s >> └─unbound.service @5.467s +12.934s >> └─network.target @5.454s >> └─NetworkManager.service @5.339s +112ms >> └─network-pre.target @5.334s >> └─glean(a)ens3.service @4.227s +1.102s >> └─basic.target @4.167s >> └─sockets.target @4.166s >> └─iscsiuio.socket @4.165s >> └─sysinit.target @4.153s >> └─systemd-udev-settle.service @1.905s +2.245s >> └─systemd-udev-trigger.service @1.242s +659ms >> └─systemd-udevd-control.socket @1.239s >> └─system.slice >> > > # systemd-analyze critical-chain > multi-user.target @2min 6.301s > └─tuned.service @1min 32.273s +34.024s > └─network.target @1min 31.590s > └─network-pre.target @1min 31.579s > └─glean(a)enp1s0.service @36.594s +54.952s > └─system-glean.slice @36.493s > └─system.slice @4.083s > └─-.slice @4.080s > > # systemd-analyze critical-chain NetworkManager.service > NetworkManager.service +9.287s > └─network-pre.target @1min 31.579s > └─glean(a)enp1s0.service @36.594s +54.952s > └─system-glean.slice @36.493s > └─system.slice @4.083s > └─-.slice @4.080s > > # cat /etc/sysconfig/network-scripts/ifcfg-enp1s0 > # Automatically generated, do not edit > DEVICE=enp1s0 > BOOTPROTO=static > HWADDR=52:54:00:1f:79:7e > IPADDR=192.168.122.42 > NETMASK=255.255.255.0 > ONBOOT=yes > NM_CONTROLLED=yes > > # ip addr > ... > 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state > UP group default qlen 1000 > link/ether 52:54:00:1f:79:7e brd ff:ff:ff:ff:ff:ff > inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic > noprefixroute enp1s0 > valid_lft 42957sec preferred_lft 42957sec > inet6 fe80::f182:7fb4:7a39:eb7b/64 scope link noprefixroute > valid_lft forever preferred_lft forever > > >> At a guess; I feel like the udev bits are probably not happening >> correctly in your case? That's important to get the glean@<interface> >> service in the chain to pre-create the config file >> > > It seems that the ordering is correct and the interface service is > executed, but the IP address is nonetheless wrong. > > Can it be related to how long glean takes to run in my case (54 seconds vs > 1 second in your case)? > > Dmitry > > >> >> -i >> >> [1] >> https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-udev.r… >> [2] >> https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-nm@.se… >> >> >

3 2

[nova][tripleo][rpm-packaging][kolla][puppet][debian][osa] Nova enforces that no DB credentials are allowed for the nova-compute service
by Balázs Gibizer 25 Nov '20

25 Nov '20

Dear packagers and deployment engine developers, Since Icehouse nova-compute service does not need any database configuration as it uses the message bus to access data in the database via the conductor service. Also, the nova configuration guide states that the nova-compute service should not have the [api_database]connection config set. Having any DB credentials configured for the nova-compute is a security risk as well since that service runs close to the hypervisor. Since Rocky[1] nova-compute service fails if you configure API DB credentials and set upgrade_level config to 'auto'. Now we are proposing a patch[2] that makes nova-compute fail at startup if the [database]connection or the [api_database]connection is configured. We know that this breaks at least the rpm packaging, debian packaging, and puppet-nova. The problem there is that in an all-in-on deployment scenario the nova.conf file generated by these tools is shared between all the nova services and therefore nova-compute sees DB credentials. As a counter-example, devstack generates a separate nova-cpu.conf and passes that to the nova-compute service even in an all-in-on setup. The nova team would like to merge [2] during Wallaby but we are OK to delay the patch until Wallaby Milestone 2 so that the packagers and deployment tools can catch up. Please let us know if you are impacted and provide a way to track when you are ready with the modification that allows [2] to be merged. There was a long discussion on #openstack-nova today[3] around this topic. So you can find more detailed reasoning there[3]. Cheers, gibi [1] https://github.com/openstack/nova/blob/dc93e3b510f53d5b2198c8edd22528f0c899… [2] https://review.opendev.org/#/c/762176 [3] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… -- http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.…

11 53

[release][infra] SSH key error - RedFlag stop approving
by Herve Beraud 25 Nov '20

25 Nov '20

Hello, We are facing SSH issues on our release jobs [1][2]. Indeed, our release account failed to connect to gerrit through SSH [2]. The ID seems to be recognized when we try it. So that would probably mean we have a stale host key on the machine the script is running on . We suppose that the issue could be a side effect of the gerrit upgrade, we updated the etherpad to inform the infra team [3] @release managers: We should stop approving, so, please hold all our unmerged patches while this incident isn't solved. Thanks for your reading, [1] http://lists.openstack.org/pipermail/release-job-failures/2020-November/001… Example of faced error: ``` ssh://release@review.opendev.org:29418/openstack/python-senlinclient.git did not work. Description: Host key verification failed. Could not read from remote repository ``` [3] https://etherpad.opendev.org/p/gerrit-3.2-post-upgrade-notes -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 2

[all] X Release Naming
by Sean McGinnis 24 Nov '20

24 Nov '20

Hello everyone, This is to notify everyone that we are now kicking off the release naming process for the 'X' OpenStack release. Starting with the last W naming, we had altered our traditional way of choosing a release name to allow any name that meets the basic criteria - basically that the name begins with the chosen letter, it is made up if the ISO basic Latin alphabet, and that it is 10 characters or less in length. Community proposed names are collected on the wiki page for the X Release Naming. This page also includes more details about the process and timing: https://wiki.openstack.org/wiki/Release_Naming/X_Proposals We welcome any names from the community. This should be an intersting release to see what everyone comes up with! Please add any ideas to the wiki page. -- Sean McGinnis

1 1

[cinder] this week's meeting in video+IRC
by Brian Rosmaita 24 Nov '20

24 Nov '20

Quick reminder that this week's Cinder team meeting on Wednesday 25 November, being the final meeting of the month, will be held in both videoconference and IRC at the regularly scheduled time of 1400 UTC. Here's a quick reminder of the video meeting rules we've agreed to: * Everyone will keep IRC open during the meeting. * We'll take notes in IRC to leave a record similar to what we have for our regular IRC meetings. * Some people are more comfortable communicating in written English. So at any point, any attendee may request that the discussion of the current topic be conducted entirely in IRC. connection info: https://bluejeans.com/3228528973 cheers, brian

1 0

RDO Community Meeting Update
by Amy Marrich 23 Nov '20

23 Nov '20

During the virtual Get Together, we decided to have the first meeting of the month virtually to help with the lack of face to face time between contributors at events. Please join us during the virtual meetings using the following link: meet.google.com/uzo-tfkt-top We will also be keeping notes within the #rdo channel on Freenode for our normal post-meeting sharing so if you can not join us virtually please join us via IRC as usual. Thanks and hope to see everyone virtually on December 2nd at 14:00 UTC! Amy (spotz)

1 0

[neutron] Cannot deploy instance in provider network openstack Ussuri -- network fails
by Pavlos Basaras 23 Nov '20

23 Nov '20

Hello, i am new to Openstack. I have followed the instructions from https://docs.openstack.org/install-guide/ to install openstack Ussuri where i use a controller node and a compute node (i can ping each other and access the internet from both nodes through the mgmt iface). I use ubuntu 18.04 for all components. I have configured the network option 2, seems to work fine: openstack network agent list +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ | ID | Agent Type | Host | Availability Zone | Alive | State | Binary | +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ | 2d8c3a89-32c4-4b97-aa4f-ca19db53b24f | L3 agent | controller | nova | :-) | UP | neutron-l3-agent | | 413cd13d-88d7-45ce-8b2e-26fdb265740f | Metadata agent | controller | None | :-) | UP | neutron-metadata-agent | | 42f57bee-63b3-44e6-9392-939ece98719d | Linux bridge agent | compute | None | :-) | UP | neutron-linuxbridge-agent | | 4a787a09-04aa-4350-bd32-0c0177ed06a1 | DHCP agent | controller | nova | :-) | UP | neutron-dhcp-agent | | fdafc337-7581-4ecd-b175-810713a25e1f | Linux bridge agent | controller | None | :-) | UP | neutron-linuxbridge-agent | +--------------------------------------+--------------------+------------+-------------------+-------+-------+---------------------------+ If i try to bring up instances connected by an internal network, they are successfully deployed. When i use the provider network to bring up an instance with the command: openstack server create --flavor m1.tiny --image cirros034 --nic net-id=4463e4a7-3b06-46d9-b24f-3e2e7867ee96 --security-group=5cf380e5-efb3-48b3-b8e9-095b1ebd817d provider-instance the instance fails to be instantiated because the network cannot be deployed. I noticed two points from the neutron-linuxbridge-agent.log file at the compute node (the logs at the controller seem fine): 1) ERROR neutron.plugins.ml2.drivers.agent._common_agent pyroute2.netlink.exceptions.NetlinkError: (13, 'Permission denied') 2) INFO neutron.plugins.ml2.drivers.agent._common_agent [req-816902d4-6581-49c1-939a-6ea69b437c99 - - - - -] Linux bridge agent Agent out of sync with plugin! -- not sure if this one is a problem. One part that i am not sure is the following configuration since i am on ubuntu 18 and not ubuntu 16: # The provider network interface auto INTERFACE_NAME iface INTERFACE_NAME inet manual up ip link set dev $IFACE up down ip link set dev $IFACE down I did not include this part in my file since its ubuntu 18, and netplan does not have an equivalent (i think) option. I have this netplan config enp0s8: --> mgmt dhcp4: false addresses: [10.0.0.31/24] gateway4: 10.0.0.1 nameservers: addresses: [8.8.8.8, 8.8.4.4] enp0s9: --> provider dhcp4: false any advice? all the best, Pavlos Basaras

2 4

[manila] Proposing Maari Tamm for python-manilaclient core
by Victoria Martínez de la Cruz 23 Nov '20

23 Nov '20

Hi everyone, It's a great pleasure for me to propose Maari Tamm (maaritamm) for the python-manilaclient core group. Maari joined us as an Outreachy intern working on the manila support for openstackclient in December 2019. She excelled at delivering the main task, and she went above and beyond by continuing to contribute with the community even after her internship finished. She now continues submitting enhancements for the different manila components and taking on new challenges as they appear. Not only that, Maari joined us as mentor for the manila project in different efforts we have made: the Open Source Day in Grace Hopper Celebration 2020 and also mentoring for three students from the Boston University that are currently working with us in manila. Maari is a truly valuable member of our team and I believe she will be a great addition to the python-manilaclient core reviewers group. Looking forward to a positive response. All the best, Victoria

8 8

[oslo] following or not following the DST changes for our meeting time
by Herve Beraud 23 Nov '20

23 Nov '20

Hello Oslofolk, As discussed during our previous meeting, at each DST change, the agenda of some of us conflicting with our Oslo meeting time slot, this thread just wants to propose a solution to avoid that. We could just move our meeting time when DST changes, and then move back to this slot once DST is back. Right now our meeting time is UTC based, we suppose that UTC is required because of the OpenStack meeting tooling. By following that we will get the following time slots: - meeting time slot when DST start: 5:00pm UTC - meeting time slot when DST end: 4:00pm UTC Does it fit well for you? -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

4 6

[nova] heads up about the limitations of the new gerrit
by Balázs Gibizer 23 Nov '20

23 Nov '20

Hi, We have the new shiny gerrit. But please be aware the limitations[1]. I want to highlight one. The launchpad - gerrit integration does not work so the bluperints and bugs are not updated in launchpad based on the changes in gerrit. So please manually update launchpad. cheers, gibi [1] https://etherpad.opendev.org/p/gerrit-3.2-post-upgrade-notes

2 1

[neutron] Bug deputy report November 16 - 22
by Jakub Libosvar 23 Nov '20

23 Nov '20

Hi all, I was the bug deputy for the last week, here is the report: Critical * Failure in test_l2_agent_restart(OVS,Flat network) https://bugs.launchpad.net/neutron/+bug/1904897 This is failing on the gate occasionally Needs an assignee High * GRE tunnels over IPv6 are created in wrong way https://bugs.launchpad.net/neutron/+bug/1904564 Assigned to: Slawek Patch review pending: https://review.opendev.org/c/openstack/neutron/+/763204/ * [OVN] Metadata namespace checksum error with DPDK https://bugs.launchpad.net/neutron/+bug/1904871 Assigned to: Rodolfo Medium * [ovn] Don't include IP addresses for OVN ports if both port security and DHCP are disabled https://bugs.launchpad.net/neutron/+bug/1904412 Assigned to: Elvira Patch review pending: https://review.opendev.org/c/openstack/neutron/+/763567/ * Designate driver: allow_reverse_dns_lookup doesn't works if dns_domain zone wasn't created https://bugs.launchpad.net/neutron/+bug/1904559 Reporter offered a patch but hasn't sent yet * [OVN] Inconsistent "flooding to unregistered" IGMP configuration https://bugs.launchpad.net/neutron/+bug/1904399 Assigned to: Lucas Patch review pending: https://review.opendev.org/c/openstack/neutron/+/762818/ Wishlist * "gateway" option is not honored when creating a subnet with subnet pool https://bugs.launchpad.net/neutron/+bug/1904436 [RFE] Extend neutron-metadata-agent to support to proxy multiple external services https://bugs.launchpad.net/neutron/+bug/1905115 This is an RFE, so far marked as wishlist, should be discussed by the drivers team. Undecided * Enforce security group cleanup (Resources leaks) https://bugs.launchpad.net/neutron/+bug/1904694 It was not clear to me where does the error come from, I assumed tempest. * Neutron – it’s possible to delete router’s port related to external gateway https://bugs.launchpad.net/neutron/+bug/1904751 * neutron-dynamic-routing reported as not alive after adding BGP Peer to BGP Speaker https://bugs.launchpad.net/neutron/+bug/1904869 It seems to me like a configuration issue, agent missing rabbitmq settings. Invalid * Neutron – it’s possible to delete router’s port related to external gateway There is a patch: https://review.opendev.org/#/c/763198/ It's claimed this patch is reproducing the issue but the patch fails elsewhere. I don't think this report is valid.

1 0

[kolla][ptg] Kolla Wallaby priorities
by Mark Goddard 23 Nov '20

23 Nov '20

Hi, Thanks to everyone who attended the Kolla PTG sessions, we covered a lot of ground. The Etherpad is available at [1]. I wrote an email [2] summarising the discussions. I have moved candidate work items across to a second Etherpad [2] for voting on. Now is the time to vote! Please add your name against a maximum of 12 items across the 3 deliverables (kolla, kolla-ansible, kayobe) in the priorities [2] Etherpad. Anyone in the community is welcome to vote. [1] https://etherpad.opendev.org/p/kolla-wallaby-ptg [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018445.… [3] https://etherpad.opendev.org/p/kolla-wallaby-priorities Thanks, Mark

1 3

[nova] How best to provide virtio-based input devices?
by Stephen Finucane 20 Nov '20

20 Nov '20

Design discussion for interested parties. As discussed during the nova team meeting today, we're looking at providing support for virtio-based input devices in nova, given benefits w.r.t. performance and security (no emulated USB bus!). The current proposal I have for this is to introduce a new image metadata property, 'hw_input_bus', and extend the existing 'hw_pointer_model' image metadata property, which currently only accepts a 'usbtablet' value, to accept 'mouse' or 'tablet' values. This means you'd end up with a matrix something like so: +------------------+--------------+------------------------+ | hw_pointer_model | hw_input_bus | Result | +------------------|--------------+------------------------+ | - | - | PS2-based mouse [*] | | usbtablet | - | USB-based tablet | | usbtablet | usb | USB-based tablet | | usbtablet | virtio | **ERROR** | | mouse | - | USB-based mouse | | mouse | usb | USB-based mouse | | mouse | virtio | virtio-based mouse | | tablet | - | USB-based tablet | | tablet | usb | USB-based tablet | | tablet | virtio | virtio-based tablet | +------------------+--------------+------------------------+ [*] libvirt adds these by default on x86 hosts dansmith noted that the only reason to select the 'mouse' pointer model nowadays is for compatibility, and something like a virtio-based mouse didn't really make sense. That being the case, I agree that this change is likely more complex that it needs to be. We do, however, disagree on the remedy. dansmith's idea is to drop the 'hw_input_bus' image metadata property entirely and simply add a new 'virtiotablet' value to 'hw_pointer_model' instead. This still leaves the question of what bus we should use for keyboards, and his suggestion there is to extrapolate out and use virtio for keyboards if 'hw_pointer_model=virtiotablet' is specified and presumably USB if 'hw_pointer_model=usbtablet'. Needless to say, I don't like this idea and prefer we took another tack and kept 'hw_input_bus' but didn't build on 'hw_pointer_model' and instead "deprecated" it. We can't really ever remove the an image metadata property, since that would be a breaking upgrade, which means we'll eventually be left with effectively dead code to maintain forever. However, I don't think that's a big deal. 'hw_pointer_model=usbtablet' is already on a path to obsolescence as the Q35 machine type slowly becomes the default on x86 hosts and the use of non-x86 hosts grows since neither support PS2 and must use a USB-based input device. In addition, I think the extrapolation of 'virtiotablet' to mean also virtio-based keyboard is unclear and leaves a gaping hole w.r.t. requesting USB-based keyboards on non-AArch64 hosts (where it's currently added by default), since we don't currently do this extrapolation and introducing it would be breaking change on x86 hosts (instances would suddenly switch from PS2-based keyboards to USB-based ones). We need to decide what approach to go for before I rework this. If anyone has input, particularly operators that think they'd use this feature, I'd love to hear it so that I can t̶e̶l̶l̶ ̶d̶a̶n̶s̶m̶i̶t̶h̶ ̶t̶o̶ ̶s̶h̶o̶v̶e̶ ̶i̶t̶ come to the best possible solution ;-) Feel free to either reply here or on the review [1]. Cheers, Stephen [1] https://review.opendev.org/#/c/756552/

3 7

[openstack-helm] No Meeting Next Week
by Gage Hugo 20 Nov '20

20 Nov '20

Hello everyone, Due to Thanksgiving in the US next week, the openstack-helm meeting will be cancelled, we will meet again at our regular time on Dec 1st. Hope everyone has a good holiday and stays safe!

1 0

[Security-SIG] No meeting next week
by Gage Hugo 20 Nov '20

20 Nov '20

Hello everyone, Due to Thanksgiving in the US next week, the Security SIG meeting will be cancelled, we will meet again at our regular time on Dec 3rd. Hope everyone has a good holiday and stays safe!

1 0

[all][diversity] IRC Channel Renames
by Kendall Nelson 20 Nov '20

20 Nov '20

Hello! So now that the OpenStack Foundation is now the Open Infrastructure Foundation, I think it time to take a look at some of the IRC channels we use. There are a few that come to mind that are used by the larger Foundation community- not just OpenStack anymore- that should probably be renamed[0]. Below is a list of the channels that come to mind and proposed new channel names. Please add to the list or suggest alternative names if you hate what I've come up with. My goal is to process these renames by the end of the year. - #openstack-ptg -> #oif-ptg - #openstack-forum -> #oif-forum - #openstack-diversity -> #oif-diversity - #openstack-board -> #oif-board - #openstack-foundation -> #oif-foundation Look forward to everyone's thoughts! -Kendall (diablo_rojo) [0] https://docs.opendev.org/opendev/system-config/latest/irc.html#renaming-an-…

4 5

[heat][tripleo] upstream heat ci job dashboard
by Wesley Hayutin 20 Nov '20

20 Nov '20

Greetings, Just an FYI.. Adriano has put together a nice dashboard for getting a high level view of the upstream CI jobs for heat [1]. Thanks Adriano, well done! [1] http://dashboard-ci.tripleo.org/d/TsdDSjtMz/upstream-heat?orgId=1

1 0

[openstack] [Interop] Todays Friday weekly meeting cancelled - will meet next week same time same meetpad
by prakash RAMCHANDRAN 20 Nov '20

20 Nov '20

Hi all,We have gerrit access issues for any Interop WG activity to be possible for Victoria cycle. Will meet next Friday 10 AM PST instead refer: [service-announce] review.opendev.org Gerrit outage and upgrade 15:00UTC November 20 to 01:00UTC November 23, 2020 | | | | [service-announce] review.opendev.org Gerrit outage and upgrade 15:00UTC... | | | Please add your items if any for next week 27th NovOpenDev Etherpad | | | | OpenDev Etherpad | | | ThanksFor Interop WGPrakash

1 0

[neutron] Floating ips instances not appear in tcpdump
by Cristina Mayo 20 Nov '20

20 Nov '20

Hello, I have a multinode Openstack cloud installed on Ubuntu machines following the official guides, without extra settings. I have realised that all the income traffic on my instances with floating ips have the same source ip (controller's node ip address). Could anyone help to understand this behaviour? I would like source ip address remains because I am interested in filter traffic, and it's currently impossible. It seems that my controller node is changing the original ip to the packets. Thanks in advance, Regards

3 4

[horizon] Error when clicking instance detailed view after upgrading from ussuri to victoria
by Bujack, Stefan 20 Nov '20

20 Nov '20

Hello, I am a little lost here. Hopefully some of you nice people could help me with this issue please. We had an Openstack Ussuri deployment on Ubuntu 20.04 and upgraded to Victoria Release via cloud_archive repository Now when I click on any instance for a detailed view I get an error 500 with the following message: ==> /var/log/apache2/error.log <== [Wed Nov 18 19:42:37.883040 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] /usr/lib/python3/dist-packages/django/contrib/staticfiles/templatetags/staticfiles.py:24: RemovedInDjango30Warning: {% load staticfiles %} is deprecated in favor of {% load static %}. [Wed Nov 18 19:42:37.883091 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] warnings.warn( [Wed Nov 18 19:42:37.886358 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] ERROR django.request Internal Server Error: /project/instances/25d58259-9d9d-4215-8fb6-521ff9a5befe/ [Wed Nov 18 19:42:37.886400 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] Traceback (most recent call last): [Wed Nov 18 19:42:37.886407 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 829, in _resolve_lookup [Wed Nov 18 19:42:37.886412 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = current[bit] [Wed Nov 18 19:42:37.886416 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] TypeError: 'Server' object is not subscriptable [Wed Nov 18 19:42:37.886421 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] [Wed Nov 18 19:42:37.886425 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] During handling of the above exception, another exception occurred: [Wed Nov 18 19:42:37.886430 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] [Wed Nov 18 19:42:37.886456 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] Traceback (most recent call last): [Wed Nov 18 19:42:37.886460 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/base.py", line 139, in __getattribute__ [Wed Nov 18 19:42:37.886465 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return object.__getattribute__(self, attr) [Wed Nov 18 19:42:37.886469 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] AttributeError: 'Server' object has no attribute 'OS-EXT-SRV-ATTR:instance_name' [Wed Nov 18 19:42:37.886473 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] [Wed Nov 18 19:42:37.886477 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] During handling of the above exception, another exception occurred: [Wed Nov 18 19:42:37.886482 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] [Wed Nov 18 19:42:37.886486 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] Traceback (most recent call last): [Wed Nov 18 19:42:37.886501 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 34, in inner [Wed Nov 18 19:42:37.886647 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] response = get_response(request) [Wed Nov 18 19:42:37.886651 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 145, in _get_response [Wed Nov 18 19:42:37.886656 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] response = self.process_exception_by_middleware(e, request) [Wed Nov 18 19:42:37.886661 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 143, in _get_response [Wed Nov 18 19:42:37.886665 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] response = response.render() [Wed Nov 18 19:42:37.886668 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/response.py", line 106, in render [Wed Nov 18 19:42:37.886672 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] self.content = self.rendered_content [Wed Nov 18 19:42:37.886676 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/response.py", line 83, in rendered_content [Wed Nov 18 19:42:37.886680 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] content = template.render(context, self._request) [Wed Nov 18 19:42:37.886684 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 61, in render [Wed Nov 18 19:42:37.886688 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.template.render(context) [Wed Nov 18 19:42:37.886692 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 171, in render [Wed Nov 18 19:42:37.886696 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self._render(context) [Wed Nov 18 19:42:37.886700 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.886704 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.886708 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.886717 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.886721 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.886725 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.886730 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 150, in render [Wed Nov 18 19:42:37.886863 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return compiled_parent._render(context) [Wed Nov 18 19:42:37.886871 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.886875 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.886894 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.886898 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.886902 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.886906 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.886909 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 62, in render [Wed Nov 18 19:42:37.886913 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] result = block.nodelist.render(context) [Wed Nov 18 19:42:37.886917 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.886945 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.886973 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.886978 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.886982 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 62, in render [Wed Nov 18 19:42:37.886986 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] result = block.nodelist.render(context) [Wed Nov 18 19:42:37.886991 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.886996 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887001 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887006 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887019 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 987, in render [Wed Nov 18 19:42:37.887093 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] output = self.filter_expression.resolve(context) [Wed Nov 18 19:42:37.887101 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 671, in resolve [Wed Nov 18 19:42:37.887105 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] obj = self.var.resolve(context) [Wed Nov 18 19:42:37.887109 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 796, in resolve [Wed Nov 18 19:42:37.887113 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] value = self._resolve_lookup(context) [Wed Nov 18 19:42:37.887117 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 858, in _resolve_lookup [Wed Nov 18 19:42:37.887121 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = current() [Wed Nov 18 19:42:37.887155 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/horizon/tabs/base.py", line 227, in render [Wed Nov 18 19:42:37.887221 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return render_to_string(self.template_name, {"tab_group": self}) [Wed Nov 18 19:42:37.887236 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader.py", line 62, in render_to_string [Wed Nov 18 19:42:37.887242 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return template.render(context, request) [Wed Nov 18 19:42:37.887246 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 61, in render [Wed Nov 18 19:42:37.887250 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.template.render(context) [Wed Nov 18 19:42:37.887254 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 171, in render [Wed Nov 18 19:42:37.887258 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self._render(context) [Wed Nov 18 19:42:37.887262 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.887267 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.887272 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887276 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887280 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887284 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887288 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader_tags.py", line 150, in render [Wed Nov 18 19:42:37.887293 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return compiled_parent._render(context) [Wed Nov 18 19:42:37.887297 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.887382 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.887395 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887403 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887407 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887411 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887415 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 513, in render [Wed Nov 18 19:42:37.887425 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.887429 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887434 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887438 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887443 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887448 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 309, in render [Wed Nov 18 19:42:37.887453 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return nodelist.render(context) [Wed Nov 18 19:42:37.887458 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887462 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887467 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887472 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887478 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 209, in render [Wed Nov 18 19:42:37.887483 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] nodelist.append(node.render_annotated(context)) [Wed Nov 18 19:42:37.887488 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887493 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887498 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 987, in render [Wed Nov 18 19:42:37.887503 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] output = self.filter_expression.resolve(context) [Wed Nov 18 19:42:37.887587 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 671, in resolve [Wed Nov 18 19:42:37.887594 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] obj = self.var.resolve(context) [Wed Nov 18 19:42:37.887598 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 796, in resolve [Wed Nov 18 19:42:37.887602 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] value = self._resolve_lookup(context) [Wed Nov 18 19:42:37.887606 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 858, in _resolve_lookup [Wed Nov 18 19:42:37.887610 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = current() [Wed Nov 18 19:42:37.887614 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/horizon/tabs/base.py", line 372, in render [Wed Nov 18 19:42:37.887619 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return render_to_string(self.get_template_name(self.request), context) [Wed Nov 18 19:42:37.887634 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/loader.py", line 62, in render_to_string [Wed Nov 18 19:42:37.887638 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return template.render(context, request) [Wed Nov 18 19:42:37.887642 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 61, in render [Wed Nov 18 19:42:37.887652 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.template.render(context) [Wed Nov 18 19:42:37.887657 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 171, in render [Wed Nov 18 19:42:37.887661 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self._render(context) [Wed Nov 18 19:42:37.887665 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 163, in _render [Wed Nov 18 19:42:37.887669 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.nodelist.render(context) [Wed Nov 18 19:42:37.887673 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 937, in render [Wed Nov 18 19:42:37.887678 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] bit = node.render_annotated(context) [Wed Nov 18 19:42:37.887682 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 904, in render_annotated [Wed Nov 18 19:42:37.887686 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.render(context) [Wed Nov 18 19:42:37.887691 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 302, in render [Wed Nov 18 19:42:37.887696 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] match = condition.eval(context) [Wed Nov 18 19:42:37.887707 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/defaulttags.py", line 876, in eval [Wed Nov 18 19:42:37.887711 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return self.value.resolve(context, ignore_failures=True) [Wed Nov 18 19:42:37.887729 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 671, in resolve [Wed Nov 18 19:42:37.887734 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] obj = self.var.resolve(context) [Wed Nov 18 19:42:37.887739 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 796, in resolve [Wed Nov 18 19:42:37.887744 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] value = self._resolve_lookup(context) [Wed Nov 18 19:42:37.887748 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/django/template/base.py", line 837, in _resolve_lookup [Wed Nov 18 19:42:37.887753 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] current = getattr(current, bit) [Wed Nov 18 19:42:37.887758 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/base.py", line 139, in __getattribute__ [Wed Nov 18 19:42:37.887763 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return object.__getattribute__(self, attr) [Wed Nov 18 19:42:37.887767 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/_nova.py", line 88, in has_extended_attrs [Wed Nov 18 19:42:37.887772 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return any(getattr(self, attr) for attr in [ [Wed Nov 18 19:42:37.887777 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/_nova.py", line 88, in <genexpr> [Wed Nov 18 19:42:37.887782 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return any(getattr(self, attr) for attr in [ [Wed Nov 18 19:42:37.887786 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/openstack_dashboard/api/base.py", line 144, in __getattribute__ [Wed Nov 18 19:42:37.887791 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] return getattr(self._apiresource, attr) [Wed Nov 18 19:42:37.887795 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] File "/usr/lib/python3/dist-packages/novaclient/base.py", line 176, in __getattr__ [Wed Nov 18 19:42:37.887800 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] raise AttributeError(k) [Wed Nov 18 19:42:37.887805 2020] [wsgi:error] [pid 846:tid 140680051717888] [remote 131.169.5.116:50070] AttributeError: OS-EXT-SRV-ATTR:instance_name Thanks in advance, Stefan Bujack

2 2

[ops][rdo-users][TripleO][RDO] novajoin project
by Belmiro Moreira 20 Nov '20

20 Nov '20

Hello, at CERN we are deploying FreeIPA and the project "novajoin" is very interesting to enroll OpenStack instances. Novajoin is "a nova vendordata plugin for the OpenStack nova metadata service to manage host instantiation in an IPA server." The project is packaged by RDO, so I believe there are some users around. It would be great to hear your experiences with "novajoin". In my prototype the project is working correctly, but now that I'm going deep I'm finding some issues that I would like to discuss. What is the preferred way to report/discuss issues? There is a launchpad page (https://launchpad.net/novajoin) but not much activity during the last months. Is there someone still working on it? thanks, Belmiro

2 2

[nova] Wallaby spec review day, round 2
by Balázs Gibizer 20 Nov '20

20 Nov '20

Hi, We had a successful spec review day on Tuesday. Most of the open specs has got reviewer attention. We will do another coordinated spec review round on 1st of December. Cheers, gibi

1 0

[neutron] Drivers meeting 20.11.2020 - cancelled
by Slawek Kaplonski 19 Nov '20

19 Nov '20

Hi, As there is no any new RFE to discuss, lets cancel this week's meeting. Please instead spent some time on reviewing some opened specs to approved RFEs [1]. Especially: * https://review.opendev.org/#/c/729532/ * https://review.opendev.org/#/c/739549/ * https://review.opendev.org/#/c/728628/ Have a great weekend and see You all online :) [1] https://review.opendev.org/#/q/project:openstack/neutron-specs++status:open -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[tripleo] Copying tripleo container images to quay.io
by Arx Cruz 19 Nov '20

19 Nov '20

Hello, I just wrote a tool in go that is right now copying every 2 hours all the containers from rdo registry to quay.io. Right now it's copying all branches: master, victoria, ussuri, train, stein, queens and rocky. You can see the containers in https://quay.io/tripleo{release} for example https://quay.io/tripleomaster The tool basically searches for container build jobs with success status, parse the containers that was built, copy these containers to quay.io and tag it with current-tripleo and the built hash. The code it's based on skopeo, and I did not use it, because there are some other stuff required on quay.io side that requires the use of quay.io api, like create an already public repository, parsing the tripleo container build job, tagging, etc. Also I wanted to play with go :) Right now the code is under review at https://review.rdoproject.org/r/#/c/31133/ and I got it running on our toolbox, and he's an log example (without the --debug flag) time="2020-11-19T12:06:17Z" level=info msg="Copying image centos-binary-horizon:4fad79713786f77292e59fa1c036f588 in tripleoussuri namespace" time="2020-11-19T12:06:18Z" level=info msg="Tagging current-tripleo to sha256:db39e7d43d4c8eec82f61acd4956d7f165b595d515f270f8dabe0c9b009c95f2" "Updated" time="2020-11-19T12:06:19Z" level=info msg="Copying image centos-binary-ceilometer-base:4fad79713786f77292e59fa1c036f588 in tripleoussuri namespace" time="2020-11-19T12:06:20Z" level=info msg="Tagging current-tripleo to sha256:5eee849a9f74d0107cbfd2f456f701be37256ea711079cffcc189d140e8f3176" "Updated" time="2020-11-19T12:06:21Z" level=info msg="Copying image centos-binary-gnocchi-base:4fad79713786f77292e59fa1c036f588 in tripleoussuri namespace" time="2020-11-19T12:06:22Z" level=info msg="Tagging current-tripleo to sha256:5b46ea43d41e56dd81005a234631905a8ad594ef8432ae78542392114956f85e" "Updated" If you want to play around with this, feel free to do so, and any feedback is welcome :) Kind regards, -- Arx Cruz Software Engineer Red Hat EMEA <https://www.redhat.com> arxcruz(a)redhat.com @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

4 4

[release] Meeting Time Poll
by Herve Beraud 19 Nov '20

19 Nov '20

Hello We have a few regular attendees of the Release Management meeting who have conflicts with the current meeting time. As a result, we would like to find a new time to hold the meeting. I've created a Doodle poll[1] for everyone to give their input on times. It's mostly limited to times that reasonably overlap the working day in the US and Europe since that's where most of our attendees are located. If you attend the Release Management meeting, please fill out the poll so we can hopefully find a time that works better for everyone. Thanks! [1] https://doodle.com/poll/7zgvfb8ne54bwhzw -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 1

[oslo][release] Oslo's Transition To Independent
by Herve Beraud 19 Nov '20

19 Nov '20

Greetings, Is it time for us to move some parts of Oslo to the independent release model [1]? I think we could consider Oslo world is mostly stable enough to answer yes to the previous question. However, the goal of this email is to trigger the debat and see which deliverables could be transitioned to the independent model. Do we need to expect that major changes will happen within Oslo and who could warrant to continue to follow cycle-with-intermediary model [2]? The following etherpad [3] is designed to help us to consider which deliverables could be moved. Concerning the roots of this topic, it was raised during the PTG of the Release Management Team [4]. [1] https://releases.openstack.org/reference/release_models.html#independent [2] https://releases.openstack.org/reference/release_models.html#cycle-with-int… [3] https://etherpad.opendev.org/p/oslo-transition-to-independent [4] https://etherpad.opendev.org/p/wallaby-ptg-os-relmgt /me takes off Oslo team hat and puts on release team hat. This kind of transition could be an option for all stable libraries even outside the Oslo scope, don't hesitate to consider this as an option for your projects. Thanks for reading, -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

3 7

NUMATopologyFilter and AMD Epyc Rome
by Eyle Brinkhuis 19 Nov '20

19 Nov '20

Hi all, We’re running into an issue with deploying our infrastructure to run high throughput, low latency workloads. Background: We run Lenovo SR635 systems with an AMD Epyc 7502P processor. In the BIOS of this system, we are able to define the amount of NUMA cells per socket (called NPS). We can set 1, 2 or 4. As we run a 2x 100Gbit/s Mellanox CX5 in this system as well, we use the preferred-io setting in the BIOS to give preferred io throughput to the Mellanox CX5. To make sure we get as high performance as possible, we set the NPS setting to 1, resulting in a single numa cell with 64 CPU threads available. Next, in Nova (train distribution), we demand huge pages. Hugepages however, demands a NUMAtopology, but as this is one large NUMA cell, even with cpu=dedicated or requesting a single numa domain, we fail: compute03, compute03 fails NUMA topology requirements. No host NUMA topology while the instance specified one. host_passes /usr/lib/python3/dist-packages/nova/scheduler/filters/numa_topology_filter.py:119 Any idea how to counter this? Setting NPS-2 will create two NUMA domains, but also cut our performance way down. Thanks! Regards, Eyle

3 5

[cinder] Ceph, active-active and no coordination
by Radosław Piliszek 19 Nov '20

19 Nov '20

Dear Cinder Masters, I have a question for you. (or two, or several; well, actually the whole Kolla team has :-) ) The background is that Kolla has been happily deploying multinode cinder-volume with Ceph RBD backend, with no coordination configured, cluster parameter unset, host properly set per host and backend_host normalised (as well as any other relevant config) between the cinder-volume hosts. The first question is: do we correctly understand that this was an active-active deployment? Or really something else? Now, there have been no reports that it misbehaved for anyone. It certainly has not for any Kolla core. The fact is it was brought to our attention because due to the drop of Kolla-deployed Ceph, the recommendation to set backend_host was not present and users tripped over non-uniform backend_host. And this is expected, of course. The second and final question is, building up on the first one, were we doing it wrong all the time? (plus extras: Why did it work? Were there any quirks? What should we do?) PS: Please let me know if this thought process is actually Ceph-independent as well. -yoctozepto

5 5

Ask a question about nova console
by Yingji Sun 18 Nov '20

18 Nov '20

Buddies, I hit an issue on nova console. In vm console, it only handles keyboard event, but not mouse event. That is I can only use keyboard in the vm, but not mouse. The backend is vsphere. I can use both keyboard and mouse through vsphere remote console. So where does the issue likely hide ? Is there any option in nova configure file that relates to this issue ? Any feedback would be appreciated. Yingji.

1 1

Clone Cinder-Backed Image (Ussuri)
by Lazuardi Nasution 18 Nov '20

18 Nov '20

Hi, I have made a cinder-backed image where my cinder is RBD-backed. The backing topology of that image is as follows. glance -> cinder -> RBD. Is it possible to clone that image like RBD-backed images? I think the following bluprint is related but I don't know if it has been implemented yet, at least on Ussuri. https://blueprints.launchpad.net/cinder/+spec/clone-image-in-glance-cinder-… Best regards,

2 2