- openstack-discuss - lists.openstack.org

sriov bonding
by Manuel Sopena Ballesteros 03 Mar '19

03 Mar '19

Hi, Is there a documentation that explains how to setup bonding on SR-IOV neutron? Thank you Manuel NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

6 7

networking-vpp 19.03 now available
by Ian Wells 02 Mar '19

02 Mar '19

Hello All, We'd like to invite you all to try out networking-vpp 19.03. As many of you may already know, VPP is a fast user space forwarder based on the DPDK toolkit. VPP uses vector packet processing algorithms to mininmise the CPU time spent on each packet to maxmise throughput. Networking-vpp is a ML2 mechanism driver that controls VPP on your control and compute hosts to provide fast L2 forwarding under Neutron. This latest version is updated to work with VPP 19.01. In the 19.03 release, we added a few features: - To complement the GPE overlay, there is now also a L3 solution for port mirroring (OpenStack TaaS) connections. When you're using GPE, the overlay is L3 and you may have routers between your compute nodes, so moving the TAP traffic around also requires an L3 overlay. We use VXLAN point to point connections to get that copy of traffic to the VM destination, and these can be routed over L3. We automatically use VXLAN connections when you're tapping ports on GPE networks and VLAN connections for L2 networks so this should all Just Work. - We've worked on out Python 3 compatibility in preparation for the EOL of Pythnon 2. Both the Neutron server's driver components and the agent components that control VPP should now support Python 3, but this work is ongoing and if you do find any issues please report them on the Launchpad page. - We've worked on our L3 Neutron routers support and added functionality that allows you to use NAT from multiple routers simultaneously - ideal if, for instance, you like to use one router per tenant and in more unusual cases routers with different external networks. - We've been doing the usual round of bug fixes and updates - the code will work with both VPP 18.10 and 19.01 and has been updated to keep up with Neutron Rocky and Stein. The README [1] explains how you can try out VPP using devstack: the devstack plugin will deploy the mechanism driver and VPP and should give you a working system with a minimum of hassle. We will be continuing our development for VPP's 19.04 release. We welcome anyone who would like to come help us. -- Ian & Naveen

1 0

[kuryr] PTG and Forum planning etherpad
by Daniel Mellado 02 Mar '19

02 Mar '19

Hi Kuryrs, As the time for the PTG and the Forum is coming and my paternity leave is about to end as well (sleepless nights have just started xD) I set up an etherpad for PTG planning [1]. Please add topics with your nick or email alongside. As a reminder we also have a Forum topics brainstorming etherpad [2]. The deadline for submitting topics is next week so don't delay! -- Daniel Mellado

1 1

[security][barbican][manila] hiding back end and service user credentials
by Tom Barron 02 Mar '19

02 Mar '19

In manila -- and so far as I can tell, other projects -- service user and back end (storage devices, security service) credentials appear plaintext in configuration files and in database tables. These are not accessible to ordinary OpenStack users but some cloud deployers nonetheless have concerns about this exposure and have asked us to tighten things up. So I want to check for best practices from other projects. I doubt this is a manila-specific concern -- e.g. is barbican already being used today by some projects to protect information of this sort? Thanks, -- Tom Barron

3 4

[sahara][heat][qa][murano] Heat integration tests run by Grenade
by Luigi Toscano 01 Mar '19

01 Mar '19

Hi, Heat is a requirement for Sahara, which means that the Heat plugin for DevStack and Grenade are enabled in the is enabled in the Sahara DevStack and Grenade jobs respectively. I noticed that the Grenade plugin for Heat unconditionally runs few tests both after the deployment of the base environment and after the upgrade phase. While I understand that the Heat team want to always run them when Heat is tested, I would argue that whenever Heat is deployed as requirement by other projects (for example, Sahara :) it should be possible to disable those tests. This way the execution time of the Grenade job would be shortened by ~20 minutes, from 1h30m to 1h10m. This change should benefit also the other projects which depend on Heat. Howoever, even if the change was implemented now, its effects would not be noticeable immediately, because it seems to be just one additional project which both a) depends on Heat and b) provides a Grenade plugin. That project is Murano, which, on the other hand, it does not enable the Heat plugin for Grenade in its Grenade job. I think that this should be fixed, otherwise (IMHO) the upgrade test is not really complete IMHO, but that's a different story (hence the [murano] tag in this email). So my question for the Heat team is: can I propose an Heat patch which allows users to disable the Heat integration tests executed by Grenade? The default behavior will be unchanged. Ciao -- Luigi

