- openstack-discuss - lists.openstack.org

[ceilometer] The correct way to change metric granularity time?
by Eddie Yen 25 Oct '19

25 Oct '19

Hi We're using Ceilometer with Gnocchi in Rocky release. And we're using cpu_util variable to doing auto scaling on Heat. We known that ceilometer will create its own archive policy in gnocchi, and default value of granularity is 5 minutes. We want change ceilometer's granularity to a minute. Here's our workaround. 1. Edit pipeline.yaml. Since gnocchi has default policy that granularity = 1 second, we change "gnocchi://" to "gnocchi://?archive_policy=high" 2. Edit ceilometer.conf & polling.yaml, change both evaluation_interval (ceilometer.conf) & interval (polling.yaml) to 60. 3. Restart all ceilometer services We tested this workaround but found that it would not work sometimes. And found that the first detection triggered every "o'clock" when created auto scaling at first time. If we want to shrink the granularity time, is our workaround correct? And how is the correct way to do this if not? Many thanks, Eddie.

1 0

[release] Release countdown for week R-28
by Sean McGinnis 24 Oct '19

24 Oct '19

Welcome back to the release countdown emails! These will be sent at major points in the Ussuri development cycle, which should conclude with a final release on May 13, 2020. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the Ussuri development cycle, assessing Ussuri community goals and approving Ussuri specs. General Information ------------------- Please note that the Ussuri cycle will be slightly longer than past cycles (30 weeks). In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/ussuri/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the Train release are continued in Ussuri with a similar release model. If you intend to drop a deliverable, or modify its release model, please do so before the ussuri-1 milestone by proposing a change to the deliverable file at: https://opendev.org/openstack/releases/src/branch/master/deliverables/ussuri Upcoming Deadlines & Dates -------------------------- Forum+PTG at Shanghai summit: November 4 Ussuri-1 milestone: December 12 (R-22 week)

1 0

[cyborg] Nominating Chenke as core reviewer
by Nadathur, Sundar 24 Oct '19

24 Oct '19

Hello, Chenke has contributed substantially to Cyborg [1], esp. in the Train release, and has been an active participant in the community. I would like to acknowledge his significant past and ongoing contributions [2] and enthusiasm, and nominate him as a core reviewer for Cyborg. Please provide any feedback on his nomination by Oct 31, 2019. If there are no objections, his nomination will be made effective on Nov 1, 2019. [1] https://www.stackalytics.com/?module=cyborg-group&user_id=chenker [2] https://review.opendev.org/#/q/project:openstack/cyborg+owner:chenker Regards, Sundar

4 3

[charms] OpenStack Charms 19.10 release is now available
by Peter Matulis 24 Oct '19

24 Oct '19

The OpenStack Charms team is thrilled to announce the 19.10 charms release, introducing support for OpenStack Train and Ceph Nautilus on Ubuntu 18.04 LTS (via UCA) and Ubuntu 19.10. This release also brings several new and valuable features to the existing OpenStack Charms deployments for Queens, Rocky, Stein, and many other stable combinations of Ubuntu + OpenStack. Please see the Release Notes for full details: https://docs.openstack.org/charm-guide/latest/1910.html == Highlights == * OpenStack Train OpenStack Train is now supported on Ubuntu 18.04 LTS (via UCA) and Ubuntu 19.10. * Policy Overrides A new Policy Overrides feature provides operators with a mechanism to override policy defaults on a per-service basis. * Ceph Nautilus The Nautilus release of Ceph is now supported, in conjunction with OpenStack Train. * Ceph placement group autotuning In Ceph Nautilus, the autotuning of placement groups is now supported. * Neutron port forwarding The Neutron port forwarding extension can now be optionally enabled for OpenStack Rocky and later. * Migration to FQDN for agent registration When deploying OpenStack Stein or newer, the Nova Compute agent and Neutron agents will now use a fully qualified domain name (FQDN) when registering with the API services. * Ceph RADOS Gateway tenant namespacing The ceph-radosgw charm now supports deployment with tenant namespaces. * New charm: Placement There is a new charm for the placement API: the 'placement' charm. The new charm must be deployed and related to the nova-cloud-controller charm for OpenStack Train deployments. This will affect Stein to Train upgrades. * New charm: Cinder integration with Pure Storage array There is a new subordinate charm that can be used to integrate Cinder with a Pure Storage array: the 'cinder-purestorage' charm. * nova-cloud-controller: instance migration - DNS caching is now the default The caching of DNS lookups of the nova-compute units is now the default behaviour. == OpenStack Charms team == The OpenStack Charms team can be contacted on the #openstack-charms IRC channel on Freenode. The team will be at the Open Infrastructure Summit and PTG events in Shanghai (November 4-8, 2019). == Thank you == Massive appreciation of the below 59 charm contributors who squashed 41 bugs, enabled support for a new release of OpenStack, improved documentation, and added compelling new functionality! Frode Nordahl Chris MacNaughton Corey Bryant Ryan Beisner Camille Rodriguez David Ames Alex Kavanagh Liam Young James Page Dmitrii Shcherbakov Rodrigo Barbieri Peter Matulis Sahid Orentino Ferdjaoui Edward Hope-Morley Tytus Kurek Ghanshyam Mann Jorge Niedbalski Natalia Litvinova Tiago Pasqualini Nicolas Pochet Narinder Gupta exsdev Andrea Ieri Andreas Jaeger Eduardo Sousa Zachary Zehring Trent Lloyd Mike Wilson David Coronel Stamatis Katsaounis Dan Ackerson Hua Zhang Dongdong Tao Ian Wienand Felipe Reyes Ramon Grullon Joe Guo Erlon R. Cruz George Kraft Alvaro Uria Peter Sabaini Michael Skalka Nikolay Vinogradov Jose Delarosa melissaml Seyeong Kim Mark S. Maglana Nobuto Murata Andrew McLeod Frank Kloeker Tim Burke Cory Johns Marian Gasparovic sunnyve Pete Vander Giessen Ryan Farrell Levente Tamas Alexander Litvinov Marcelo Subtil Marcal -- OpenStack Charms Team

1 0

[api sig] office hour cancelled for today
by Michael McCune 24 Oct '19

24 Oct '19

due to schedule conflicts we are short on staff for the office hour today and it will be cancelled. peace o/

1 0

[nova] Is config drive data stored in ephemeral storage?
by Jean-Philippe Méthot 24 Oct '19

24 Oct '19

Hi, We currently use Ceph for storage on our Openstack cluster. We set up a pool to use for ephemeral nova storage, but we never actually use it, as we prefer to use cinder block devices. However, we notice that objects are being created inside that pool. Could it be that when you use config drives, the actual config drive is created inside nova’s ephemeral storage instead of on the compute node’s disk? Best regards, Jean-Philippe Méthot Openstack system administrator Administrateur système Openstack PlanetHoster inc.

3 2

[qa] [all] Opinion on dropping the py2.7 support from Tempest & Tempest plugin
by Ghanshyam Mann 24 Oct '19

24 Oct '19

Hello Everyone, We are in Ussuri development cycle which is planned to drop the py2.7 support[1]. I was holding and planning to support the py2.7 in Tempest due to its branchless model[2]. My main point to keep py2 support is if any users running the Tempest on py27 env cloud and not in virtual env then they can keep running in the same way. But this might be just me overthinking on this usage. What happens if we drop py2.7 from Tempest: * Users with the above case have the way to install the latest Tempest on virtual env of py3. or use the Tempest tag if they do not need latest Tempest. * No change in users using Tempest on py3 or in py3 virtual env. * Upstream testing of master or stable branch is no issue as we install the Tempest in virtual env. Tempest in py3 venv can always test the py2.7 jobs. * other than that no change in Tempest usage or at least it would not break anything. Why we cannot keep the support: There is no big cost of supporting the py2.7 in Tempest itself but that require Temepst dependency (OpenStack lib like Oslo and non-openstack maintained lib [3]) to keep supporting the py2.7 which is not feasible. Other solution: One way is to cut the Tempest stable branch and keep the py2.7 support there with eligible backport from Tempest master which is py3 only. But I would say, QA team has no bandwidth to do so. if anyone wants to maintain that then we can discuss this option in more detail. I have given a second thought on this and now ok to drop the py2.7 from Tempest by considering all the above points. Please reply if any disagreement on this or add if anything I missed to consider. NOTE: Tempest includes its plugins also. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010142.… [2] https://review.opendev.org/#/c/681203/ [3] https://opendev.org/openstack/tempest/src/commit/7fdd39c6dbde37bccd419c4037… -gmann

7 12

[ironic][release][stable] Ironic Train release can be broken due to entry in driver-requirements.txt
by Richard.Pioso＠dell.com 24 Oct '19

24 Oct '19

Hi, The Ironic Train release can be broken due to an entry in its driver-requirements.txt. driver-requirements.txt defines a dependency on the sushy package [1] which can be satisfied by version 1.9.0. Unfortunately, that version contains a few bugs which prevent Ironic from being able to manage Dell EMC and perhaps other vendors' bare metal hardware with its Redfish hardware type (driver). The fixes to them [2][3][4] were merged into master before the creation of stable/train. Therefore, they are available on stable/train and in the last sushy release created during the Train cycle, 2.0.0, the only other version which can satisfy the dependency today. However, consumers -- packagers, operators, and users -- could, fighting time constraints or lacking solid visibility into Ironic, package or install Ironic with sushy 1.9.0 to satisfy the dependency, but, in so doing, unknowingly render the package or installation severely broken. A change [5] has been proposed as part of a prospective solution to this issue. It creates a new release of sushy from the change which fixes the first bug [2]. Review comments [6] discuss basing the new release on a more recent stable/train change to pick up other bug fixes and, less importantly, backward compatible feature modifications and enhancements which merged before the change from which 2.0.0 was created. Backward compatible feature modifications and enhancements are interspersed in time among the bug fixes. Once a new release is available, the sushy entry in driver-requirements.txt on stable/train would be updated. However, apparently, the stable branch policy prevents releases from being done at a point earlier than the last release within a given cycle [6], which was 2.0.0. Another possible resolution which comes to mind is to change the definition of the sushy dependency in driver-requirements.txt [1] from "sushy>=1.9.0" to "sushy>=2.0.0". Does anyone have a suggestion on how to proceed? Thank you, Rick [1] https://opendev.org/openstack/ironic/src/commit/b8ae681b37eec617736ac4a507e… [2] https://review.opendev.org/#/c/666253/ [3] https://review.opendev.org/#/c/668936/ [4] https://review.opendev.org/#/c/669889/ [5] https://review.opendev.org/#/c/688551/ [6] https://review.opendev.org/#/c/688551/1/deliverables/train/sushy.yaml@14

