- openstack-discuss - lists.openstack.org

[keystone] Weekly meeting for September 3rd 2019
by Morgan Fainberg 03 Sep '19

03 Sep '19

As of this time, we are planning to skip the keystone weekly meeting for 2019-09-03. This is to allow for work to continue with less interruption as well as US-based folks who have Labor Day (2019-09-02 this year) off to continue to make progress in light of the abbreviated week. As always, please feel free to join us on irc (freenode) in #openstack-keystone if you have any questions. I am also available (irc nic: kmalloc ). Cheers, --Morgan

1 1

[RelMgmt][election] PTL candidacy
by Sean McGinnis 03 Sep '19

03 Sep '19

Greetings! I would like to submit my name to continue as the release management PTL for the Ussuri release. I think release management is one of those critical functions for a project like OpenStack that often gets overlooked or just doesn't have the level of awareness that some of the other projects have. I've been PTL or active core since the Queens release. We have a lot of the release mechanisms automated now, but we still need to keep things running smoothly and handling any of the little issues that always pop up. My day job role isn't as focused on OpenStack as it had been, but I will still be able to devote enough time to help keep the fires out and guide anyone else that would like to get ready to take over the reins. Thank you for your consideration. Sean McGinnis (smcginnis)

1 0

[openstack-ansible][election] PTL candidacy for Ussuri
by Mohammed Naser 03 Sep '19

03 Sep '19

I'd like to announce my candidacy for OpenStack Ansible PTL. Since my last time as PTL, I mentioned the hopes of doing a few things during the cycle: # Simplifying scenarios for usage and testing We made some really good progress on this but I think our testing has improved (see below) but there's still a big wall to climb to reach a production environment. # Using integrated repository for testing and dropping role tests This effort has been largely completed. I'm very happy of the results and I'm hoping to drop the tests/ folder once we figure out the linting stuff. # Progress on switching all deployments to use Python3 This is pretty much blocked and waiting until CentOS 8 is out so we can make an all EL8 release. # Eventual addition of CentOS 8 option The lack of availability has impared this :( # Reduction in number of config variables (encouraging overrides) We slowly started to do this for a few roles but it seems like this is a very long term thing. # Increase cooperation with other deployment projects (i.e. TripleO) This has started to happen over a few roles and the newly formed Ansible SIG which should encompass a lot of the work. I would like us to be able to continue to catch up on our technical debt as I think at this point, OSA is pretty much feature complete for the most part so it's about doing things that make the maintainership easy moving onwards. I would also like to start dropping some of the old releases that still have open branches. We don't have anyone that works on them at the moment and it's better to end them than leave them stale. Thank you for your consideration. -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

[monasca][election][ptl] PTL Candidacy for Ussuri
by Witek Bedyk 03 Sep '19

03 Sep '19

Hello everyone, I would like to announce my candidacy to continue as the PTL of Monasca for the Ussuri release. After looking at my candidacy statement for the last cycle I would like to keep most of the defined themes. In the next release I would like to focus on the following goals: * strengthen the community and improve active participation and contribution * consolidate the project by concentrating on the core functionality (metrics, logs, events), cleaning up technical debt; in particular, I would like to continue driving the work on replacing the thresholding engine * collaborate with Telemetry project to identify and solve possible gaps and allow users to seamlessly migrate to Monasca * continue working on and promoting containerized deployment and Prometheus integration * continue to improve the documentation * collaborate with other OpenStack projects, e.g. by contributing to self-healing and auto-scaling SIGs Thank you for considering my candidacy. Best greetings Witek

1 0

[election][tc] Candidacy for TC
by Nate Johnston 03 Sep '19

03 Sep '19

