- openstack-discuss - lists.openstack.org

[openstack-helm] support per-host auto_bridge_add
by Li, Cheng1 03 Mar '19

03 Mar '19

Hi Pete, Sorry for disturbing you, but I really would like to merge this patch ASAP. I have updated the patch https://github.com/stackanetes/kubernetes-entrypoint Could you please help review it again? Thanks. Thanks, Cheng

1 1

[all][ops] Ops Meetup Agenda Planning - Berlin Edition
by Erik McCormick 03 Mar '19

03 Mar '19

Hello All, The time is rapidly approaching for the Ops Meetup in Berlin. In preparation, we need your help developing the agenda. i put an [all] tag on this because I'm hoping that anyone, not just ops, looking for discussion and feedback on particular items might join in and suggest sessions. It is not required that you attend the meetup to post session ideas. If there is sufficient interest, we will hold the session and provide feedback and etherpad links following the meetup. Please insert your session ideas into this etherpad, add subtopics to already proposed sessions, and +1 those that you are interested in. Also please put your name, and maybe some contact info, at the bottom. If you'd be willing to moderate a session, please add yourself to the moderators list. https://etherpad.openstack.org/p/BER-ops-meetup I'd like to give a big shout out to Deutsche Telekom for hosting us and providing the catering. I look forward to seeing many of you in Berlin! Cheers, Erik

3 3

[dev] [qa][ptg] Train PTG Planning for QA
by Ghanshyam Mann 03 Mar '19

03 Mar '19

Hello Everyone, I have prepared the etherpad[1] to collect the Train cycle PTG topic ideas for QA. Please start adding your item/topic you want to discuss in PTG or comment on proposed topics. Even you are not making to PTG physically, still, add your topic which you want us to discuss or give a thought. Anyone is welcome to add the cross-project testing topics they want to discuss related to QA. For example, keystone (lance) is planning one for system-scope testing. [1] https://etherpad.openstack.org/p/qa-train-ptg -gmann

1 0

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