- openstack-discuss - lists.openstack.org

[kolla] PTL candidacy
by Mark Goddard 30 Aug '19

30 Aug '19

Hi, I'd like to nominate myself to serve as the Kolla PTL for the Ussuri cycle. I have been PTL for the Train cycle, and would like the opportunity to continue to lead the team. In my Train nomination [1] I proposed a few things, including: * help those on the periphery of the project get more involved * try a new meeting time * hold a virtual PTG * adopt some of ironic's planning and tracking processes * continue improving CI testing During the cycle we have helped a number of new contributors get involved, and have taken on a new core contributor who is already one of the most active members. We polled for a new meeting time but found we were already optimal. The virtual PTG helped us to prioritise our efforts, and I expect we'll hold another this cycle. We now use a whiteboard [2] similar to ironic's, and went through a process of prioritisation of features for this cycle which we continue to use to guide our efforts. Finally, CI test coverage continues to improve - notably the new multinode upgrade job caught a pretty nasty MariaDB upgrade bug that we might not otherwise have spotted before release. If elected this cycle I'd like to continue to reflect on our processes, and encourage increasing test coverage for further stability. We recently added Kayobe [3] as a project deliverable, and I intend to ensure that these two overlapping communities come together effectively to make the most effective use of our combined resources. Thanks for reading, Mark Goddard (mgoddard) [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003617.ht… [2] https://etherpad.openstack.org/p/KollaWhiteBoard [3] https://docs.openstack.org/kayobe

1 0

Re: [User-committee] UC candidacy
by Ian Y. Choi 30 Aug '19

30 Aug '19

Hello, As an UC election official, I confirm that the candidate is eligible for UC election within nomination period. With many thanks, /Ian On Friday, August 30, 2019, Jaesuk Ahn <bluejay.ahn(a)gmail.com> wrote: > > Hi, > > This is Jaesuk Ahn from OpenStack Korea User Group. > I would like announce my candidacy to serve as the User Committee. > > As a strong advocate of OpenStack community, I have been involved in > OpenStack > from 2010, founded OpenStack Korea Community in 2011, and been a > coordinator of > the Korea community since then. I have devoted myself to build an open and > healthy local community, in addition, I have always been trying to be a > good > arbitrator between local and global community to embrace a diversity > together. > > Here are articles about various events that I have been one of main > organizers > and program chair of the events [1], [2], [3]. Please see the presentation > [4] > I did with two other community leaders on how we have built community in > Korea. > > From a technical point of view, I have been leading OpenStack dev team > since > 2010. I have switched companies during those years but was able to focus > on one > thing: deployment automation & lifecycle management of OpenStack. > OpenStack-Helm, > and Airship are the most recent efforts on this line of work in my career. > Here is my linkedin profile stating my work during the last 10 years [5]. > > I am currently leading a development team to work on > openstack-on-kubernetes in > SK Telecom. I have made an architectural decision to leverage kubernetes > for > OpenStack lifecycle management in 2016, that this decision eventually led > us to > collaborate with AT&T team. As a result of community collaboration with > AT&T, > I am happy to see both OpenStack-Helm project and Airship project active > in > the community. > > if I am chosen by the community, I am fully committed to hear various > voices > from many community members, especially from community members who has > difficulties in language and time barrier. I will do my best to > collaborate with others to > make OpenStack community more diverse and active. > > [1] https://superuser.openstack.org/articles/building-new- > foundations-openinfra-days-korea/ > [2] https://superuser.openstack.org/articles/openstack-korea-days-2017/ > [3] https://superuser.openstack.org/articles/openstack-day-in- > korea-2015-to-infinity-and-beyond/ > [4] https://www.slideshare.net/openstack_kr/boston-summit- > what-makes-it-possible-to-run-openstack-community-for-three-generations > [5] https://www.linkedin.com/in/jsahn/ > > > Thanks > > > *Jaesuk Ahn*, Ph.D. > Cloud Labs, SK Telecom >

1 0

[Packaging-Rpm] PTL Candidacy
by Javier Pena 30 Aug '19

30 Aug '19

Hello everyone, I would like to announce my candidacy to be the PTL for the Packaging Rpm project during the Ussuri development cycle. For the Ussuri cycle, my focus would be on: * Making sure all packages have been migrated to Python 3, so we can finally get rid of Python 2. * Transition the RDO CI and packages to CentOS 8, once it is released, and remove the now obsolete Fedora-based CI. That, of course, would be in addition to our common goals: expanding our contributor base, improving collaboration between RPM distributions, and keeping a high quality set of packages. Thanks, Javier