Hello everyone, I would like to nominate myself for a position on the OpenStack Technical Committee. I started working in OpenStack in the Kilo release. I have always been focused on the networking aspects of OpenStack, mostly from a telco perspective. I had a two-cycle absence during Ocata/Pike when my former employer made a strategic decision to de-emphasize OpenStack. But I came back a year ago, and now I am a core reviewer for the Neutron project. I have never served on the TC. I deeply love OpenStack, the community of people that have come together to make cloud technology available in a completely open way for the world. It is indisputable that OpenStack is a truly global project now. I think the work that lies ahead of us is to cement OpenStack's place as a fundamental building block upon which future technologies are built. Now that StarlingX, Zuul, and Airship are also under the OpenStack foundation I think it will be more important for some of the strategic vision for the future evolution of OpenStack to come from the TC. Here are the main things I would focus on as a member of the TC: 1.) IPv6-only cloud computing: The incredible proliferation of network addressable devices will only accelerate. Some forward-thinking enterprises are already switching over to mostly, or entirely, IPv6 networking. Here we have an established advantage, as OpenStack supported IPv6 before any of the big public clouds, and we can continue to lean into the future by providing a well tested and documented IPv6-only option. 2.) A continued focus on Edge: Edge is not just for large enterprises with hundreds of widely spread points of presence. An edge deployment could also serve a small-to-medium business with a thin presence in two remote locations. The work to drive towards an edge architecture, combined with improvements in stability and ease of use, will make OpenStack an option in new areas, and I think that will be vitally important for our future. 3.) Making the experience of both operator and developer easier. I think this can be accomplished in a number of ways: by making the systems we use to develop and test our code more similar to operational clouds by moving beyond Devstack in the gate. 4.) Dealing with the contraction of the contributor community: There is much more documentation around what happens when a project begins than for what happens when it is no longer actively maintained. I think there is a lot of ambiguity that we ought to clear up for our users to clearly delineate a process of stepping down support as a project loses vitality, so that we are clearly communicating what they should expect from us as a community. Thank you very much for reading, and for considering my candidacy. Nate Johnston IRC: njohnston

1 0

[tc] Gradually reduce TC to 11 members over 2020
by Thierry Carrez 03 Sep '19

03 Sep '19

Hi everyone, The size of the TC is a trade-off between getting enough community representation and keeping enough members engaged and active. The current size (13 members) was defined by in 2013, as we moved from 5 directly-elected seats + all PTLs (which would have been 14 people) to a model that could better cope with our explosive growth. Since then, 13 has worked well, to ensure that new blood could come in at every cycle. I would argue that today, there are far less need to get wide representation in the TC (we are pretty aligned), and less difficulty to enter the TC (there is more turnover). In 2019 OpenStack, 13 members is a rather large group. It is becoming difficult to find 13 people able to commit to a significant amount of time over the coming year. And it is difficult to keep all those 13 members active and engaged. IMHO it is time to reduce the TC to 11 members, which sounds like a more reasonable and manageable size. We should encourage people to stop for a while and come back, rather than burn too many people at the same time. We should encourage more people to watch from the sidelines, rather than have a group so large that everyone that can be in it is in it. This would not be a big-bang change, just something we would gradually put in place over the next year. My strawman plan would be as follows: - Sept. 2019 election: no change, elect 6 seats as planned - Feb. 2020 election: elect 6 seats instead of 7 - Sept. 2020 election: elect 5 seats instead of 6 - Then elect 6 seats at every start-of-year and 5 at every end-of-year That would result in TC membership sizes: - U cycle (Q4 2019/Q1 2020): 13 members - V cycle (Q2/Q3 2020): 12 members - W cycle (Q4 2020/Q1 2021): 11 members - after that: 11 members FWIW, I intend to not run for reelection in the Feb 2020 election, so nobody else has to sacrifice their seat to that reform for that election :) Thoughts? -- Thierry Carrez (ttx)

13 18

RE: Openstack IPv6 neutron confiuraton
by Md. farhad Hasan Khan 03 Sep '19

03 Sep '19