10 16

[magnum][kubernetes] Train release updates
by feilong 24 Oct '19

24 Oct '19

Hi all, Glad to see the Train just released. I'd like to take this opportunity to highlight some cool features Magnum team have done in this cycle. Please feel free to pop up at #openstack-containers for any feedback. Thank you. 1. Fedora CoreOS driver Finally we get this done in this cycle which is quite important and urgent. Because the Fedora Atomic will be end of life soon (at the end of this Nov?). Now with stable/train, user can create k8s cluster based on Fedora CoreOS image. We're welcome for any feedback about this. 2. Node group This is a quite large feature, thanks for the great work from CERN team and StackHPC. With this feature, user can create different node groups with different specs. 3. Rolling upgrade Now user can do rolling upgrade for both k8s version and the node operating system without downtime, it's a quite important feature. 4. Auto healing With auto healing feature, a small service will be deployed on k8s cluster to monitor the health status of the cluster and replace broken node when failure detected. 5. Volume based k8s nodes Now user can create a Kubernetes cluster with nodes based on volume and the volume type is configurable. User can even set the volume type of etcd volume which is very useful for cloud providers who want to use SSD for etcd and k8s nodes. 6. Private cluster As a security best practice, isolating Kubernetes clusters from Internet access is one of the most desired features for enterprise users. Now user has the flexibility to create a private cluster by default, only allow the API exposed on Internet or fully opened. -- Cheers & Best regards, Feilong Wang (王飞龙) ------------------------------------------------------ Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington ------------------------------------------------------

2 2

[ironic]: Timeout reached while waiting for callback for node
by fsbiz＠yahoo.com 23 Oct '19

23 Oct '19

