September 2020 - openstack-discuss

[openstack][manila] GenericShareDriver on stein
by Ignazio Cassano 25 Sep '20

25 Sep '20

Hello Stackers, I am testing manila manila.share.drivers.generic.GenericShareDriver with manila.share.drivers.generic.GenericShareDriver. I created in my project an instance with nfs server and it is up and running. In my manila.conf I have specified the instance id, use and password: [locale] share_driver = manila.share.drivers.generic.GenericShareDriver driver_handles_share_servers = false share_backend_name= locale service_instance_user = manila service_instance_passwod = manila service_instance_name_or_id = 5b0fa246-e94b-4a84-b730-7066dfb31fb0 path_to_private_key=~/.ssh/id_rsa path_to_public_key=~/.ssh/id_rsa.pub I have also other backend with netapp drivers and they works fine. The generic drivers reports: 2020-09-25 13:56:13.955 4097174 WARNING manila.share.drivers.generic [req-f0a5294a-3ef2-4226-9fc9-f3b4f35c53f5 - - - - -] Waiting for the common service VM to become available. Driver is currently uninitialized. Share server: None Retry interval: 5 2020-09-25 13:56:14.143 4097174 ERROR manila.share.drivers.generic [req-f0a5294a-3ef2-4226-9fc9-f3b4f35c53f5 - - - - -] string indices must be integers 2020-09-25 13:56:19.144 4097174 WARNING manila.share.drivers.generic [req-f0a5294a-3ef2-4226-9fc9-f3b4f35c53f5 - - - - -] Waiting for the common service VM to become available. Driver is currently uninitialized. Share server: None Retry interval: 5 2020-09-25 13:56:19.340 4097174 ERROR manila.share.drivers.generic [req-f0a5294a-3ef2-4226-9fc9-f3b4f35c53f5 - - - - -] string indices must be integers Seems the instance I created is not available. Please, any help? Ignazio

2 2

[election][Kuryr] PTL candidacy for Wallaby
by Maysa De Macedo Souza 25 Sep '20

25 Sep '20

Hello, I would like to propose my candidacy to be the PTL of Kuryr for the Wallaby cycle. I have been a contributor to Kuryr since the Queens release and was appointed to the Kuryr core team in the Ussuri cycle. I see the following goals for the Kuryr project during the Wallaby cycle: * Improve stability and extend CI: we already included great improvements in our CI, but I believe we must continuously work on it to provide better and quicker feedback when developing new features. As part of that, we should start graduating experimental jobs like the ones using OVN-Octavia driver and Network Policy, and handle issues with jobs requiring more swap. * Address testing gaps for new and existing features: this would avoid regressions and find bugs. Also, improves stability. * Continue extending and improving Kuryr functionalities, such as dual stack, SCTP support and CRDs usage. * Grow the contributor base. I would like to contribute back to the community as a PTL while following great examples of previous PTLs. Thank you, Maysa.

1 0

[rpm-packaging] Proposing Hervé Beraud as new core reviewer
by Javier Pena 25 Sep '20

25 Sep '20

Hi, I would like to propose Hervé Beraud as a new core reviewer for the rpm-packaging project. Hervé has been providing consistently good reviews over the last few months, and I think he would be a great addition to the core reviewer team. Existing cores, please vote on the thread! Regards, Javier Peña

3 3

[tc] monthly meeting
by Mohammed Naser 25 Sep '20

25 Sep '20

Hi everyone, Our monthly TC meeting is scheduled for next Thursday, October 1st, at 1400 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, September 30th, at 1900 UTC. Thank you, Regards, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[tripleo] PTL candidacy for Wallaby
by Marios Andreou 25 Sep '20

25 Sep '20

I would like to nominate myself for the TripleO PTL role for the Wallaby cycle. I think it is obvious that the role of the PTL has changed significantly compared to the early days of TripleO. Most importantly we are (and have been for a while) now organised into self-contained topic squads (deployment, validations, upgrades, networking, storage, ci, etc). Typically technical decisions are driven exclusively within those squads (even if they are done 'in the open' on gerrit and launchpad and opendev-discuss). The role of the PTL then is more about coordination across the squads, ensuring we deliver release targets, keeping bug backlogs in order and facilitating the resolution of any conflicts that arise. I have worked on TripleO since before the Kilo release and have collaborated with many current and past members of the community including engineers and also users/operators. My contributions thus far have been in code/docs/bugs, originally working on upgrades and more recently working on CI. I haven't had the opportunity to work on the 'admin' side of TripleO (besides in the past cutting the occasional release). I am thus especially excited by the prospect of contributing in this new way as PTL, if TripleO will have me! I sincerely promise to give it my best and I am sure that together with the kind help of the current PTL Wes Hayutin we will have a smooth Wallaby cycle, meeting our responsibilities to the foundation and the community. There is (as ever!) a lot of exciting work coming in the Victoria release and continuing in Wallaby including the continued exploration of the removal of Heat as our configuration engine, the new validations repos and framework, the new container builds process, Fast Forward Upgrades II (back with a vengeance), ci component and dependency pipelines, ci parent/child jobs, and I'm sure many more that we will discuss at the coming Wallaby PTG. Two areas I would like to focus on as PTL should you give me the opportunity are: - improve our current documentation/deployment guides - at minimum they must be updated to recent releases and there are many items missing. I am hoping to rally support from the various squads for this. - improve visibility into the various TripleO squads - this may mean re-instating a 'new' weekly/bi-weekly (or other frequency) tripleo meeting or by some new way of collaborating. Again this is really dependent on support from the tripleo community. thank you for your consideration!

