October 2019 - openstack-discuss - lists.openstack.org

[cinder][ops][extended-maintenance-sig][public-cloud-sig][enterprise-wg] request for info about stable branch usage
by Brian Rosmaita 28 Oct '19

28 Oct '19

Cinder currently has nine (9) branches open, which is a lot. (See [0] for a graphical representation.) We'd like to close some. In release chronological order, the eight stable branches are: 1. driverfixes/mitaka 2. driverfixes/newton The above pre-date the OpenStack-wide extended maintenance phase [1] for stable branches; they were created after mitaka and newton went EOL so that there'd be a place where operators could get backported fixes for Cinder drivers only. 3. stable/ocata 4. stable/pike 5. stable/queens The above are currently in the extended maintenance phase. Vulnerability Management is done on a reasonable effort basis only, and there's no official statement of level of testing (could be extremely limited). This phase also means that there are no longer any official releases of these branches. So like driverfixes, any bug fixes merged must be picked up and applied by someone downstream. 6. stable/rocky 7. stable/stein 8. stable/train The above are in the 'maintained' phase [2] and not really the subject of this email (they're just listed for completeness). Ok, so here's what the Cinder team would like to know. 1. We're assuming that no one is using driverfixes/mitaka anymore and would like to kill it. Are we correct? 2. Is anyone still relying upon driverfixes/newton? It contains 98 commits after the 9.1.4 tag (the final Cinder Newton release), so it's been getting a lot of love from the team. This is a key issue, because if we keep this branch open, the OpenStack stable branch "appropriate fixes" policy (point #4) implies that we must keep stable ocata, pike, and queens open as well. 3. As far as the Extended Maintenance branches go, it seems that ocata and pike could go EOL. At the very least, we may need to reduce the gate coverage on stable/ocata as there are rumors that it doesn't play nice with Zuul v3. Is anyone relying on stable/ocata or stable/pike ? Thank you for your attention to this matter. I should mention that the Cinder team doesn't mind keeping branches open (as you can see by the number of commits into driverfixes/newton), we just want to make sure they're being used so we can allocate our resources efficiently. It would be really helpful if you could respond before November 1 (that is, before the end of this week) so we can make a decision at the PTG. [0] https://launchpad.net/cinder/+series [1] https://docs.openstack.org/project-team-guide/stable-branches.html#extended… [2] https://docs.openstack.org/project-team-guide/stable-branches.html#maintain… [3] https://docs.openstack.org/project-team-guide/stable-branches.html#appropri…

1 0

[openstack-ansible] core updates
by Mohammed Naser 28 Oct '19

28 Oct '19

Hi everyone, I'd like to propose the addition of the following 2 new core members: - Georgina Shippey (BBC R&D, committed continuous contributor and operator) - James Denton (long time contributor, extremely knowledgeable in OSA) If no one opposes to this, I will be adding them to our core list shortly. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. https://vexxhost.com

7 7

[heat] software deployment doen not work on queens (timed out)
by Ignazio Cassano 25 Oct '19

25 Oct '19