Hi folks, We have a 300 strong ironic cluster which has been relatively stable for the most part.Occasionally we get the IPA timeout errors. | | 2019-10-20 23:33:37.994 | 2019-10-20 23:33:37.421 265272 ERROR nova.virt.ironic.driver [req-71933c39-2ac4-497b-8cdc-9578889f42fe cda0725e2a68445db857f56c49f77faf 53a4a4738d9f49e99fe580c1bd51f950 - default default] Error deploying instance c51368f6-b9d8-4c3c-bd63-d1f84ee26bfb on baremetal node 83dc67d4-36be-4004-8847-afd9b969de0e.: InstanceDeployFailure: Failed to provision instance c51368f6-b9d8-4c3c-bd63-d1f84ee26bfb: Timeout reached while waiting for callback for node 83dc67d4-36be-4004-8847-afd9b969de0e | Here's my troubleshooting so far. DHCP: All good. Oct 22 09:49:58 sc-control03 dnsmasq-dhcp[965699]: 3076961402 DHCPDISCOVER(ns-601d0738-39) 6c:b3:11:4f:87:acOct 22 09:49:58 sc-control03 dnsmasq-dhcp[965699]: 3076961402 DHCPOFFER(ns-601d0738-39) 10.33.23.94 6c:b3:11:4f:87:acOct 22 09:50:02 sc-control03 dnsmasq-dhcp[965699]: 3076961402 DHCPREQUEST(ns-601d0738-39) 10.33.23.94 6c:b3:11:4f:87:acOct 22 09:50:02 sc-control03 dnsmasq-dhcp[965699]: 3076961402 DHCPACK(ns-601d0738-39) 10.33.23.94 6c:b3:11:4f:87:ac host-10-33-23-94Oct 22 10:19:47 sc-control03 dnsmasq-dhcp[965699]: 0 DHCPRELEASE(ns-601d0738-39) 10.33.23.94 6c:b3:11:4f:87:acOct 22 10:21:23 sc-control03 dnsmasq-dhcp[965699]: 2188330678 DHCPDISCOVER(ns-601d0738-39) 6c:b3:11:4f:87:acOct 22 10:21:23 sc-control03 dnsmasq-dhcp[965699]: 2188330678 DHCPOFFER(ns-601d0738-39) 10.33.23.187 6c:b3:11:4f:87:acOct 22 10:21:26 sc-control03 dnsmasq-dhcp[965699]: 2188330678 DHCPREQUEST(ns-601d0738-39) 10.33.23.187 6c:b3:11:4f:87:acOct 22 10:21:26 sc-control03 dnsmasq-dhcp[965699]: 2188330678 DHCPACK(ns-601d0738-39) 10.33.23.187 6c:b3:11:4f:87:ac host-10-33-23-Oct 22 10:22:46 sc-control03 dnsmasq-dhcp[965699]: 3549042952 DHCPDISCOVER(ns-601d0738-39) 6c:b3:11:4f:87:ac Ironic conductor logs: (shows ironic state proceeding to Power ON, ironic state: deploying. Then 30 minutes later timeout since IPA failed to check-in 2019-10-22 09:49:03.746 267066 DEBUG ironic.drivers.modules.deploy_utils [req-fabea5a4-da6c-48be-834a-49763c23b0e9 1ded19959aa94e53b6487d7c4f8d3371 acf8cd411e5e4751a61d1ed54e8e874d - default default] Deploy boot mode is uefi for d465fa17-a2ea-43ff-a3a7-033cbb497774. get_boot_mode_for_deploy /usr/lib/python2.7/site-packages/ironic/drivers/modules/deploy_utils.py:798 2019-10-22 09:49:03.747 267066 DEBUG ironic.common.pxe_utils [req-fabea5a4-da6c-48be-834a-49763c23b0e9 1ded19959aa94e53b6487d7c4f8d3371 acf8cd411e5e4751a61d1ed54e8e874d - default default] Building PXE config for node d465fa17-a2ea-43ff-a3a7-033cbb497774 create_pxe_config /usr/lib/python2.7/site-packages/ironic/common/pxe_utils.py:222 2019-10-22 09:49:03.748 267066 DEBUG ironic.drivers.modules.deploy_utils [req-fabea5a4-da6c-48be-834a-49763c23b0e9 1ded19959aa94e53b6487d7c4f8d3371 acf8cd411e5e4751a61d1ed54e8e874d - default default] Deploy boot mode is uefi for d465fa17-a2ea-43ff-a3a7-033cbb497774. get_boot_mode_for_deploy /usr/lib/python2.7/site-packages/ironic/drivers/modules/deploy_utils.py:798 2019-10-22 09:49:04.516 267066 DEBUG ironic.drivers.modules.pxe [req-fabea5a4-da6c-48be-834a-49763c23b0e9 1ded19959aa94e53b6487d7c4f8d3371 acf8cd411e5e4751a61d1ed54e8e874d - default default] Fetching necessary kernel and ramdisk for node d465fa17-a2ea-43ff-a3a7-033cbb497774 _cache_ramdisk_kernel /usr/lib/python2.7/site-packages/ironic/drivers/modules/pxe.py:382 2019-10-22 09:49:17.761 267066 INFO ironic.conductor.utils [req-fabea5a4-da6c-48be-834a-49763c23b0e9 1ded19959aa94e53b6487d7c4f8d3371 acf8cd411e5e4751a61d1ed54e8e874d - default default] Successfully set node d465fa17-a2ea-43ff-a3a7-033cbb497774 power state to power on by rebooting. ===== 30 minutes later timeout. IPA failed to check-in 2019-10-22 10:19:37.448 267066 INFO ironic.conductor.task_manager [req-762d8acf-0a55-4d8d-99d8-93020a14547c - - - - -] Node d465fa17-a2ea-43ff-a3a7-033cbb497774 moved to provision state "deploy failed" from state "wait call-back"; target provision state is "active" 2019-10-22 10:19:37.471 267066 DEBUG ironic.common.pxe_utils [req-762d8acf-0a55-4d8d-99d8-93020a14547c - - - - -] Cleaning up PXE config for node d465fa17-a2ea-43ff-a3a7-033cbb497774 clean_up_pxe_config /usr/lib/python2.7/site-packages/ironic/common/pxe_utils.py:288 TFTP logs: shows TFTP client timed out (weird). Any pointers here?tftpd shows ramdisk_deployed completed. Then, it reports that the client timed out. Oct 22 09:50:15 sc-ironic04 in.tftpd[318194]: RRQ from 10.33.23.94 filename d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_ramdisk remapped to /tftpboot/d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_ramdisk Oct 22 09:50:44 sc-ironic04 in.tftpd[318194]: Client 10.33.23.94 finished d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_ramdiskOct 22 09:50:44 sc-ironic04 in.tftpd[318194]: Client 10.33.23.94 timed out Oct 22 09:50:03 sc-ironic04 in.tftpd[318148]: remap: input: bootx64.efiOct 22 09:50:03 sc-ironic04 in.tftpd[318148]: remap: rule 3: rewrite: /tftpboot/bootx64.efiOct 22 09:50:03 sc-ironic04 in.tftpd[318148]: remap: rule 3: exitOct 22 09:50:03 sc-ironic04 in.tftpd[318148]: RRQ from 10.33.23.94 filename bootx64.efi remapped to /tftpboot/bootx64.efiOct 22 09:50:04 sc-ironic04 in.tftpd[318148]: Error code 8: User aborted the transferOct 22 09:50:04 sc-ironic04 in.tftpd[318150]: remap: input: bootx64.efiOct 22 09:50:04 sc-ironic04 in.tftpd[318150]: remap: rule 3: rewrite: /tftpboot/bootx64.efiOct 22 09:50:04 sc-ironic04 in.tftpd[318150]: remap: rule 3: exitOct 22 09:50:04 sc-ironic04 in.tftpd[318150]: RRQ from 10.33.23.94 filename bootx64.efi remapped to /tftpboot/bootx64.efiOct 22 09:50:04 sc-ironic04 in.tftpd[318150]: Client 10.33.23.94 finished bootx64.efiOct 22 09:50:04 sc-ironic04 in.tftpd[318151]: remap: input: grubx64.efiOct 22 09:50:04 sc-ironic04 in.tftpd[318151]: remap: rule 3: rewrite: /tftpboot/grubx64.efiOct 22 09:50:04 sc-ironic04 in.tftpd[318151]: remap: rule 3: exitOct 22 09:50:04 sc-ironic04 in.tftpd[318151]: RRQ from 10.33.23.94 filename grubx64.efi remapped to /tftpboot/grubx64.efiOct 22 09:50:05 sc-ironic04 in.tftpd[318151]: Client 10.33.23.94 finished grubx64.efiOct 22 09:50:05 sc-ironic04 in.tftpd[318152]: remap: input: /grub.cfg-01-6c-b3-11-4f-87-acOct 22 09:50:05 sc-ironic04 in.tftpd[318152]: remap: rule 2: rewrite: /tftpboot//grub.cfg-01-6c-b3-11-4f-87-acOct 22 09:50:05 sc-ironic04 in.tftpd[318152]: remap: rule 2: exitOct 22 09:50:05 sc-ironic04 in.tftpd[318152]: RRQ from 10.33.23.94 filename /grub.cfg-01-6c-b3-11-4f-87-ac remapped to /tftpboot//grub.cfg-01-6c-b3-11-4f-87-acOct 22 09:50:05 sc-ironic04 in.tftpd[318152]: Client 10.33.23.94 File not found /tftpboot//grub.cfg-01-6c-b3-11-4f-87-acOct 22 09:50:05 sc-ironic04 in.tftpd[318152]: sending NAK (1, File not found) to 10.33.23.94Oct 22 09:50:05 sc-ironic04 in.tftpd[318153]: remap: input: /grub.cfg-0A21175EOct 22 09:50:05 sc-ironic04 in.tftpd[318153]: remap: rule 2: rewrite: /tftpboot//grub.cfg-0A21175EOct 22 09:50:05 sc-ironic04 in.tftpd[318153]: remap: rule 2: exitOct 22 09:50:05 sc-ironic04 in.tftpd[318153]: RRQ from 10.33.23.94 filename /grub.cfg-0A21175E remapped to /tftpboot//grub.cfg-0A21175EOct 22 09:50:05 sc-ironic04 in.tftpd[318153]: Client 10.33.23.94 File not found /tftpboot//grub.cfg-0A21175EOct 22 09:50:05 sc-ironic04 in.tftpd[318153]: sending NAK (1, File not found) to 10.33.23.94Oct 22 09:50:05 sc-ironic04 in.tftpd[318154]: remap: input: /grub.cfg-0A21175Oct 22 09:50:05 sc-ironic04 in.tftpd[318154]: remap: rule 2: rewrite: /tftpboot//grub.cfg-0A21175Oct 22 09:50:05 sc-ironic04 in.tftpd[318154]: remap: rule 2: exitOct 22 09:50:05 sc-ironic04 in.tftpd[318154]: RRQ from 10.33.23.94 filename /grub.cfg-0A21175 remapped to /tftpboot//grub.cfg-0A21175Oct 22 09:50:05 sc-ironic04 in.tftpd[318154]: Client 10.33.23.94 File not found /tftpboot//grub.cfg-0A21175Oct 22 09:50:05 sc-ironic04 in.tftpd[318154]: sending NAK (1, File not found) to 10.33.23.94Oct 22 09:50:05 sc-ironic04 in.tftpd[318155]: remap: input: /grub.cfg-0A2117Oct 22 09:50:05 sc-ironic04 in.tftpd[318155]: remap: rule 2: rewrite: /tftpboot//grub.cfg-0A2117Oct 22 09:50:05 sc-ironic04 in.tftpd[318155]: remap: rule 2: exitOct 22 09:50:05 sc-ironic04 in.tftpd[318155]: RRQ from 10.33.23.94 filename /grub.cfg-0A2117 remapped to /tftpboot//grub.cfg-0A2117Oct 22 09:50:05 sc-ironic04 in.tftpd[318155]: Client 10.33.23.94 File not found /tftpboot//grub.cfg-0A2117Oct 22 09:50:05 sc-ironic04 in.tftpd[318155]: sending NAK (1, File not found) to 10.33.23.94Oct 22 09:50:05 sc-ironic04 in.tftpd[318156]: remap: input: /grub.cfg-0A211Oct 22 09:50:05 sc-ironic04 in.tftpd[318156]: remap: rule 2: rewrite: /tftpboot//grub.cfg-0A211Oct 22 09:50:05 sc-ironic04 in.tftpd[318156]: remap: rule 2: exitOct 22 09:50:05 sc-ironic04 in.tftpd[318156]: RRQ from 10.33.23.94 filename /grub.cfg-0A211 remapped to /tftpboot//grub.cfg-0A211Oct 22 09:50:05 sc-ironic04 in.tftpd[318156]: Client 10.33.23.94 File not found /tftpboot//grub.cfg-0A211Oct 22 09:50:05 sc-ironic04 in.tftpd[318156]: sending NAK (1, File not found) to 10.33.23.94Oct 22 09:50:05 sc-ironic04 in.tftpd[318157]: remap: input: /grub.cfg-0A21Oct 22 09:50:05 sc-ironic04 in.tftpd[318157]: remap: rule 2: rewrite: /tftpboot//grub.cfg-0A21Oct 22 09:50:05 sc-ironic04 in.tftpd[318157]: remap: rule 2: exitOct 22 09:50:05 sc-ironic04 in.tftpd[318157]: RRQ from 10.33.23.94 filename /grub.cfg-0A21 remapped to /tftpboot//grub.cfg-0A21Oct 22 09:50:05 sc-ironic04 in.tftpd[318157]: Client 10.33.23.94 File not found /tftpboot//grub.cfg-0A21Oct 22 09:50:05 sc-ironic04 in.tftpd[318157]: sending NAK (1, File not found) to 10.33.23.94Oct 22 09:50:05 sc-ironic04 in.tftpd[318158]: remap: input: /grub.cfg-0A2Oct 22 09:50:05 sc-ironic04 in.tftpd[318158]: remap: rule 2: rewrite: /tftpboot//grub.cfg-0A2Oct 22 09:50:05 sc-ironic04 in.tftpd[318158]: remap: rule 2: exitOct 22 09:50:05 sc-ironic04 in.tftpd[318178]: RRQ from 10.33.23.94 filename /EFI/centos/grub.cfg remapped to /tftpboot//EFI/centos/grub.cfgOct 22 09:50:05 sc-ironic04 in.tftpd[318178]: Client 10.33.23.94 finished /EFI/centos/grub.cfgOct 22 09:50:05 sc-ironic04 in.tftpd[318179]: remap: input: /EFI/centos/grub.cfgOct 22 09:50:05 sc-ironic04 in.tftpd[318179]: remap: rule 2: rewrite: /tftpboot//EFI/centos/grub.cfgOct 22 09:50:05 sc-ironic04 in.tftpd[318179]: remap: rule 2: exitOct 22 09:50:05 sc-ironic04 in.tftpd[318179]: RRQ from 10.33.23.94 filename /EFI/centos/grub.cfg remapped to /tftpboot//EFI/centos/grub.cfgOct 22 09:50:05 sc-ironic04 in.tftpd[318179]: Client 10.33.23.94 finished /EFI/centos/grub.cfgOct 22 09:50:07 sc-ironic04 ironic-conductor: 2019-10-22 09:50:07.298 267066 DEBUG futurist.periodics [-] Submitting periodic callback 'ironic.conductor.manager.ConductorManager._sync_local_state' _process_scheduled /usr/lib/python2.7/site-packages/futurist/periodics.py:639Oct 22 09:50:07 sc-ironic04 ironic-conductor: 2019-10-22 09:50:07.298 267066 INFO ironic.conductor.manager [-] Executing sync_local_stateOct 22 09:50:07 sc-ironic04 ironic-conductor: 2019-10-22 09:50:07.305 267066 DEBUG ironic.common.hash_ring [-] Rebuilding cached hash rings ring /usr/lib/python2.7/site-packages/ironic/common/hash_ring.py:51Oct 22 09:50:07 sc-ironic04 ironic-conductor: 2019-10-22 09:50:07.466 267066 DEBUG ironic.common.hash_ring [-] Finished rebuilding hash rings, available drivers are ipmi, fake, snmp, fake_pxe, pxe_snmp, agent_ipmitool, pxe_ipmitool ring /usr/lib/python2.7/site-packages/ironic/common/hash_ring.py:56Oct 22 09:50:10 sc-ironic04 in.tftpd[318184]: remap: input: /tftpboot/10.33.23.94.confOct 22 09:50:10 sc-ironic04 in.tftpd[318184]: remap: rule 0: rewrite: /tftpboot/10.33.23.94.confOct 22 09:50:10 sc-ironic04 in.tftpd[318184]: remap: rule 0: exitOct 22 09:50:10 sc-ironic04 in.tftpd[318184]: RRQ from 10.33.23.94 filename /tftpboot/10.33.23.94.confOct 22 09:50:10 sc-ironic04 in.tftpd[318184]: Client 10.33.23.94 finished /tftpboot/10.33.23.94.confOct 22 09:50:10 sc-ironic04 in.tftpd[318185]: remap: input: /tftpboot/10.33.23.94.confOct 22 09:50:10 sc-ironic04 in.tftpd[318185]: remap: rule 0: rewrite: /tftpboot/10.33.23.94.confOct 22 09:50:10 sc-ironic04 in.tftpd[318185]: remap: rule 0: exitOct 22 09:50:10 sc-ironic04 in.tftpd[318185]: RRQ from 10.33.23.94 filename /tftpboot/10.33.23.94.confOct 22 09:50:10 sc-ironic04 in.tftpd[318185]: Client 10.33.23.94 finished /tftpboot/10.33.23.94.confOct 22 09:50:10 sc-ironic04 in.tftpd[318186]: remap: input: /tftpboot/10.33.23.94.confOct 22 09:50:10 sc-ironic04 in.tftpd[318186]: remap: rule 0: rewrite: /tftpboot/10.33.23.94.confOct 22 09:50:10 sc-ironic04 in.tftpd[318186]: remap: rule 0: exitOct 22 09:50:10 sc-ironic04 in.tftpd[318186]: RRQ from 10.33.23.94 filename /tftpboot/10.33.23.94.confOct 22 09:50:10 sc-ironic04 in.tftpd[318186]: Client 10.33.23.94 finished /tftpboot/10.33.23.94.confOct 22 09:50:15 sc-ironic04 in.tftpd[318192]: remap: input: d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_kernelOct 22 09:50:15 sc-ironic04 in.tftpd[318192]: remap: rule 3: rewrite: /tftpboot/d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_kernelOct 22 09:50:15 sc-ironic04 in.tftpd[318192]: remap: rule 3: exitOct 22 09:50:15 sc-ironic04 in.tftpd[318192]: RRQ from 10.33.23.94 filename d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_kernel remapped to /tftpboot/d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_kernelOct 22 09:50:15 sc-ironic04 ironic-conductor: 2019-10-22 09:50:15.898 267066 DEBUG futurist.periodics [-] Submitting periodic callback 'ironic.conductor.manager.ConductorManager._check_rescuewait_timeouts' _process_scheduled /usr/lib/python2.7/site-packages/futurist/periodics.py:639Oct 22 09:50:15 sc-ironic04 in.tftpd[318192]: Client 10.33.23.94 finished d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_kernelOct 22 09:50:15 sc-ironic04 in.tftpd[318194]: remap: input: d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_ramdiskOct 22 09:50:15 sc-ironic04 in.tftpd[318194]: remap: rule 3: rewrite: /tftpboot/d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_ramdiskOct 22 09:50:15 sc-ironic04 in.tftpd[318194]: remap: rule 3: exitOct 22 09:50:15 sc-ironic04 in.tftpd[318194]: RRQ from 10.33.23.94 filename d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_ramdisk remapped to /tftpboot/d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_ramdisk Oct 22 09:50:44 sc-ironic04 in.tftpd[318194]: Client 10.33.23.94 finished d465fa17-a2ea-43ff-a3a7-033cbb497774/deploy_ramdiskOct 22 09:50:44 sc-ironic04 in.tftpd[318194]: Client 10.33.23.94 timed out This has me stumped here. This exact failure seems to be happening 3 to 4 times a week on different nodes.Any pointers appreciated. thanks,Fred.