2 2

[ops] berlin ops meetup content thread
by Chris Morgan 01 Mar '19

01 Mar '19

Hello Everyone, Here's the first etherpad for next week's Ops Meetup in Berlin, hosted by Deutsche Telekom: https://etherpad.openstack.org/p/BER19-OPS-DUDES This one is for a proposed group discussion amongst the openstack operators attending about all the new (or newly top-level) projects under the openstack foundation umbrella, or as I've nicknamed it "All the young dudes", kata,zuul, airship, starlingx. I also added a section about the changes to the foundation, stackforge, the summits etc.I haven't seen a prior effort to get feedback from openstack operators on all these changes. Feedback welcome Chris p.s. still tickets available, come join us if you can - especially if it's nearby to you there's still time! https://www.eventbrite.com/e/openstack-ops-meetup-berlin-tickets-55034908894 -- Chris Morgan <mihalis68(a)gmail.com>

1 2

[loci] Cleaning fetch_wheels.py
by Jean-Philippe Evrard 01 Mar '19

01 Mar '19

Hello everyone, scripts/fetch_wheels.py could deserve more love, as it's not really DRY, and to be honest, I still wonder the value of some of it. For example, I've seen multiple failures in the protocol_detection method. And, in the face of ambiguity, I would prefer to avoid the temptation to guess :) We've discussed with Chris about the removal at our weekly meeting, and he was not opposed to it. Would you be okay if I remove this protocol_detection method, instead relying on user provided information in the `REGISTRY_PROTOCOL` argument? (Which would default to http). If no answer within a week, I would consider that nobody cares or everyone agrees, and therefore I will go on with the cleanup :p Regards, Jean-Philippe Evrard (evrardjp)

1 0

[dev][keystone] Keystone Team Update - Week of 25 February 2019
by Colleen Murphy 01 Mar '19

01 Mar '19

