- openstack-discuss - lists.openstack.org

[goals][IPv6-Only Deployments and Testing] Week R-6 Update
by Ghanshyam Mann 05 Sep '19

05 Sep '19

Hello Everyone, Below is the progress on Ipv6 goal during R6 week. I am preparing the legacy base job for IPv6 deployment. NOTE: As first step, I am going to set up the job with all IPv6 deployment setting and basic verification whether service listens on IPv6 or not. As the second step, we will add post-run script to audit the tcpdump/logs etc for unwanted IPv4 traffic. Summary: * Number of Ipv6 jobs proposed Projects: 28 * Number of pass projects: 18 ** Number of project merged out of pass project: 13 * Number of failing projects: 10 Storyboard: ========= - https://storyboard.openstack.org/#!/story/2005477 Current status: ============ 1. Cinder and devstack fix are merged for cinder IPv6 job and I did recheck on cinder patch. 2. Preparing the legacy base job with IPv6 setting - https://review.opendev.org/#/c/680233/ 3. Zun, Watcher, Telemetry(thanks to zhurong) are merged. I have proposed to run telemetry ipv6 job on Panko and Aodh gate also. 4. This week new projects ipv6 jobs patch and status: - Tacker: link: https://review.opendev.org/#/c/676918/ status: Current functional jobs are n-v so I am not sure IPv6 job will pass or not. waiting for gate result. Need Help from the project team: 1. Monasca: waiting for new kafka client patches merge - https://review.opendev.org/#/c/674814/2 2. Sahara: https://review.opendev.org/#/c/676903/ Job is failing to start the sahara service. I could not find the logs for sahara service(it shows an empty log under apache). Need help from sahara team. 3. Searchlight: https://review.opendev.org/#/c/678391/ python-searchlightclient error, Trinh will be looking into this. 4. Senlin: https://review.opendev.org/#/c/676910/ Not able to connect on auth url - https://zuul.opendev.org/t/openstack/build/0ad3b4aac0424ad78171ca7546421f5e… 5. qinling: https://review.opendev.org/#/c/673506/1 logs are not there so i did recheck to get the fresh log for debugging. IPv6 missing support found: ===================== 1. https://review.opendev.org/#/c/673397/ 2. https://review.opendev.org/#/c/673449/ 3. https://review.opendev.org/#/c/677524/ How you can help: ============== - Each project needs to look for and review the ipv6 job patch. - Verify it works fine on ipv6 and no ipv4 used in conf etc - Any other specific scenario needs to be added as part of project IPv6 verification. - Help on debugging and fix the bug in IPv6 job is failing. Everything related to this goal can be found under this topic: Topic: https://review.opendev.org/#/q/topic:ipv6-only-deployment-and-testing+(stat… How to define and run new IPv6 Job on project side: ======================================= - I prepared a wiki page to describe this section - https://wiki.openstack.org/wiki/Goal-IPv6-only-deployments-and-testing Review suggestion: ============== - Main goal of these jobs will be whether your service is able to listen on IPv6 and can communicate to any other services either OpenStack or DB or rabbitmq etc on IPv6 or not. So check your proposed job with that point of view. If anything missing, comment on patch. - One example was - I missed to configure novnc address to IPv6- https://review.opendev.org/#/c/672493/ - base script as part of 'devstack-tempest-ipv6' will do basic checks for endpoints on IPv6 and some devstack var setting. But if your project needs more specific verification then it can be added in project side job as post-run playbooks as described in wiki page[1]. [1] https://wiki.openstack.org/wiki/Goal-IPv6-only-deployments-and-testing -gmann

1 0

[zaqar][requirements] - release zaqarclient please?
by Matthew Thode 05 Sep '19

05 Sep '19

Hi Zaqar team, I tried to contact you via IRC but that didn't seem to go very well. The requirements team is looking for a release of the client so that we can move on updating jsonschema. We'd like to update it before the freeze time (starts Monday the 9th) so that all the other projects that use it can use it for a while in gate before release. held back because waiting for zaqarclient -jsonschema===3.0.2 +jsonschema===2.6.0 Is it possible to release a new version of the client (for instance as novaclient just recently did (among others))? Thanks, -- Matthew Thode

2 1