2 1

[ptg][neutron][all] Project onboarding session
by Slawek Kaplonski 23 Oct '19

23 Oct '19

Hi, As a Neutron team we are planning to do onboarding session on Wednesday morning during the Shanghai PTG. I’m wondering if there are any ways to reach to as much people as it is possible with information when this onboarding will take place and I’m sure that putting it just in PTG etherpad will not be enough for potential newcomers. So I have a question if there are any other ways to announce when exactly such onboarding session will be? And maybe how other teams are announcing that. Thx in advance for any tips on clues :) — Slawek Kaplonski Senior software engineer Red Hat

1 0

[nova] Which nova container service that nova/conf/compute.py map to
by yu.chengde＠99cloud.net 23 Oct '19

23 Oct '19

Hi, I have deployed a stein version openstack on server thought Kolla-ansible method. Then, I git clone the nova code, and ready to do coding in " nova/nova/conf/compute.py" However, many of nova containers include this file. So, I want to know that I should modify them all, or just pick a specific one. Thanks [root@chantyu kolla-ansible]# docker ps | grep nova 05f72e539974 kolla/centos-source-nova-compute:stein "dumb-init --single-…" 28 hours ago Up 2 hours nova_compute 7393a7d566ee kolla/centos-source-nova-libvirt:stein "dumb-init --single-…" 28 hours ago Up 5 hours nova_libvirt 9d8357cfa334 kolla/centos-source-nova-scheduler:stein "dumb-init --single-…" 32 hours ago Up 3 hours nova_scheduler 085b9da918df kolla/centos-source-nova-api:stein "dumb-init --single-…" 6 days ago Up 3 hours nova_api b80e9503e93e kolla/centos-source-nova-serialproxy:stein "dumb-init --single-…" 6 days ago Up 3 hours nova_serialproxy c15d41823a22 kolla/centos-source-nova-novncproxy:stein "dumb-init --single-…" 6 days ago Up 3 hours nova_novncproxy c30e47cd56c6 kolla/centos-source-nova-consoleauth:stein "dumb-init --single-…" 6 days ago Up 3 hours nova_consoleauth b7d5e9ba1f11 kolla/centos-source-nova-ssh:stein "dumb-init --single-…" 7 days ago Up 5 hours nova_ssh 3f81cd0a97ce kolla/centos-source-nova-conductor:stein "dumb-init --single-…" 7 days ago Up 3 hours nova_conductor [root@chantyu kolla-ansible]#

4 4

[tc][all] Community-wide goal Ussuri and V cycle forum collaboration idea
by Ghanshyam Mann 23 Oct '19

23 Oct '19

Hello Everyone, During the TC meeting on 10th Oct, we discussed the community-wide goal planning for Ussuri as well as the V cycle[1] but there was no consensus on V cycle planning so I am bringing this to ML for further thoughts. Ussuri cycle goal planning is all good here, That has been already started[2] and we have a dedicated forum session [3] for the same to discuss the goals in more detail. Question is for V cycle goal planning, whether we should discuss the V cycle goal in Ussuri goal fourm sessoin[3] or it is too early to kick off V cycle goal at least until we finalize U cycle goal first. I would like to list the below two options to proceed further (at least to decide if we need to change the existing U cycle goal forum sessions title). 1. Merge the Forum session for both cycle goal discussion (divide both in two half). This need forum session title and description change. 2. Keep forum session for U cycle goal only and start the V cycle over ML asynchronously. This will help to avoid any confusion or mixing the both cycle goal discussions. Thoughts? [1] http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-10-10-14.00.log.htm… [2] https://etherpad.openstack.org/p/PVG-u-series-goals [3] https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24398… -gmann

2 2

[Infra][Cinder] IBM Storage OpenStack CI Gerrit account issue
by Ling LL Chen 23 Oct '19

23 Oct '19

Hi Dear, This is Linda from IBM Storage cinder team. Currently we need to set up the OpenStack CI environment. But now we failed to configure the Gerrit server with ssh key pair. We only know the Gerrit account is "ibm_storage_ci", but we don't know which mail address used for this account. Would you please help to check this Gerrit account "ibm_storage_ci" and provide the detail information with us? Thanks. Regards, Chen Ling(Linda,陈玲) ------------------------------------------- Cloud Storage Solutions Development (CSSD) IBM System SRA troubleshooting wiki: https://apps.na.collabserv.com/wikis/home?lang=en-us#!/wiki/W9c4e08533b49_4… Tel: (8621)6092-8292 Ext:28292 Address: 3F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New District, Shanghai 201203, China -------------------------------------------

2 1

[sigs][publiccloud][publiccloud-wg][publiccloud-sig] Bi-weekly meeting for the Public Cloud SIG tomorrow CANCELLED
by Tobias Rydberg 23 Oct '19

23 Oct '19

Hi all, Need to cancel tomorrows meeting since I will be on a flight at that time. Hope to see most of you in Shanghai in less than 2 weeks. Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

1 0

[Openstack] OpenStack Train for Ubuntu 18.04 LTS
by Corey Bryant 23 Oct '19

23 Oct '19

The Ubuntu OpenStack team at Canonical is pleased to announce the general availability of OpenStack Train on Ubuntu 18.04 LTS via the Ubuntu Cloud Archive. Details of the Train release can be found at: https://www.openstack.org/software/train To get access to the Ubuntu Train packages: Ubuntu 18.04 LTS ----------------------- You can enable the Ubuntu Cloud Archive pocket for OpenStack Train on Ubuntu 18.04 installations by running the following commands: sudo add-apt-repository cloud-archive:train sudo apt update The Ubuntu Cloud Archive for Train includes updates for: aodh, barbican, ceilometer, ceph (14.2.2), cinder, designate, designate-dashboard, dpdk (18.11.2), glance, gnocchi, heat, heat-dashboard, horizon, ironic, keystone, libvirt (5.4.0), magnum, manila, manila-ui, mistral, murano, murano-dashboard, networking-arista, networking-bagpipe, networking-bgpvpn, networking-hyperv, networking-l2gw, networking-mlnx, networking-odl, networking-ovn, networking-sfc, neutron, neutron-dynamic-routing, neutron-fwaas, neutron-lbaas, neutron-lbaas-dashboard, neutron-vpnaas, nova, octavia, openstack-trove, openvswitch (2.12.0), panko, placement, qemu (4.0), sahara, sahara-dashboard, senlin, swift, trove-dashboard, vmware-nsx, watcher, and zaqar. For a full list of packages and versions, please refer to: http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/train_vers… Python support ------------------- The Train release of Ubuntu OpenStack is Python 3 only; all Python 2 packages have been dropped in Train. Branch package builds ----------------------------- If you would like to try out the latest updates to branches, we deliver continuously integrated packages on each upstream commit via the following PPA’s: sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata sudo add-apt-repository ppa:openstack-ubuntu-testing/queens sudo add-apt-repository ppa:openstack-ubuntu-testing/rocky sudo add-apt-repository ppa:openstack-ubuntu-testing/train Reporting bugs ------------------- If you have any issues please report bugs using the 'ubuntu-bug' tool to ensure that bugs get logged in the right place in Launchpad: sudo ubuntu-bug nova-conductor Thanks to everyone who has contributed to OpenStack Train, both upstream and downstream. Special thanks to the Puppet OpenStack modules team and the OpenStack Charms team for their continued early testing of the Ubuntu Cloud Archive, as well as the Ubuntu and Debian OpenStack teams for all of their contributions. Enjoy and see you in Ussuri! Corey (on behalf of the Ubuntu OpenStack team)

1 0

[RelMgmt] Release team meeting cancelled Oct 24
by Sean McGinnis 23 Oct '19

23 Oct '19

Hey all, We discussed this in last week's meeting, but just a reminder that we will be skipping the release team meeting this Thursday, October 24. We are reaching the final deadline for the stable/queens branch to transition to Extended Maintenance. Please watch for anything related to that and help review final release patches if you can. Anything else that comes up, we can just address ad hoc in the #openstack-release channel. Thanks! Sean

1 0

"Large Scale SIG" discussion in Shanghai
by Thierry Carrez 23 Oct '19

23 Oct '19

