May 2019 - openstack-discuss - lists.openstack.org

[kayobe] No meeting today
by Mark Goddard 27 May '19

27 May '19

Hi, It's a public holiday in the UK today so there won't be a kayobe meeting. We'll meet again on 10th June but please discuss issues in IRC before then if necessary. Cheers, Mark

1 0

[kolla] Virtual PTG
by Mark Goddard 27 May '19

27 May '19

Hi, Just a reminder for the Kolla virtual PTG this week on Tuesday 28th and Wednesday 29th May, 12:00 - 16:00 UTC. We're planning to meet virtually using Google meet [1] for voice and/or video, but please let me know if this is likely to be a problem for you. Everyone is welcome to attend, regardless of how long you've been working with the project or your level of contribution so far. If you can't make the full session, you could join for part of it to say hello to the team. We'll be discussing potential new features, planning, and prioritising work for the Train cycle. We'll also take a step back and look at the current state of the project, and ask if we should be doing anything differently. I've put up a rough agenda on the etherpad [2]. It's more of an ordering than a timed schedule - let's just go through the list. If you can't make the whole session and there's something in particular you'd like to discuss, let me know and I will pin it to a specific time. See you tomorrow, Mark (mgoddard) [1] https://meet.google.com/pbo-boob-csh?hs=122 [2] https://etherpad.openstack.org/p/kolla-train-ptg

1 0

[neutron][qa] Grenade jobs in check queue
by Slawomir Kaplonski 27 May '19

27 May '19

Hi, In Neutron team we are thinking about limiting a bit number of CI jobs which we are running. Currently we have e.g. 4 different grenade jobs: neutron-grenade grenade-py3 neutron-grenade-multinode neutron-grenade-dvr-multinode And jobs grenade-py3 and neutron-grenade-multinode are almost the same (same python version, same L2 agent, same legacy L3 agent, same fw driver). Only difference between those 2 jobs is that one of them is single and one is multinode (2) job. So I thought that maybe we can use only one of them and I wanted to remove grenade-py3 and left only multinode job in check queue. But grenade-py3 comes from "integrated-gate-py3” template so we probably shouldn’t remove this one. Can we run only grenade-py3 and drop neutron-grenade-multinode? Or maybe we can change grenade-py3 to be multinode job and then drop neutron-grenade-multinode? — Slawek Kaplonski Senior software engineer Red Hat

2 1

[openstack-dev] [neutron] Cancelling Neutron weekly meeting on May 27th
by Miguel Lavalle 27 May '19

27 May '19

Hi Neutrinos, May 27th is a holiday in the USA, so we will cancel our weekly meeting. We will resume on Tuesday June 4th Best regards Miguel

1 0

[DVR config] Can we use drv_snat agent_mode in every compute node?
by Yi Yang (杨燚)-云服务集团 26 May '19

26 May '19

Hi, folks I saw somebody discussed distributed SNAT, but finally they didn’t make agreement on how to implement distributed SNAT, my question is can we use dvr_snat agent_mode in compute node? I understand dvr_snat only does snat but doesn’t do east west routing, right? Can we set dvr_snat and dvr in one compute node at the same time? It is equivalent to distributed SNAT if we can set drv_snat in every compute node, isn’t right? I know Opendaylight can do SNAT in compute node in distributed way, but one external router only can run in one compute node. I also see https://wiki.openstack.org/wiki/Dragonflow is trying to implement distributed SNAT, what are technical road blocks for distributed SNAT in openstack dvr? Do we have any good way to remove these road blocks? Thank you in advance and look forward to getting your replies and insights. Also attached official drv configuration guide for your reference. https://docs.openstack.org/neutron/stein/configuration/l3-agent.html agent_mode <https://docs.openstack.org/neutron/stein/configuration/l3-agent.html#DEFAUL…> ¶ Type string Default legacy Valid Values dvr, dvr_snat, legacy, dvr_no_external The working mode for the agent. Allowed modes are: ‘legacy’ - this preserves the existing behavior where the L3 agent is deployed on a centralized networking node to provide L3 services like DNAT, and SNAT. Use this mode if you do not want to adopt DVR. ‘dvr’ - this mode enables DVR functionality and must be used for an L3 agent that runs on a compute host. ‘dvr_snat’ - this enables centralized SNAT support in conjunction with DVR. This mode must be used for an L3 agent running on a centralized node (or in single-host deployments, e.g. devstack). ‘dvr_no_external’ - this mode enables only East/West DVR routing functionality for a L3 agent that runs on a compute host, the North/South functionality such as DNAT and SNAT will be provided by the centralized network node that is running in ‘dvr_snat’ mode. This mode should be used when there is no external network connectivity on the compute host.