Hello All, I created a simple heat stack on queens with SoftwareDeployment but it does not terminate because timed out. The following is my simple stack template: heat_template_version: queens parameters: key_name: type: string default: opstkcsi flavor: type: string default: m1.small image: type: string default: centos7 resources: config: type: OS::Heat::SoftwareConfig properties: inputs: - name: previous default: 'NONE' group: script config: | #!/bin/bash echo "Previous: $previous" echo "${deploy_resource_name} is running on $(hostname) at $(date)" deployment_a: type: OS::Heat::SoftwareDeployment properties: config: get_resource: config server: get_resource: server_a deployment_b: type: OS::Heat::SoftwareDeployment properties: input_values: previous: get_attr: [deployment_a, deploy_stdout] config: get_resource: config server: get_resource: server_b deployment_c: type: OS::Heat::SoftwareDeployment depends_on: deployment_b properties: input_values: previous: 'deployment_b' config: get_resource: config server: get_resource: server_a server_a: type: OS::Nova::Server properties: flavor: get_param: flavor networks: - network: "565" key_name: get_param: key_name block_device_mapping: [{ device_name: "vda", volume_id : { get_resource : volume1 }, delete_on_termination : "false" }] user_data_format: SOFTWARE_CONFIG server_b: type: OS::Nova::Server properties: flavor: get_param: flavor networks: - network: "565" key_name: get_param: key_name block_device_mapping: [{ device_name: "vda", volume_id : { get_resource : volume2 }, delete_on_termination : "false" }] user_data_format: SOFTWARE_CONFIG volume1: type: OS::Cinder::Volume properties: name: "Server-RootDisk" image: { get_param: image } size: 20 volume2: type: OS::Cinder::Volume properties: name: "Server-RootDisk" image: { get_param: image } size: 20 outputs: deployment_a_stdout: value: get_attr: [deployment_a, deploy_stdout] deployment_b_stdout: value: get_attr: [deployment_b, deploy_stdout] deployment_c_stdout: value: get_attr: [deployment_c, deploy_stdout] It works on ocata but timed out on queens. I connected on the first virtual machine for debugging and I launched: ystemctl stop os-collect-config.service and then: sudo os-collect-config --force --one-time --debug It reports the following: HTTPConnectionPool(host='10.102.184.83', port=8000): Read timed out. (read timeout=10.0) Source [cfn] Unavailable. /var/lib/os-collect-config/local-data not found. Skipping [2019-10-25 21:02:31,948] (os-refresh-config) [INFO] Starting phase pre-configure dib-run-parts ven 25 ott 2019, 21.02.31, CEST ----------------------- PROFILING ----------------------- dib-run-parts ven 25 ott 2019, 21.02.31, CEST dib-run-parts ven 25 ott 2019, 21.02.31, CEST Target: pre-configure.d dib-run-parts ven 25 ott 2019, 21.02.31, CEST dib-run-parts ven 25 ott 2019, 21.02.31, CEST Script Seconds dib-run-parts ven 25 ott 2019, 21.02.31, CEST --------------------------------------- ---------- dib-run-parts ven 25 ott 2019, 21.02.31, CEST dib-run-parts ven 25 ott 2019, 21.02.31, CEST dib-run-parts ven 25 ott 2019, 21.02.31, CEST --------------------- END PROFILING --------------------- [2019-10-25 21:02:31,987] (os-refresh-config) [INFO] Completed phase pre-configure [2019-10-25 21:02:31,987] (os-refresh-config) [INFO] Starting phase configure dib-run-parts ven 25 ott 2019, 21.02.32, CEST Running /usr/libexec/os-refresh-config/configure.d/20-os-apply-config [2019/10/25 09:02:32 PM] [INFO] writing /var/run/heat-config/heat-config [2019/10/25 09:02:32 PM] [INFO] writing /etc/os-collect-config.conf [2019/10/25 09:02:32 PM] [INFO] success dib-run-parts ven 25 ott 2019, 21.02.32, CEST 20-os-apply-config completed dib-run-parts ven 25 ott 2019, 21.02.32, CEST Running /usr/libexec/os-refresh-config/configure.d/55-heat-config dib-run-parts ven 25 ott 2019, 21.02.32, CEST 55-heat-config completed dib-run-parts ven 25 ott 2019, 21.02.32, CEST ----------------------- PROFILING ----------------------- dib-run-parts ven 25 ott 2019, 21.02.32, CEST dib-run-parts ven 25 ott 2019, 21.02.32, CEST Target: configure.d dib-run-parts ven 25 ott 2019, 21.02.32, CEST dib-run-parts ven 25 ott 2019, 21.02.32, CEST Script Seconds dib-run-parts ven 25 ott 2019, 21.02.32, CEST --------------------------------------- ---------- dib-run-parts ven 25 ott 2019, 21.02.32, CEST dib-run-parts Fri Oct 25 21:02:32 CEST 2019 20-os-apply-config 0.316 dib-run-parts Fri Oct 25 21:02:32 CEST 2019 55-heat-config 0.165 dib-run-parts ven 25 ott 2019, 21.02.32, CEST dib-run-parts ven 25 ott 2019, 21.02.32, CEST --------------------- END PROFILING --------------------- [2019-10-25 21:02:32,530] (os-refresh-config) [INFO] Completed phase configure [2019-10-25 21:02:32,530] (os-refresh-config) [INFO] Starting phase post-configure dib-run-parts ven 25 ott 2019, 21.02.32, CEST Running /usr/libexec/os-refresh-config/post-configure.d/99-refresh-completed ++ os-apply-config --key completion-handle --type raw --key-default '' + HANDLE= ++ os-apply-config --key completion-signal --type raw --key-default '' + SIGNAL= ++ os-apply-config --key instance-id --type raw --key-default '' + ID=i-00000049 + '[' -n i-00000049 ']' + '[' -n '' ']' + '[' -n '' ']' ++ os-apply-config --key deployments --type raw --key-default '' ++ jq -r 'map(select(.group == "os-apply-config") | select(.inputs[].name == "deploy_signal_id") | .id + (.inputs | map(select(.name == "deploy_signal_id")) | .[].value)) | .[]' + DEPLOYMENTS= + DEPLOYED_DIR=/var/lib/os-apply-config-deployments/deployed + '[' '!' -d /var/lib/os-apply-config-deployments/deployed ']' dib-run-parts ven 25 ott 2019, 21.02.33, CEST 99-refresh-completed completed dib-run-parts ven 25 ott 2019, 21.02.33, CEST ----------------------- PROFILING ----------------------- dib-run-parts ven 25 ott 2019, 21.02.33, CEST dib-run-parts ven 25 ott 2019, 21.02.33, CEST Target: post-configure.d dib-run-parts ven 25 ott 2019, 21.02.33, CEST dib-run-parts ven 25 ott 2019, 21.02.33, CEST Script Seconds dib-run-parts ven 25 ott 2019, 21.02.33, CEST --------------------------------------- ---------- dib-run-parts ven 25 ott 2019, 21.02.33, CEST dib-run-parts Fri Oct 25 21:02:33 CEST 2019 99-refresh-completed 1.231 dib-run-parts ven 25 ott 2019, 21.02.33, CEST dib-run-parts ven 25 ott 2019, 21.02.33, CEST --------------------- END PROFILING --------------------- [2019-10-25 21:02:33,811] (os-refresh-config) [INFO] Completed phase post-configure [2019-10-25 21:02:33,811] (os-refresh-config) [INFO] Starting phase migration dib-run-parts ven 25 ott 2019, 21.02.33, CEST ----------------------- PROFILING ----------------------- dib-run-parts ven 25 ott 2019, 21.02.33, CEST dib-run-parts ven 25 ott 2019, 21.02.33, CEST Target: migration.d dib-run-parts ven 25 ott 2019, 21.02.33, CEST dib-run-parts ven 25 ott 2019, 21.02.33, CEST Script Seconds dib-run-parts ven 25 ott 2019, 21.02.33, CEST --------------------------------------- ---------- dib-run-parts ven 25 ott 2019, 21.02.33, CEST dib-run-parts ven 25 ott 2019, 21.02.33, CEST dib-run-parts ven 25 ott 2019, 21.02.33, CEST --------------------- END PROFILING --------------------- [2019-10-25 21:02:33,848] (os-refresh-config) [INFO] Completed phase migration The first line: HTTPConnectionPool(host='10.102.184.83', port=8000): Read timed out. (read timeout=10.0) Source [cfn] Unavailable. It is strange: 10.102.184.83 is the vip public endpoint reported in my heat.conf: heat_metadata_server_url = http://10.102.184.83:8000 heat_waitcondition_server_url = http://10.102.184.83:8000/v1/waitcondition The virtual machine can contact the above addres on port 8000. Please, anyone can help me ? Regards Ignazio

