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

networking-vpp 19.04 is now available
by Naveen Joy (najoy) 14 May '19

14 May '19

Hello All, We'd like to invite you all to try out networking-vpp 19.04. As many of you may already know, VPP is a fast user space forwarder based on the DPDK toolkit. VPP uses vector packet processing algorithms to minimize the CPU time spent on each packet to maximize throughput. Networking-vpp is a ML2 mechanism driver that controls VPP on your control and compute hosts to provide fast L2 forwarding under Neutron. This latest version is updated to work with VPP 19.04. In the 19.04 release, we've worked on making the below updates: - We've built an automated test pipeline using Tempest. We've identified and fixed bugs discovered during our integration test runs. We are currently investigating a bug, which causes a race condition in the agent. We hope to have a fix for this issue soon. - We've made it possible to overwrite the VPP repo path. VPP repo paths are constructed, pointing to upstream repos, based on OS and version requested. Now you can allow this to be redirected elsewhere. - We've updated the mac-ip permit list to allow the link-local IPv6 address prefix for neighbor discovery to enable seamless IPv6 networking. - We've worked on additional fixes for Python3 compatibility and enabled py3 tests in gerrit gating. - We've updated the ACL calls in vpp.py to tidy-up the arguments. We've worked on reordering vpp.py to group related functions, which is going to be helpful for further refactoring work in the future. - We've been doing the usual round of bug fixes and updates - the code will work with both VPP 19.01 and 19.04 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 19.04 and should give you a working system with a minimum of hassle. We will be continuing our development for VPP's 19.08 release. We welcome anyone who would like to come help us. -- Naveen & Ian [1] https://opendev.org/x/networking-vpp/src/branch/master/README.rst

1 0

[scientific-sig] IRC Meeting - summit roundup, cycle planning
by Stig Telfer 14 May '19

14 May '19

Hi All - We have a Scientific SIG meeting at 2100 UTC (about 40 minutes time) in channel #openstack-meeting. Everyone is welcome. Today’s agenda is available here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_May_14th_2019 We’d like to recap the summit activities and discuss some new plans for the Train cycle. Cheers, Stig

1 0

[Glance] Is Bug 1493122 fixed?
by rajiv mucheli 14 May '19

14 May '19

Hi, Could you please let me know if https://bugs.launchpad.net/horizon/+bug/1493122 has been fixed? if not, in which release would it be fixed? or is there a workaround? I did follow-up on : https://blueprints.launchpad.net/glance/+spec/glance-quota-enhancements Regards, Rajiv

2 1

[cinder] PTG and Forum Summary
by Jay Bryant 14 May '19

14 May '19

All, I have now gone through all the notes and recordings from the OpenInfra Summit Forum sessions as well as the OpenStack PTG meetings. You can see the summary of discussions and action items here [1] with links to the detailed etherpads and recordings organized chronologically. I have also gotten the Cinder Project Update [2] and Cinder On-boarding [3] session slides posted. All-in-all the PTG meetings and forum sessions were well attended and we had many productive discussions. As indicated in my project update presentation, I feel the health of the Cinder community continues to be good. We still have a diverse population (different geographies, different companies, different technologies) contributing to Cinder. We also are seeing a consistent stream of user experience and stability improvements being proposed and merged. The attendance at the PTG and Summit sessions supported the health status of our community. Thank you to everyone who was able to attend our sessions both in person and remotely! Make sure to mark your calendars for the planned mid-cycle meeting at the Lenovo site in RTP, August 21st - 23rd, 2019. Hope to see many of you there! Jay (JungleboyJ) [1] https://wiki.openstack.org/wiki/CinderTrainSummitandPTGSummary [2] https://www.slideshare.net/JayBryant2/cinder-project-update-denver-summit-2… [3] https://www.slideshare.net/JayBryant2/cinder-project-onboarding-openinfra-s…

1 0

[release][ptl] Cycle Highlights Schedule Changes
by Kendall Nelson 14 May '19

14 May '19