3 10

[infra] api reference not updated
by Hongbin Lu 25 May '19

25 May '19

Hi infra team, I have a patch to update the Zun API reference: https://review.opendev.org/#/c/658722/ . The patch is merged but the API reference [1] doesn't seem pick up the change. Is anything wrong in somewhere? [1] https://developer.openstack.org/api-ref/application-container/ Best regards, Hongbin

2 2

[tripleo][kolla][osa][nova][deployment] Removing nova-consoleauth
by Stephen Finucane 25 May '19

25 May '19

In my continued efforts to remove as much nova code as possible in one cycle, I've set my sights on the 'nova-consoleauth' service. Since Rocky [1], 'nova-consoleauth' is no longer needed and we now store and retrieve tokens from the database. The only reason to still deploy 'nova-consoleauth' was to support cells v1 or to provide a window where existing tokens could continue to be validated before everything switched over to the new model, but we're also in the process of removing cells v1 [2] and two cycles in quite a large window in which to migrate things. I've the work done from the nova side but before we can merge anything, we need to remove support for nova-consoleauth from the various deployment projects and anything else that relies on it at the moment. I have talked to some folks internally about doing this in TripleO this cycle and I have a (likely wrong) patch proposed against Kolla [3] for this, but I haven't been able to figure out how/if OSA are deploying the service and would appreciate some help here. I'd also like it if people could let me know if there are any other potential blockers out there that we should be aware of before we proceed with this. Cheers, Stephen [1] https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/co… [2] https://blueprints.launchpad.net/nova/+spec/remove-cells-v1/ [3] https://review.opendev.org/#/c/661251/

6 6

[Security SIG] Weekly Newsletter - May 23rd 2019
by Gage Hugo 24 May '19

24 May '19

At the Denver Summit, one of the forum sessions was a PTL Tips & Tricks session[0] where one topic was sending out a project update email. Other projects/SIGs seem to do this from time-to-time (this idea was mostly inspired by Keystone's weekly newsletter, thanks cmurphy!) and the plan for the Security SIG to do something similar was discussed during this week's meeting and seemed to have unanimous approval. So starting this week, the Security SIG will begin sending out a weekly newsletter, the overall goal of this is to provide updates to the happenings of the Security SIG as well as provide insight to the current security happenings within OpenStack. As the amount of content varies week to week, the occurrence may be tweaked in the future to something bi-weekly or monthly as we see how this goes. [0] https://etherpad.openstack.org/p/DEN-ptl-tips-and-tricks If there's anything else you would like to see here or feedback you'd like to give, please feel free to respond here, reach out via IRC in #openstack-security, and/or comment in the newsletter etherpad here: https://etherpad.openstack.org/p/security-sig-newsletter. Thanks! # Week of: 23 May 2019 - Security SIG Meeting Info: http://eavesdrop.openstack.org/#Security_SIG_meeting - Weekly on Thursday at 1500 UTC in #openstack-meeting - Agenda: https://etherpad.openstack.org/p/security-agenda - https://security.openstack.org/ - https://wiki.openstack.org/wiki/Security-SIG ## Meeting Notes - Summary: http://eavesdrop.openstack.org/meetings/security/2019/security.2019-05-23-1… - TL;DR: During this week's meeting, we discussed the two bugs/stories listed below, as well as the idea of sending out some Security SIG newsletter. ## VMT Bug List A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ Updates from this week: - Security Group filtering hides rules from user Edit: https://bugs.launchpad.net/ossa/+bug/1824248 - This was made public this week, and multiple fixes have been submitted. - SQL Injection vulnerability in node_cache: https://storyboard.openstack.org/#!/story/2005678 - Made public this week, multiple fixes have been submitted/merged

1 0

[ops] [nova] Wrong network interface model virtio1.0-net given to libvirt
by Jean-Philippe Méthot 24 May '19

24 May '19

Hi, We’re setting up 4 new compute nodes in our openstack Pike setup and 2 of them are behaving strangely, despite having the same hardware as the others. When I try to create a new instance on these compute nodes, the instance fail to spawn and the following error message appears in the log : 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager Traceback (most recent call last): 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2203, in _build_resources 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager yield resources 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2018, in _build_and_run_instance 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager block_device_info=block_device_info) 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2898, in spawn 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager block_device_info=block_device_info) 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5220, in _get_guest_xml 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager context) 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5035, in _get_guest_config 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager flavor, virt_type, self._host) 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/vif.py", line 558, in get_config 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager vnic_type) 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/vif.py", line 521, in _get_config_os_vif 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager inst_type, virt_type, vnic_type) 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/vif.py", line 134, in get_base_config 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager virt=virt_type) 2019-05-24 15:13:35.559 16944 ERROR nova.compute.manager UnsupportedHardware: Requested hardware 'virtio1.0-net' is not supported by the 'kvm' virt driver After doing some research on google, I understand that this happens when the network interface model is defined as virtio1.0-net in the xml that’s fed to libvirt and libvirt does not consider that a valid name for a network interface model. That said, why is Nova passing that model name to libvirt? I understand that it comes from libosinfo, but how is Nova getting that (wrong) information? If I look on other compute nodes, the model for the network interface is simply virtio. Best regards, Jean-Philippe Méthot Openstack system administrator Administrateur système Openstack PlanetHoster inc.