Hi Jens, Thanks for your nice documentation. Thanks & B'Rgds, Farhad -----Original Message----- From: Md. Farhad Hasan Khan [mailto:rony.khan@brilliant.com.bd] Sent: Tuesday, August 6, 2019 12:00 PM To: 'Core System' Subject: FW: Openstack IPv6 neutron confiuraton -----Original Message----- From: Jens Harbott [mailto:frickler@x-ion.de] Sent: Friday, August 2, 2019 2:10 PM To: Slawek Kaplonski Cc: rony.khan(a)brilliant.com.bd; OpenStack Discuss Subject: Re: Openstack IPv6 neutron confiuraton On Friday, August 02, 2019 09:16 CEST, Slawek Kaplonski <skaplons(a)redhat.com> wrote: > Hi, > > In tenant networks IPv6 packets are going same way as IPv4 packets. > There is no differences between IPv4 and IPv6 AFAIK. > In https://docs.openstack.org/neutron/latest/admin/deploy-ovs.html You > can find some deployment examples and explanation when ovs mechanism > driver is used and in > https://docs.openstack.org/neutron/latest/admin/deploy-lb.html > there is similar doc for linuxbridge driver. For private networking this is true, if you want public connectivity with IPv6, you need to be aware that there is no SNAT and no floating IPs with IPv6. Instead you need to assign globally routable IPv6 addresses directly to your tenant subnets and use address-scopes plus neutron-dynamic-routing in order to make sure that these addresses get indeed routed to the internet. I have written a small guide how to do this[1], feedback is welcome. [1] https://cloudbau.github.io/openstack/neutron/networking/ipv6/2017/09/11/neu… > There are differences with e.g. how DHCP is handled for IPv6. Please > check https://docs.openstack.org/neutron/latest/admin/config-ipv6.html > for details. Also noting that the good reference article at the end of this doc sadly has disappeared, though you can still find it via the web archives. See also https://review.opendev.org/674018

1 0

[election][tc] Candidacy for TC
by Carter, Kevin 03 Sep '19

03 Sep '19

Hello Everyone, Some of you I've known for years; others are reading this and wondering who I am. While I may not know everyone in our ever-expanding community, I'd love the opportunity to get to know more of you, and I'd be honored to represent this community as a member of the TC. At this time, I would like to (re)introduce myself[6] and announce my candidacy for the upcoming TC election. A bit about me and why OpenStack is where my heart is. I have had the pleasure of working with OpenStack since 2012 and on OpenStack since 2013. My contributions to the community have not focused on core services, so I'm sure I've never crossed paths with a lot of folks reading this. However, I've spent considerable time working on the deployment, operations, and scale components of OpenStack. I got my start in OpenStack as an administrator of public clouds in 2012. I transitioned to Private Clouds in 2013. I had the pleasure to join a system engineering and the development team; focused on platform operations and deployments. It was through my time in the Private Cloud where when I began working on tooling that would eventually become the OpenStack-Ansible project. I was PTL of OpenStack-Ansible from its inception[2] until Liberty. I remained a core reviewer with the project, continuing to work on every facet of the tooling, until very recently. In 2015, at the Vancouver OpenStack summit, the simple OpenStack initiative was announced[5]. I took an active role in this effort as it aimed to promote better cross-community collaboration in a time where folks were somewhat siloed. While this particular effort never really took off, it establishes credibility in trying to work with people not necessarily focused on OpenStack. In my opinion, the simple OpenStack initiative was a success as it helped pave the way to future relationships while also serving as a precursor to other efforts just now starting (e.g., the Ansible-SIG[4]). This year, my journey charted a slightly new course. In mid-2019, I put on a Red fedora and have begun working on TripleO. I joined an incredible team within the Deployment Framework, and I'm looking forward to the new challenges ahead of me as I dive deeper into developing cloud tooling for the enterprise. Rest assured, I'm still working on OpenStack, I'm still trying to build a more perfect cloud, and I'm still in love with our community. So now that you know a little bit about me, I bet your reading this and wondering, why I'm running for the TC. To put it simply, I believe my experience running, building, and developing both public and private clouds puts me in a position to add a distinct voice to the TC. As a member of the TC, I would like to partner with everyone interested to help build a better, more engaged, fraternity of Stackers. I also think we can do more cross-project (cross-community) collaboration. We've done some fantastic work in this space, and I'd like to take up this mantle to continue our collaborative march to success. OpenStack has been a tremendous community to be involved with. My success as an individual is directly tied to the community, and if elected to the TC, it would be my honor to give back to the community in this new capacity. I will focus on bringing different points of view to the table. I will concentrate on collaboration. I will reach out to new and old projects alike. I will work tirelessly to assist anyone who requests my help. Finally, while it goes without saying, I will do everything I can to promote OpenStack's future success. Thank you for your consideration. -- Kevin Carter IRC: Cloudnull [0] https://www.stackalytics.com/?metric=commits&release=all&module=openstackan… [1] https://www.stackalytics.com/?metric=commits&release=all&module=openstackan… [2] http://lists.openstack.org/pipermail/openstack-operators/2014-December/0056… [3] https://www.stackalytics.com/?metric=commits&release=all&module=tripleo-gro… [4] https://review.opendev.org/#/c/676428/1/sigs.yaml [5] https://www.ansible.com/blog/simple-openstack [6] https://www.openstack.org/community/speakers/profile/758/kevin-carter

