March 2019 - openstack-discuss - lists.openstack.org

[all][ptl][tc] Missing PTL nominations for 31 more teams
by Jeremy Stanley 11 Mar '19

11 Mar '19

A quick reminder that we're still missing "Train" cycle PTL candidate nominations for nearly half our official teams: Adjutant Blazar Chef OpenStack Cinder Congress Designate Glance Heat Horizon I18n Ironic Magnum Manila Mistral Monasca Neutron Octavia OpenStack Helm PowerVMStackers Puppet OpenStack Qinling Rally Storlets Tacker Telemetry Tricircle Tripleo Trove Vitrage Zaqar Zun This means that with approximately 2 days left, 31 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [1]. (Any open reviews[2] have not been factored into these stats.) If you want to stand for PTL, don't delay, follow the instructions at [3] 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. Thank you, [1] https://governance.openstack.org/resolutions/20141128-elections-process-for… [2] https://review.openstack.org/#/q/is:open+project:openstack/election [3] https://governance.openstack.org/election/#how-to-submit-a-candidacy -- Jeremy Stanley

3 3

[tripleo] Nova HWMachineType settings
by Wesley Hayutin 11 Mar '19

11 Mar '19

Greetings, As we started to bootstrap f28 standalone jobs we noticed basic tempest tests were failing because the libvirt on f28 did not support the default "x86_64=pc-i440fx-rhel7.6.0" [5] Kashyap recommend switch to q35 [1]. So we can change to q35 maybe globally in puppet [2] if Juan, Alex and Emilien approve. Alternatively we can isolate the deployment in question w/ [3],[4] I should restart this thread in openstack-dev[tripleo] for greater transparency. Thanks Any comments on how to proceed? We need to enable f28 jobs in the next few days, so [2] may need to be the short term answer until we get feedback. [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-be… [2] https://review.openstack.org/#/c/642443/ [3] https://review.openstack.org/#/c/642517/ switch to "pc" [4] https://review.openstack.org/#/c/642547 switch to "q35" [5] http://logs.rdoproject.org/openstack-periodic/git.openstack.org/openstack-i…

1 0

[tc][all][sdk] Devs and feedback needed for 'Project Resource Cleanup' goal for Train cycle
by Adrian Turjak 11 Mar '19

11 Mar '19

Hello OpenStackers! As has been mentioned a few times on the mailing list, one of the current community goal proposals is a new library/tool for cleaning up all the resources for a given project in an OpenStack cloud. For a long time we've lacked something like this, and it has made cleaning up a project and deleting it a pain, specifically because of the various dependencies around resources. The goal is now up for review: https://review.openstack.org/#/c/639010 The discussion right now is around the version originally proposed and discussed at the last Summit, a plugin based solution with a central library. We are also looking at an alternative which would be a single library like the SDK, or potentially even including the deletion login in the SDK itself, and the CLI part in the OpenStackClient. In all likelihood the single library approach will end up chosen, and I'll have a new written version of the goal up soon for that. If you have feedback against that you should voice it now! Are there any arguments for or against a plugin based solution we haven't heard yet? Additionally we would like feedback (specifically from the SDK team) if they think we should keep this as a standalone library that uses the SDK, or make it part of the SDK. We also need additional developers willing to contribute their time to this goal. Ideally we want every service to have some say in the code to clean up their resources, so I would highly suggest each new PTL works with their team to see who wants to help us make sure they are represented in this goal. Let's actually make this goal a reality! Put your hand up for wanting to contribute review time, and code! Cheers, Adrian

3 2

[tc] weekly update
by Mohammed Naser 11 Mar '19

11 Mar '19

Hi everyone: Just wanted to keep everyone up to date on what's going on in the TC over the past week briefly, this is meant to be a quick digested update that can (and should!) spark up some conversation, so please feel free to ask questions or bring in ideas # Python 3 The TC met and discussed last week about finalizing everything regarding Python 3. This happened over an ad-hoc meeting which you can follow the minutes here alongside the action items that came out of it - http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-… # Cycle goals There has also been work done from Lance and Jean-Philippe regarding the cycle goals, input from projects would be really useful, please have a look at them here: - https://review.openstack.org/#/c/639376/ Add Move legacy client CLIs to OSC goal to Train - https://review.openstack.org/#/c/639010/ Add Project Deletion goal for Train # Business value of help most needed Lance has put in a lot of work and effort in terms of moving our help most needed document to something that explains business value, reviews are up: - https://review.openstack.org/#/c/641790/ Elaborate on the business value of Designate - https://review.openstack.org/#/c/641773/ Elaborate on the business value of goal champions - https://review.openstack.org/#/c/641750/ Elaborate on the business value of documentation owners - https://review.openstack.org/#/c/641890/ Elaborate on the business value of infra admins - https://review.openstack.org/#/c/641784/ Elaborate on the business value of Glance # Goal closure updates Matt has pushed up a change discussing what to be done "at the end of a goal" which is currently up for discussion: - https://review.openstack.org/#/c/641507/ Document goal closure # Other Thanks to Doug once again for serving as chair for the past few cycles. The PTG is coming up and we're excited to see all the community again to build Train, without the train background noise :) Thanks, 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