1 0

Re: [stackalytics] Reported numbers seem inaccurate
by Edward Ionel 24 May '19

24 May '19

Hello All, I first want to thank each and everyone of you for reaching out and sharing the inaccuracies you all have found within Stackalytics, this has helped us tremendously with the efforts to correct these flaws. I am writing this email to directly address each individual that has reached out and shared their concerns with our Stackalytics data. Mark Goddard Michael Johnson Julia Kreger Collen Murphy Clark Boylan Sean Mooney Thierry Carrez Jermey Stanley Arkady Kanvesky (Hopefully, I did not miss anyone) I want to insure everyone that the team is working hard to fix the inaccuracies in some of our data. We are still very much involved in OpenStack and we do read each and every message regarding Stackalytics. As Boris and Sergey mentioned, we found that this occurred due to an outdated production environment. We are currently in the progress of migrating to a new environment, and the data should be corrected. The team and I are sorry for these discrepancies and appreciate you all for bringing this to our attention. Thank you all, for providing links and examples of the inaccuracies. This has helped our efforts greatly in correcting the current issues. It would be great if the community can continue reviewing Stackalytics data and help us provide a better service to all. Once again, we are all very sorry for this and will continue to fix these issues. Cheers, Edward > On Apr 16, 2019, at 4:05 PM, Edward Ionel <eionel(a)mirantis.com> wrote: > > > >> On Tue, Apr 16, 2019 at 2:56 PM Boris Renski <brenski(a)mirantis.com> wrote: >> Folks - more specifically, we plan to roll out an update by tomorrow mid-day PT which should fix all the numbers + add aggregate details on Airship project contributions. >> >> Would really appreciate the help of the community to poke around tomorrow afternoon and see if there are still discrepancies. >> >> Sorry about this and thank you for catching it and brining it to our attention. >> >> -Boris >> >>> On Tue, Apr 16, 2019 at 1:33 PM Sergey Nikitin <snikitin(a)mirantis.com> wrote: >>> Hello everyone, >>> As you mentioned there are some inaccuracies in stats on stackalytics.com. It happened because of outdated Prod env. At this moment we are in a process of migration to the new env. All data on this env is fresh and accurate. So the problem will be solved soon. >>> >>> -- >>> Best Regards, >>> Sergey Nikitin > > > -- > Edward Ionel > Marketing Operations Manager > Mirantis, Inc. > 900 E Hamilton Ave, Suite 650 > Campbell, CA 95008 > Eionel(a)mirantis.com > www.mirantis.com

4 14