[dev][tosca-parser] review of toscadefinition1.2-support code
by Uikey, Nitin 05 Sep '19

05 Sep '19

Dear core-reviewers, We have submitted one patch regarding `Add support for tosca definition version 1.2` under topic `toscadefinition1.2-support`. Ref: https://review.opendev.org/#/c/675561/ We are adding a new feature in tacker to implement ETSI specs. In the beginning adding interface to manage vnf packages. For this feature spec [1] to merge, we need tosca-parser patch to be merged. We would appreciate if you can take a look at the patch and give your feedback. Thank you in advance. [1] : https://review.opendev.org/#/c/582930 Regards, Nitin Uikey Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

1 0

[tc] monthly meeting agenda
by Mohammed Naser 04 Sep '19

04 Sep '19

Hi everyone, Here’s the agenda for our monthly TC meeting. It will happen tomorrow (Thursday the 5th) at 1400 UTC in #openstack-tc and I will be your chair. If you can’t attend, please put your name in the “Apologies for Absence” section. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting * Follow up on past action items ** mnaser to contact Alan to mention that TC will have some presence at Shanghai leadership meeting ** ricolin update SIG guidelines to simplify the process for new SIGs ** ttx contact interested parties in a new 'large scale' SIG (help with mnaser, jroll reaching out to Verizon Media) * Active Initiatives ** mugsie to sync with dhellmann or release-team to resolve proposal bot for project-template patches ** Shanghai TC sessions: https://etherpad.openstack.org/p/PVG-TC-brainstorming ** Forum selection commitee: http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008188.h… ** Make goal selection a two-step process (needs reviews at https://review.opendev.org/#/c/667932/ ) Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

[Tacker] [Mistral] Regarding Inputs in Network Service Descriptors
by Nehal Bansal 04 Sep '19

04 Sep '19

Hi, I have been trying to create a Network Service Descriptor which takes flavor, image, network_name as inputs from a parameter file and then passes it on to the VNF Descriptor but so far my attempts have been unsuccessful. Is there a standard template available because I could not find even a single one which took image_name or flavor_name from a parameter file. Thank you. Regards, Nehal Bansal

1 0

[all] [tc] PDF goal change
by Alexandra Settle 04 Sep '19

04 Sep '19

Hi all, Further work on the PDF generation showed that many projects have project logos as svg files with the name PROJECT.svg, those get converted to PROJECT.pdf and collide with the default name used here. We have now changed the default to "doc-PROJECT.pdf" to have a unique name. The review [1] merged yesterday, so please be aware of this change when you are working on the goal. Thanks, Alex [1] https://review.opendev.org/#/c/679777 -- Alexandra Settle <a.settle(a)outlook.com> IRC: asettle

1 0

[keystone][edge] Edge Hacking Days - August 16
by Ildiko Vancsa 04 Sep '19

04 Sep '19

Hi, It is a friendly reminder that we are having the second edge hacking days in August this Friday (August 16). The dial-in information is the same, you can find the details here: https://etherpad.openstack.org/p/osf-edge-hacking-days If you’re interested in joining please __add your name and the time period (with time zone) when you will be available__ on these dates. You can also add topics that you would be interested in working on. We will keep on working on two items: * Keystone to Keystone federation testing in DevStack * Building the centralized edge reference architecture on Packet HW using TripleO Please let me know if you have any questions. See you on Friday! :) Thanks, Ildikó

1 1

[kolla] Cancelling today's meeting
by Mark Goddard 04 Sep '19

04 Sep '19

Hi, I can't make today's meeting, and we're missing a number of cores so I'll cancel. Please get in touch on IRC if there is anything to update. Cheers, Mark

1 0

[ops] Introducing Waldur - open-source platform for openstack operators
by Andres Toomsalu 04 Sep '19

04 Sep '19