1 0

[Neutron] Not create .2 port
by Tony Liu 24 Sep '20

24 Sep '20

Hi, When create a subnet, by default, the first address is the gateway and Neutron also allocates an address for serving DHCP and DNS. Is there any way to NOT create such port when creating subnet? Thanks! Tony

3 4

[election][neutron] PTL candidacy for Wallaby
by Slawek Kaplonski 24 Sep '20

24 Sep '20

Hi, I want to propose my candidacy and continue serving as Neutron PTL in the Wallaby cycle. In the Victoria cycle I proposed a couple of major goals. We achieved most of them, like for example: * add support for metadata over IPv6 in Neutron, * continue adoption of the OVN driver as one of the in-tree Neutron drivers. * find new maintainers for the networking-midonet project so we keep it the * Neutron stadium. In the upcoming cycle I would like to continue work which we started already and focus mostly on: * implement old, unfinished Blueprints like adoption of new engine facade, * continue adoption of the OVN backend in Neutron, closing more feature parity * gaps * switch the OVN driver to be the default backend in Devstack, In addition to the goals mentioned above mentioned, I want to continue work to improve our CI stability and coverage. It is my continuing desire to do my best to help our outstanding team to deliver better software and to grow. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[neutron] Drivers meeting agenda - 25.09.2020
by Slawek Kaplonski 24 Sep '20

24 Sep '20

Hi, For tomorrows drivers meeting we again don't have any new RFEs to discuss but I wanted to use this meeting to quickly discuss about 1 bug: https://bugs.launchpad.net/neutron/+bug/1895933 So see You on tomorrows meeting :) -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[all][election][TC] Candidacy
by Kendall Nelson 24 Sep '20

24 Sep '20

Hello Everyone! I am once again declaring my candidacy for the Technical Committee. This last year I have learned so much about OpenStack and our amazing community. There is never a shortage of work to be done and I feel there is still a lot I can do to help the community as a part of the TC. I served as TC Vice Chair during the second half of my term and I felt like I was able to do a lot to help support Mohammed, the chair and other members of the TC. My work in coordinating the new office hours and our time at the upcoming PTG will enable the future TC to be more accessible and productive. I also lead the community goal to improve the onboarding documentation, further lowering the barrier for new contributors. If elected, I will continue bridging our community with the kubernetes community. I am actively facilitating the conversations between the TC and the k8s Technical Steering Committee at the upcoming PTG meetings to share insight between both of our communities and generally share knowledge about keeping open source communities healthy. I would also like to take a more active role in pushing the unification of the community around a single CLI to simplify openstack operations to better support our users and lessen the load on developers. I think a good first step would be to work with the CLI/SDK team to build a list of items that are blocking project teams from fully implementing all their features in the openstack client. From there we can figure out what is missing from the list, which teams are affected by which blocking items and prioritize what needs to be worked on first. Thank you for your time and consideration. As I said in my platform last year, I love this community and all the awesome people in it, serving on the TC is a great experience and an honor. -Kendall Nelson (diablo_rojo)

1 0

[ironic] Recovering IPMI-type baremetal nodes in 'error' state
by Paul Browne 24 Sep '20

24 Sep '20

Hello all, I have a handful of baremetal nodes enrolled in Ironic that use the IPMI hardware type, whose motherboards were recently replaced in a hardware recall by the vendor. After the replacement, the BMC IPMI-over-LAN feature was accidentally left disabled on the nodes, and future attempts to control them with Ironic has put these nodes into the ERROR provisioning state. The IPMI-over-LAN feature on the boards has been enabled again as expected, but is there now any easy way to get the BM nodes back out of that ERROR state, without first deleting and re-enrolling them? -- ******************* Paul Browne Research Computing Platforms University Information Services Roger Needham Building JJ Thompson Avenue University of Cambridge Cambridge United Kingdom E-Mail: pfb29(a)cam.ac.uk Tel: 0044-1223-746548 *******************

2 3