September 2019 - openstack-discuss

[tacker][requirements] Requesting a requirement freeze exception for python-tackerclient
by Dharmendra Kushwaha 26 Sep '19

26 Sep '19

Hello everyone, On behalf of the Tacker team, I'm asking for a requirements freeze exception for python-tackerclient. The stable/train branch has been created from the 0.16.0 release of python-tackerclient. And since then, some blocking bug fixes been added. We request to have these changes included in the Train release. Thanks & Regards Dharmendra Kushwaha ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECTI or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECTI or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.

2 1

[TripleO][TripleO-Ansible] Transformation Squad Meeting
by Kevin Carter 26 Sep '19

26 Sep '19

Hello all, The TripleO-Transformation squad meeting is shutting down. During the last meeting we decided the time has come for us to fold our efforts back up into TripleO proper [0]. At this time we will no longer hold a separate squad meeting. We will now provide updates during the main TripleO meeting and through mailing list posts, whenever needed. Please update your calendars accordingly. Thank you to everyone who's helped on the Transformation squad efforts thus far. We've made a lot of great progress and we're only getting started. [0] http://eavesdrop.openstack.org/meetings/tripleo/2019/tripleo.2019-09-25-14.… Kevin Carter IRC: cloudnull

1 0

Neutron - dnsmasq reloads causing dhcp failures
by fsbiz＠yahoo.com 26 Sep '19

26 Sep '19

Hi all, We have a relatively stable 140 node Openstack deployment consisting of hypervisors and bare-metal. Periodically, we have observed that the baremetals timeout during the PXE. We have been able to reproduce this relatively easily by rebooting several baremetals simultaneously.I believe I have traced the issue to the dnsmasq reloading every time an entry is added / deleted. Can anyone who has experienced similar issue provide feedback on what you did to work around this ? We are running a stable Queens release. thanks,Fred.

1 0

octavia-dashboard 4.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for octavia-dashboard for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/octavia-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/octavia-dashboard/src/branch/stable/train Release notes for octavia-dashboard can be found at: https://docs.openstack.org/releasenotes/octavia-dashboard/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/909 and tag it *train-rc-potential* to bring it to the octavia-dashboard release crew's attention.

1 0

octavia 5.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for octavia for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/octavia/ 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/octavia/src/branch/stable/train Release notes for octavia can be found at: https://docs.openstack.org/releasenotes/octavia/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/908 and tag it *train-rc-potential* to bring it to the octavia release crew's attention.

1 0

manila 9.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for manila for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/manila/ 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/manila/src/branch/stable/train Release notes for manila can be found at: https://docs.openstack.org/releasenotes/manila/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/manila/+bugs and tag it *train-rc-potential* to bring it to the manila release crew's attention.

1 0

[Infra] [Stable] [Trove] Request membership in trove-stable-maint
by Lingxian Kong 26 Sep '19

26 Sep '19

Hi, Could anyone who has the permission add me (Lingxian Kong anlin.kong(a)gmail.com) to the trove-stable-maint group in Gerrit so that I can merge patches for Trove stable/train? No one in the trove-stable-maint group is active now for Trove, I'm currently the only person who maintains Trove project(e.g. fix CI, complete community goal, add CI job to build trove guest image, etc.). - Best regards, Lingxian Kong Catalyst Cloud

2 2

Retiring stale repositories from the OpenStack org on GitHub
by Thierry Carrez 26 Sep '19

26 Sep '19