I would like to introduce open-source Waldur platform - targeted for openstack cloud operators and implementing service delivery pipeline towards end customers. It uses modular approach and has the following core features: * integrated marketplace and self-service for the end users (REST API and webapp) * built-in accounting, integrations with backend billing systems and payment gateways * built-in customer support/servicedesk functionality and integrations with backend servicedesk systems (Atlassian Servicedesk for example) * built-in organisation membership and user management * multi-cloud (ie multiple openstack API endpoints) support inside customer project containers This diagram provides overview about available modules and their relations: https://waldur.com/assets/doc/waldur-diagram.pdf Waldur openstack support is fairly mature - it has been successfully used in production deployments since 2015. Its web-based self-service for end users implements somewhat opiniated openstack tenant and resource management - based on our real-world experience and some best practices delivered from it. But also Horizon access provisioning and out-of-band tenant changes sync are supported. More details about Waldur platform and its openstack support can be found here: https://waldur.com/#openstack Source code is available from OpenNode github repositories: https://github.com/opennode/waldur-mastermind https://github.com/opennode/waldur-homeport Documentation is available here: http://docs.waldur.com All the best, Andres Toomsalu andres at opennodeloud.com

2 4

[openstack-ansible] weekly office hours
by Mohammed Naser 04 Sep '19

04 Sep '19

Hi everyone, Here’s the update of what happened in this week’s OpenStack Ansible Office Hours. - The 42.3 clean up and job state matrix are still pending. - We decided to retire Ocata and are thinking of retiring Pike since they are not being used or maintained anymore. - We also discussed the future of OSA. We noticed a lot of operators are going more towards containers or kubernetes and the contributions and traction for OSA have decreased, so we’re wondering if we should start thinking about adopting a new direction in the future. I suggest that you read the eavesdrop for the last point and would like to ask for input. Thanks! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

2 1

[cyborg][election][ptl] PTL candidacy for Ussuri
by Nadathur, Sundar 04 Sep '19

04 Sep '19

Hello all, I would like to announce my candidacy for the PTL role of Cyborg for the Ussuri cycle. I have been involved with Cyborg since 2018 Rocky PTG, and have had the privilege of serving as Cyborg PTL for the Train cycle. In the Train cycle, Cyborg saw some important developments. We reached an agreement on integration with Nova at the PTG, and the spec that I wrote based on that agreement has been merged. We have seen new developers join the community. We have seen existing Cyborg drivers getting updated and new Cyborg drivers being proposed. We are also in the process of developing a tempest plugin for Cyborg. In the U cycle, I'd aim to build on this foundation. While we may support a certain set of VM operations with accelerators with Nova in Train, we can expand on that set in U. We should also focus on Day 2 operations like performance monitoring and health monitoring for accelerator devices. I would like to formalize and expand on the driver addition/development process. Thank you for your support. Regards, Sundar

2 1

[kolla-ansible] Correct way to add/remove nodes.
by Eddie Yen 04 Sep '19

04 Sep '19

Hi, I wanna know the correct way to add/remove nodes since I can't find the completely document or tutorial about this part. Here's what I know for now. For addition: 1. Install OS and setting up network on new servers. 2. Add new server's information into /etc/hosts and inventory file 3. Do bootstrapping to these servers by using bootstrap-servers with --limit option 4. (For Ceph OSD node) Add disk label to the disks that will become OSD. 5. Deploy again. For deletion (Compute): 1. Do migration if there're VMs exist on target node. 2. Set nova-compute service down on target node. Then remove the service from nova cluster. 3. Disable all Neutron agents on target node and remove from Neutron cluster. 4. Using kolla-ansible to stop all containers on target node. 5. Cleanup all containers and left settings by using cleanup-containers and cleanup-host script. For deletion (Ceph OSD node): 1. Remove all OSDs on target node by following Ceph tutorial. 2. Using kolla-ansible to stop all containers on target node. 3. Cleanup all containers and left settings by using cleanup-containers and cleanup-host script. Now I'm not sure about Controller if there's one controller down and want to add another one into HA cluster. My thought is that add into cluster first, then delete the informations about corrupted controller. But I have no clue about the details. Only about Ceph controller (mon, rgw, mds,. etc) Does anyone has experience about this? Many thanks, Eddie.

1 1

[manila][ptl] Non-candidacy for the Ussuri Cycle
by Tom Barron 03 Sep '19

03 Sep '19

I want to thank the Manila community for allowing me to serve as PTL for the last three cycles, but it is time for us to change it up! I know it's late for this announcement, but I wanted first to make sure that I won't be leaving an unfilled vacancy and events conspired such that that took longer than anticipated :) So stay tuned for an announcment shortly of a nomination for a new PTL for Ussuri -- I'm sure you'll be as pleased as I am with what you'll read. I'm not going anywhere. I'll be working on Manila itself and helping the new PTL, as well as working with actual Manila deployments and the use of Manila as open infrastructure by adjacent communities. Thanks again! -- Tom Barron