1 0

re: [lists.openstack.org代发][election][tc] TC Candidacy
by Brin Zhang(张百林) 03 Sep '19

03 Sep '19

Agree with the gmann campaign TC. He has always been concerned about the work of the OpenStack community (mainly nova) and has provided help to contributors (including me) on different projects in the community. I think that TC will make him more broad-minded and need to provide more people who contribute to the community. Brin

1 0

[requirements][election][ptl] PTL canidacy for ussuri
by Matthew Thode 03 Sep '19

03 Sep '19

I would like to announce my candidacy for PTL of the Requirements project for the Ussuri cycle. The following will be my goals for the cycle, in order of importance: 1. The primary goal is to keep a tight rein on global-requirements and upper-constraints updates. (Keep things working well) 2. Un-cap requirements where possible (stuff like cmd2). 3. Publish constraints and requirements to streamline the freeze process. 4. Audit global-requirements and upper-constraints for redundancies. One of the rules we have for new entrants to global-requirements and/or upper-constraints is that they be non-redundant. Keeping that rule in mind, audit the list of requirements for possible redundancies and if possible, reduce the number of requirements we manage. JSON libs are on the short list this go around. I look forward to continue working with you in this cycle, as your PTL or not. Thanks for your time, Matthew Thode IRC: prometheanfire -- Matthew Thode

1 0

[horizon][ptl][election] PTL Non-Candidacy
by Ivan Kolodyazhny 02 Sep '19

02 Sep '19

Hi team, It has been a pleasure and a big honour to lead Horizon team for the last three cycles. Beeing a PTL is a hard full-time job. Unfortunately, my job priorities changed and I'm not feeling that I could spend enough time as a PTL for the next cycle. There are a lot of things to be done in Horizon which we started and planned. I'm not going away from the community and will continue to contribute to the project. I'm pretty sure that with a new PTL we'll have a good time to work on at least during the next U cycle. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 0

[all][elections][ptl][tc] Conbined PTL/TC Nominations Last Days
by Jeremy Stanley 02 Sep '19

02 Sep '19