Hi everyone, The migration of our infrastructure to the Opendev domain gave us the opportunity to no longer have everything under "openstack" and stop the confusion around what is a part of OpenStack and what is just hosted on the same infrastructure. To that effect, in April we transferred non-OpenStack repositories to their own organization names on Opendev, with the non-claimed ones being kept for the time being under a "x" default organization. One consequence of that transition is that non-OpenStack repositories that were previously mirrored to GitHub under the "openstack" organization are now stale and no longer updated, which is very misleading. Those should now be retired, with a clear pointer to the original repository on Opendev. Jim and I volunteered to build tools to do handle that retirement and we are now ready to run those Thursday. This will not affect OpenStack repositories or repositories that were already retired or migrated off the OpenStack org on GitHub (think openstack-infra, opendev, airship...). That will only clean up no-longer-mirrored, stale, non-openstack repositories still present in the OpenStack GitHub organization. If you own a non-openstack repository on Opendev and would like to enable GitHub mirroring (to a GitHub org of your choice), it is possible to configure it as part of your Zuul jobs. You can follow instructions at: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.ht… Cheers, -- Jim and Thierry

1 1

Neutron - dnsmasq reloads causing dhcp failures
by fsbiz＠yahoo.com 26 Sep '19

26 Sep '19

Hi all, We have a relatively stable 140 node Openstack deployment consisting of hypervisors and bare-metal. Periodically, we have observed that the baremetals timeout during the PXE. We have been able to reproduce this relatively easily by rebooting several baremetals simultaneously.I believe I have traced the issue to the dnsmasq reloading every time an entry is added / deleted. Can anyone who has experienced similar issue provide feedback on what you did to work around this ? For what it is worth we are on a stable Queens release. thanks,Fred.

1 0

[ironic] FFE: Add idrac HW type Redfish virtual media boot interface
by Richard.Pioso＠dell.com 26 Sep '19

26 Sep '19

Hi, I request a late feature freeze exception (FFE) for https://review.opendev.org/#/c/672498/ -- "Add Redfish vmedia boot interface to idrac HW type". There is high demand from operators for this feature. They would be delighted if it were included in Train. We believe it is a low risk change, because of the following: 1) It affects only the idrac hardware type. 2) The highest priority boot interfaces supported by the idrac hardware type remain so. 'ipxe' and 'pxe' continue to have the highest priority, and the new 'idrac-redfish-virtual-media' has the lowest priority. The new order from highest to lowest priority is 'ipxe', 'pxe', and 'idrac-redfish-virtual-media'. 3) The new interface is based on and almost entirely leverages an already merged interface implementation, 'redfish-virtual-media'. [1] Please let me know if you have any concerns or questions. Thank you for your consideration. Rick [1] https://review.opendev.org/#/c/638453/

3 3

networking-ovn 7.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for networking-ovn for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/networking-ovn/ 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/networking-ovn/src/branch/stable/train Release notes for networking-ovn can be found at: https://docs.openstack.org/releasenotes/networking-ovn/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/networking-ovn/+bugs and tag it *train-rc-potential* to bring it to the networking-ovn release crew's attention.

1 0

neutron 15.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for neutron for the end of the Train 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 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/neutron/src/branch/stable/train Release notes for neutron can be found at: https://docs.openstack.org/releasenotes/neutron/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/neutron/+bugs and tag it *train-rc-potential* to bring it to the neutron release crew's attention.

1 0

ceilometer-powervm 9.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for ceilometer-powervm for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/ceilometer-powervm/ 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/ceilometer-powervm/src/branch/stable/train Release notes for ceilometer-powervm can be found at: https://docs.openstack.org/releasenotes/ceilometer-powervm/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/ceilometer-powervm/+bugs and tag it *train-rc-potential* to bring it to the ceilometer-powervm release crew's attention.

1 0

openstack-placement 2.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for openstack-placement for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/placement/ 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/openstack-placement/src/branch/stable/train Release notes for openstack-placement can be found at: https://docs.openstack.org/releasenotes/placement/

1 0

networking-powervm 9.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for networking-powervm for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/networking-powervm/ 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/networking-powervm/src/branch/stable/train Release notes for networking-powervm can be found at: https://docs.openstack.org/releasenotes/networking-powervm/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/networking-powervm/+bugs and tag it *train-rc-potential* to bring it to the networking-powervm release crew's attention.

1 0