2 1

[manila][ptl][election] PTL candidacy for Ussuri
by Goutham Pacha Ravi 03 Sep '19

03 Sep '19

Greetings Zorillas & other Stackers, I would like to submit my candidacy to be the PTL of Manila for the Ussuri cycle. I have been a contributor to OpenStack since the Liberty release and a maintainer of Manila and its associated deliverables since the Ocata release. I have had the opportunity to work closely with, and learn from, two stellar engineers who have served as PTLs so far. I've also had the privilege of collaborating with contributors from varied backgrounds. This taught me the technical aspects of orchestrating Open Infrastructure Storage at cloud scale. I attribute the tremendous growth of the project to each of us in the project internalizing and espousing the "OpenStack Way" of upstream open-source development. My strongest qualification for this job is that I wake up excited about the problems we're solving. As an engineer I see features left to implement; as an ambassador, I see untapped use cases; as a maintainer, I see new contributors and technical debt. So, if you'll have me, as the PTL, I will work towards maturing Manila, tackling its technical debt, advocating its usage and sustaining its neutrality. I'll also continue doing the thing I love most: mentoring new members and preserving this well-knit community. In the near term, I propose that you and I: - Continue hard on the path to growing contributors: Stein/Train was an exciting time for us; we worked hard on this goal! We lowered the barrier of entry for new contributors by relaxing our review norms [1] and provided quick and easy tutorials [2] to bootstrap with our free and open source storage drivers, among many other things. We had an opportunity to mentor interns under Outreachy [3], Google Summer of Code [4] and the Open University of Israel [5] internship programs. Let's do more of this and ensure we have able successors. Let's also mentor reviewers and create more maintainers. - Complete integration to openstackclient/openstacksdk and evolve manila-csi by reaching feature parity to the rich feature-set we already provide. - Continue the work on reliability, availability and fault tolerance of individual components and allow for more flexible deployment scenarios. - Gather feedback from edge/telco/scientific computing consumers and address pain points. Thank you for your support, Goutham Pacha Ravi <gouthampravi(a)gmail.com> IRC: gouthamr [1] https://docs.openstack.org/manila/latest/contributor/manila-review-policy.h… [2] https://docs.openstack.org/manila/latest/contributor/development-environmen… [3] https://www.outreachy.org/apply/rounds/may-2019-august-2019-outreachy-inter… [4] https://summerofcode.withgoogle.com/projects/#5067835716403200 [5] https://review.opendev.org/#/q/committer:gilboa.nir%2540gmail.com+status:me… [6] Candidacy submission: https://review.opendev.org/679881

1 0

[adjutant][ptl] Adrian Turjak as Adjutant U cycle PTL
by Adrian Turjak 03 Sep '19

03 Sep '19

Hello OpenStackers, I'm submitting myself as the PTL for Adjutant during the U cycle. At this time I think I'm still the best suited to continue leading the project, with the best understanding of the codebase and the direction that the service is taking. The Train cycle was sadly not as productive as I'd have liked, purely because of how much big refactor work we've been in the middle of. The progress of that though has been good, and it should lay the groundwork for a very productive U cycle. The planned work for the next cycle is: - introduce partial policy support rather than relying on hardcoded decorators. - finish the long planned support for sub-project management - add project (and resource) termination logic - rework the identity manager as a pluggable construct. Cheers, Adrian Turjak

1 0

[qa][nova][migrate]CPU doesn't have compatibility
by 崔恒香 03 Sep '19

03 Sep '19