A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Sep 03, 2019 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Election statistics[2]: Nominations started @ 2019-08-27 23:45:00 UTC Nominations end @ 2019-09-03 23:45:00 UTC Nominations duration : 7 days, 0:00:00 Nominations remaining : 1 day, 6:41:51 Nominations progress : 81.73% --------------------------------------------------- Projects[1] : 63 Projects with candidates : 39 ( 61.90%) Projects with election : 0 ( 0.00%) --------------------------------------------------- Need election : 0 () Need appointment : 24 (Adjutant Cyborg Designate Freezer Horizon I18n Infrastructure Loci Manila Monasca Nova Octavia OpenStackAnsible OpenStackSDK OpenStack_Helm Oslo Placement PowerVMStackers Rally Release_Management Requirements Telemetry Winstackers Zun) =================================================== Stats gathered @ 2019-09-02 17:03:09 UTC This means that with approximately one day left, 24 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. We also need at least three more candidates to fill the six open seats on the OpenStack Technical committee. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.openstack.org/#/q/is:open+project:openstack/election have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for… -- Jeremy Stanley, on behalf of the OpenStack Technical Election Officials

1 0

[neutron][networking-infoblox] current status?
by James Page 02 Sep '19

02 Sep '19

Hi networking-infoblox developers What's the current status of this driver for Neutron? I've been working on packaging for Ubuntu today and don't see a release for Stein as well as a few reviews in gerrit that have been open for a while with no activity so I was wondering whether this project still had focus from Infoblox. Cheers James

1 0

[QA][nova][Concurrent performance]
by 崔恒香 02 Sep '19

02 Sep '19

Hello everyone! Why the performance of Stein concurrent creation of VM is not as good as that of Ocata? Create 250 VMs concurrently, the O version only needs 160s, but the S version needs 250s. Security_group and port_security functions are disabled. Among 250 VMs, there are single network card and multi-network card. Using neutron-openvswitch-agent. Regards, Cuihx

3 4

[election][tc] TC Candidacy
by Ghanshyam Mann 02 Sep '19

02 Sep '19

Hi All, I would like to announce my candidacy for OpenStack Technical Committee position. First of all, thanks for giving me the opportunity as the technical committee in the previous term. It has been a learning process for me to understand the community and its technicality in a much broader way. There are a lot of things to do for me which I targetted last year but not finished. I am fortunate to work in this community which help me to learn a lot on daily basis. While being a TC, I got more opportunities to talk and work with multiple projects and awesome contributors. Thank you everyone for your support and hardwork. Along with my QA and Nova role, I tried to target broader and cross projects work as my TC responsibility. Migrating the OpenStack CI/CD from Xenial to Bionic, updating the python testing, a current ongoing community goal of IPv6 deployment and testing are the main work as part of this. Obviously it is not necessary to be a TC to do community-wide work but as TC it gives more understanding and actual benefits as overall. For those who do not know, let me introduce myself. I have joined the OpenStack community since 2012 as operator and started as a full-time upstream contributor since 2014 during mid of Ice-House release. Currently, I am PTL for the QA Program since the Rocky cycle and active contributor in QA projects and Nova. Also, I have been randomly contributing in many other projects for example, to Tempest plugins for bug fix and tempest compatibility changes. Along with that, I am actively involved in programs helping new contributors in OpenStack. 1. As a mentor in the Upstream Institute Training since Barcelona Summit (Oct 2016)[1]. 2. FirstContact SIG [2] to help new contributors to onboard in OpenStack. It's always a great experience to introduce OpenStack upstream workflow to new contributors and encourage them to start contribution. I feel that is very much needed in OpenStack. Hosting Upstream Training in Tokyo was a great experience. TC direction has always been valuable and helps to keep the common standards in OpenStack. There are always room for improvements and so does in TC. In the last cycle, TC started an effort to ask the community about "what they expect from TC" but I think we did not get much feedback from the community. But these kind of effort are really great and I think making these practice in every cycle or year is needed. This is my personal interest or opinion. As TC, which is there to set and govern the technical direction and common standard in OpenStack, I think we should also participate in doing more coding. Every TC members are from some projects and contribute a lot of code there. But as TC let's make a practice to do more coding for community-wide efforts. Getting the use case or common problem from users and try to fix them by themselves if no one there. There is no restriction of doing that currently but making this as practice will help the community. Let me list down the area I want to work in my second TC term as well (few are continue from my last term target and few new): * Share Project teams work for Common Goals: This is very important for me as TC and I tried to do this at some extent. I helped on OpenStack gate testing migration from Xenial to Bionic and also I am doing the IPv6 community goal in Train cycle. My strategy is always to do the things by myself if there is no one there instead of keeping things in the backlog. I will be continuing this effort as much as possible. * Users/Operators and Developers interaction: Users and Operators are the most important part of any product and improving the users and developers interaction is much needed for any software. I still feel we are lacking in this area. There are few projects which get user feedback from time to time. Nova is great example to see many users or operators engaged with developers as direct contribution or meetup or ML etc. There are many other projects which are doing good in this area. But there are many projects who do not have much interaction or feedback from users. I would like to try a few ideas to improve this. Not just project-wise but as overall OpenStack. * TC and Developers interaction: There is good amount of effort to improve the interaction between PTL and TC in last couple of years. Health tracker was a good example and now TC Liasion. I would like to extend this interaction to each developer, not just PTL. We need some practical mechanism to have frequent discussions between TC and developers. At this stage, I do not know how to do that but I will be working on this in my next term. One way is to help them in term of coding, user feedback etc and then encourage them to take part in TC engagements. Thank you for reading and considerating my candidacy. Refernce: * Blogs: https://ghanshyammann.com * Review: http://stackalytics.com/?release=all&metric=marks&user_id=ghanshyammann&pro… * Commit: http://stackalytics.com/?release=all&metric=commits&user_id=ghanshyammann&p… * Foundation Profile: https://www.openstack.org/community/members/profile/6461 * IRC (Freenode): gmann [1] https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute_Occasions https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute [2] https://wiki.openstack.org/wiki/First_Contact_SIG - Ghanshyam Mann (gmann)