1 0

[stable][EM] Extended Maintenance - Queens
by Elõd Illés 25 Oct '19

25 Oct '19

Hi, As it was agreed during PTG, the planned date of Extended Maintenance transition of Queens is around two weeks after Train release (a less busy period) [1]. Now that Train is released, it is a good opportunity for teams to go through the list of open and unreleased changes in Queens [2] and schedule a final release for Queens if needed. Feel free to use / edit / modify the lists (I've generated the lists for repositories which have 'follows-policy' tag). I hope this helps. [1] https://releases.openstack.org/ [2] https://etherpad.openstack.org/p/queens-final-release-before-em Thanks, Előd

6 7

[tc] Weekly update
by Rico Lin 25 Oct '19

25 Oct '19

Hello TC members, Here's some update for this week ** For summit update* - No launch time presentation due to launch place limitation - Joint Leadership Meeting will take place on Sunday [1] - TC Dinner update: Dinner is scheduled at 8:00 pm on Wednesday. More detail can be found in [2]. - Remember we now have two meet project leaders events settled during Summit - Monday: https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24417… - Wednesday: https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24426… - Right now, we already have some PTG session proposed in [2], please help to prepare it before PTG. And of course we still allow new suggestions, but be careful and make sure all members notice it. - PTG team photo will take place on Friday 11:50-12:00 ** We now have goal champions [5]:* - tosky for zuulv3 migration - diablo_rojo for `Project Specific New Contributor & PTL Docs` ** Reference to Airship TC confirmation feedbacks* - Airship is official now! here's what feedbacks OpenStack TCs provides [3] ** drop python 2.7 * - Discussion for drop python 2.7 in etherpad[7] and ML[4]. There's a lot of discussion happened in [6]. - Please review the schedule mentioned in [7]. - Also, action required for TC members as TC liaison for projects. ** Release naming status:* As mentioned in [8], we need TC members to vote on roll call. And by not give any vote means you're fine to let others decide if any of them are good. Thank you, everyone! And for who will come to Summit! See you in Shanghai:) [1] https://wiki.openstack.org/wiki/Governance/Foundation/3November2019BoardMee… [2] https://etherpad.openstack.org/p/PVG-TC-PTG [3] https://etherpad.openstack.org/p/openstack-tc-airship-confirmation-feedback [4] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010142.… [5] https://etherpad.openstack.org/p/PVG-u-series-goals [6] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019… [7] https://etherpad.openstack.org/p/drop-python2-support [8] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010106.… Regards, JP & Rico

1 0

[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 25 Oct '19

25 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 25 Oct '19

25 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