Hi everyone, As OpenStack clusters grow larger, they hit scaling limitations in a number of components. To work around this problem, operators create multiple clusters. In recent visits to OpenStack users, I noticed a common theme around people interested in working to scale single clusters past their current limits. In the past we had various groups trying to identify bottlenecks or work on alternate technologies (RabbitMQ replacements): the Performance WG, or the "Large deployment" WG. However those groups had a bit of a wide focus, and/or are not active anymore. In Shanghai we'll discuss creating a "Large Scale SIG" that would tackle specifically those single-cluster-scaling issues. The idea is that by sharing performance analysis, it can help identify key bottlenecks. By pooling development resources, it can push fixes or new features to address those issues. I directly reached out to several people and organizations interested in working on that. Please join the session in Shanghai if you'll be present there and are interested in discussing this topic: https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24405… -- Thierry Carrez (ttx)

1 0

[tacker][ptg] Ussuri PTG Planning for Tacker
by Dharmendra Kushwaha 22 Oct '19

22 Oct '19

Hello Everyone, I have created an etherpad [1] to collect the topics for Shanghai PTG discussion for Tacker. Please start drafting/adding your topics which you want to discuss in PTG. Even if anyone not be physically available for PTG, but want to discuss their topics, please add in etherpad, we will discuss. [1]: https://etherpad.openstack.org/p/Tacker-PTG-Ussuri Thanks & Regards Dharmendra Kushwaha

1 0

[tc][goal]: Ussuri community goal candidate 2: 'Switch remaining legacy jobs to Zuul v3 and drop legacy support'
by Ghanshyam Mann 22 Oct '19

22 Oct '19

Hello Everyone, As you might have seen on the ML about Ussuri community goal feedback for each proposed candidate [1], 2nd candidate is 'Switch remaining legacy jobs to Zuul v3 and drop legacy support' [2]. Andreas has briefed this goal in etherpad[2]. "Convert the remaining legacy jobs to Zuul v3 features. Grenade might be the largest open issue. This means especially that devstack-gate will not support Ussuri but only older releases. Having all jobs migrated to Zuul v3 native will allow easier maintenance and sharing between them. " Zuul has good documentation about migrating the legacy job to zuulv3 native. devstack and tempest have already migrated all their legacy jobs and so does many projects also ( if not all but few jobs for sure). Keeping legacy jobs are very costly not just in term of maintenance but also for doing the community-wide work. I have experienced the same during the migration of upstream CI from xenial - > Bionic in stein and IPV6 goal in Train. Currently, we do not have any volunteers to lead this goal. I would like to ask for the volunteer who can drive this goal do the pre-work about defining the goal and then be champion for this goal. Feel Free to reply to this email or ping me on #openstack-tc IRC channel. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010287.… [2] https://etherpad.openstack.org/p/PVG-u-series-goals -gmann

2 2

[helm][loci][rpm][ironic] Please fill deployment tool capabilities
by Thierry Carrez 22 Oct '19

22 Oct '19

OpenStack-Helm, LOCI, RPM-packaging & Bifrost (ironic) folks: We recently started to display deployment tools capabilities over at: https://www.openstack.org/software/project-navigator/deployment-tools However OpenStack-Helm, LOCI, RPM Packaging and Bifrost display only the (default) component:keystone capability, because they were not filled when we we last asked[1][2]. As such, they look a bit sad. Please propose a patch to the following file: https://opendev.org/osf/openstack-map/src/branch/master/deployment_tools.ya… Capabilities are described in detail in: https://opendev.org/osf/openstack-map/src/branch/master/deployment_tools_ca… Let me know if you have any question, [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007585.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-July/008150.html -- Thierry Carrez (ttx)

2 1

[Watcher] No meeting on October 23 and November 6
by li.canwei2＠zte.com.cn 22 Oct '19

22 Oct '19

Hi all, I'm no time tomorrow and Nov 6 is during the Openstack Shanghai Summit, so canceling the IRC meeting. thanks! licanwei

1 0

[neutron] CI meeting cancelled
by Slawek Kaplonski 21 Oct '19

21 Oct '19

Hi, I’m on training this week and I can’t lead CI meeting. As also some other people who usually attends our CI meeting are also on the same training, lets cancel the meeting this week. We will back with CI meetings next week, so 29.10. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[openstack-discuss][Airship] Call for PTG Participation for Airship
by prakash RAMCHANDRAN 21 Oct '19

21 Oct '19

Hi all, We seek active participation from community to enable Airship design and deployment for new release v2 in progress.Join us at PTG & mini-PTG to complete the Specs for MVP Beta (v2) before we get to November monthly sprint targets.Add your name topics and any topics you want to be bring forth. PTG at Shnnghai - Airship PTG Ussuri Half day Thursday Nov 7th, full day Friday Nov 8th https://etherpad.openstack.org/p/airship-ptg-ussuri Airship KubeCon mini-PTG San DiegoMonday, 12:30-6:30 [planning on kicking off @ 1pm] https://etherpad.openstack.org/p/airship-kubecon-san-diego ThanksPrakash / For Airship PTG/mini-PTGs

1 0

RMQ notifications.info has no consumers
by Albert Braden 21 Oct '19

21 Oct '19

I installed the RMQ management plugin in my dev and qa clusters and noticed a queue called notifications.info that has 0 consumers: root@us01odc-qa-ctrl1:~# rabbitmqctl list_queues|grep notific notifications.info 15496 If I cold-start RMQ it starts without a notifications.info queue but after I create a VM it appears with 1 or 2 messages and then gradually grows over time. The messages in it appear to be Openstack operations: {"oslo.message": "{\"_context_domain\": null, \"_context_roles\": [\"admin\"], \"_context_global_request_id\": null, \"event_type\": \"dns.domain.exists\", \"_context_edit_managed_records\": false, \"_context_service_catalog\": null, \"timestamp\": \"2019-10-10 21:02:01.524052\", \"_context_all_tenants\": true, \"_unique_id\": \"326b8e30d10f40279d806384e7023954\", \"_context_resource_uuid\": null, \"_context_request_id\": \"req-a16c0cd5-94c3-4bf7-90ed-3ab677cc8e66\", \"_context_is_admin_project\": true, \"_context_tsigkey_id\": null, \"_context_client_addr\": null, \"payload\": {\"updated_at\": \"2019-09-24T15:08:55.000000\", \"minimum\": 3600, \"ttl\": 60, \"serial\": 1569337730, \"deleted_at\": null, \"id\": \"67840d5f-6b98-449c-80c4-4d3e3ee74d19\", \"parent_zone_id\": null, \"retry\": 600, \"transferred_at\": null, \"version\": 470, \"type\": \"PRIMARY\", \"email\": \"linux-admin-core(a)synopsys.com\", \"status\": \"ACTIVE\", \"description\": null, \"deleted\": \"0\", \"shard\": 1656, \"action\": \"NONE\", \"expire\": 86400, \"audit_period_beginning\": \"2019-10-10T20:02:01.486946\", \"masters\": [], \"name\": \"sg.us01-qa.synopsys.com.\", \"tenant_id\": \"80a60cda79be4ec48e12683478f0cf3b\", \"created_at\": \"2019-09-05T17:18:47.000000\", \"pool_id\": \"794ccc2c-d751-44fe-b57f-8894c9f5c842\", \"refresh\": 3545, \"delayed_notify\": false, \"audit_period_ending\": \"2019-10-10T21:02:01.486946\", \"attributes\": []}, \"_context_auth_token\": null, \"_context_system_scope\": null, \"_context_original_tenant\": null, \"_context_user_identity\": \"- - - - -\", \"_context_show_deleted\": false, \"_context_tenant\": null, \"_context_hide_counts\": false, \"priority\": \"INFO\", \"_context_read_only\": false, \"_context_is_admin\": true, \"_context_abandon\": null, \"_context_project_domain\": null, \"_context_user\": null, \"_context_user_domain\": null, \"publisher_id\": \"producer.us01odc-qa-ctrl2\", \"message_id\": \"0ceae8e3-e6df-4b08-8b1e-c6d8e75d456d\", \"_context_project\": null}", "oslo.version": "2.0"} I didn't install the management plugin in prod, but it appears that I have the same issue there: root@us01odc-p01-ctrl1:~# rabbitmqctl list_queues|grep notific notifications.info 226869 What should be consuming the notifications.info queue?

4 3

[infra] Trying to reproduce an OpenStack CI run
by Neil Jerram 21 Oct '19

21 Oct '19

I'm trying to reproduce an OpenStack CI run on a fresh Ubuntu Bionic VM, like this: sudo apt-get update sudo apt-get install -y python-all-dev build-essential git libssl-dev ntp ntpdate libre2-dev python-pip sudo pip install virtualenv wget https://1a5e1b314637dd59968a-fddd31f569f44d98bd401bfd88253d97.ssl.cf5.rackc… chmod +x reproduce.sh sudo ./reproduce.sh The last line runs for a short while but then fails with: [...] Successfully built zuul PyYAML voluptuous PrettyTable ansible sqlalchemy alembic cachecontrol psutil fb-re2 paho-mqtt ws4py Mako repoze.lru pycparser Installing collected packages: pbr, six, python-dateutil, uritemplate, urllib3, certifi, chardet, idna, requests, enum34, ipaddress, pycparser, cffi, cryptography, jwcrypto, github3.py, PyYAML, pynacl, bcrypt, paramiko, smmap2, gitdb2, GitPython, docutils, lockfile, python-daemon, extras, statsd, voluptuous, gear, pytz, tzlocal, funcsigs, futures, apscheduler, PrettyTable, babel, MarkupSafe, jinja2, ansible, netaddr, kazoo, sqlalchemy, Mako, python-editor, alembic, msgpack, cachecontrol, pyjwt, iso8601, psutil, fb-re2, paho-mqtt, contextlib2, more-itertools, zc.lockfile, backports.functools-lru-cache, jaraco.functools, tempora, portend, cheroot, cherrypy, ws4py, repoze.lru, routes, zuul Successfully installed GitPython-2.1.14 Mako-1.1.0 MarkupSafe-1.1.1 PrettyTable-0.7.2 PyYAML-5.1.2 alembic-1.2.1 ansible-2.5.15 apscheduler-3.6.1 babel-2.7.0 backports.functools-lru-cache-1.5 bcrypt-3.1.7 cachecontrol-0.12.5 certifi-2019.9.11 cffi-1.13.0 chardet-3.0.4 cheroot-8.2.1 cherrypy-17.4.2 contextlib2-0.6.0.post1 cryptography-2.8 docutils-0.15.2 enum34-1.1.6 extras-1.0.0 fb-re2-1.0.7 funcsigs-1.0.2 futures-3.3.0 gear-0.14.0 gitdb2-2.0.6 github3.py-1.3.0 idna-2.8 ipaddress-1.0.23 iso8601-0.1.12 jaraco.functools-2.0 jinja2-2.10.3 jwcrypto-0.6.0 kazoo-2.6.1 lockfile-0.12.2 more-itertools-5.0.0 msgpack-0.6.2 netaddr-0.7.19 paho-mqtt-1.4.0 paramiko-2.6.0 pbr-5.4.3 portend-2.5 psutil-5.6.3 pycparser-2.19 pyjwt-1.7.1 pynacl-1.3.0 python-daemon-2.0.6 python-dateutil-2.8.0 python-editor-1.0.4 pytz-2019.3 repoze.lru-0.7 requests-2.22.0 routes-2.4.1 six-1.12.0 smmap2-2.0.5 sqlalchemy-1.3.10 statsd-3.3.0 tempora-1.14.1 tzlocal-2.0.0 uritemplate-3.0.0 urllib3-1.25.6 voluptuous-0.11.7 ws4py-0.5.1 zc.lockfile-2.0 zuul-3.2.0 + cat + /usr/zuul-env/bin/zuul-cloner -m clonemap.yaml --cache-dir /opt/git https://opendev.org openstack/devstack-gate ./reproduce.sh: line 112: /usr/zuul-env/bin/zuul-cloner: No such file or directory Can you see what I'm doing wrong? Many thanks, Neil