openstack-congress 10.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for openstack-congress for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/congress/ 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/openstack-congress/src/branch/stable/train Release notes for openstack-congress can be found at: https://docs.openstack.org/releasenotes/congress/

1 0

nova_powervm 9.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for nova_powervm for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/nova-powervm/ 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/nova_powervm/src/branch/stable/train Release notes for nova_powervm can be found at: https://docs.openstack.org/releasenotes/nova-powervm/

1 0

congress-dashboard 5.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for congress-dashboard for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/congress-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/congress-dashboard/src/branch/stable/train Release notes for congress-dashboard can be found at: https://docs.openstack.org/releasenotes/congress-dashboard/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/congress/+bugs and tag it *train-rc-potential* to bring it to the congress-dashboard release crew's attention.

1 0

ceilometer 13.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for ceilometer for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/ceilometer/ 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/ceilometer/src/branch/stable/train Release notes for ceilometer can be found at: https://docs.openstack.org/releasenotes/ceilometer/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/ceilometer/+bugs and tag it *train-rc-potential* to bring it to the ceilometer release crew's attention.

1 0

panko 7.0.0.0rc1 (train)
by no-reply＠openstack.org 26 Sep '19

26 Sep '19

Hello everyone, A new release candidate for panko for the end of the Train cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/panko/ 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/panko/src/branch/stable/train Release notes for panko can be found at: https://docs.openstack.org/releasenotes/panko/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/panko/+bugs and tag it *train-rc-potential* to bring it to the panko release crew's attention.

1 0

[qa][nova][osapi_compute_workers]
by 崔恒香 25 Sep '19

25 Sep '19

Hello everyone! This was my configuration of osapi_compute_workers: osapi_compute_workers=24 But the number of processes on my controller was 58. root@controller10:~# ps -aux|grep nova-api nova 112811 0.8 0.1 286952 134384 ? Ss 11:51 2:13 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112828 4.4 0.1 478032 258960 ? R 11:51 12:15 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112829 2.6 0.1 470544 251428 ? S 11:51 7:26 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112830 5.0 0.1 482568 263480 ? S 11:51 13:59 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112831 4.6 0.2 484160 266240 ? R 11:51 12:59 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112832 2.3 0.1 477260 258832 ? S 11:51 6:37 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112833 4.5 0.2 483744 265512 ? S 11:51 12:31 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112834 4.9 0.2 492952 275884 ? S 11:51 13:39 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112835 2.5 0.1 468892 251244 ? S 11:51 7:10 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112836 5.0 0.1 480480 263424 ? S 11:51 13:54 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112837 4.7 0.2 493596 275996 ? S 11:51 13:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112838 3.7 0.1 474616 259336 ? S 11:51 10:27 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112839 5.4 0.2 485732 266648 ? S 11:51 15:08 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112840 4.7 0.1 482836 263748 ? S 11:51 13:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112841 4.6 0.2 517084 297508 ? S 11:51 12:52 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112842 3.0 0.2 491076 271984 ? S 11:51 8:34 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112843 3.8 0.2 487412 270360 ? S 11:51 10:35 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112844 3.0 0.1 469468 251676 ? S 11:51 8:29 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112845 4.5 0.2 489440 270884 ? S 11:51 12:36 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112846 4.3 0.2 493308 275760 ? S 11:51 12:11 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112847 4.5 0.2 490400 272936 ? S 11:51 12:39 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112848 4.3 0.1 482036 262968 ? S 11:51 12:08 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112849 5.6 0.2 486328 267240 ? S 11:51 15:32 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112850 4.3 0.2 483660 264580 ? S 11:51 12:03 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112851 4.4 0.2 482116 267096 ? S 11:51 12:17 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112875 0.0 0.1 312132 152852 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112876 0.0 0.1 311420 152116 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112877 0.0 0.1 311364 152196 ? S 11:51 0:05 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112878 0.0 0.1 312992 153940 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112879 0.0 0.1 312008 152696 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112880 0.0 0.1 312980 153668 ? S 11:51 0:08 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112881 0.0 0.1 310892 151536 ? S 11:51 0:05 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112882 0.0 0.1 311340 152012 ? S 11:51 0:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112883 0.0 0.1 311508 152144 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112884 0.0 0.1 310720 151568 ? S 11:51 0:08 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112885 0.0 0.1 311360 152276 ? S 11:51 0:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112886 0.0 0.1 311836 152772 ? S 11:51 0:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112887 0.0 0.1 310872 151600 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112888 0.0 0.1 313084 153880 ? S 11:51 0:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112889 0.0 0.1 312332 153236 ? S 11:51 0:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112890 0.0 0.1 310796 151696 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112891 0.0 0.1 311708 152448 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112892 0.0 0.1 311460 152328 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112893 0.0 0.1 312808 153532 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112897 0.0 0.1 311668 152528 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112898 0.0 0.1 311352 152128 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112899 0.0 0.1 312844 153696 ? S 11:51 0:09 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112901 0.0 0.1 311280 152076 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112904 0.0 0.1 311212 152104 ? S 11:51 0:08 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112907 0.0 0.1 310832 151752 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112915 0.0 0.1 311136 152040 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112918 0.0 0.1 311140 152112 ? S 11:51 0:07 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112919 0.0 0.1 311348 152324 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112920 0.0 0.1 311712 152684 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112923 0.0 0.1 310768 151508 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112927 0.0 0.1 311156 152080 ? S 11:51 0:06 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log nova 112928 0.0 0.1 312132 152824 ? S 11:51 0:08 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-api.log