Hi This is my ERROR info(ocata): 2019-09-03 10:00:46.518 25163 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 5229, in check_can_live_migrate_destination 2019-09-03 10:00:46.518 25163 ERROR oslo_messaging.rpc.server disk_over_commit) 2019-09-03 10:00:46.518 25163 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 5240, in _do_check_can_live_migrate_destination 2019-09-03 10:00:46.518 25163 ERROR oslo_messaging.rpc.server block_migration, disk_over_commit) 2019-09-03 10:00:46.518 25163 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5670, in check_can_live_migrate_destination 2019-09-03 10:00:46.518 25163 ERROR oslo_messaging.rpc.server self._compare_cpu(None, source_cpu_info, instance) 2019-09-03 10:00:46.518 25163 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5938, in _compare_cpu 2019-09-03 10:00:46.518 25163 ERROR oslo_messaging.rpc.server raise exception.InvalidCPUInfo(reason=m % {'ret': ret, 'u': u}) 2019-09-03 10:00:46.518 25163 ERROR oslo_messaging.rpc.server InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility.

3 4

review.opendev.org Outage September 16 to Perform Project Renames
by Clark Boylan 03 Sep '19

03 Sep '19

Hello, We will be taking a Gerrit outage of about an hour on September 16 at 14:00 UTC to perform project renames. Please let us know if this scheduling does not work for some reason. We have tried to schedule this for a quiet time at the end of OpenStack's Train release cycle. Also, if you'd like to rename a project, now is the time to start prepping for that. Feel free to ask us any questions you have or bring up your concerns with us. Thank you for your patience, Clark

1 0

[nova][ptl] Eric Fried candidacy for Nova U PTL
by Eric Fried 03 Sep '19

03 Sep '19

I would be honored to continue serving as the Nova PTL in the Ussuri release [0]. Please note that I will not be in Shanghai. As Train PTL, I am working to delegate the project update [1]. If reelected for Ussuri, I intend to do the same for PTG responsibilities, including doing as much as possible via "virtual pre-PTG" on the mailing list. Being PTL for Train has been a growth experience. It has forced me to take a broader view of the project versus my previous focus on my topics of interest [2]. The flip-side is that I have had less time to devote to those things, and that has been a sacrifice. As such, I intend to be bolder about delegating this time around. In my stump speech for Train [3] I expressed a desire to grow contributor participation. I feel we have seen positive movement with new and existing non-cores showing improved code and review activity. Let's maintain the encouraging atmosphere and continue to grow in this space. However, core participation has not seen the same health, and it shows in the relatively low volume of feature work that has been accomplished to date in Train (more on this below). This has been one of my main frustrations as Nova Cat-Herder: like cats, Nova cores are mysterious beings motivated by forces beyond my ability to control. I would like to find ways to make core review activity more consistent as a step toward being able to predict more accurately what we can expect to get done in a cycle. This should make everyone's (project) managers happier, a delicious treat made with real tuna. Feature-wise, I was disappointed in the lack of progress exploiting nested resource providers. The Placement team worked hard to deliver the dependencies [4] to allow us to express things like subtree affinity for NUMA, but Nova missed the boat (train) due to lack of resource [5] and inability to agree on how to move forward [6]. Expressing NUMA in Placement is going to be the next major inflection point for scheduling robustness and performance; we need to get serious about making it a priority. But first we should finish what we started, closing on the many almost-there features that are looking risky for Train. We should be conservative about committing to new features until those are done. Thanks, Eric Fried (efried) (say it like "freed") [0] https://review.opendev.org/679862 [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/thread.h… [2] meaning things my employer cares about, areas where I have background/expertise, and things that sound fun and/or further some mission of Nova/OpenStack [3] https://opendev.org/openstack/election/src/branch/master/candidates/train/N… [4] https://docs.openstack.org/placement/latest/specs/train/approved/2005575-ne… [5] insert Placement joke here [6] https://review.opendev.org/#/c/650963/

1 0

[tc] weekly update
by Mohammed Naser 03 Sep '19

03 Sep '19

Hi everyone, Here’s the update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # General changes - Added kayobe as a deliverable of the kolla project: https://review.opendev.org/#/c/669299/ Thanks! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

[ptl] [docs] [election] PTL Candidacy for Ussuri
by Alexandra Settle 03 Sep '19

03 Sep '19

Hey all, I would like to submit my candidacy for the documentation team's PTL for the Ussuri cycle. Stephen Finucane (Train PTL) will be unofficially serving alongside me in a co-PTL capacity so we can equally address documentation-related tasks and discussions. I served as the documentation PTL for Pike, and am currently serving as an elected member of the Technical Committee in the capacity of vice chair. I have been a part of the community since the beginning of 2014, and have seen the highs and the lows and continue to love working for and with this community. The definition of documentation for OpenStack has been rapidly changing and the future of the documentation team continues to evolve and change. I would like that opportunity to help guide the documentation team, and potentially finish what myself, Petr, Stephen and many others have started and carried on. Thanks, Alex -- Alexandra Settle <a.settle(a)outlook.com> IRC: asettle