3 4

Re: [Release-job-failures] release-post job for openstack/releases for ref refs/heads/master failed
by Thierry Carrez 21 Oct '19

21 Oct '19

zuul(a)openstack.org wrote: > Build failed. > > - tag-releases https://zuul.opendev.org/t/openstack/build/f5018416e3e443af88c0e1c7981bacfd : RETRY_LIMIT in 1m 41s > - publish-tox-docs-static https://zuul.opendev.org/t/openstack/build/None : SKIPPED This is the second similar issue in a row in tag-releases: https://zuul.opendev.org/t/openstack/builds?job_name=tag-releases Root cause seems to be: LOOP [Add origin remote to enable notes fetching] fatal: remote origin already exists. Coincides with start of usage of 'prepare-workspace-git' (instead of 'use-cached-repos' which apparently worked better): https://opendev.org/opendev/base-jobs/commit/59f84f00db1c6be614bb713c055b13… use-cached-repos removed the origin, while prepare-workspace-git replaces it by a zuul fake origin. We should probably tweak: https://opendev.org/openstack/project-config/src/branch/master/playbooks/re… Once fixed we'll need to reenqueue this one to process the tags correctly. -- Thierry Carrez (ttx)

1 1

[tripleo] tripleoclient and tripleo-common have stable/train branch
by Emilien Macchi 21 Oct '19

21 Oct '19

We branched stable/train for python-tripleoclient and tripleo-common. Please do the backports to that branch when necessary. We'll continue with branching hopefully today or tomorrow. Let me know if any questions, -- Emilien Macchi

1 1

Deployment tools capabilities now displayed on openstack.org/software
by Thierry Carrez 21 Oct '19

21 Oct '19

Hi everyone, During the Train cycle, we pushed to provide better information to users of OpenStack on the differences between the various upstream ways to deploy OpenStack. We first defined a number of deployment tools capabilities[1] and then asked our various deployment tools to fill out which capabilities applied to them[2]. [1] https://opendev.org/osf/openstack-map/src/branch/master/deployment_tools_ca… [2] https://opendev.org/osf/openstack-map/src/branch/master/deployment_tools.ya… Those capabilities are now displayed on the website at: https://www.openstack.org/software/project-navigator/deployment-tools Thanks for everyone who helped defining and providing this information. Please feel free to propose improvements through changes to the osf/openstack-map repository. Cheers, -- Thierry Carrez (ttx)

2 2

[keystone] Keystone Team Update - Week of 14 October 2019
by Colleen Murphy 21 Oct '19

21 Oct '19

# Keystone Team Update - Week of 14 October 2019 ## News ### Train Released Keystone has been successfully released for the Train cycle! Congratulations everyone on a smooth release. Check out the release notes[1] for details on what's new in this release. [1] https://docs.openstack.org/releasenotes/keystone/train.html ## Office Hours When there are topics to cover, the keystone team holds office hours on Tuesdays at 17:00 UTC. No office hours next week due to no topics. Add topics you would like to see covered during office hours to the etherpad: https://etherpad.openstack.org/p/keystone-office-hours-topics ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 21 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 39 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Roadmap Stories - Keystone to Keystone Testing https://tree.taiga.io/project/keystone-ussuri-roadmap/us/39 + https://review.opendev.org/580041 Keystone to Keystone tests + https://review.opendev.org/689208 Use up-to-date federation job names + https://review.opendev.org/689222 Add option to disable testing against external idp + https://review.opendev.org/689223 Add voting k2k tests - Federated Attributes for Users https://tree.taiga.io/project/keystone-ussuri-roadmap/us/32 + https://review.opendev.org/448755 Add federated support for creating a user + https://review.opendev.org/448730 https://review.opendev.org/448730 * Needs Discussion - https://review.opendev.org/687753 Drop project.id foreign keys - https://review.opendev.org/687756 Revert "Resource backend is SQL only now" * Oldest - https://review.opendev.org/373983 OpenID Connect improved support * Special Requests - https://review.opendev.org/687362 Set up for Ussuri - https://review.opendev.org/689558 Fix line-length PEP8 errors for c7fae97 - https://review.opendev.org/689559 Re-enable line-length linter * Closes Bugs - https://review.opendev.org/687990 Stop adding entry in local_user while updating ephemerals - https://review.opendev.org/688939 Remove group deletion for non-sql driver when removing domains. - https://review.opendev.org/685042 Fetch discovery documents with auth when needed ## Bugs This week we opened 5 new bugs and closed 2. Bugs opened (5) Bug #1848238 (keystone:Medium) opened by Sami Makki https://bugs.launchpad.net/keystone/+bug/1848238 Bug #1848342 (keystone:Medium) opened by Pedro Henrique Pereira Martins https://bugs.launchpad.net/keystone/+bug/1848342 Bug #1848400 (keystone:Undecided) opened by Eric Xie https://bugs.launchpad.net/keystone/+bug/1848400 Bug #1848470 (keystone:Undecided) opened by yongyi,ren https://bugs.launchpad.net/keystone/+bug/1848470 Bug #1848625 (keystone:Undecided) opened by David Coronel https://bugs.launchpad.net/keystone/+bug/1848625 Bugs closed (2) Bug #1848400 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1848400 Bug #1848625 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1848625 Bugs fixed (0) ## Milestone Outlook https://releases.openstack.org/ussuri/schedule.html Keystone-specific deadlines have been proposed[2]. [2] https://review.opendev.org/689549 ## Shout-outs Thanks to the whole team for making this a smooth release! ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

3 2

[neutron] Bug deputy Oct 14 - Oct 20
by Hongbin Lu 20 Oct '19

20 Oct '19

Hi all, I am on the bug deputy role last week. Below is the report: High * https://bugs.launchpad.net/neutron/+bug/1848545 Remove PostgreSQL support in Neutron Medium * https://bugs.launchpad.net/neutron/+bug/1848152 Update mtu of network has no validation * https://bugs.launchpad.net/neutron/+bug/1848187 DHCP agent timing out spawning dnsmasq * https://bugs.launchpad.net/neutron/+bug/1848738 Sometimes dnsmasq may not be restarted after adding new subnet * https://bugs.launchpad.net/neutron/+bug/1848213 Do not pass port-range to backend if all ports specified in security group rule Low * https://bugs.launchpad.net/neutron/+bug/1848147 not mocking openstacksdk exception may cause random non detected errors in unit tests * https://bugs.launchpad.net/neutron/+bug/1848201 [neutron-vpnaas] Neutron installed inside venv makes VPNaaS broken * https://bugs.launchpad.net/neutron/+bug/1848220 TestMinBwQoSOvs is not calling the correct methods * https://bugs.launchpad.net/neutron/+bug/1848851 move fwaas_v2_log constants to neutron-lib Wishlist * https://bugs.launchpad.net/neutron/+bug/1848500 Implement an OpenFlow monitor Undecided * https://bugs.launchpad.net/neutron/+bug/1848311 trunk + subports not working * https://bugs.launchpad.net/neutron/+bug/1848131 <https://bugs.launchpad.net/neutron/+bug/1848131> [FWaaS] Support blacklist filtering Best regards, Hongbin

1 0

[kolla][ovs][networking] LLDP support within an internal network?
by Laurent Dumont 19 Oct '19

19 Oct '19

Hey everyone, Somewhat of a random question, but is there any built-in support within OVS to carry LLDP traffic between instances running on the same Tenant network? I know that linux-br will eat the LLDP traffic by default. So far, enabling LLDP on the port "qbr" allows the hypervisor to see the instances hosted on that hypervisor. The instances can see the hypervisor as well. That said, instances cannot see each other. All are residing within the same L2 network and are able to have L2 between each other. I am seeing the LLDP packets from the hypervisor arriving on the instance internal interface but nothing from the other instances. I am seeing the outgoing LLDP packets on each interfaces as well. Let me know if anything else is required. Thanks!

2 2

[cinder][tooz]Lock-files are remained
by Rikimaru Honjo 19 Oct '19

19 Oct '19

Hi, I'm using Queens cinder with the following setting. --------------------------------- [coordination] backend_url = file://$state_path --------------------------------- As a result, the files like the following were remained under the state path after some operations.[1] cinder-63dacb3d-bd4d-42bb-88fe-6e4180164765-delete_volume cinder-32c426af-82b4-41de-b637-7d76fed69e83-delete_snapshot In my understanding, these are lock-files created for synchronization by tooz. But, these lock-files were not deleted after finishing operations. Is this behaviour correct? [1] e.g. Delete volume, Delete snapshot -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikimaru@ntt-tx.co.jp

7 15

[neutron]: How to find the version of the L2 agent
by fsbiz＠yahoo.com 18 Oct '19

18 Oct '19

I know neutron-server --version gives me the version of the neutron server currently running.For the recent queens release it is 12.1.0 Is there a command or easy way to check the version of the L2 agent on the compute hosts? We are running the the neutron-linuxbridge-agent. thanks,Fred.

2 2