[tc] selecting a vice chair
by Mohammed Naser 11 Mar '19

11 Mar '19

Hi everyone: Thanks for having me serve as chair for the upcoming session. As part of my duties getting started is appointing a vice chair[1]. I'd like to invite those who would like to run for vice chair to personally contact me, as I think it's a great way to ease into the TC workflow and learning more about the inner workings of how we (try?!) to keep things moving. I'll be assigning someone by Tuesday, so I just wanted to extend this for those who wanted to run to contact me. :) Thanks, Mohammed [1]: https://governance.openstack.org/tc/reference/charter.html#tc-chair -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 1

[horizon][plugins][vitrage][heat][ironic][manila] Integration tests on gates
by Ivan Kolodyazhny 11 Mar '19

11 Mar '19

Hi team, A few weeks ago we enabled horizon-integration-tests job[1]. It's a set of selenium-based test cases to verify that Horizon works as expected from the user's perspective. Like any new job, it's added in a non-voting mode for now. During the PTG, I'd got several conversations with project teams that it would be good to have such tests in each plugin to verify that plugin works correctly with a current Horizon version. We've got about 30 plugins in the Plugin Registry [2]. Honestly, without any kind of testing in most of the plugins, we can't be sure that they work well with a current version of Horizon. That's why we decided to implement some kind of smoke tests for plugins based on Horizon integration tests framework. These tests should verify that a plugin is installed and pages could be opened in a browser. We will run these tests on the experimental queue and/or on some schedule on Horizon gates to verify that plugins are maintained and working properly. My idea is to have such a list of 'tested' plugins, so we can add 'Maintained' label to the Plugin Registry. Once these jobs become voting, we can add a label 'Verified'. I think such a schedule looks reasonable: * Stein-Train release cycles - add non-voting jobs for each maintained plugin and introduce "Maintained" label * Train-U release cycles - makes stable jobs voting and introduce "Verified" label in the Horizon Plugin registry I do understand that some teams don't have enough resources to maintain integration tests, so I'm stepping as a volunteer to introduce such tests and jobs for the project. I already published patches for Vitrage and Heat [3] plugins and will do the same for Ironic and Manila dashboards in a short time. Any help or feedback is welcome:). [1] https://review.openstack.org/#/c/580469/ [2] https://docs.openstack.org/horizon/latest/install/plugin-registry.html [3] https://review.openstack.org/#/q/topic:horizon-integration-tests+(status:op… Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

3 3

Firmware Update (cleaning step) issues
by Martin Sysadmin 11 Mar '19

11 Mar '19

Hi all I wondered if anybody had managed to update ILO firmware via openstack cleaning step? Details: openstack triple-o / RDO containerised deployment (ironic_conductor etc is a Docker container on the under cloud) I have constructed a JSON file with the contents as follows: [ { "interface": "management", "step": "update_firmware", "args": { "firmware_update_mode": "ilo", "firmware_images":[ { "url": "https://.../..../CP0xyz.scexe", "checksum": "<checksum_value>", "component": "ilo" } ] } } ] which I then initiate a clean step test using following: openstack baremetal node clean --clean-steps fw_update_test.json mytestnode.test.local and this fails with the error "Clean step update_firmware *failed* on node <<node_uid>> with the error: Unable to update firmware" when looking in /var/log/containers/ironic/ironic-conductor.log I have tested this myself by importing proliantutils into my own test Python script, it doesn't matter what URL I provide it fails with the error above. Has anyone managed to get this step working at all? I have also tried with unpacked image (.bin file) and the same error. Would appreciate any tips Thanks