Hello! I wanted to bring your attention to the shift in the schedule for the collection of cycle highlights[1]. It used to be that collection started around m3 and concluded at RC1. However, not having them until then makes it difficult to get them to the marketing machine in time to process/ turn into a press release to celebrate our hard work. Now, with the changes, between m2 and m3 I will send out a reminder to get liaisons + PTLs to start thinking about them. From then on you are welcome to start adding them to your deliverable files (I suppose you could add them sooner if you want to be extra on top of things). But, more importantly.. *The new final deadline for cycle highlights will now be feature freeze[2] the week of R-5. * The process for submitting them remains the same[3]. If you have any questions please let me know or join us in the #openstack-release channel. Look forward to seeing what everyone has accomplished during Train :) Thanks! -Kendall (diablo_rojo) [1] https://releases.openstack.org/reference/process.html#between-milestone-2-a… [2] https://releases.openstack.org/train/schedule.html [3] https://docs.openstack.org/project-team-guide/release-management.html#cycle…

1 0

[all[tc][ptls] Success bot lives on!
by Alexandra Settle 14 May '19

14 May '19

Hi all, Hope you're all settled back in after an absolutely crazily long week in Denver. The TC met on Saturday the 4th of May for the PTG and we had a large group discussing how we can evolve our systems towards more simplicity, fun, exciting, enjoyable, and rewarding (take your wordy pick). But in the mean time, we don't appear to celebrate the little things anymore. One of the proposals to this was to revive success bot for consistent use. For those who don't know or remember what success bot is, it is a success IRC bot (*dramatic gasp*) that makes it simple to record "little moments of joy and progress" and share them. Review this article for more info [1] or the original email from Thierry [2]. It is clear that we still have some using it, with about ~25 posts last year and 2 so far this year, but I think we can do better than that. There are a lot of new people in the community, so I hope this generates more interest! So whenever you feel like you (or someone) made progress, or had a little success in your OpenStack adventures, or have some joyful moment to share, just throw the following message on your local IRC channel: #success [Your message here] The openstackstatus bot will take that and record it on the wiki page [3]. Cheers, Alex IRC: asettle Twitter: dewsday [1] https://superuser.openstack.org/articles/success-bot-helps-share-your-happy… [2] http://lists.openstack.org/pipermail/openstack-dev/2015-October/076552.html [3] https://wiki.openstack.org/wiki/Successes p.s - The bot still only works in channels where openstackstatus is present (the official OpenStack IRC channels), and we may remove entries that are off-topic or spam.

4 4

[TripleO][Validations] Tag convention
by Cédric Jeanneret 14 May '19

14 May '19

Dear all, We're currently working hard in order to provide a nice way to run validations within a deploy (aka in-flight validations). We can already call validations provided by the tripleo-validations package[1], it's working just fine. Now comes the question: "how can we disable the validations?". In order to do that, we propose to use a standard tag in the ansible roles/playbooks, and to add a "--skip-tags <tag>" when we disable the validations via the CLI or configuration. After a quick check in the tripleoclient code, there apparently is a tag named "validation", that can already be skipped from within the client. So, our questions: - would the reuse of "validation" be OK? - if not, what tag would be best in order to avoid confusion? We also have the idea to allow to disable validations per service. For this, we propose to introduce the following tag: - validation-<service>, like "validation-nova", "validation-neutron" and so on What do you think about those two additions? Thank you all for your feedbacks and idea! Cheers, C. [1] as shown here: https://cjeanner.github.io/openstack/tripleo/validations/2019/04/26/in-flig… -- Cédric Jeanneret Software Engineer - OpenStack Platform Red Hat EMEA https://www.redhat.com/

4 6

[tc] Summary: "Driving common goals" forum session and Popup teams discussion at PTG
by Thierry Carrez 14 May '19

14 May '19

In Denver we had a Forum session on how to facilitate driving common goals, here is a quick summary. We started by defining the different types of common goals in OpenStack. There are OpenStack-wide consistency goals (having common support for a feature across all OpenStack components, raising the minimal QA/doc/operations bar, improving overall "openstack" experience). And there are cross-project changes that only affect some projects: project refactoring (like extracting placement), multi-project features (like volume multi-attach) or architectural changes (like having common node-centric agents). The discussion then shifted to discussing why cross-project is hard. While I thought the projectteam-centric structure made the cross-project work less rewarding, discussion revealed that most of the difficulty comes from lack of initial directions / contacts, and lack of synchronous discussions to get buy-in from the various stakeholders. We then moved to discuss implementation models. The release goals (small, limited to one development cycle and affecting all teams) are great to drive consistency goals. SIGs are great to drive long-term cross-project changes, care for special interests, or global concerns that affect both software production and software consumption. That leaves a gap for short or mid-term cross-project changes. Popup teams are designed to fill that gap. Those would be used to drive a clear, limited cross-project objective. They are temporary like release goals, but can extend beyond a release cycle. They just need a clear disband criteria. During the rest of the session we discussed how to best implement them to facilitate that work. We ran out of time before solving the key question of whether the TC should approve the idea, the technical implementation, or the team membership itself. The implementation discussion continued during the TC meeting at the PTG on Saturday. The general consensus in the room was that the TC should look at the scope/goal of the proposed popup team (before any spec), and offer to "support" it if it looks like a viable goal and a desirable objective for OpenStack. Supported popup teams would get listed on the governance website, and get a experienced community member sponsor to serve as a liaison with the TC and mentor the popup team through initial steps (like getting the right connections in the various affected teams). Further discussion on implementation specs may reveal that the goal is impossible or not desirable, in which case the popup team can be disbanded. Action items to move this idea forward include documenting the popup team concept / approval criteria and create a home for them on the governance website (ttx), documenting best practices on how to get cross-project work done (ildiko), and documenting the difference between project teams, SIGs and popup teams (ricolin, ttx, persia). -- Thierry Carrez (ttx)

1 0

[StoryBoard] Forum + PTG Summary
by Kendall Nelson 14 May '19

14 May '19

Hello Everyone :) Quick summaries of what we talked about during the sessions in Denver. If you have any questions about anything below feel free to reply or drop into #storyboard and ask us there! Forum (Ibuprofen for Your StoryBoard Pain Points) ------------------------------------------------------------------- The Forum session went really well. We had a pretty full room and lots of engagement from basically everyone. There were no real surprises about anything people were having issues with or new features they needed added that we didn't already know about. It was nice that we weren't blindsided by anything and seem to have a pretty good feel on the pulse of what people (that have spoke up at least) are asking for. The most entertaining part was that it had never occurred to us to do StoryBoard onboarding (both for howto use it and another for how to get started on developing for Storyboard) but also might be a really helpful thing for us to do at the next event. We talked about trying to fit it in before the end of the week, but our schedules were just too full to make it happen. I'm still working through making sure everything that needs to becomes a story in our backlog, but that should be done by the end of the week. Etherpad from Forum Session: https://etherpad.openstack.org/p/storyboard-pain-points PTG ------ During the PTG, Adam and I basically just sat down and did a full run through of all open stories. We closed duplicates, cleaned up old vague stories, replied to stories that we had questions about. It was all very cathartic. Next step is to make sure all the new stories got created that we need to and do another pass through to make sure its all tagged accurately. After that, we should document what tags we are using in our contributor documentation. Etherpad we used during the purge: https://etherpad.openstack.org/p/sb-train-ptg -Kendall Nelson (diablo_rojo)

3 3

[tripleo] Specs & Blueprints for the Train cycle
by Alex Schultz 14 May '19

14 May '19

Hey folks, Last IRC meeting I mentioned that we would like to try and get the specs that we'll be committing to reviewed and merged by Train M1. This means we need to have the specs up and blueprints[0] filed as soon as possible. Please let me know if you have any questions or need help. Also please take a moment or two to review the tripleo specs that we have up[1]. Thanks, -Alex [0] https://blueprints.launchpad.net/tripleo/train [1] https://review.opendev.org/#/q/project:openstack/tripleo-specs+status:open

1 0