1 0

[cloudkitty] PTL candidacy
by Luka Peschke 30 Aug '19

30 Aug '19

Hello contributors, user, operators, I would like to submit my candidacy as CloudKitty's PTL for the Ussuri cycle. I've been contributing to the project for several releases and I've been the PTL for the last two releases. I'm very happy with the T cycle, as the goals we fixed ourselves have been achieved: the planned features have been implemented, some features that were planned for U might make it into T, and most importantly, our community has grown. If you want to have me as the project's PTL for the Ussuri cycle, I'd like to keep focusing on the points we addressed during the last few cycles: * Help CloudKitty's community to grow. This is a constant effort, and it is starting to pay off: people are gaining interest in CloudKitty, more and more questions and suggestions are being asked/made on IRC, and some external contributors are proposing patches. That's very rewarding for our small community, and we intent to keep it going! * Improving the documentation: A lot has been done during the last cycles, but with the growth of the v2 API, we need to keep putting effort into this; more specifically into tutorials, guides and into the developer documentation I'd also like to finally work on the new rating module. This has been planned and asked for too long, and we should finally work on this together. I will use this opportunity to thank everybody who's been involved in CloudKitty: developers, reviewers, users... The project lives thanks to you! Thank you for your attention, Luka Peschke

1 0

[Glance] PTL Candidacy
by Abhishek Kekane 30 Aug '19

30 Aug '19

Hello everyone, I would like to announce my candidacy for the role of PTL of Glance for the Ussuri cycle. I have been working closely with several previous PTL's like Erno and Brian and I am hoping to contribute back to the community as a PTL while following their excellent example. I've been working primarily with Glance since Icehouse and do work full-time on Glance upstream. During that time I've served community in release liaison role, as Glance core reviewer and part of Glance bugs team. I have represented Glance in interactions with various teams, such as the cross-projects interactions, API workgroup, documentation and OSIC. Even though I work in GMT+05:30 time zone, I am flexible enough to catchup with peoples who were in US or European time-zone. I have seen lots of highs and lows of the Glance and am proud that we have not only survived but also becoming strong. During the Train cycle we have managed to release glance-store version 1.0 which supports multiple stores configuration. This is how I want to focus for Ussuri cycle 1. Multiple stores support As glance-store v1.0 is out with multiple stores configuration support, I want to make sure Glance is able maintain it's backward compatibility and doesn't break any cross-project workflow. Most of the work is already done during Train cycle but in case if any bug occurs then it will be solved on the high priority. Multiple stores will also play role in Edge computing, so if any enhancement is required then it will be handled on top priority. 2. Glance cluster awareness With Interoperable Image Import and new edge usecases, Glance cluster awareness [0] is most important feature. Even the basic implementation has started during Train cycle, we want to use this in caching operations which will be carried out during this development cycle. 3. Bridging gap between Glance and Horizon Glance has now added new features such as new import workflow, import plugins, hidden images etc. Horizon is yet to implement these in the dashboards. I am going to put some efforts in communication with horizon team and help them to understand/implement/bridge this gap. 4. Catching up with tempest Similar to horizon, Glance needs to have tempest upto-date with new image import workflow, hidden images, multiples stores scenarios. I would like to catchup with tempest team and extend a hand to bridge this gap. 5. Community priorities Whatever community goals put forward by TC, as a PTL of Glance project will want to adopt these as a priority for Ussuri cycle. 6. Other As we are very short team at this moment, I would like to put some efforts in attracting some contributors, help them to understand how Glance functions and encourage them to contribute for Glance. Looking at past how Erno and Brian has steadied the ship, I know its a big task and with their help I will do my best not to fail the expectations. Thank you for consideration, Abhishek Kekane [0] https://review.opendev.org/#/c/664956/2/specs/train/approved/glance/cluster…

1 0

[all][election][TC] Candidacy for TC
by Kendall Nelson 30 Aug '19

30 Aug '19