3 3

[elections][tc] Announcing Candidacy for OpenStack Technical Committee
by Jay Bryant 03 Sep '19

03 Sep '19

Dear OpenStack Community, This note is to officially announce my candidacy for the OpenStack TC. For those of you that don’t know me, allow me to introduce myself: [1] I have been active in the OpenStack Community since early in 2013. After nine years of working on Super Computing Solutions with IBM I moved to OpenStack and started working on Neutron (Quantum back in those days) before moving over to a relatively new project called Cinder. Within IBM I worked to create the processes for IBM’s storage driver development teams to interact with and contribute to the Cinder project. I became a core member of the Cinder team in the middle of 2013 and have remained active ever since. [2] [3] I have been the Cinder PTL for the last two years, starting in the Queens release. Beyond Cinder I have sought opportunities to work across OpenStack projects. I was the liaison between the Cinder and Documentation teams. This lead to opportunities to learn how OpenStack’s documentation is developed and enabled me to help improve the Cinder team’s documentation. I have also served for quite some time as the liaison to the Oslo team. Education and on-boarding of new team members has been a focus of my tenure in OpenStack. I started helping to lead the OpenStack Upstream Institute at the fall 2016 Summit in Barcelona. After Barcelona I helped to revise the education to meet the needs of future Upstream Institute sessions and have coordinated with my current employer, Lenovo, to sponsor each OpenStack Upstream Institute at Summits since the Spring 2017 Summit in Boston. Lenovo will even be hosting the OUI session in Shanghai! I also created Cinder’s on-boarding education which I have presented at each Summit since the Fall 2017 Summit in Sydney. I have sought opportunities to mentor new contributors both within my employers and from the community in general. I have a long experience working with OpenStack and a broad understanding of how the community works, I also feel that I have a breadth of technical experience that will benefit the TC. I have experience in High Performance Computing and feel I can understand and represent the needs of the HPC community. I have years of experience in the storage realm and can represent the unique concerns that storage vendors bring to OpenStack and the subsequent concerns that our OpenStack distributors have supporting OpenStack and its many drivers. Since moving from IBM to Lenovo my focus has changed from development of OpenStack to developing solutions that leverage OpenStack. I have enjoyed the opportunity to become a consumer of OpenStack as it has given me an opportunity to better understand the versatility and complexity of OpenStack. I have been working with customers with an interest in both telco applications, particularly where Edge computing is concerned, as well as enterprise customers. Given my latest work I feel that I am able to understand and represent many interests from the OpenStack community. If elected to the TC here are some of the concerns that I would like to address: * Ensure that we continue to improve our on-boarding and educational processes. The days where people are assigned to only work on OpenStack are gone. The easier we make it for people to successfully contribute to and leverage OpenStack, the more likely they will be to continue to contribute. * Improve documentation of OpenStack and Project processes. There have been a lot of discussions lately regarding undocumented processes. There is a lot of tribal knowledge involved in OpenStack and this too makes it hard for new contributors to integrate. Improving the documentation/description of ‘how we build OpenStack’ is crucial. * I would like the community as a whole to seek ways to make OpenStack more consumable by our users and distributors. I think the move to having longer lived stable branches has been a good step, but it has not resolved all the issues posed by customers that stay on older releases of OpenStack. The stable backport policies need to be readdressed to seek a solution that allows vendors to backport code for their customers, improving OpenStack’s usability without risking its stability. * I would like to continue the work that has been started to increase the visibility of the TC’s contributions to OpenStack and increase the effort to have the TC be a resource to the whole community. * I want to seek opportunities for OpenStack to continue to inter-operate with other cloud solutions. Virtualization is not the only cloud approach available and customers, very often, do not want just one solution or the other. OpenStack needs to continue to expand to address these concerns to remain vibrant and relevant. I hope that the thoughts above have resonated with you and appreciate you considering me for a position on the Technical Committee. I am passionate about OpenStack and believe that we have a community like no other in the industry. It would be a great honor to represent this community in a new capacity. Sincerely, Jay Bryant [1] Foundation Profile: https://www.openstack.org/community/members/profile/8348/jay-bryant [2] Reviews: https://www.stackalytics.com/?user_id=jsbryant [3] Commits: https://www.stackalytics.com/?user_id=jsbryant&metric=commits IRC (Freenode): jungleboyj

