September 2019 - openstack-discuss

trove 12.0.0.0rc1 (train)
by no-reply＠openstack.org 25 Sep '19

25 Sep '19

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

1 0

qinling-dashboard 2.0.0.0rc1 (train)
by no-reply＠openstack.org 25 Sep '19

25 Sep '19

Hello everyone, A new release candidate for qinling-dashboard for the end of the Train 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 Train release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/train release branch at: https://opendev.org/openstack/qinling-dashboard/log/?h=stable/train 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://storyboard.openstack.org/#!/project/1050 and tag it *train-rc-potential* to bring it to the qinling-dashboard release crew's attention.

1 0

qinling 3.0.0.0rc1 (train)
by no-reply＠openstack.org 25 Sep '19

25 Sep '19

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

1 0

[tripleo] deploying tripleo on centos8
by Emilien Macchi 24 Sep '19

24 Sep '19

As you probably know, CentOS8 was published today and the TripleO team will use this platform in the CI very soon. Today I spent a bit of time trying to deploy an undercloud on centos8 and I had some issues, and I wanted to share them in case some other folks do testing as well: https://etherpad.openstack.org/p/tripleo-centos8 Note that this is really early stage testing, and some work will have to happen on the packaging side mainly. Feel free to contribute, -- Emilien Macchi

1 0

[Watcher] no irc meeting today
by li.canwei2＠zte.com.cn 24 Sep '19

24 Sep '19

Hi, Watcher irc meeting will be cancelled because I'm no time today. Thanks, licanwei

1 0

[nova] The test of NUMA aware live migration
by wang.ya 24 Sep '19

24 Sep '19

Hi: The main code of NUMA aware live migration was merged. I’m testing it recently. If only set NUMA property(‘hw:numa_nodes’, ‘hw:numa_cpus’, ‘hw:numa_mem’), it works well. But if add the property “hw:cpu_policy='dedicated'”, it will not correct after serval live migrations. Which means the live migrate can be success, but the vCPU pin are not correct(two instance have serval same vCPU pin on same host). Below is my test steps. env: code: master branch (build on 16 September 2019, include the patches of NUMA aware live migration) three compute node: - s1: 24C, 48G (2 NUMA nodes) - stein-2: 12C, 24G (2 NUMA nodes) - stein-3: 8C, 16G (2 NUMA nodes) flavor1 (2c2g): hw:cpu_policy='dedicated', hw:numa_cpus.0='0', hw:numa_cpus.1='1', hw:numa_mem.0='1024', hw:numa_mem.1='1024', hw:numa_nodes='2' flavor2 (4c4g): hw:cpu_policy='dedicated', hw:numa_cpus.0='0,1,2', hw:numa_cpus.1='3', hw:numa_mem.0='1024', hw:numa_mem.1='3072', hw:numa_nodes='2' image has no property. I create four instances(2*flavor1, 2* flavor2), then begin live migration on by one(one instance live migrate done, next instance begin live migrate) and check the vCPU pin whether is correct. After serval live migrations, the vCPU pin will not correct. (You can find full migration list in attached file). The last live migrate is: +-----+--------------------------------------+-------------+-----------+----------------+--------------+----------------+-----------+--------------------------------------+------------+------------+----------------------------+----------------------------+----------------+ | Id | UUID | Source Node | Dest Node | Source Compute | Dest Compute | Dest Host | Status | Instance UUID | Old Flavor | New Flavor | Created At | Updated At | Type | +-----+--------------------------------------+-------------+-----------+----------------+--------------+----------------+-----------+--------------------------------------+------------+------------+----------------------------+----------------------------+----------------+ | 470 | 2a9ba183-4f91-4fbf-93cf-6f0e55cc085a | s1 | stein-3 | s1 | stein-3 | 172.16.130.153 | completed | bf0466f6-4815-4824-8586-899817207564 | 1 | 1 | 2019-09-17T10:28:46.000000 | 2019-09-17T10:29:09.000000 | live-migration | | 469 | c05ea0e8-f040-463e-8957-a59f70ed8bf6 | s1 | stein-3 | s1 | stein-3 | 172.16.130.153 | completed | a3ec7a29-80de-4541-989d-4b9f4377f0bd | 1 | 1 | 2019-09-17T10:28:21.000000 | 2019-09-17T10:28:45.000000 | live-migration | | 468 | cef4c609-157e-4b39-b6cc-f5528d49c75a | s1 | stein-2 | s1 | stein-2 | 172.16.130.152 | completed | 83dab721-3343-436d-bee7-f5ffc0d0d38d | 4 | 4 | 2019-09-17T10:27:57.000000 | 2019-09-17T10:28:21.000000 | live-migration | | 467 | 5471e441-2a50-465a-bb63-3fe1bb2e81b9 | s1 | stein-2 | s1 | stein-2 | 172.16.130.152 | completed | e3c19fbe-7b94-4a65-a803-51daa9934378 | 4 | 4 | 2019-09-17T10:27:32.000000 | 2019-09-17T10:27:57.000000 | live-migration | There are two instances land on stein-3, and the two instances have same vCPU pin: (nova-libvirt)[root@stein-3 /]# virsh list --all Id Name State ---------------------------------------------------- 32 instance-00000025 running 33 instance-00000024 running (nova-libvirt)[root@stein-3 /]# virsh vcpupin 32 VCPU: CPU Affinity ---------------------------------- 0: 2 1: 7 (nova-libvirt)[root@stein-3 /]# virsh vcpupin 33 VCPU: CPU Affinity ---------------------------------- 0: 2 1: 7 I checked the nova compute’s log on stein-3(you can find the log in attached log), then I found ‘host_topology’ isn’t updated when ‘hardware.numa_fit_instance_to_host’ be called in claims. ‘host_topology’ is the property of ‘objects.ComputeNode’ and it’s cached in ‘ResourceTracker’, it will use cached ‘cn’ to build ‘claim’ when ‘check_can_live_migrate_destination’ called. Therefore, I guess the cache was not updated or updated too late or some other reason. I also checked the database, the NUMA topology of the two instances have same vCPU pin: “[0,2], [1,7]”, and the compute node: stein-3 only has vCPU pin: “[2], [7]”. Please correct me if there is something wrong :) Best Regards