Hello Everyone :) I am declaring my candidacy for the TC election. Roles like PTL and TC member are incredibly important when it comes to enabling others’ success and removing roadblocks that stand between contributors (new or established) and the work they want to do. Much of the work I have done over the years has had this focus, and as an elected member of the TC I think I could have an even larger impact. A little background on me: I have been working on OpenStack since 2015 (Liberty release). I started with getting involved organizing and mentoring in the Women of OpenStack’s mentoring programs and developing Cinder before branching out to os-brick and on to other roles. Since then, I have been involved in many different projects and efforts focused on supporting the larger community. Highlights: - Onboarded over 300 global contributors as instructor at OpenStack Upstream Institute (OUI) building our contributor community in places like Brazil, Korea, and Vietnam[1] - Developed the curriculum of OUI, including the Contributor Guide[2]. - Evolved OpenStack’s various mentoring programs[3] and actively participated in them, including our community’s involvement in the Outreachy Program[4]. - Established the First Contact SIG[5]. - Coordinated the community’s ongoing migration to StoryBoard from Launchpad - Presided over 5 releases of (Pike-Train) technical elections (both PTL and TC) as an election official - Served on the Release Management, Cinder, & Infrastructure (StoryBoard) teams - Helped organize Forums, PTGs, and other in-person gatherings - Collaborated with the k8s community to improve both our community’s various onboarding programs My experience teaching Upstream Institute and running the First Contact SIG has helped me build skills that will be beneficial as a TC member, such as making connections between new contributors and existing projects or efforts. This ability to make connections and start conversations will support our community’s cross project efforts as they continue to be a challenge that I will help the TC overcome. My previous work has afforded me the opportunity to interact with almost every OpenStack project and understand how they operate differently from one another. Each project has its own culture; understanding that and how to engage with each of them is incredibly important for the Technical Committee to achieve selected community goals and other cross project efforts. As a member of the TC, I will seek to lower the barrier to entry to roles like contributor or even PTL. There is a lot of duplicate and stale information for setting up the accounts and tools needed to get started which should be cleaned up. Individual project contributor documentation[6][7] doesn’t exist for all the projects currently and would be valuable. Individual project PTL guides (similar to the Release Management process doc[8]) would also benefit our community as it would smooth the transition from one PTL to another and minimize the loss of tribal knowledge, especially when these transitions happen in the middle of a cycle. I’ve proposed this contributor documentation focus as a community goal for the U release[9]. Anything we can do to make a cohesive path for new community members to work their way to roles like PTL will ensure the health and success of our future. I love this community and all the awesome people in it, serving on the TC would be a great experience and an honor. Thank you, Kendall Review history: https://review.opendev.org/#/q/reviewer:16708,n,z Commit history: https://review.openstack.org/#/q/owner:16708,n,z Foundation Profile: https://www.openstack.org/community/members/profile/35859/ Freenode: diablo_rojo [1] https://docs.openstack.org/upstream-training/ [2] https://docs.openstack.org/contributors/ [3] https://wiki.openstack.org/wiki/Mentoring [4] https://www.outreachy.org/ [5] https://wiki.openstack.org/wiki/First_Contact_SIG [6] https://docs.openstack.org/swift/latest/development_guidelines.html [7] https://docs.openstack.org/nova/latest/contributor/index.html [8] https://releases.openstack.org/reference/process.html [9] https://etherpad.openstack.org/p/PVG-u-series-goals

2 1

[openstack-dev] [neutron] Cancelling Neutron Drivers meeting on August 30th
by Miguel Lavalle 30 Aug '19

30 Aug '19

Dear Neutrinos, It turns out that this week we still have 3 out of 5 members of the drivers team off on vacation, so we won't have quorum for the meeting again. As a consequence, I am cancelling this week once more. We will resume on September 9th at the usual time. Best regards

1 0

Re: [User-committee] UC candidacy.
by Ian Y. Choi 30 Aug '19

30 Aug '19

Hello Natal, First of all, thanks a lot for your UC candidacy! UC election is applicable for Active User Contributors (AUCs) as defined by OpenStack User Committee Charter [1], and I would like to share that both UC election officials could not verify that you are an AUC. If you can share more details which support to verify that you are an AUC who is eligible for the election, please do not hesitate to share with the election officials before the due of the nomination period. Although the election officials could not confirm that you are an eilgible candidacy for the election, I am pretty sure that you can become AUC later, and can run for next UC election(s). With many thanks, /Ian [1] https://governance.openstack.org/uc/reference/charter.html#active-user-cont… Natal Ngétal wrote on 8/26/2019 9:29 PM: > Hi, > > I saw a mail on openstack-discuss about the new user committee election. I'm > Natal I principally contribute to the tripleo part. I have also contribute a > little to oslo projects and gertty, for example. I'm really interested to > candidate for this post, that can be seems weird, because I have started to > contribute in october 2018 only. But I think that can be interesting for the > project, a new eyes. I wish to implicate me more in the community. For example, > I want to organize local meetup regularly, go to the OpenStack summit and ptg > and started to give talk and write articles on the project. I wish also meet > more the customers and work with they to improve the project. Understand the > customers problems. With this role that can be more easy. For me, that can be > also really interesting to learn more the project and the community. That can > be also really source motivation and that can help me for my work. > > My gerrit profile: > > https://review.opendev.org/#/q/owner:hobbestigrou%2540erakis.eu > > > Thanks > > _______________________________________________ > User-committee mailing list > User-committee(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee

3 3

[Openstack][Swift] : Swift file-storage allocation policy
by Sai Vishwas 29 Aug '19

29 Aug '19

Hi all, I have the following questions regarding the file allocation policy in Openstack Swift: 1. Are the uploaded files/objects mapped to partitions solely based on the name by hashing? Is there any way that I could force a particular file to reside on a particular disk? 2. How are the partitions mapped to disks? Is there any way that I could force a particular partition to reside on a particular disk? 3. Are the sizes of all partitions the same? (I am aware that a partition is a virtual concept but I am interested in whether a limit is placed on how many files are assigned to a particular partition ) I am asking the above questions as I have a few files which are accessed very frequently and would like them to reside on one of the SSDs that we have. Does OpenStack Swift internally provide this option? If not how does Swift accommodate for such SLA bound requirements without violating the concept of partitions? It would be of great help if you could explain the internal working of swift with respect to this scenario. Regards, Sai Vishwas Padigi

2 1

[release] Release countdown for week R-6, September 2-6
by Sean McGinnis 29 Aug '19

29 Aug '19

Development Focus ----------------- Work on libraries should be wrapping up, in preparation for the various library-related deadlines coming up. Now is a good time to make decisions on deferring feature work to the next development cycle in order to be able to focus on finishing already-started feature work. General Information ------------------- We are now getting close to the end of the cycle, and will be gradually freezing feature work on the various deliverables that make up the OpenStack release. This coming week is the deadline for general libraries (except client libraries): their last feature release needs to happen before "Non-client library freeze" on September 05. Only bugfixes releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/train branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/…) In the next weeks we will have deadlines for: * Client libraries (think python-*client libraries), which need to have their last feature release before "Client library freeze" (September 12) * Deliverables following a cycle-with-rc model (that would be most services), which observe a Feature freeze on that same date, September 12. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. As we are getting to the point of creating stable/train branches, this would be a good point for teams to review membership in their $project-stable-maint groups. Once the stable/train branches are cut for a repo, the ability to approve any necessary backports into those branches for train will be limited to the members of that stable team. If there are any questions about stable policy or stable team membership, please each out in the #openstack-stable channel. Finally, now is also a good time to start planning what highlights you want for your deliverables in the cycle highlights. The deadline to submit an initial version for those is set to Feature freeze on September 12. Background on cycle-highlights: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html Project Team Guide, Cycle-Highlights: https://docs.openstack.org/project-team-guide/release-management.html#cycle… knelson [at] openstack.org/diablo_rojo on IRC is available if you need help selecting or writing your highlights Upcoming Deadlines & Dates -------------------------- Non-client library freeze: September 05 (R-6 week) Client library freeze: September 12 (R-5 week) Train-3 milestone (feature freeze): September 12 (R-5 week) RC1 deadline: September 26 (R-3 week) Train final release: October 16 Forum+PTG at Shanghai summit: November 4

1 0

[neutron][election] PTL candidacy
by Slawek Kaplonski 29 Aug '19

29 Aug '19