[oslo][security] Are config files vetted for ownership/permissions?
by Eric Fried 18 Oct '19

18 Oct '19

When $service loads up a config file like /etc/nova/nova.conf via oslo.config, is there anything that makes sure the dir and/or file are owned by the process user/group and have appropriate permissions? E.g. to prevent $hacker from modifying/replacing config opts and making $service do horrible things to my system/cloud. (I'm less concerned with $hacker seeing passwords etc., though I expect we would be accounting for both or neither.) efried .

2 1

[stable][oslo] Supporting qemu 4.1.0 on stein and older
by Ben Nemec 18 Oct '19

18 Oct '19

Hi, This is related to the FFE for train, but I wanted to discuss it separately because I think the circumstances are a bit different. Qemu 4.1.0 did not exist during the Stein cycle, so it's not clear to me that backporting bug fixes for it is valid. The original author of the patch actually wants it for Rocky, which is basically in the same situation as Stein. I should note he's willing to carry the patch downstream if necessary. On the one hand, it sounds like this is something at least one operator wants, but on the other I'm not sure the stable policy supports backporting patches to support a version of a dependency that didn't exist when the release was initially cut. I'm soliciting opinions on how to proceed here. Reference: https://review.opendev.org/#/c/686532 Thanks. -Ben

4 7

[openstack-operators] RBD problems after data center power outage
by Dinçer Çelik 18 Oct '19

18 Oct '19

Greetings, Today I had a data center power outage, and the OpenStack cluster went down. After taking the cluster up again, I cannot start some VMs due to error below. I've tried "rbd object-map rebuild" but it didn't work. What's the proper way to re-create the missing "_disk.config" files? Thanks. [instance: c2b54eac-179b-4907-9d61-8e075edc21cf] Failed to start libvirt guest: libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2019-10-17T23:19:41.103720Z qemu-system-x86_64: -drive file=rbd:vms/c2b54eac-179b-4907-9d61-8e075edc21cf_disk.config:id=nova:auth_supported=cephx\;none:mon_host=10.250.129.10\:6789\;10.250.129.11\:6789\;10.250.129.12\:6789\;10.250.129.15\:6789,file.password-secret=ide0-0-0-secret0,format=raw,if=none,id=drive-ide0-0-0,readonly=on,cache=writeback,discard=unmap: error reading header from c2b54eac-179b-4907-9d61-8e075edc21cf_disk.config: No such file or directory /* Please encrypt every message you can. Privacy is your right, don't let anyone take it from you. */ /* My fingerprint is: 5E50 ABB0 F108 24DA 10CC BD43 D2AE DD2A 7893 0EAA */

3 5

[nova] Stance on trivial features for driver configs without integration testing
by Matt Riedemann 18 Oct '19

18 Oct '19

This was brought up in the nova meeting today [1] as: "Do we have a particular stance on features to the libvirt driver for non-integration tested configurations, e.g. lxc [2] and xen [3], meaning if they are trivial enough do we just say the driver's quality warning on startup is sufficient to let them land since these are changes from casual contributors scratching an itch?" We agreed to move this to the mailing list. We don't have tempest jobs for the libvirt+lxc or libvirt+xen configurations (Citrix used to host 3rd party CI for the latter) and for the changes referenced they are from part-time contributors, minor and self-contained, and therefore I wouldn't expect them to build CI jobs for those configurations or stand up 3rd party CI. There are cases in the past where we've held features out due to lack of CI, e.g. live migration support in the vSphere driver. That's quite a bit different in my opinion because (1) it's a much more complicated feature, (2) there already was 3rd party CI for the vSphere driver and (3) there is a big rich corporation maintaining the driver so I figured they could pony up the resources to make that testing happen (and it eventually did). For these other small changes are we OK with letting them in knowing that the libvirt driver already logs a quality warning on startup for these configs [4]? In this case I am but wanted to ask and I don't think this sets a precedent as not all changes are equal. [1] http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-10-17-14.00.log… [2] https://review.opendev.org/#/c/667976/ [3] https://review.opendev.org/#/c/687827/ [4] https://github.com/openstack/nova/blob/1a226aaa9e8c969ddfdfe198c36f7966b1f6… -- Thanks, Matt

7 8

[metrics] [telemetry] [stein] cpu_util
by Budai Laszlo 18 Oct '19

18 Oct '19

Hello all, the release release announce of ceilometer rocky is deprecating the cpu_util and *.rate metrics "* cpu_util and *.rate meters are deprecated and will be removed in future release in favor of the Gnocchi rate calculation equivalent." so we don't have them in Stein. Can you direct me to some document that describes how to achieve these with Gnocchi rate calculation? Thank you, Laszlo

5 4

[all][ceilometer][aodh][[docs] Possible error in Stein's Aodh documentation and how to configure cpu_util and pass on value to Aodh
by Gauri Sindhu 17 Oct '19

17 Oct '19

Hi all, As per the Rocky release notes <https://docs.openstack.org/releasenotes/ceilometer/rocky.html>, *cpu_util and *.rate meters are deprecated and will be removed in future release in favor of the Gnocchi rate calculation equivalent.* I have two doubts regarding this. Firstly, if the 'cpu_util' metric has been deprecated then why has it been used as an example in the documentation <https://docs.openstack.org/aodh/stein/admin/telemetry-alarms.html> in the 'Using Alarms' section? I've attached an image of the same. Secondly, I'm using OpenStack Stein and want to use the cpu_util or its equivalent to create an alarm. If this metric is no longer available then what do I pass onto Aodh to create the alarm? There seems to be no documentation that to help me out with this. Additionally, even if Gnocchi rate calculation is to be used, how am I supposed to transfer the result to Aodh? I also cannot seem to find the Gnocchi documentation. Regards, Gauri Sindhu

2 4

[aodh] [heat] Stein: How to create alarms based on rate metrics like CPU utilization?
by Bernd Bausch 17 Oct '19

17 Oct '19

Prior to Stein, Ceilometer issued a metric named /cpu_util/, which I could use to trigger alarms and autoscaling when CPU utilization was too high. cpu_util doesn't exist anymore. Instead, we are asked to use Gnocchi's /rate/ feature. However, when using rates, alarms on a group of resources require more parameters than just one metric: Both an aggregation and a reaggregation method are needed. For example, a group of instances that implement "myapp": gnocchi measures aggregation -m cpu --reaggregation mean --aggregation rate:mean --query server_group=myapp --resource-type instance Actually, this command uses a deprecated API (but from what I can see, Aodh still uses it). The new way is like this: gnocchi aggregates --resource-type instance '(aggregate rate:mean (metric cpu mean))' server_group=myapp If rate:mean is in the archive policy, it also works the other way around: gnocchi aggregates --resource-type instance '(aggregate mean (metric cpu rate:mean))' server_group=myapp Without reaggregation, I get quite unexpected numbers, including negative CPU rates. If you want to understand why, see this discussion with one of the Gnocchi maintainers [1]. *My problem*: Aodh allows me to set an aggregation method, but not a reaggregation method. How can I create alarms based on rates? The problem extends to Heat and autoscaling. Thanks much, Bernd. [1] https://github.com/gnocchixyz/gnocchi/issues/1044

4 3

PostgreSQL driver has been removed from DevStack
by Stephen Finucane 17 Oct '19

17 Oct '19

Just a heads up that the PostgreSQL DB driver has been removed from DevStack as of today [1]. This was deprecated in Pike due to lack of maintenance and has been on the chopping block since then. If you have jobs that relied on this, it would be advisable to drop these jobs now. I don't think the DevStack team have the resources to maintain this so if someone *really* needed to keep it around, they should probably put together a plugin and consume it that way. Stephen [1] https://review.opendev.org/#/c/678496/

4 5

[tripleo] owls at ptg
by Wesley Hayutin 17 Oct '19

17 Oct '19

Greetings, A number of folks from TripleO will be at the OpenDev PTG. If you would like to discuss anything and collaborate please list your topic on this etherpad [1] Thank you! [1] https://etherpad.openstack.org/p/tripleo-ussuri-topics

3 2

[Neutron] Metering agent issues
by Eric K. Miller 17 Oct '19

17 Oct '19

Hi, We have a Stein deployment using Kolla Ansible 8.0.1 (the latest) and have enabled the deployment of the neutron metering agent. We have separate network nodes and compute nodes and use DVR. DVR is working properly, where ingress and egress traffic to floating IPs binded to fixed IPs flows directly to our upstream routers, not through the network nodes, whereas SNAT traffic flows through the network nodes. I configured the agent using the simplest of rules to test the agent (as cloud admin): openstack network meter create --description Shared --share bandwidth openstack network meter rule create --egress --remote-ip-prefix 0.0.0.0/0 bandwidth openstack network meter rule create --ingress --remote-ip-prefix 0.0.0.0/0 bandwidth None of the compute nodes appeared to be metering. So I checked the metering agent log (see below my signature for a snippet of the respective log entries), which shows that no routers are being found. Note that the Debug flag is set to True (in metering_agent.ini). On the primary network node, the "get_traffic_counters" method returns a list of all routers for every project, and runs a respective meter retrieval for each, such as the following, for each router: 2019-10-17 15:29:30.437 6 DEBUG neutron.agent.linux.utils [-] Running command (rootwrap daemon): ['ip', 'netns', 'exec', 'qrouter-e0d2ee4f-76ec-4043-93f7-a47fae488d59', 'iptables', '-t', 'filter', '-L', 'neutron-meter-l-fb2c912d-9ce', '-n', '-v', '-x', '-w', '10', '-Z'] execute_rootwrap_daemon /var/lib/kolla/venv/lib/python2.7/site-packages/neutron/agent/linux/util s.py:103 However, a single metering report is being created. Only one debug row appears in the log, and only one "bandwidth metric" measure is added to Gnocchi: 2019-10-17 15:38:15.494 6 DEBUG neutron.services.metering.agents.metering_agent [-] Send metering report: {'label_id': u'fb2c912d-9ced-433b-914e-df6526e034d1', 'time': 30, 'pkts': 0, 'tenant_id': u'96b2e5246a7744219e2af51f0e7b91d6', 'first_update': 1571300562, 'bytes': 0, 'host': 'networknode002', 'last_update': 1571344695} _metering_notification /var/lib/kolla/venv/lib/python2.7/site-packages/neutron/services/meterin g/agents/metering_agent.py:103 No errors are being reported in the logs. Am I missing something? Thanks! Eric 2019-10-17 15:25:12.418 6 DEBUG oslo_concurrency.lockutils [-] Lock "metering-agent" acquired by "neutron.services.metering.agents.metering_agent._invoke_driver" :: waited 0.000s inner /var/lib/kolla/venv/lib/python2.7/site-packages/oslo_concurrency/lockuti ls.py:327 2019-10-17 15:25:12.418 6 DEBUG neutron.services.metering.drivers.iptables.iptables_driver [-] neutron.services.metering.drivers.iptables.iptables_driver.IptablesMeter ingDriver method get_traffic_counters called with arguments (<neutron_lib.context.ContextBase object at 0x7f661dfa9c90>, []) {} wrapper /var/lib/kolla/venv/lib/python2.7/site-packages/oslo_log/helpers.py:66 2019-10-17 15:25:12.418 6 DEBUG oslo_concurrency.lockutils [-] Lock "metering-agent" released by "neutron.services.metering.agents.metering_agent._invoke_driver" :: held 0.000s inner /var/lib/kolla/venv/lib/python2.7/site-packages/oslo_concurrency/lockuti ls.py:339 2019-10-17 15:25:27.421 6 DEBUG neutron.services.metering.agents.metering_agent [-] Get router traffic counters _get_traffic_counters /var/lib/kolla/venv/lib/python2.7/site-packages/neutron/services/meterin g/agents/metering_agent.py:215 2019-10-17 15:25:27.421 6 DEBUG oslo_concurrency.lockutils [-] Lock "metering-agent" acquired by "neutron.services.metering.agents.metering_agent._invoke_driver" :: waited 0.000s inner /var/lib/kolla/venv/lib/python2.7/site-packages/oslo_concurrency/lockuti ls.py:327 2019-10-17 15:25:27.421 6 DEBUG neutron.services.metering.drivers.iptables.iptables_driver [-] neutron.services.metering.drivers.iptables.iptables_driver.IptablesMeter ingDriver method get_traffic_counters called with arguments (<neutron_lib.context.ContextBase object at 0x7f661dfa9c90>, []) {} wrapper /var/lib/kolla/venv/lib/python2.7/site-packages/oslo_log/helpers.py:66 2019-10-17 15:25:27.421 6 DEBUG oslo_concurrency.lockutils [-] Lock "metering-agent" released by "neutron.services.metering.agents.metering_agent._invoke_driver" :: held 0.000s inner /var/lib/kolla/venv/lib/python2.7/site-packages/oslo_concurrency/lockuti ls.py:339

1 0

[tc] Feedback on Airship pilot project
by Jeremy Stanley 17 Oct '19

17 Oct '19

Hi TC members, The Airship project will start its confirmation process with the OSF Board of Directors at the Board meeting[1] Tuesday next week. A draft of the slide deck[2] they plan to present is available for reference. Per the confirmation guidelines[3], the OSF Board of directors will take into account the feedback from representative bodies of existing confirmed Open Infrastructure Projects (OpenStack, Zuul and Kata) when evaluating Airship for confirmation. Particularly worth calling out, guideline #4 "Open collaboration" asserts the following: Project behaves as a good neighbor to other confirmed and pilot projects. If you (our community at large, not just TC members) have any observations/interactions with the Airship project which could serve as useful examples for how these projects do or do not meet this and other guidelines, please provide them on the etherpad[4] ASAP. If possible, include a citation with links to substantiate your feedback. If a TC representative can assemble this feedback and send it to the Board (for example, to the foundation mailing list) for consideration before the meeting next week, that would be appreciated. Apologies for the short notice. [1] http://lists.openstack.org/pipermail/foundation/2019-October/002800.html [2] https://www.airshipit.org/collateral/AirshipConfirmation-Review-for-the-OSF… [3] https://wiki.openstack.org/wiki/Governance/Foundation/OSFProjectConfirmatio… [4] https://etherpad.openstack.org/p/openstack-tc-airship-confirmation-feedback -- Jeremy Stanley

3 4

[monasca] Ussuri planning meeting summary
by Witek Bedyk 17 Oct '19

17 Oct '19

Hello everyone, yesterday we held a planning meeting for the next release cycle (Ussuri). You can find the summary of the meeting in the etherpad [1]. Please discuss with your teams and vote for the proposed topics in this spreadsheet [2] until next Wednesday. We meet next week again to agree on priorities during the regular Team Meeting hour, Wednesday, 15 UTC [3]. Thanks Witek [1] https://etherpad.openstack.org/p/monasca-planning-ussuri [2] https://docs.google.com/spreadsheets/d/17PLO8PJr28jXuPaFJ7efZCwgdgMpinZyDRT… [3] https://global.gotomeeting.com/join/817873693

1 0

[nova][gate] Hold off on rechecks until https://review.opendev.org/689152/ merges
by Matt Riedemann 17 Oct '19

17 Oct '19

The gate is blocked for nova changes until [1] is merged so hold off on rechecking anything until then. [1] https://review.opendev.org/#/c/689152/ -- Thanks, Matt

1 0

[openstacksdk][RelMgmt] release-post job for openstack/releases for ref refs/heads/master failed
by Sean McGinnis 17 Oct '19

17 Oct '19

----- Forwarded message from zuul(a)openstack.org ----- Date: Thu, 17 Oct 2019 10:19:24 +0000 From: zuul(a)openstack.org To: release-job-failures(a)lists.openstack.org Subject: [Release-job-failures] release-post job for openstack/releases for ref refs/heads/master failed Reply-To: openstack-discuss(a)lists.openstack.org Build failed. - tag-releases https://zuul.opendev.org/t/openstack/build/571c0f0e43cb469d8727121b77a3c92b : FAILURE in 3m 14s - publish-tox-docs-static https://zuul.opendev.org/t/openstack/build/None : SKIPPED _______________________________________________ Release-job-failures mailing list Release-job-failures(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures ----- End forwarded message ----- The tagging of the new stable/queens OpenStackSDK release failed. It appears to be due to the .gitreview file in that branch still referring to the python-openstacksdk name. That caused the automation to fail on trying to interact with that repo, but it has since been renamed to openstack/openstacksdk. Since this wasn't able to process the release, even though the patch had merged, I think the fix is actually fairly easy. I've proposed a backport of the repo name changes with: https://review.opendev.org/#/c/689131/ If we were to do another release to pick up that change, I believe it would actually fail validation because it would not find the current 0.11.4 tag and therefore think that two releases were needed instead of just one. So since it was not able to process anything to actually perform the release, I believe the easy path forward is to just revert the release patch of this last release: https://review.opendev.org/#/c/689132/ Then wait for the .gitreview patch to merge, then propose the 0.11.4 release again with the hash updated to include that rename fix. Please let me know if there are any questions or if I've overlooked anything. Thanks, Sean

1 0

CentOS 8 nodes available now
by Ian Wienand 17 Oct '19

17 Oct '19

Hello, I'm happy to say that CentOS 8 images are now live in OpenDev infra. Using a node label of "centos-8" will get you started. --- The python environment setup on these images is different to our other images. Firstly, some background: currently during image build we go to some effort to: a) install the latest pip/virtualenv/setuptools b) ensure standard behaviour: /usr/bin/python -> python2 /usr/bin/pip -> python2 install /usr/bin/pip3 -> python3 install /usr/bin/virtualenv -> creates python2 environment by default; python3 virtualenv package in sync This means a number of things; hosts always have python2, and because we overwrite the system pip/virtualenv/setuptools we put these packages on "hold" (depending on the package manager) so jobs don't re-install them and create (even more of) a mess. This made sense in the past, when we had versions of pip/setuptools in distributions that couldn't understand syntax in requirements files (and other bugs) and didn't have the current fantastic job inheritance and modularity that Zuul (v3) provides. However, it also introduces a range of problems for various users, and has a high maintenance overhead. Thus these new images are, by default, python3 only, and have upstream pip and virtualenv packages installed. You will have a default situation: /usr/bin/python -> not provided /usr/bin/pip -> not provided, use /usr/bin/pip3 or "python3 -m pip" /usr/bin/virtualenv -> create python3 environment; provided by upstream python3-virtualenv package /usr/bin/pyvenv -> not provided (is provided by Ubuntu python3-venv), use /usr/bin/pyvenv-3 or "python3 -m venv". Ergo, the "standard behaviour" is not so standard any more. I would suggest if you wish to write somewhat portable jobs/roles etc., you do the following: * in general don't rely on "unversioned" calls of tools at all (python/pip/virtualenv) -- they can all mean different things on different platforms. * scripts should always be #!/usr/bin/python3 * use "python3 -m venv" for virtual environments (if you really need "virtualenv" because of one of the features it provides, use "-m virtualenv") * use "python3 -m pip" to install global pip packages; but try not too -- mixing packages and pip installs never works that well. * if you need python2 for some reason, use a bindep file+role to install it (don't assume it is there) --- For any Zuul admins, note that to use python3-only images similar to what we make, you'll need to set "python-path" to python3 in nodepool so that Ansible calls the correct remote binary. Keep an eye on [1] which will automate this for Ansible >=2.8 after things are merged and released. --- Most of the job setup has been tested (network configs, setting mirrors, adding swap etc.) but there's always a chance of issues with a new platform. Please bring up any issues in #openstack-infra and we'll be sure to get them fixed. --- If you're interested in the images, they are exported at https://nb01.openstack.org/images/ although they are rather large, because we pre-cache a lot. If you'd like to build your own, [2] might help with: DISTRO=centos-minimal DIB_RELEASE=8 --- Thanks, -i [1] https://review.opendev.org/#/c/682797/ [2] https://opendev.org/openstack/project-config/src/branch/master/tools/build-…

5 5

[placement][ptg] Ussuri Placement Topics
by Tetsuro Nakamura 17 Oct '19

17 Oct '19

Hi Placementers, We won't have a specific meeting space for Shanghai PTG, but I'd like to have retrospective on Stein, and gather and note work items we have. Please put your ideas on the etherpad [1]. [1] https://etherpad.openstack.org/p/placement-shanghai-ptg -- Tetsuro Nakamura <tetsuro.nakamura.bc(a)hco.ntt.co.jp> NTT Network Service Systems Laboratories TEL:0422 59 6914(National)/+81 422 59 6914(International) 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan

1 0