4 4

[all][tc] What happened in OpenStack Governance last week
by Jean-Philippe Evrard 24 Sep '19

24 Sep '19

Hello everyone, Here are a few things that happened recently: We introduced "comparison of Official Group Structures" [1]. It should help you navigate better our structures and process, if you want to start a new initiative. We now have a plan to reduce the amount of members of our Technical Committee going forward, down to 9 in Q3 2020 [2]. We've clarified the completion criteria for the PDF goal [3]. We've got fresh PTLs! Tetsuro Nakamura for Placement, Ian Y. Choi for I18n, and Monty Taylor for OpenStackSDK. Congratulations! The Ussuri runtimes are out [4][5]. Ussuri will be the first release to not require python2. Projects are encouraged to move forward! Reminder: Projects are allowed to test extra runtimes, like python2.7, if they want to. Note: Most, if not all, initiatives above were started by TC members. Keep in mind you don't need to be in the TC to propose patches in governance! For example, Tom Barron proposed quite a few patches recently, thank you Tom! :) Regards, Jean-Philippe Evrard (evrardjp) [1]: https://review.opendev.org/668093 [2]: https://review.opendev.org/681266 [3]: https://review.opendev.org/679654 [4]: https://governance.openstack.org/tc/reference/runtimes/ussuri.html [5]: https://review.opendev.org/679798

1 0

[keystone] Ussuri Virtual PTGs
by Colleen Murphy 24 Sep '19

24 Sep '19

Hi team, As we've discussed in IRC and at the virtual midcycle, we'll be holding two virtual planning meetings in place of meeting in-person at the PTG in Shanghai. We'll hold one before the real event in order to prepare for the Forum, and one following it in order to disseminate information and recalibrate. I've drawn up a straw man agenda and proposed meeting dates/times in our brainstorming etherpad: https://etherpad.openstack.org/p/keystone-shanghai-ptg The proposal is to have the pre-PTG on Tuesday, October 29 at 14:00 UTC and the post-PTG on Tuesday, November 12 at 15:00 UTC. (Every time I send a scheduling poll we usually settle on Tuesday mornings anyway so I'm just cutting to the chase.) Please speak up if you want to attend but the proposed dates or times do not work for you, we still have plenty of time to play with the schedule. If no one voices concerns by Tuesday, October 8 we'll consider the dates final. The agenda and topics are also open for feedback and additional topic suggestions are still welcome. We'll plan on using jitsi.org as our conference tool but can fall back to gotomeeting if necessary. Colleen

1 0

[FFE][designate] Pool Manager Removal and refactor
by Graham Hayes 24 Sep '19

24 Sep '19

Hi All, I am granting a FFE for 3 patches: https://review.opendev.org/#/c/678432/ - Refactored service layer https://review.opendev.org/#/c/665476/22 - Removed deprecated pool-manager implementation https://review.opendev.org/#/c/657289/ - Removed deprecated powerdns 3 driver These patches remove a duplicate code paths that have been deprecated for an extended period of time, and reduce a lot of the complexity in our implementation. Please contact me if there is any issues or concern. Thanks, Graham

1 0

[requirements] [ironic] FFE for python-ironicclient 3.1.0
by Dmitry Tantsur 24 Sep '19

24 Sep '19

Hi all, we would like to request an exception to release python-ironicclient 3.1.0 from the stable/train branch. The current 3.0.0 release has several issues, one of them [1] is critical and breaks no-auth mode (used e.g. in bifrost). I'm also proposing [2] to exclude python-ironicclient 3.0.0 from requirement. A release request will be posted once [3] merges. The minor version bump is because we've made the previously existing implicit oslo.config dependency explicit [4]. I don't believe the new release will break anyone who is not broken by 3.0.0 already. Thanks, Dmitry [1] https://storyboard.openstack.org/#!/story/2006600 [2] https://review.opendev.org/#/c/684376/ [3] https://review.opendev.org/#/c/684363/ [4] https://review.opendev.org/#/c/684281/

2 3