Hi, I want to propose my candidacy for Neutron PTL. I have worked with OpenStack since the Havana release, first as a user and operator and later on as an upstream developer mostly focused on Neutron. I was appointed to the Neutron core team in the Queens cycle and joined the Neutron Drivers last September. I participated very actively and led the QoS sub-team and currently lead the project's CI group, focusing on identifying bugs and keeping our gate jobs squeaky clean. During my involvement with Neutron, I have been employed by an OpenStack operator, OVH, and one of the big distributions, Red Hat. This experience allows me to bring to the project a blend of operational and product development perspective. I think that my experience uniquely positions me to serve as an effective Neutron PTL. My priorities to focus on as a PTL are: * I would like to continue the team effort on merging the ML2/OVS+DVR solution with networking-ovn - it is quite a new initiative, described in https://review.opendev.org/#/c/658414/ which I want to continue in the next cycle. OVN backend in OpenStack scales better than Neutron’s current default solution with openvswitch agent. It already have some features which we are missing in core Neutron, like DVR based on OpenFlow, enabling DVR for OVS DPDK. OVN is also becoming more prominent backend in e.g. Kubernetes and is more and more popular with OpenStack operators. I think that we should use this momentum and finally include OVN as one of in-tree backends in Neutron, and consider it as a default at some future point. * Improve overall stability of our CI - we already did a lot of improvements in this area but I think that we must continue the effort in order to provide developers a great overall experience and the highest possible speed when working on new features. * Improve test coverage for existing features - this is very important to avoid regressions and find bugs in existing features. Stability of existing Neutron features is very important for users and operators and we, as developers should focus on this maybe even more than on providing new features. * Finish the transition to the new engine facade - it is a long standing blueprint already and we should focus to finally finish this transition and use the new engine facade everywhere in Neutron. * Improve stability of Neutron when it is running under uWSGI - since a couple of cycles ago we have the possibility to run Neutron in this way but it is not the default yet. We have some CI jobs to test Neuton in this configuration but those jobs are non-voting and quite unstable still. So I would like to make those jobs more stable and voting. I think that Miguel did a great job in the last four cycles as Neutron’s PTL and I would like to continue his work and his way of managing the team, like e.g. mentoring potential new core reviewers. I think that currently we have a pretty stable and good team, with quite enough number of cores so my goal is to keep it in good shape. Helping onboard new contributors is critical to the growth and success of our community and will be a priority during my tenure. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[PTLs] [i18n] Call for help for Project Onboarding in Shanghai
by Jimmy McArthur 29 Aug '19

29 Aug '19

Hi everyone! We'd like to suggest that PTLs/presenters of Project Onboarding find a buddy to do Chinese translation in the room in Shanghai. We're hoping some local volunteers will step up to pair with each project. I've set up an etherpad here so community members can sign up to volunteer: https://etherpad.openstack.org/p/Shanghai_Project_Onboarding_Translation PTLs, if you know someone within your project that can help, please add them to the list. Cheers, Jimmy

1 0

How to prevent adding admin-role?
by Tavasti Markku EXT 29 Aug '19

29 Aug '19

Hi! I am trying to create 'domain admin' role which has permissions to create projects and users, and manage user roles in projects within own domain. I have pretty ok working set of policies done, but there is one critical security hole: domain admin can add 'admin' role to user, and after it user has superuser privileges. Is there any possibility to limit domain admin rights to give only _member_ roles? I am working in Queens-based Redhat OSP13. Tavasti, Openstack admin For Internal Use Only

2 3

[OSSA-2019-004] Ageing time of 0 disables linuxbridge MAC learning (CVE-2019-15753)
by Jeremy Stanley 29 Aug '19

29 Aug '19

================================================================= OSSA-2019-004: Ageing time of 0 disables linuxbridge MAC learning ================================================================= :Date: August 29, 2019 :CVE: CVE-2019-15753 Affects ~~~~~~~ - Os-vif: >=1.15.0<1.15.2, 1.16.0 Description ~~~~~~~~~~~ James Denton with Rackspace reported a vulnerability in os-vif, the Nova/Neutron network integration library. A hard-coded MAC ageing time of 0 disables MAC learning in linuxbridge, forcing obligatory Ethernet flooding for non-local destinations which both impedes network performance and allows users to possibly view the content of packets for instances belonging to other tenants sharing the same network. Only deployments using the linuxbridge backend are affected. Patches ~~~~~~~ - https://review.opendev.org/678098 (Stein) - https://review.opendev.org/672834 (Train) Credits ~~~~~~~ - James Denton from Rackspace (CVE-2019-15753) References ~~~~~~~~~~ - https://launchpad.net/bugs/1837252 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15753 -- Jeremy Stanley, on behalf of the OpenStack VMT

1 0

CEPH/RDMA + Openstack
by Volodymyr Litovka 29 Aug '19

29 Aug '19

Dear colleagues, does anyone have experience using RDMA-enabled CEPH with Openstack? How stable is it? Whether all Openstack components (Nova, Cinder) works with such specific configuration of Ceph? Any issues which can affect overall system reliability? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

3 6

[blazar] No IRC meeting today
by Pierre Riteau 29 Aug '19

29 Aug '19

Hello, I won't be able to chair the biweekly Blazar IRC meeting today. The next scheduled meeting is on September 12. Cheers, Pierre

1 0

[neutron][ovn] networking-ovn plugin support for multiple remote ovsdb-server
by Zufar Dhiyaulhaq 29 Aug '19