2 2

[tc] Weekly update
by Jean-Philippe Evrard 25 Sep '19

25 Sep '19

Hello my friends, Here's what need attention for the OpenStack TC this week. 1. We should ensure we have two TC members focusing on next cycle goal selection process. As far as I know, there is no one assigned to this yet. And that's _very important_. 2. Jimmy McArthur sent us the results of the OpenStack User survey on the ML [1]. We currently haven't analyzed the information yet. Any volunteer to analyse the information (in order to extract action items) is welcomed. It would be great if we could discuss this at our next official meeting. 3. Our next meeting date needs to be decided (same time as usual). Pleas e use the framadate here [2]. 4. Our next meeting agenda needs clarifications. It would be great if you could update the wiki [3], so that I can send the invite to the ML. 5. We have a vice-chair candidate, Rico. It would be awesome if you could cast a vote on this nomination, if you didn't vote on it yet[4]. 6. There are plenty of patches that are waiting for your opinion. Have a look at [5] to [10] for example :) 7. We may have multiple patches with too many dissenting votes. I will abandon them if nobody is against that (pun intended). Thank you everyone! Jean-Philippe Evrard (evrardjp) [1]: http://lists.openstack.org/pipermail/openstack-discuss/2019-September/00950… [2]: https://framadate.org/6zASzWzX4ejkr4ae [3]: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [4]: https://review.opendev.org/684262 [5]: https://review.opendev.org/681203 [6]: https://review.opendev.org/681260 [7]: https://review.opendev.org/681480 [8]: https://review.opendev.org/681924 [9]: https://review.opendev.org/680985 [10]: https://review.opendev.org/682380

2 1

[tc][uc][all] Starting goal selection for U series
by Ghanshyam Mann 25 Sep '19

25 Sep '19