2 2

[ptl][election][horizon] PTL candidacy
by Ivan Kolodyazhny 11 Mar '19

11 Mar '19

Hi, I would like to announce my candidacy for PTL of Horizon for Train release. I served this role during the last two releases and I still feel strong enough to do this role during the next six months. We did a good job as a team during the Stein release cycle: enabled integration tests both for Horizon and several plugins created a good list of priorities and TODOs to fix our huge feature gaps between UI and command-line clients and started work on them, so you can find a few more useful features in our release notes. During the Train cycle, I’m going to continue these efforts: * Add integration tests for all maintained plugins so we can be sure that we’ve got a verified list of working Horizon plugins. * Involve project teams in Horizon: even such contributions like feature requests are extremely important to understand what should we do to make cloud users and operators happier * We missed few community goals in the past and I’ll do my best to fix it in Train release. * Last, but not least, I’ll be happy to help new contributors to be a part of Horizon team. I hope you’ll give me a chance to wear a PTL hat for Train and help me with all these efforts. Thank you, Ivan Kolodyazhny (e0ne)

1 0

[ptl][manila][election] Tom Barron manila PTL candidacy
by Tom Barron 11 Mar '19

11 Mar '19

All, I served as Manila PTL for Rocky and Stein and am willing and able to take on that role in Train if you choose me. I continue to be less interested in adding new features to Manila itself than in improving its durability, ease of use, and consumability. I will continue to get the message out that Manila is loosely coupled with other OpenStack components and serves up storage via the network rather than through hypervisors so that it is ideally positioned to provide shared file storage both within and outside of OpenStack proper. I will work to make sure that storage vendors understand that if they maintain drivers for their back ends in Manila then this will at the same time enable them to provide storage for OpenStack consumers and also for Container Orchestrator clouds. I will continue to champion development of "**production quality**" 100% open source storage back ends for Manila. We have done a good job fostering new contributors and helping outreachy intern applicants get started. I want us to continue to be known as a friendly project and a good place to work. In Train we need to complete work already begun to: * build a manila CSI plugin * integrate manila into the OpenStack Client and SDK * integrate manila into OpenStack ansible and extend TripleO coverage to more storage back ends. In addition, in the Train cycle I want the Manila project to take up the challenge of shared storage as a service at the Edge. We need to: * Articulate use cases for shared storage (vs block or object) at the Edge. * Drive common understanding of appropriate service architecture for Edge. * Position vendors and open source software defined back ends for Edge deployments using Manila. These are the things that will drive me if you choose me as manila PTL. Thanks for listening, -- Tom Barron (tbarron)

1 0

[designate][election][ptl] PTL Candidacy
by Graham Hayes 11 Mar '19

11 Mar '19

Hi All, I would like to announce my candidacy for PTL of Designate for the Train cycle. I have been PTL for Mitaka, Newton, Ocata, Queens, Rocky, Stein (and hopefully Train), and have been a core for longer. I have been part of teams that ran Designate in production in public clouds, and also shipped products based on it. I feel that this gives a great viewpoint for where we should go. That said, leadership turn over is healthy, and is required to ensure that a project does not get stale, and in Designate we have been very bad at ensuring there is a good turn over (Designate has had 3 PTLs in its existance, 2 of which were originally from Managed I.T. - the company that founded it). As a result, Train will be my last cycle as PTL (if you see fit to elect me). My cycle goals will be to ensure a clean handover to the next PTL - writing down roadmaps, documenting what I do as PTL, and guiding anyone who is interested in taking on the role. While DNS is not something that is traditionally on a hype curve, we have had solid growth over the years, and the software we write is deployed in some of the largest OpenStack users. It is an important part of the Datacentre as a Service space, and we should be proud of it, and help promote its use where it fits. Thank you for taking the time to read this, and thank you for your support. - Graham (mugsie)

1 0