29 Aug '19

Hi All, I have testing OpenStack (Queens Version) with OVN and works, but when I want to cluster the ovsdb-server, OpenStack stuck to create neutron object. based on my discussion in openvswitch mailing list ( https://mail.openvswitch.org/pipermail/ovs-discuss/2019-August/049175.html) my ovsdb-server clustering databases are working. Is networking-ovn support to connect to multiple ovsdb-server? something like this in ml2_conf.ini [ovn] ovn_nb_connection = tcp:10.101.101.100:6641,tcp:10.101.101.101:6641,tcp: 10.101.101.102:6641 ovn_sb_connection = tcp:10.101.101.100:6642,tcp:10.101.101.101:6642,tcp: 10.101.101.102:6642 networking-ovn-metadata-agent.ini [ovn] ovn_sb_connection = tcp:10.101.101.100:6642,tcp:10.101.101.101:6642,tcp: 10.101.101.102:6642 Below is the full step to create ovsdb-server and neutron services. - step 1: bootstrapping ovsdb-server cluster : http://paste.openstack.org/show/766812/ - step 2: creating neutron service in controller : http://paste.openstack.org/show/766464/ - step 3: creating neutron service in compute : http://paste.openstack.org/show/766465/ But when I try to create neutron resource, Its always hang (only neutron resource). This is the full logs of all nodes, contain: http://paste.openstack.org/show/766461/ - all openvswitch logs - port (via netstat) - step bootstraping ovsdb-server Neutron logs in controller0: paste.openstack.org/show/766462/ Is networking-ovn support to connect to multiple ovsdb-server? Best Regards, Zufar Dhiyaulhaq

1 0

[Mistral] PTL candidacy
by Renat Akhmerov 29 Aug '19

29 Aug '19

Hi, I'd like to announce my PTL candidacy for Mistral in U cycle. In Train, we again made a big step towards having better performance, which turned to be very important for real production use cases. Mistral “join” mechanism is now much more CPU and RAM efficient (60-70% faster for same workflows). Mistral now also provides a mechanism to plug in an alternative scheduler implementation. The new implementation of scheduler, which designed to be more scalable, is now available and being tested. For U cycle I'd like to focus on making Mistral more usable: * Consistent and well-structured documentation * Additional tools that simplify creating custom actions and functions for Mistral * Easier debugging of workflow errors * Easier and smoother installation process Some of the mentioned activities are already going on. For example, we added the workflow execution report that, when requested, shows the entire execution tree (including sub workflows). That allows to see error paths (and hence root causes) w/o having to do many copy-paste actions. It's not a secret that in the last few cycles there was a struggle with attracting more active contributors. Now, we finally have several very talanted engineers fully allocated to work on Mistral. So it makes me believe that we'll be able to solve a number of big tasks (including cool user facing goodies) that we had to put on a shelve just for the lack of resources. As usually, anybody is welcome to join our team! It's a fun project to work on. The best way to get in touch with us is IRC channel #openstack-mistral or the openstack-discuss mailing list (with [mistral] tag in email subject). Renat [1] https://review.opendev.org/#/c/679191

1 0

[neutron][ovn] networking-ovn plugin support for multiple remote ovsdb-server
by Zufar Dhiyaulhaq 29 Aug '19

29 Aug '19

[neutron][ovn] networking-ovn plugin support for multiple remote ovsdb-server Hi All, I have testing OpenStack (Queens Version) with OVN and works, but when I want to cluster the ovsdb-server, OpenStack stuck to create neutron object. based on my discussion in openvswitch mailing list ( https://mail.openvswitch.org/pipermail/ovs-discuss/2019-August/049175.html) my ovsdb-server clustering databases are working. Are networking-ovn support to connect to multiple ovsdb-server? something like this in ml2_conf.ini [ovn] ovn_nb_connection = tcp:10.101.101.100:6641,tcp:10.101.101.101:6641,tcp: 10.101.101.102:6641 ovn_sb_connection = tcp:10.101.101.100:6642,tcp:10.101.101.101:6642,tcp: 10.101.101.102:6642 networking-ovn-metadata-agent.ini [ovn] ovn_sb_connection = tcp:10.101.101.100:6642,tcp:10.101.101.101:6642,tcp: 10.101.101.102:6642 Below is the full step to create ovsdb-server and neutron services. - step 1: bootstrapping ovsdb-server cluster : http://paste.openstack.org/show/766812/ - step 2: creating neutron service in controller : http://paste.openstack.org/show/766464/ - step 3: creating neutron service in compute : http://paste.openstack.org/show/766465/ But when I try to create neutron resource, Its always hang (only neutron resource). This is the full logs of all nodes, contain: http://paste.openstack.org/show/766461/ - all openvswitch logs - port (via netstat) - step bootstraping ovsdb-server Neutron logs in controller0: paste.openstack.org/show/766462/ Are networking-ovn support to connect to multiple ovsdb-server? Best Regards, Zufar Dhiyaulhaq

1 0

[ptl][zaqar][election]WangHao's candidacy for Zaqar PTL in U cycle
by hao wang 29 Aug '19

29 Aug '19

Hi all, I would like to announce my candidacy for Zaqar PTL for U I've been PTL for Zaqar for two cycles(Rocky and Stein), I still want to serve this project in the new cycle, so there is my self-nomination: In U release, we will continue our works in: 1) Keep the Zaqar health and stable 2) Continue to support more backends for topic resource 3) Consider removing the old API code and let it more clearly. 4) Support sms subscription in Zaqar Thanks for your consideration!

1 0

[ptl][searchlight][election] Trinh Nguyen's candidacy for Searchlight PTL in U cycle
by Trinh Nguyen 29 Aug '19

29 Aug '19

Hello. I would like to announce my candidacy for Searchlight PTL for U. I've been the PTL for Searchlight for the last two cycles (Stein and Train) which I believe have been giving me enough understanding and confidence to help to maintain it for at least one more release. Even though there was not much activity of Searchlight in the Train cycle, as I surveyed people and companies around my circle, there're still needs for a centralized resource indexing service as well as multi-cloud support as we laid out [1] in the use cases and vision documents [2]. Moreover, with a simple architecture and well-defined contributing process, I strongly think Searchlight would be a good starting point for future OpenStack contributors. Therefore, Searchlight has good reasons to live one. My jobs as a PTL for Searchlight in the U cycle as I envisioned are: * Welcome and help new contributors * Help to make Searchlight work with ElasticSearch 6.x, 7.x * Finish on-going blueprints and fix bugs Thank you for your consideration. Trinh Nguyen (dangtrinhnt) [1] https://docs.openstack.org/searchlight/latest/user/usecases.html [2] https://docs.openstack.org/searchlight/latest/contributor/searchlight-visio… -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[election][ptl][magnum] PTL Candidacy
by feilong 29 Aug '19

29 Aug '19

Greeting, Over the last release, I have had the privilege and honor to serve as the PTL of Magnum. I would like to take this opportunity to express my appreciation for all your support and contribution to Magnum. And I look forward to working with you all over the next release. Therefore, I would like announce my candidacy to serve as the Magnum project team leader for the U cycle, if you will have me. In case if you don't know me, I've been working on and contributing to Magnum since Queens release as a core developer. And I have done a lot work for Magnum to help it getting production ready, e.g. the Calico network driver, nodes anti affinity, k8s health status check, Keystone auth, coreDNS autoscale, rolling upgrade, auto scaling, auto healing, private cluster, getting Magnum certified by CNCF and etc, etc. That said, I really understand the ups and downs which Magnum went through and I know the blueprints, direction and pains of this project, for interests from both private cloud and public cloud sides, which make me a good candidate for the PTL position. For U release (including the rest of Train cycle), things I'd like to do: 1. Fedora CoreOS The most matured driver for Kubernetes in Magnum is Fedora Atomic, however, the Fedora community is moving to Fedora CoreOS, so we should start to think about the migration. We have started the work but haven't finished it due to the limited resource among the team. This need to be done in Train or early of U cycle. 2. Node groups Node groups provide users with the ability to specify groups of nodes with different properties for different purposes. Within the scope of a group users are able to define labels, used image, flavor, etc depending on the purpose. We have merged part of this huge feature, but we do need to finish the rest of the work. 3. Security hardening Security is always the most important area we would like to improve for Magnum, there are still parts we need to improve to make Magnum more securer. 4. Containerize Kubernetes master This could be one of the most interesting features for Magnum and it's definitely hard work. Running Kubernetes master nodes in a seed/root Kubernetes could bring us a lot of benefits. 5. Rolling upgrade for node operating system With the big support from CERN, We have done the k8s version rolling upgrade, but we still need the rolling upgrade work for node operating system. I have already got a patch for that being reviewed now. It has been a fantastic experience working with this amazing team and I know without the dedication and hard work of everyone who has contributed to Magnum we can't get those good work done. So the PTL of this cool team is most like a facilitator, coordinator, and mentor. I would be pleased to serve as PTL for Magnum for the U cycle and I'd appreciate your vote. Thanks for your consideration! -- Cheers & Best regards, Feilong Wang (王飞龙) ------------------------------------------------------ Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington ------------------------------------------------------

1 0

[all] [tc] [osc] [glance] [train] [ptls] Legacy client CLI to OSC review 639376
by Alexandra Settle 29 Aug '19

29 Aug '19

Hi all, For the Train cycle Artem Goncharov proposed moving the legacy client CLIs to OSC. This goal did not move forward due to a broad range of concerns and was eventually -1'd by Erno Kuvaja (Glance PTL) as he was unable to support it from a Glance point of view. Moving forward, I'd like to end the discussion in the review [1] by abandoning the patch and move this to the mailing list. The following looks like it needs to happen: 1. This PR should be abandoned. It is not going to be accepted as a commmunity goal in this format and the debate within the comments is circular. Let's step out of here, and start having conversation elsewhere. 2. To start those conversations, a pop-up team would be a suitable alternative to begin driving that work. Someone needs to step forward to lead the pop-up team. The TC recommends two individuals step forwards as indicated in the pop-up team Governance document [2]. 3. I recommend the pop-up team include Erno Kuvaja or a representative from the Glance team and including Matt Reidemann (who has been working to close the compute API gaps). 4. The leaders must then identify a clear objective, and a clear disband criteria. If in case the pop-up team decide that this could be better drafted as a community goal for U, then that is a suitable alternative that can be defined using the new goal selection criteria that is being defined here [3] But this should not be decided before clear objectives are defined. Thanks, Alex IRC: asettle [1] https://review.opendev.org/#/c/639376/ [2] https://governance.openstack.org/tc/reference/popup-teams.html [3] https://review.opendev.org/#/c/667932/

8 10

[ptl][tripleo][election] PTL Candidacy
by Wesley Hayutin 29 Aug '19

29 Aug '19

Greetings, I would like to nominate myself for the TripleO PTL role for the U cycle. I have been working closely with several previous PTL's like Alex, Emilien and Juan Osorio and I am hoping to contribute back to the community as a PTL while following their excellent example. I would like to see Tripleo continue focusing on simplification and improving the user experience. Specifically continue the path set in previous TripleO cycles. - Push forward with tripleo-ansible and the transformation squad. - Work with the newly formed ansible sig group. - Help continue to simplify the stack of components where possible. - Help with new features like the undercloud minion node. - Continue to support the wider adoption of the Tripleo Single Node deployment as a development and test tool. - Continue the great work being done to clean up logging and error handling to improve operators ability to troubleshoot their installations. Thank you for the opportunity! Thanks, Wes Hayutin irc: weshay

1 0

[tripleo] TripleO CI Summary: Sprint 35
by Rafael Folco 28 Aug '19

28 Aug '19

Greetings, The TripleO CI team has just completed Sprint 35 / Unified Sprint 14 (Aug 08 thru Aug 28). The following is a summary of completed work during this sprint cycle: - Completed testing on the RHEL8 OVB featureset 001 job and added it to the periodic pipeline. - Added RHEL8 scenario{1-4} jobs to the periodic pipeline as non-voting. - Completed the design for staging environment as a zuul job for testing changes in the promoter server and also prepare for the multi-arch builds. - Created a staging promoter job and started implementing functional tests on molecule for the staging environment setup. - Completed a PoC for multi-arch container builds with tagging and manifests approach. The change [3] on build-containers role that introduces arch aware tagging is still under review. - Promotion status: green on all branches for most of the sprint cycle. - Removed Fedora and Pike jobs everywhere. - Bumped ansible to version 2.8 across tripleo ci jobs. The planned work for the next sprint [1] are: - Address issues for scenario{1-4} jobs for RHEL8 in the periodic pipeline and get jobs to green status. - Merge multi-arch container tagging support and change the promoter code to push manifests with annotated metadata for architecture in addition to the arch tagged containers strategy. - Implement the staging promoter job for testing changes in the promotion workflow. - Create functional test cases for the staging promoter setup using molecule. - Design a staging promotion workflow to emulate promotions using mock containers and test servers. The Ruck and Rover for this sprint are Gabriele Cerami (panda) and Sagi Shnaidman (sshnaidm). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes are being tracked in etherpad [2]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-15 [2] https://etherpad.openstack.org/p/ruckroversprint15 [3] https://review.opendev.org/#/c/663977/

1 0