1 0

[TripleO][CI] Outage on the rdoprojects.org server is causing jobs to fail
by Gabriele Cerami 03 Sep '19

03 Sep '19

Hi, this weekend, and outage caused trunk.rdoprojects.org servers to become unreachable. As main effect, all tripleo ci jobs were unable to download and install dlrn repositories for the needed hashes and failed. The outage has been resolved yesterday but there's a problem with DNS propagation and we're still seeing DNS queries returning incorrect IPs, and as a result, jobs are not consistently passing. You may see problems dowloading repos, building changes, installing packages We would advise to limit the rechecks until we are sure the DNS results are stable. Thanks.

2 1

[elections][ptl][tc][adjutant][cyborg][designate][i18n][manila][nova][openstacksdk][placement][powervmstackers][winstackers] Missing PTL/TC Candidates!
by Jeremy Stanley 03 Sep '19

03 Sep '19

A final reminder, we are now into the last few 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 to make sure the community knows your intentions: https://governance.openstack.org/election/#how-to-submit-a-candidacy Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. With approximately six hours remaining, the 10 projects tagged in the Subject line of this message will be deemed leaderless if no eligible nominees step forward. In this case the TC will directly oversee PTL selection/appointment. We also need at least one more TC candidate to have enough to fill the six open seats on the OpenStack Technical committee. Thank you, -- Jeremy Stanley, on behalf of the OpenStack Technical Election Officials

1 0

[kolla] Kayobe Stein release now available
by Mark Goddard 03 Sep '19

03 Sep '19

Hi, I'm pleased to announce that the first Stein cycle release for Kayobe is now available - 6.0.0. Thanks to everyone who contributed. Release notes: https://docs.openstack.org/releasenotes/kayobe/stein.html Join us on #openstack-kolla to help make the Train cycle release even better. Cheers, Mark

1 0

[ALL][UC] The UC Special Election results
by Ian Y. Choi 03 Sep '19

03 Sep '19

Hello all, On behalf of the User Committee Elections officials, I am pleased to announce the results of the UC elections for the special election 2019 [1]. Please join me in congratulating the winner: Jaesuk Ahn! With the result from the previous UC election on last month [2], total two winners (Mohamed Elsakhawy, Jaesuk Ahn) will serve UC for one year. Thank you, - Ed & Ian [1] https://governance.openstack.org/uc/reference/uc-election-sep2019.html [2] http://lists.openstack.org/pipermail/user-committee/2019-August/002870.html

1 0

[Horizon] [stable] Adding Radomir Dopieralski to horizon-stable-maint
by Ivan Kolodyazhny 03 Sep '19

03 Sep '19

Hi team, I'd like to propose adding Radomir Dopieralski to the horizon-stable-maint team. He's doing good quality reviews for stable branches [1] on a regular basis and I think Radomir will be a good member of our small group. [1] https://review.opendev.org/#/q/reviewer:openstack%2540sheep.art.pl+NOT+bran… Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

2 2

[TripleO][CI] Outage on the rdoprojects.org server is causing jobs to fail
by Gabriele Cerami 03 Sep '19

03 Sep '19

Hi, this weekend, and outage caused trunk.rdoprojects.org servers to become unreachable. As main effect, all tripleo ci jobs were unable to download and install dlrn repositories for the needed hashes and failed. The outage has been resolved yesterday but there's a problem with DNS propagation and we're still seeing DNS queries returning incorrect IPs, and as a result, jobs are not consistently passing. We would advise to limit the rechecks until we are sure the DNS results are stable. Thanks.

1 0

[oslo][ptl][election] PTL candidacy for Ussuri
by Ben Nemec 03 Sep '19

03 Sep '19

See my election review for more details: https://review.opendev.org/#/c/679803/1/candidates/u/Oslo/openstack%2540nem… Thanks. -Ben

1 0

[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 02 Sep '19

02 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