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

[nova][dev] Stein blueprint burndown chart
by melanie witt 26 Mar '19

26 Mar '19

Hey all, We have just wrapped up RC1 and I have a burndown chart [1] of blueprints [2] for the Stein cycle to share. I sent a similar email after we released Rocky last cycle [3]. I generated data for this chart throughout the cycle using a script I have proposed to add to the nova-specs repo [4]. Comparing final numbers to Rocky -------------------------------- Max approved for Rocky: 72 Max approved for Stein: 49 Final completed for Rocky: 59 Final completed for Stein: 29 Our completion percentage of approved blueprints in Rocky was 81.9% and in Stein it was 59.2%. We had a significant drop in completion percentage from last cycle. We approved many more blueprints than we completed. Comparing the release note prelude from Rocky [5] to Stein [6], I think we had an increase in larger and more complex user-impacting features implemented this cycle than last cycle. Throughout the cycle, we also had the placement extraction happening, which was a substantial amount of work not represented by a blueprint. Finally, many of the approved blueprints which were not completed were also larger and more complex features (NUMA-aware live migration, SRIOV live migration, cross-cell resize, detach/attach of root volume, just to name a few). I think we completed an impressive amount of work this cycle and I'm proud of how many user-impacting features we released. Cheers, -melanie [1] https://docs.google.com/spreadsheets/d/e/2PACX-1vTDpcoCN_Q2jVBxlH9LgHY_wsI4… [2] https://blueprints.launchpad.net/nova/stein [3] http://lists.openstack.org/pipermail/openstack-dev/2018-August/133342.html [4] https://review.openstack.org/581914 [5] https://docs.openstack.org/releasenotes/nova/rocky.html#prelude [6] https://docs.openstack.org/releasenotes/nova/stein.html#prelude

2 1

[openstack-ansible] proposing Dmitriy Rabotjagov (noonedeadpunk) as core
by Mohammed Naser 26 Mar '19

26 Mar '19

Hi everyone, Dmitriy has done an excellent amount of work in the past few cycles in helping maintaining our roles, both around patches inside our roles and providing excellent and detailed reviews as well. I'd like to propose to add him to our core members! Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

9 10

[neutron] Bug deputy report for the week of March 18th
by Miguel Lavalle 26 Mar '19

26 Mar '19

Critical: https://bugs.launchpad.net/neutron/+bug/1821384 Customization of ubuntu image fails before upload to devstack. Proposed fix: https://review.openstack.org/645883 Medium: https://bugs.launchpad.net/neutron/+bug/1821137 neutron_tempest_plugin.api test_show_network_segment_range fails Need further triaging: https://bugs.launchpad.net/neutron/+bug/1821299 Associating Floating IP with a port can result in duplicate Floating IPs, due to the original FIP not being removed from the SNAT namespace https://bugs.launchpad.net/neutron/+bug/1821357 VRRP vip on VM not reachable from other network on DVR setup RFEs https://bugs.launchpad.net/neutron/+bug/1821058 [RFE] Port binding event extended information for Nova https://bugs.launchpad.net/neutron/+bug/1821208 [RFE] Only enforce policy when selected option does not match default Incomplete: https://bugs.launchpad.net/neutron/+bug/1820827 neutron-vpnaas :ipsec site connection pending create https://bugs.launchpad.net/neutron/+bug/1821203 DVR: When a subnet is removed from a router the qrouter namespaces aren't removed from the compute nodes https://bugs.launchpad.net/neutron/+bug/1821016 Race on reboot, fault on spawning sriov instance after reboot. Ocata https://bugs.launchpad.net/neutron/+bug/1821567 network_segment_ranges could not load in tricirlce test

1 0

[oslo][requirements][release] oslo.db lower-constraints job broken
by Ben Nemec 25 Mar '19

25 Mar '19

Hi, Our stable/stein patches in oslo.db are currently failing the lower-constraints job due to [0]. I assume master has the same problem since there haven't been any changes since branching. It looks like the problem is that psycopg2 < 2.7 doesn't work with postgresql 10, and we're getting 10 now on bionic. The simple solution is to bump the lower-constraint, but I'm not sure how that's going to work for the stable branch since we can't change requirements there. How do we proceed? Thanks. -Ben 0: https://bugs.launchpad.net/oslo.db/+bug/1821400

4 11

[placement] [translation] translating exceptions
by Chris Dent 25 Mar '19

25 Mar '19