1 0

[tacker][election][ptl] PTL candidacy for Ussuri
by Dharmendra Kushwaha 02 Sep '19

02 Sep '19

Hello Everyone, I would like to announce my candidacy again for Tacker PTL role for Ussuri cycle. I am Dharmendra Kushwaha known as dkushwaha on IRC, active member of Tacker community since Mitaka release. I run as Tacker PTL in last two cycles. I would like to thanks all who supported Tacker with their contributions in Train cycle. It is a great experience for me to working in Tacker project with very supportive contributors team. In Train cycle we planned limited features level activities and more towards project stability, bug fixes & code coverage things. Team is working on some rich features like VNF packages support, resource force delete, enhancements in containerized VNFs, and couple of other improvements. Along with daily Tacker activities, my priority for Tacker for U cycle will be more towards: * Tacker CI/CD Improvement: - Focus to introduce more functional and scenario tests. * Tacker stability & production ready: - Focus to have more error-handling and significant logging. - More user friendly documentation. * More towards NFV-MANO rich features: - Make Tacker more ESTI compatible. * More enhancements in VNF Forwarding Graph area. * More work on container based VNFs. You can find my complete contributions here: http://stackalytics.com/?release=all&project_type=all&metric=commits&user_i… Thanks for reading and consideration my candidacy. Thanks & Regards Dharmendra Kushwaha IRC: dkushwaha ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECTI or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECTI or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.

1 0

[charms][election][ptl] PTL non-candidacy for Ussuri
by James Page 02 Sep '19

02 Sep '19

Hi All As Frode has kindly offered to pickup the PTL role this cycle I won't be putting myself forward as a PTL candidate for OpenStack Charms for the Ussuri release cycle. Thanks James

1 0

[blazar][election][ptl] PTL candidacy for Ussuri
by Pierre Riteau 02 Sep '19

02 Sep '19