Hello everyone, We are in R10 week of Train cycle and not so far from the start of U cycle. It's time to start the discussions about community-wide goals ideas for the U series. We are little late to start this thread for U series which usually happened during Summit Forum. But it is not mandatory to wait for f2f meetup to kick off the goal discussions, we can always start the same via ML or ad-hoc meetings. During Shanghai Summit Forum, we will be having the f2f discussion for U (continue the discussion from ML threads) as well as V cycle goals ideas. Community-wide goals are important in term of solving and improving a technical area across OpenStack as a whole. It has lot more benefits to be considered from users as well from a developers perspective. See [1] for more details about community-wide goals and process. Also, you can refer to the backlogs of community-wide goals from this[2] and train cycle goals[3]. If you are interested in proposing a goal, please write down the idea on this etherpad[4] - https://etherpad.openstack.org/p/PVG-u-series-goals Accordingly, we will start the separate ML discussion over each goal idea. [1] https://governance.openstack.org/tc/goals/index.html [2] https://etherpad.openstack.org/p/community-goals [3] https://etherpad.openstack.org/p/BER-t-series-goals [4] https://etherpad.openstack.org/p/PVG-u-series-goals -gmann

1 1

numa affinity question
by Manuel Sopena Ballesteros 25 Sep '19

25 Sep '19