In placement we've been experimenting with removing oslo_versionedobjects. There's neither RPC nor rolling upgrades in placement so it is effectively overkill and the experiment has revealed that removing it also improves performance. The removal of OVO allows us to remove a lot of transitive dependencies. See https://review.openstack.org/#/c/636807/ where the lower-constraints.txt file is updated to reflect the changes. After those changes the biggest single package remaining in the test virtualenvs is Babel (included via oslo.i18n), weighing in at a mighty 26M. Placement is currently set to enable translation of exception messages, especially those that will end up in API responses. It has no other UI to speak of, so we've begun to wonder about getting rid of translation entirely. I asked about this in the TC office hours[1], which generated some useful but not entirely conclusive discussion. One way to summarize that discussion is that it might be okay to not translate the error messages, because it is unlikely they will be a priority for translators who are more oriented towards docs and UI, and that since no translation has yet happened, if there were ever going to be a time to turn off translation, now would be the time. It is additionally okay because placement is striving to follow the errors guideline [2] and use error.code in error responses, which exist at least in part to make googling for "what do I do when I get this error" a bit easier. That desire to google is also a good reason to keep the error responses in one language. However: We shouldn't do this if people need or want the error responses to be translated. Thus this message. Do people have opinions on this? Is it okay to not translate error responses in an API-only service like placement? Thanks. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019… [2] https://specs.openstack.org/openstack/api-wg/guidelines/errors.html -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

5 7

qinling-dashboard 1.0.0.0rc1 (stein)
by no-reply＠openstack.org 25 Mar '19

25 Mar '19

Hello everyone, A new release candidate for qinling-dashboard for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/qinling-dashboard/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/qinling-dashboard/log/?h=stable/st… Release notes for qinling-dashboard can be found at: https://docs.openstack.org/releasenotes/qinling-dashboard/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/qinling-dashboard and tag it *stein-rc-potential* to bring it to the qinling-dashboard release crew's attention.

1 0

[searchlight] Today meeting's cancelled
by Trinh Nguyen 25 Mar '19

25 Mar '19

Hi team, Since all of the active members are busy today, I will cancel the team meeting. Ping me on the #openstack-searchlight channel if you need any help. Cheers, Trinh

1 0

[placement][nova] placement cores adjustment
by Chris Dent 25 Mar '19

25 Mar '19

The placement cores were established by basing off the nova-cores and then adding me and Tetsuro. As we approach the end of the cycle, I'd like to change the nova-cores inclusion to a list of actual people. In the process it seems wise to only include those people who are actively interested in regularly reviewing placement projects (which includes placement itself, osc-placement, os-traits, and os-resource-classes). To that end, could any nova-core that would like to continue as a placement-core please contact me privately (IRC or email is fine) to let me know. If you're not interested in regularly reviewing in placement, you don't need to do anything. Thanks for your help and support thus far. If you have time in the future to start reviewing placement projects, great, we'll happily welcome you back. If you are interested, please contact me so I can make the list complete. A few weeks after the new list of placement cores has been set, we'll review the statistics to see if there are any likely candidates for new +2ers. Thanks. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 1

[dev] [all] [ptl] Migrating legacy jobs to Bionic (Ubuntu LTS 18.04)
by Ghanshyam Mann 25 Mar '19

25 Mar '19

Hi Everyone, During Dec/Jan month, we have migrated the devstack jobs (zuulv3 native jobs) from Xenial to Bionic. [1]. But that did not move all gate job to Bionic as there are a large number of jobs are still the legacy job. All the legacy job still use Xenial as nodeset. As per the decided runtime for Stein, we need to test everything on OpenStack CI/CD on Bionic - https://governance.openstack.org/tc/reference/runtimes/stein.html This is something we discussed TC meeting as one of the Stein items to finish in openstack community[2]. I am starting this ML thread to coordinate the work to move all the legacy jobs to Bionic. I have created the Etherpad to include more details and status check for each project gate- https://etherpad.openstack.org/p/legacy-job-bionic The approach is the same as we did for previous migration for devstack jobs. 1. Push patch which migrates the legacy base jobs to bionic - 1. https://review.openstack.org/#/c/639096/ 2. Each Project team, add the testing patch with Depends-on on base patch (example 639096) and confirm the status of their gate on etherpad - Example: https://review.openstack.org/#/c/639017 3. Project jobs not using base job as parent, need to migrate their legacy job to bionic by own. Please add yourself as your project volunteer in etherpad and update the status accordingly. I am tagging [ptl] in this thread so that they can assign someone from their team if no volunteer. Deadline: 1st April to merge the base legacy job to bionic. That gives around 1 month to test the jobs which I feel enough for each project. let me know if more time is needed, we can adjust the same. The goal is to finish this activity before Stein release. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000837… https://etherpad.openstack.org/p/devstack-bionic [2] http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-02-07-14.00.html -gmann

10 21

neutron 14.0.0.0rc1 (stein)
by no-reply＠openstack.org 25 Mar '19

25 Mar '19

Hello everyone, A new release candidate for neutron for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/neutron/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/neutron/log/?h=stable/stein Release notes for neutron can be found at: https://docs.openstack.org/releasenotes/neutron/

1 0