Hi, I would like to submit my candidacy to serve as PTL of Blazar for the Ussuri release cycle. I served as PTL during the Stein and Train cycles and I am willing to continue in this role. The Train release cycle has been less active than previous ones, with core contributors being less available due to other commitments. To keep the project healthy, it is essential that we grow our community further. As an example, we started running an additional IRC meeting in a timezone compatible with the Americas, which has proved helpful with getting more people involved in the community. I would like to continue this effort in the upcoming cycle, release all the new features that are currently in progress, and work together to fix the main issues that are blocking further adoption of Blazar. Thank you for your support, Pierre Riteau (priteau)

1 0

[neutron] Bug Deputy August 26 - September 01
by Lajos Katona 02 Sep '19

02 Sep '19

Hi, Here is the bug deputy report for the week August 26 - September 01: As far as I see only one is without assignee (#1842150 <https://bugs.launchpad.net/neutron/+bug/1842150>) - Medium - [L2][OVS] add accepted egress fdb flows <https://bugs.launchpad.net/neutron/+bug/1841622> (#1841622): assigned - DHCP port information incomplete during the DHCP port setup <https://bugs.launchpad.net/neutron/+bug/1841636> (#1841636): assigned / in progress - Pyroute2 netns.ns_pids() will fail if during the function loop, one namespace is deleted <https://bugs.launchpad.net/neutron/+bug/1841753> (#1841753) In progress - Make the MTU attribute not nullable <https://bugs.launchpad.net/neutron/+bug/1842261> (#1842261) assigned - Low - rootwrap sudo process goes into defunct state <https://bugs.launchpad.net/neutron/+bug/1841682> (#1841682) assigned - neutron_dynamic_routing.services.bgp.bgp_plugin.BgpPlugin DBError <https://bugs.launchpad.net/neutron/+bug/1841788> (#1841788) assigned neutron_dynamic_routing - ML2 mech driver sometimes receives network context without provider attributes in delete_network_postcommit <https://bugs.launchpad.net/neutron/+bug/1841967> (#1841967) in progress / assigned - Undecided - excessive SQL query fanout on port list with many trunk ports <https://bugs.launchpad.net/neutron/+bug/1842150> (#1842150) Trunk/neutron performance - Dupilicate: - Port-Forwarding can't be set to different protocol in the same IP and Port <https://bugs.launchpad.net/neutron/+bug/1841741> (#1841741) duplicate of https://bugs.launchpad.net/neutron/+bug/1799155 - Whislist - [L2] stop processing ports twice in ovs-agent <https://bugs.launchpad.net/neutron/+bug/1841865> (#1841865) - kolla-ansible - Neutron bootstrap failing on Ubuntu bionic with Cannot change column 'network_id <https://bugs.launchpad.net/kolla-ansible/+bug/1841907> (#1841907) fix released in kolla - Old bugs that reappeared: - openvswitch firewall flows cause flooding on integration bridge <https://bugs.launchpad.net/neutron/+bug/1732067> (#1732067): High, assigned - Invalid: - instance ingress bandwidth limiting doesn't works in ocata. <https://bugs.launchpad.net/neutron/+bug/1841700> (#1841700) - Vlan network with vlan_id outside of available ranges for physical network can be created always <https://bugs.launchpad.net/neutron/+bug/1842052> (#1842052) Regards Lajos

1 0

[charms] Ussuri Cycle PTL Candidacy
by Frode Nordahl 02 Sep '19

02 Sep '19

Hello all, I would like to announce my candidacy as PTL for the OpenStack Charms project for the Ussuri cycle. The project has made great progress in the Train cycle under James's capable leadership. Some examples are; further Python3 stabilization and Python2 dependency removal, multi-model support was implemented in the Zaza functional test framework, improvements were made to SSH host key handling for our charmed deployment of Nova, Neutron DVR support was improved, actions to help handle cold start of a Percona Cluster and a tool for retrofitting existing cloud images for use as Octavia Amphora was implemented. We also provided preview charmed support for Masakari. For the Ussuri cycle we look to further improve existing features as well as implement new charm features and new charms. Over several cycles we have developed a good framework for our reactive charm development of OpenStack related charms. This framework has also been adopted for use by non-OpenStack components. I think it is worth taking some time to analyze which building blocks attract non-OpenStack components, and perhaps move the generally applicable parts of the framework down a layer to make it available for general consumption. In the spirit of Open Development this will provide us with benefits we can reap for OpenStack in the long term. Cheers, -- Frode Nordahl

1 0

[tc] not seeking reelection
by Lance Bragstad 02 Sep '19

02 Sep '19

Hi all, Now that the nomination period is open for TC candidates, I'd like to say that I won't be running for a second term on the TC. My time on the TC has enriched my understanding of open-source communities and I appreciate all the time people put into helping me get up-to-speed. I wish the best of luck to folks putting their hat in the ring this week! Thanks all, Lance

5 4

[tc][elections] Not seeking re-election to TC
by Julia Kreger 02 Sep '19

02 Sep '19

Greetings everyone, I wanted to officially let everyone know that I will not be running for re-election to the TC. I have enjoyed serving on the TC for the past two years. Due to some changes in my personal and professional lives, It will not be possible for me to serve during this next term. Thanks everyone! -Julia

8 7

[tc][elections] Not running for reelection to TC this term
by Jeremy Stanley 02 Sep '19

02 Sep '19

I've been on the OpenStack Technical Committee continuously for several years, and would like to take this opportunity to thank everyone in the community for their support and for the honor of being chosen to represent you. I plan to continue participating in the community, including in TC-led activities, but am stepping back from reelection this round for a couple of reasons. First, I want to provide others with an opportunity to serve our community on the TC. I hope that by standing aside for now, others will be encouraged to run. A regular influx of fresh opinions helps us maintain the requisite level of diversity to engage in productive debate. Second, the scheduling circumstances for this election, with the TC and PTL activities combined, will be a bit more complicated for our election officials. I'd prefer to stay engaged in officiating so that we can ensure it goes as smoothly for everyone a possible. To do this without risking a conflict of interest, I need to not be running for office. It's quite possible I'll run again in 6 months, but for now I'm planning to help behind the scenes instead. Best of luck to all who decide to run for election to any of our leadership roles! -- Jeremy Stanley

9 8

not running for the TC this term
by Doug Hellmann 02 Sep '19

02 Sep '19

Since nominations open this week, I wanted to go ahead and let you all know that I will not be seeking re-election to the Technical Committee this term. My role within Red Hat has been changing over the last year, and while I am still working on projects related to OpenStack it is no longer my sole focus. I will still be around, but it is better for me to make room on the TC for someone with more time to devote to it. It’s hard to believe it has been 6 years since I first joined the Technical Committee. So much has happened in our community in that time, and I want to thank all of you for the trust you have placed in me through it all. It has been an honor to serve and help build the community. Thank you, Doug

8 7

[I18n] PTL Non-Candidacy
by Ian Y. Choi 02 Sep '19

02 Sep '19

Hello I18n team, As announced by [1], now is U-cycle (Ussuri) PTL nomination period, and only less than 2 days are left from now. I will not run for I18n PTL for U-cycle because I am now serving as an PTL/TC election official and the role conflicts with running for PTL [2]. I ran for election official to better understand OpenStack ecosystem and more interact with community members, not to leave from I18n team. I will still stay around I18n team, but it would be so great if someone runs for I18n PTL on upcoming cycle. Also, I shared the current status of I18n team on last July [3]. If you have not read this, please read for more information. Note that I will be at Shanghai Summit + PTG for more I18n sessions as an official team succeeding from my current PTL activities - please prioritize to participate in upcoming Summit + PTG with any kind of ways - both online and offline participation should be definitely fine. With many thanks, /Ian [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008679.h… [2] https://wiki.openstack.org/wiki/Election_Officiating_Guidelines [3] http://lists.openstack.org/pipermail/openstack-i18n/2019-July/003439.html

1 0