Dear openstack user group, I have a server with 2 numa nodes and I am trying to setup nova numa affinity. [root@zeus-53 ~]# numactl -H available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 28 29 30 31 32 33 34 35 36 37 38 39 40 41 node 0 size: 262029 MB node 0 free: 2536 MB node 1 cpus: 14 15 16 17 18 19 20 21 22 23 24 25 26 27 42 43 44 45 46 47 48 49 50 51 52 53 54 55 node 1 size: 262144 MB node 1 free: 250648 MB node distances: node 0 1 0: 10 21 1: 21 10 openstack flavor create --public xlarge.numa.perf --ram 250000 --disk 700 --vcpus 25 --property hw:cpu_policy=dedicated --property hw:emulator_threads_policy=isolate --property hw:numa_nodes='1' --property pci_passthrough:alias='nvme:4' openstack server create --network hpc --flavor xlarge.numa.perf --image centos7.6-kudu-image --availability-zone nova:zeus-53.localdomain --key-name mykey kudu-1 This is the xmldump for the created vm But for some reason the second VM fails to create with the error <name>instance-00000108</name> <uuid>5d278c90-27ab-4ee4-aeea-e1bf36ac246a</uuid> <metadata> <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0"> <nova:package version="18.2.2-1.el7"/> <nova:name>kudu-4</nova:name> <nova:creationTime>2019-09-25 07:20:32</nova:creationTime> <nova:flavor name="xlarge.numa.perf"> <nova:memory>250000</nova:memory> <nova:disk>700</nova:disk> <nova:swap>0</nova:swap> <nova:ephemeral>0</nova:ephemeral> <nova:vcpus>25</nova:vcpus> </nova:flavor> <nova:owner> <nova:user uuid="91e83343e9834c8ba0172ff369c8acac">admin</nova:user> <nova:project uuid="b91520cff5bd45c59a8de07c38641582">admin</nova:project> </nova:owner> <nova:root type="image" uuid="ff9e09ac-86d5-4698-9883-cf3e6579caec"/> </nova:instance> </metadata> <memory unit='KiB'>256000000</memory> <currentMemory unit='KiB'>256000000</currentMemory> <vcpu placement='static'>25</vcpu> <cputune> <shares>25600</shares> <vcpupin vcpu='0' cpuset='27'/> <vcpupin vcpu='1' cpuset='55'/> <vcpupin vcpu='2' cpuset='50'/> <vcpupin vcpu='3' cpuset='22'/> <vcpupin vcpu='4' cpuset='49'/> <vcpupin vcpu='5' cpuset='21'/> <vcpupin vcpu='6' cpuset='48'/> <vcpupin vcpu='7' cpuset='20'/> <vcpupin vcpu='8' cpuset='25'/> <vcpupin vcpu='9' cpuset='53'/> <vcpupin vcpu='10' cpuset='18'/> <vcpupin vcpu='11' cpuset='46'/> <vcpupin vcpu='12' cpuset='51'/> <vcpupin vcpu='13' cpuset='23'/> <vcpupin vcpu='14' cpuset='19'/> <vcpupin vcpu='15' cpuset='47'/> <vcpupin vcpu='16' cpuset='26'/> <vcpupin vcpu='17' cpuset='54'/> <vcpupin vcpu='18' cpuset='42'/> <vcpupin vcpu='19' cpuset='14'/> <vcpupin vcpu='20' cpuset='17'/> <vcpupin vcpu='21' cpuset='45'/> <vcpupin vcpu='22' cpuset='43'/> <vcpupin vcpu='23' cpuset='15'/> <vcpupin vcpu='24' cpuset='24'/> <emulatorpin cpuset='14-15,17-27,42-43,45-51,53-55'/> </cputune> <numatune> <memory mode='strict' nodeset='1'/> <memnode cellid='0' mode='strict' nodeset='1'/> </numatune> <sysinfo type='smbios'> <system> <entry name='manufacturer'>RDO</entry> <entry name='product'>OpenStack Compute</entry> <entry name='version'>18.2.2-1.el7</entry> <entry name='serial'>00000000-0000-0000-0000-0cc47aa482cc</entry> <entry name='uuid'>5d278c90-27ab-4ee4-aeea-e1bf36ac246a</entry> <entry name='family'>Virtual Machine</entry> </system> </sysinfo> <os> <type arch='x86_64' machine='pc-i440fx-rhel7.6.0'>hvm</type> <boot dev='hd'/> <smbios mode='sysinfo'/> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-model' check='partial'> <model fallback='allow'/> <topology sockets='25' cores='1' threads='1'/> <numa> <cell id='0' cpus='0-24' memory='256000000' unit='KiB'/> </numa> </cpu> <clock offset='utc'> <timer name='pit' tickpolicy='delay'/> <timer name='rtc' tickpolicy='catchup'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/5d278c90-27ab-4ee4-aeea-e1bf36ac246a/disk'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <controller type='usb' index='0' model='piix3-uhci'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <interface type='bridge'> <mac address='fa:16:3e:d6:1d:78'/> <source bridge='qbr16cb6622-01'/> <target dev='tap16cb6622-01'/> <model type='virtio'/> <mtu size='1500'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <log file='/var/lib/nova/instances/5d278c90-27ab-4ee4-aeea-e1bf36ac246a/console.log' append='off'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <log file='/var/lib/nova/instances/5d278c90-27ab-4ee4-aeea-e1bf36ac246a/console.log' append='off'/> <target type='serial' port='0'/> </console> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' listen='192.168.1.53'> <listen type='address' address='192.168.1.53'/> </graphics> <video> <model type='cirrus' vram='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x87' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x86' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x85' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x84' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> <memballoon model='virtio'> <stats period='10'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </memballoon> </devices> </domain> QUESTIONS: Are my vcpus in the same numa node? if not why? How can I tell from the xmldump that all vcpus are assigned to the same numa node? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

3 3

Re: [Release-job-failures] Release of openstack/ironic-prometheus-exporter for ref refs/tags/1.0.0 failed
by Thierry Carrez 25 Sep '19

25 Sep '19

zuul(a)openstack.org wrote: > Build failed. > > - release-openstack-python https://zuul.opendev.org/t/openstack/build/d1ff269af65f431abd4d057be7d480b2 : POST_FAILURE in 2m 44s > - announce-release https://zuul.opendev.org/t/openstack/build/None : SKIPPED > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/None : SKIPPED So this one failed because there is already a ironic-prometheus-exporter 1.0.0 on Pypi, uploaded on June 13: https://pypi.org/project/ironic-prometheus-exporter/1.0.0/ This is obviously very confusing: the recently-pushed 1.0.0 tag does not correspond to the published PyPI release, and our 1.0.0 tarball is not what was uploaded to PyPI. We can't rewrite history, but I propose we push a 1.1.0 release (and remove reference to 1.0.0 release in our history) to sync things up: https://review.opendev.org/684721 -- Thierry Carrez (ttx)

3 2