# Keystone Team Update - Week of 25 February 2019 ## News ### Releases and Feature Freeze Yesterday we released keystonemiddleware, keystoneauth, and python-keystoneclient, and then the release team was kind enough to let us release keystoneauth again today. Next week will be the feature freeze for keystone, so we should aim for having all of the domain limits changes[1] and ideally the default roles and system scope changes[2] merged by then. We'll hold off on application credentials access rules (capabilities) changes[3] until the next cycle opens for development. [1] https://review.openstack.org/#/q/status:open+topic:bp/domain-level-limit [2] https://review.openstack.org/#/q/status:open+topic:implement-default-roles [3] https://review.openstack.org/#/q/status:open+topic:bp/whitelist-extension-f… ### Forum/PTG prep As a reminder, we're brainstorming for Forum and PTG topics[4]. If you are prepared to moderate a Forum topic don't hesitate to speak up and mark it on etherpad. [4] https://etherpad.openstack.org/p/DEN-keystone-forum-sessions ### Rate-limiting in keystoneauth Lance and Morgan heroically walked through[5], tested and landed Monty's threaded rate limiting feature in keystoneauth[6]. They found the interface for it to be slightly but unavoidably unintuitive, but docs will be forthcoming. We released keystoneauth again to include this feature. [5] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… [6] https://review.openstack.org/605043 ### Domain admin in tempest There are issues with the assumptions tempest makes the scope requirements for a deployment administrator role that prevent us from landing one of the reader role changes[7][8]. A workaround is proposed[9] that will help us move forward, but we need to unwind the tempest/devstack implementation with the QA team to ensure that tempest can understand and validate scope the way we intend for it to work. It's also an opportunity to consider what interesting workarounds operators may have come up with for managing the admin role so that we can come up with migration plans. [7] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… [8] http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2019… [9] https://review.openstack.org/624218 ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 30 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 46 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 9 new bugs and closed 14. Bugs opened (9) Bug #1816833 (keystone:High) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1816833 Bug #1817313 (keystone:High) opened by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1817313 Bug #1816927 (keystone:Low) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1816927 Bug #1817047 (keystone:Low) opened by André Luis Penteado https://bugs.launchpad.net/keystone/+bug/1817047 Bug #1817780 (keystone:Low) opened by Patrick Lepak https://bugs.launchpad.net/keystone/+bug/1817780 Bug #1818085 (keystone:Wishlist) opened by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1818085 Bug #1817623 (keystone:Undecided) opened by Rastislav Fukas https://bugs.launchpad.net/keystone/+bug/1817623 Bug #1817769 (keystone:Undecided) opened by prashkre https://bugs.launchpad.net/keystone/+bug/1817769 Bug #1817953 (oslo.policy:Low) opened by Ben Nemec https://bugs.launchpad.net/oslo.policy/+bug/1817953 Bugs closed (1) Bug #1817623 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1817623 Bugs fixed (13) Bug #1815539 (keystone:High) fixed by Guang Yee https://bugs.launchpad.net/keystone/+bug/1815539 Bug #1757000 (keystone:Medium) fixed by erus https://bugs.launchpad.net/keystone/+bug/1757000 Bug #1804292 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804292 Bug #1804463 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804463 Bug #1804516 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804516 Bug #1804517 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804517 Bug #1804519 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804519 Bug #1804521 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804521 Bug #1804523 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804523 Bug #1805369 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805369 Bug #1805402 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805402 Bug #1806713 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1806713 Bug #1817953 (oslo.policy:Low) fixed by Ben Nemec https://bugs.launchpad.net/oslo.policy/+bug/1817953 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html Yesterday was the non-client library release deadline. Next week will be the final client release deadline as well as feature freeze. After that we'll being prepping the RC. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[manila] PTG planning etherpad available and Forum topics reminder
by Tom Barron 01 Mar '19

01 Mar '19

Dear Zorillas, I set up an etherpad for PTG planning [1]. Please add topics with your nick or email alongside. As a reminder we also have a Forum topics brainstorming etherpad [2]. The deadline for submitting topics is next week so don't delay! -- Tom Barron [1] https://etherpad.openstack.org/p/manila-denver-train-ptg-planning [2] https://etherpad.openstack.org/p/DEN-train-forum-manila-brainstorming

1 0

[nova] Updates about Detaching/Attaching root volumes
by Zhenyu Zheng 01 Mar '19

01 Mar '19

Hi Nova, I'm working on a blueprint to support Detach/Attach root volumes. The blueprint has been proposed for quite a while since mitaka[1] in that version of proposal, we only talked about instances in shelved_offloaded status. And in Stein[2] the status of stopped was also added. But now we realized that support detach/attach root volume on a stopped instance could be problemastic since the underlying image could change which might invalidate the current host.[3] So Matt and Sean suggested maybe we could just do it for shelved_offloaded instances, and I have updated the patch according to this comment. And I will update the spec latter, so if anyone have thought on this, please let me know. Another thing I wanted to discuss is that in the proposal, we will reset some fields in the root_bdm instead of delete the whole record, among those fields, the tag field could be tricky. My idea was to reset it too. But there also could be cases that the users might think that it would not change[4]. Thoughts, BR, [1] http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/detac… [2] http://specs.openstack.org/openstack/nova-specs/specs/stein/approved/detach… [3] https://review.openstack.org/#/c/614750/34/nova/compute/manager.py@5467 [4] https://review.openstack.org/#/c/614750/37/nova/objects/block_device.py

5 18