- openstack-discuss - lists.openstack.org

[release] Release countdown for week R-0, October 14-18
by Sean McGinnis 10 Oct '19

10 Oct '19

Development Focus ----------------- We will be releasing the coordinated OpenStack Train release next week, on Wednesday October 16th. Thanks to everyone involved in the Train cycle! We are now in pre-release freeze, so no new deliverable will be created until final release, unless a release-critical regression is spotted. Otherwise, teams attending the PTG in Shanghai should start to plan what they will be discussing there, by creating and filling team etherpads. You can find the list of etherpads at: http://ptg.openstack.org/etherpads.html General Information ------------------- On release day, the release team will produce final versions of deliverables following the cycle-with-rc release model, by re-tagging the commit used for the last RC. A patch doing just that will be proposed. PTLs and release liaisons should watch for that final release patch from the release team. While not required, we would appreciate having an ack from each team before we approve it on the 16th. Upcoming Deadlines & Dates -------------------------- Final Train release: October 16 Forum+PTG at Shanghai summit: November 4

1 1

Networking-vpp 19.08.1 for VPP 19.08.1 is now available
by Naveen Joy (najoy) 10 Oct '19

10 Oct '19

Hello All, We'd like to invite you to try out Networking-vpp 19.08.1. As many of you may already know, VPP is a fast user space forwarder based on the DPDK toolkit. VPP uses vector packet processing algorithms to minimize the CPU time spent on each packet to maximize throughput. Networking-vpp is a ML2 mechanism driver that controls VPP on your control and compute hosts to provide fast L2 forwarding under Neutron. This latest version of Networking-vpp is updated to work with VPP 19.08.1 In this release, we've worked on the below updates: - We've added ERSPAN support for Tap-as-a-Service (TaaS). Since ERSPAN provides remote port mirroring, you can now mirror your OpenStack traffic to a destination outside of OpenStack or to a remote OpenStack VM. This is a customized version of OpenStack TaaS. We will be working with the community to push our custom TaaS extensions upstream. In the meantime, you can access our modified TaaS code here[2]. For further info on installation and usage, you can read the TaaS-README[3]. - We've updated the code to be compatible with VPP 19.08 & 19.08.1 API changes. - We've updated the unit test framework to support python3.5 onwards. - We've added security-group support for Trunk subports. We've added support for neutron trunk_details extension. - We've fixed some bugs in our Trunk and L3 plugins that caused a race condition during port binding. - We've migrated our repo from OpenStack to OpenDev. - A recent change in nova caused live migration to fail for instances with NUMA characteristics. We've found that this is a limitation in nova and not VPP/Networking-vpp. It is still possible to use live migration with VPP/Networking-vpp. Please refer to the README[1] for further details. - We've been doing the usual round of bug fixes and updates. The code will work with VPP 19.08.1 and has been updated to keep up with Neutron Rocky and Stein. The README [1] explains how you can try out VPP with Networking-vpp using Devstack: the Devstack plugin will deploy the mechanism driver and VPP and should give you a working system with a minimum of hassle. We will be continuing our development for VPP's 20.01 release. We welcome anyone who would like to come help us. -- Naveen, Ian & Jerome [1] https://opendev.org/x/networking-vpp/src/branch/master/README.rst [2] https://github.com/jbeuque/tap-as-a-service [3] https://opendev.org/x/networking-vpp/src/branch/master/README_taas.txt

1 0

[charms] placement charm
by Corey Bryant 10 Oct '19

10 Oct '19

Hi All, I'd like to see if I can get some input on the current state of the Placement API split. For some background, the nova placement API was removed from nova in train, and it's been split into its own project. It's mostly just a basic API charm. The tricky part is the migration of tables from the nova_api database to the placement database. Code is located at: https://github.com/coreycb/charm-placement https://github.com/coreycb/charm-interface-placement https://review.opendev.org/#/q/topic:charms-train-placement+(status:open+OR… Test scenarios I've been testing with: 1) deploy nova-cc et al train, configure keystonev3, deploy instance 2) deploy nova-cc et al stein, configure keystonev3, deploy instance 1, deploy placement train, deploy instance 2, upgrade nova-cc to train, deploy instance 3 There is currently an issue with the second test scenario where instance 2 creation errors because nova-scheduler can't find a valid placement candidate (not sure of the exact error atm). However if I delete instance 1 before creating instance 2 it is created successfully. It feels like a DB related issue but I'm really not sure so I'll keep digging. Thanks! Corey

2 6

[nova] No meeting today
by Eric Fried 10 Oct '19

10 Oct '19

Hi all. I'm going to be on PTO, it sounds like several other key members will be absent, the US-time meetings have been very sparsely attended lately, and there are a few things on the agenda for which we should really have a quorum, so I'm canceling today's meeting. https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting Thanks, efried .

1 0

[tc] Time off for JP!
by Jean-Philippe Evrard 10 Oct '19

10 Oct '19

Hello, I will have limited access to internet and emails until the 23rd of October. For all urgent matters, you can contact Rico Lin, our vice-chair. Talk to you all later! Regards, JP

1 0

[tc] monthly meeting agenda
by Jean-Philippe Evrard 10 Oct '19

10 Oct '19

Hello everyone, Here's the agenda for our monthly TC meeting. It will happen next Thursday (10 October) at the usual time (1400 UTC) in #openstack-tc . If you can't attend, please put your name in the "Apologies for Absence" section in the wiki [1] Our meeting chair will be Alexandra (asettle). * Follow up on past action items ** ricolin: Follow up with SIG chairs about guidelines https://etherpad.openstack.org/p/SIGs-guideline ** ttx: contact interested parties in a new 'large scale' sig (help with mnaser, jroll reaching out to verizon media) ** Release Naming - Results of the TC poll - Next action * New initiatives and/or report on previous initiatives ** Help gmann on the community goals following our new goal process ** mugsie: to sync with dhellmann or release-team to find the code for the proposal bot ** jroll - ttx: Feedback from the forum selection committee -- Follow up on https://etherpad.openstack.org/p/PVG-TC-brainstorming -- Final accepted list? ** mnaser: sync up with swift team on python3 migration Thank you everyone! Regards, JP [1]: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

3 4

[ptl][release] Last call for RC updates
by Sean McGinnis 10 Oct '19

10 Oct '19

Hey everyone, This is just a reminder about tomorrow's deadline for a final RC for Train. There are several projects that have changes merged since cutting the stable/train branch. Not all of these changes need to be included in the initial Train coordinated release, but it would be good if there are translations and bug fixes merged to get them into a final RC while there's still time. After tomorrow's (Oct 10) deadline, we will only want to release something if it's absolutely critical. We will enter a quiet period from tomorrow until the coordinated release date next week to give time for packagers to complete their work and to make sure things are stable. Next week the last RC releases will then be retagged as the final release. Again, not all changes need to be included if they are not critical bugfixes or translations at this point. Stable releases can be done at any point after the official release date. Thanks for your help as we reach the end of the Train. Sean

2 2

[trove] Core team change
by Lingxian Kong 09 Oct '19

09 Oct '19

Hi, As the Ussuri dev cycle begins, it's time to make some changes to Trove core team. Unfortunately, except myself, there is no one actively contributing(including coding and reviewing) to Trove according to https://www.stackalytics.com/report/contribution/trove/90. Some of the reasons are probably because there was a significant change in Trove community in the history and the security concerns. However, as a member of a public cloud provider who deployed Trove, I've been trying my best to bring Trove back on track during the recent several dev cycles. Although it's very hard to make this decision, I am going to remove all the current members from the core team according to https://docs.openstack.org/project-team-guide/open-development.html, but everyone is encouraged to help review changes and join the core team again with enough valuable reviews and contributions. Thanks for all your contributions in the past. - Best regards, Lingxian Kong Catalyst Cloud

1 0

[tc] Weekly update
by Jean-Philippe Evrard 09 Oct '19

09 Oct '19

Hello friends, Here's what need attention for the OpenStack TC this week. 1. You should probably prepare our next meeting, happening on Thursday. Alexandra is preparing the topics and warming up the gifs already. 2. We still need someone to step up for the OpenStack User survey on the ML [2] 3. We have plenty of patches which haven't received a vote. 4. We only have two goals for Ussuri [3]. Having more goals makes it easier to select the goals amongst the suggested ones :) If you can socialize about those, that would be awesome. Thank you everyone! JP & Rico [1]: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2]: http://lists.openstack.org/pipermail/openstack-discuss/2019-September/00950… [3]: https://etherpad.openstack.org/p/PVG-u-series-goals

2 3

Re: [PTLs] [TC] OpenStack User Survey - PTL & TC Feedback
by Jay Bryant 09 Oct '19

09 Oct '19

Jimmy, I will take a User Survey feedback for the TC and let you know if we need additional information on anything. Thanks! Jay

1 0

Release Cycle Observations
by Donny Davis 09 Oct '19

09 Oct '19

As many of you know I am fairly new to public participation in Openstack, but I am a long time lurker and operator. This is my first cycle and I wanted to capture an observation on the release cycle of Openstack. *this is only an observation for discussion* Over the last week or so I have watch people just about kill themselves to get features into Openstack for this release. Everyone in this community appears to be giving it their all. And way to go everyone for pushing so hard. Seriously! So this brings me to my observation. Can the release cycle be modified to ease this push at the end? I think what we all want is a smooth and steady stream of features and bug fixes, but a 6 month release cycle seems to do directly the opposite. Also if everyone has gate issues at the end of the cycle, is it the gate or the cycle? The gate seemed to work fine early on... Maybe if we went to a Major / Minor release sort of system we could remove some burden to *get that feature into X release* and we could steady out that flow of features / bug fixes. Maybe something like a 9 month major, one month minor release cycle. It would also probably help with micro api versioning. I am sure the more experienced developers here can highlight pros / cons, etc of all of the release types. Just a thought. Tell me yours. ~/DonnyD

10 19

[all][PTG] Strawman Schedule
by Kendall Nelson 09 Oct '19

09 Oct '19

Hello Everyone! In the attached picture or link [0] you will find the proposed schedule for the various tracks at the Shanghai PTG in November. We did our best to avoid the key conflicts that the track leads (PTLs, SIG leads...) mentioned in their PTG survey responses, although there was no perfect solution that would avoid all conflicts especially when the event is three-ish days long and we have over 40 teams meeting. If there are critical conflicts we missed or other issues, please let us know, by October 6th at 7:00 UTC! -Kendall (diablo_rojo) [0] https://usercontent.irccloud-cdn.com/file/00mZ3Q3M/pvg_ptg_schedule.png

9 20

[Watcher] team meeting at 08:00 UTC today
by li.canwei2＠zte.com.cn 08 Oct '19

08 Oct '19

Hi, Watcher team will have a meeting at 08:00 UTC today in the #openstack-meeting-alt channel. The agenda is available on https://wiki.openstack.org/wiki/Watcher_Meeting_Agenda feel free to add any additional items. Thanks! Canwei Li

1 0

[openstack][heat-cfn] CFN Signaling with heat
by Ajay Kalambur (akalambu) 08 Oct '19

08 Oct '19

Hi I was trying the Software Deployment/Structured deployment of heat. I somehow can never get the signaling to work I see that authentication is happening but I don’t see a POST from the VM as a result stack is stuck in CREATE_IN_PROGRESS I see this message in my heat api cfn log which seems to suggest authentication is successful but it does not seem to POST. Have included debug output from VM and also the sample heat template I used. Don’t know if the template is correct as I referred some online examples to build it 2019-10-05 10:30:00.908 7 INFO heat.api.aws.ec2token [-] Checking AWS credentials.. 2019-10-05 10:30:00.909 7 INFO heat.api.aws.ec2token [-] AWS credentials found, checking against keystone. 2019-10-05 10:30:00.910 7 INFO heat.api.aws.ec2token [-] Authenticating with http://10.10.173.9:5000/v3/ec2tokens 2019-10-05 10:30:01.315 7 INFO heat.api.aws.ec2token [-] AWS authentication successful. 2019-10-05 10:30:02.326 7 INFO eventlet.wsgi.server [req-506f22c6-4062-4a84-8e85-40317a4099ed - adccd09df89e4b71b0a42f462679e75a-b1c6eb69-3877-466b-b00d-03dc051 - 0ecadd4762a34de1ac08508db4d3caa9 0ecadd4762a34de1ac08508db4d3caa9] 10.11.59.36,10.10.173.9 - - [05/Oct/2019 10:30:02] "GET /v1/?SignatureVersion=2&AWSAccessKeyId=f7874ac9898248edaae53511230534a4&StackName=test_stack&SignatureMethod=HmacSHA256&Signature=c03Q7Hb35q9tPPuYOv6YByn5YekF96p2s5zx36sX7x4%3D&Action=DescribeStackResource&LogicalResourceId=sig-vm-1 HTTP/1.1" 200 4669 1.418045 Some debugging output from my VM: [root@sig-vm-1 fedora]# sudo os-collect-config --force --one-time --debug /var/lib/os-collect-config/local-data not found. Skipping [2019-10-05 17:32:47,058] (os-refresh-config) [INFO] Starting phase pre-configure dib-run-parts Sat Oct 5 17:32:47 UTC 2019 ----------------------- PROFILING ----------------------- dib-run-parts Sat Oct 5 17:32:47 UTC 2019 dib-run-parts Sat Oct 5 17:32:47 UTC 2019 Target: pre-configure.d dib-run-parts Sat Oct 5 17:32:47 UTC 2019 dib-run-parts Sat Oct 5 17:32:47 UTC 2019 Script Seconds dib-run-parts Sat Oct 5 17:32:47 UTC 2019 --------------------------------------- ---------- dib-run-parts Sat Oct 5 17:32:47 UTC 2019 dib-run-parts Sat Oct 5 17:32:47 UTC 2019 dib-run-parts Sat Oct 5 17:32:47 UTC 2019 --------------------- END PROFILING --------------------- [2019-10-05 17:32:47,091] (os-refresh-config) [INFO] Completed phase pre-configure [2019-10-05 17:32:47,092] (os-refresh-config) [INFO] Starting phase configure dib-run-parts Sat Oct 5 17:32:47 UTC 2019 Running /usr/libexec/os-refresh-config/configure.d/20-os-apply-config [2019/10/05 05:32:47 PM] [INFO] writing /var/run/heat-config/heat-config [2019/10/05 05:32:47 PM] [INFO] writing /etc/os-collect-config.conf [2019/10/05 05:32:47 PM] [INFO] success dib-run-parts Sat Oct 5 17:32:47 UTC 2019 20-os-apply-config completed dib-run-parts Sat Oct 5 17:32:47 UTC 2019 Running /usr/libexec/os-refresh-config/configure.d/50-heat-config-docker-compose dib-run-parts Sat Oct 5 17:32:47 UTC 2019 50-heat-config-docker-compose completed dib-run-parts Sat Oct 5 17:32:47 UTC 2019 Running /usr/libexec/os-refresh-config/configure.d/50-heat-config-kubelet dib-run-parts Sat Oct 5 17:32:47 UTC 2019 50-heat-config-kubelet completed dib-run-parts Sat Oct 5 17:32:47 UTC 2019 Running /usr/libexec/os-refresh-config/configure.d/55-heat-config [2019-10-05 17:32:47,724] (heat-config) [ERROR] Skipping group Heat::Ungrouped with no hook script None [2019-10-05 17:32:47,724] (heat-config) [ERROR] Skipping group Heat::Ungrouped with no hook script None dib-run-parts Sat Oct 5 17:32:47 UTC 2019 55-heat-config completed dib-run-parts Sat Oct 5 17:32:47 UTC 2019 ----------------------- PROFILING ----------------------- dib-run-parts Sat Oct 5 17:32:47 UTC 2019 dib-run-parts Sat Oct 5 17:32:47 UTC 2019 Target: configure.d dib-run-parts Sat Oct 5 17:32:47 UTC 2019 dib-run-parts Sat Oct 5 17:32:47 UTC 2019 Script Seconds dib-run-parts Sat Oct 5 17:32:47 UTC 2019 --------------------------------------- ---------- dib-run-parts Sat Oct 5 17:32:47 UTC 2019 dib-run-parts Sat Oct 5 17:32:47 UTC 2019 20-os-apply-config 0.345 dib-run-parts Sat Oct 5 17:32:47 UTC 2019 50-heat-config-docker-compose 0.064 dib-run-parts Sat Oct 5 17:32:47 UTC 2019 50-heat-config-kubelet 0.134 dib-run-parts Sat Oct 5 17:32:47 UTC 2019 55-heat-config 0.065 dib-run-parts Sat Oct 5 17:32:47 UTC 2019 dib-run-parts Sat Oct 5 17:32:47 UTC 2019 --------------------- END PROFILING --------------------- [2019-10-05 17:32:47,787] (os-refresh-config) [INFO] Completed phase configure [2019-10-05 17:32:47,787] (os-refresh-config) [INFO] Starting phase post-configure dib-run-parts Sat Oct 5 17:32:47 UTC 2019 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-0000000d + '[' -n i-0000000d ']' + '[' -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 Sat Oct 5 17:32:49 UTC 2019 99-refresh-completed completed dib-run-parts Sat Oct 5 17:32:49 UTC 2019 ----------------------- PROFILING ----------------------- dib-run-parts Sat Oct 5 17:32:49 UTC 2019 dib-run-parts Sat Oct 5 17:32:49 UTC 2019 Target: post-configure.d dib-run-parts Sat Oct 5 17:32:49 UTC 2019 dib-run-parts Sat Oct 5 17:32:49 UTC 2019 Script Seconds dib-run-parts Sat Oct 5 17:32:49 UTC 2019 --------------------------------------- ---------- dib-run-parts Sat Oct 5 17:32:49 UTC 2019 dib-run-parts Sat Oct 5 17:32:49 UTC 2019 99-refresh-completed 1.206 dib-run-parts Sat Oct 5 17:32:49 UTC 2019 dib-run-parts Sat Oct 5 17:32:49 UTC 2019 --------------------- END PROFILING --------------------- [2019-10-05 17:32:49,041] (os-refresh-config) [INFO] Completed phase post-configure [2019-10-05 17:32:49,042] (os-refresh-config) [INFO] Starting phase migration dib-run-parts Sat Oct 5 17:32:49 UTC 2019 ----------------------- PROFILING ----------------------- dib-run-parts Sat Oct 5 17:32:49 UTC 2019 dib-run-parts Sat Oct 5 17:32:49 UTC 2019 Target: migration.d dib-run-parts Sat Oct 5 17:32:49 UTC 2019 dib-run-parts Sat Oct 5 17:32:49 UTC 2019 Script Seconds dib-run-parts Sat Oct 5 17:32:49 UTC 2019 --------------------------------------- ---------- dib-run-parts Sat Oct 5 17:32:49 UTC 2019 dib-run-parts Sat Oct 5 17:32:49 UTC 2019 dib-run-parts Sat Oct 5 17:32:49 UTC 2019 --------------------- END PROFILING --------------------- [2019-10-05 17:32:49,073] (os-refresh-config) [INFO] Completed phase migration onfig]# cat /var/run/heat-config/heat-config [{"inputs": [{"type": "String", "name": "foo", "value": "fu"}, {"type": "String", "name": "bar", "value": "barmy"}, {"type": "String", "name": "deploy_server_id", "value": "226ed96d-2335-436e-9707-95af73041e5f", "description": "ID of the server being deployed to"}, {"type": "String", "name": "deploy_action", "value": "CREATE", "description": "Name of the current action being deployed"}, {"type": "String", "name": "deploy_stack_id", "value": "test_stack/b1c6eb69-3877-466b-b00d-03dc051d1893", "description": "ID of the stack this deployment belongs to"}, {"type": "String", "name": "deploy_resource_name", "value": "other_deployment", "description": "Name of this deployment resource in the stack"}, {"type": "String", "name": "deploy_signal_transport", "value": "CFN_SIGNAL", "description": "How the server should signal to heat with the deployment output values."}, {"type": "String", "name": "deploy_signal_id", "value": "http://172.29.85.87:8000/v1/signal/arn%3Aopenstack%3Aheat%3A%3Aadccd09df89e…", "description": "ID of signal to use for signaling output values"}, {"type": "String", "name": "deploy_signal_verb", "value": "POST", "description": "HTTP verb to use for signaling outputvalues"}], "group": "Heat::Ungrouped", "name": "test_stack-config-bmekpj67pq6p", "outputs": [], "creation_time": "2019-10-05T01:14:31Z", "options": {}, "config": {"config_value_foo": "fu", "config_value_bar": "barmy"}, "id": "5c404619-ce79-48cd-b001-00ac6ff4f4e8"}, {"inputs": [{"type": "String", "name": "foo", "value": "fooooo"}, {"type": "String", "name": "bar", "value": "baaaaa"}, {"type": "String", "name": "deploy_server_id", "value": "226ed96d-2335-436e-9707-95af73041e5f", "description": "ID of the server being deployed to"}, {"type": "String", "name": "deploy_action", "value": "CREATE", "description": "Name of the current action being deployed"}, {"type": "String", "name": "deploy_stack_id", "value": "test_stack/b1c6eb69-3877-466b-b00d-03dc051d1893", "description": "ID of the stack this deployment belongs to"}, {"type": "String", "name": "deploy_resource_name", "value": "deployment", "description": "Name of this deployment resource in the stack"}, {"type": "String", "name": "deploy_signal_transport", "value": "CFN_SIGNAL", "description": "How the server should signal to heat with the deployment output values."}, {"type": "String", "name": "deploy_signal_id", "value": "http://172.29.85.87:8000/v1/signal/arn%3Aopenstack%3Aheat%3A%3Aadccd09df89e…", "description": "ID of signal to use for signaling output values"}, {"type": "String", "name": "deploy_signal_verb", "value": "POST", "description": "HTTP verb to use for signaling outputvalues"}], "group": "Heat::Ungrouped", "name": "test_stack-config-bmekpj67pq6p", "outputs": [], "creation_time": "2019-10-05T01:14:31Z", "options": {}, "config": {"config_value_foo": "fooooo", "config_value_bar": "baaaaa"}, "id": "f4dea0c1-73c9-4ce4-aa04-c76ef9b08859"}][root@sig-vm-1 heat-config]# [root@sig-vm-1 heat-config]# cat /etc/os-collect-config.conf [DEFAULT] command = os-refresh-config collectors = ec2 collectors = cfn collectors = local [cfn] metadata_url = http://172.29.85.87:8000/v1/ stack_name = test_stack secret_access_key = npa^GWsPtbRL7D*MYObOI*kV0i1yqKOG access_key_id = f7874ac9898248edaae53511230534a4 path = sig-vm-1.Metadata Here is my basic sample temple heat_template_version: 2013-05-23 description: > This template demonstrates how to use OS::Heat::StructuredDeployment to override substitute get_input placeholders defined in OS::Heat::StructuredConfig config. As there is no hook on the server to act on the configuration data, these deployment resource will perform no actual configuration. parameters: flavor: type: string default: 'a061cb6c-99e7-4bdb-93e4-f0037ee3e947' image: type: string default: 3be29d9f-2ce6-4b95-b80c-0dbca7acfdfe public_net_id: type: string default: 67ae0e17-6258-4fb6-8b9b-0f29f6adb9db private_net_id: type: string description: Private network id default: 995fc046-1c58-468a-b81c-e42c06fc8966 private_subnet_id: type: string description: Private subnet id default: 7598c805-3a9b-4c27-be5b-dca4d89f058c password: type: string description: SSH password default: lab123 resources: the_sg: type: OS::Neutron::SecurityGroup properties: name: the_sg description: Ping and SSH rules: - protocol: icmp - protocol: tcp port_range_min: 22 port_range_max: 22 config: type: OS::Heat::StructuredConfig properties: config: config_value_foo: {get_input: foo} config_value_bar: {get_input: bar} deployment: type: OS::Heat::StructuredDeployment properties: signal_transport: CFN_SIGNAL config: get_resource: config server: get_resource: sig-vm-1 input_values: foo: fooooo bar: baaaaa other_deployment: type: OS::Heat::StructuredDeployment properties: signal_transport: CFN_SIGNAL config: get_resource: config server: get_resource: sig-vm-1 input_values: foo: fu bar: barmy server1_port0: type: OS::Neutron::Port properties: network_id: { get_param: private_net_id } security_groups: - default fixed_ips: - subnet_id: { get_param: private_subnet_id } server1_public: type: OS::Neutron::FloatingIP properties: floating_network_id: { get_param: public_net_id } port_id: { get_resource: server1_port0 } sig-vm-1: type: OS::Nova::Server properties: name: sig-vm-1 image: { get_param: image } flavor: { get_param: flavor } networks: - port: { get_resource: server1_port0 } user_data_format: SOFTWARE_CONFIG user_data: get_resource: cloud_config cloud_config: type: OS::Heat::CloudConfig properties: cloud_config: password: { get_param: password } chpasswd: { expire: False } ssh_pwauth: True

2 2

[requirements][heat] remove salt from requirements (used by heat-agents tests only)
by Matthew Thode 08 Oct '19

08 Oct '19

Salt has been harsh to deal with. Upstream adding and maintaining caps has caused it to be held back. This time it's pyyaml, I'm not going to hold back the version of pyyaml for one import of salt. In any case, heat-agents uses salt in one location and may not even be using the one we define via constraints in any case. File: heat-config-salt/install.d/50-heat-config-hook-salt Installs salt from package then runs heat-config-salt/install.d/hook-salt.py In heat-config-salt/install.d/hook-salt.py is defined the only import of salt I can find and likely uses the package version as it's installed after tox sets things up. Is the heat team ok with this? -- Matthew Thode

2 2

[manila] Proposal to add dviroel to the core maintainers team
by Goutham Pacha Ravi 08 Oct '19

08 Oct '19

Dear Zorillas and other Stackers, I would like to formalize the conversations we've been having amongst ourselves over IRC and in-person. At the outset, we have a lot of incoming changes to review, but we have limited core maintainer attention. We haven't re-jigged our core maintainers team as often as we'd like, and that's partly to blame. We have some relatively new and enthusiastic contributors that we would love to encourage to become maintainers! We've mentored contributors 1-1, n-1 before before adding them to the maintainers team. We would like to do more of this!** In this spirit, I would like your inputs on adding Douglas Viroel (dviroel) to the core maintainers team for manila and its associated projects (manila-specs, manila-ui, python-manilaclient, manila-tempest-plugin, manila-test-image, manila-image-elements). Douglas has been an active contributor for the past two releases and has valuable review inputs in the project. While he's been around here less longer than some of us, he brings a lot of experience to the table with his background in networking and shared file systems. He has a good grasp of the codebase and is enthusiastic in adding new features and fixing bugs in the Ussuri cycle and beyond. Please give me a +/-1 for this proposal. ** If you're interested in helping us maintain Manila by being part of the manila core maintainer team, please reach out to me or any of the current maintainers, we would love to work with you and help you grow into that role! Thanks, Goutham Pacha Ravi (gouthamr)

9 10

Neutron dhcp-agent scalability techniques
by fsbiz＠yahoo.com 08 Oct '19

08 Oct '19

Hi folks, We have a rather large flat network consisting of over 300 ironic baremetal nodesand are constantly having the baremetals timing out during their PXE boot due tothe dhcp agent not able to respond in time. Looking for inputs on successful DHCP scaling techniques that would help mitigate this. thanks,Fred.

3 6

[ops] ops meetups team meeting 2019-10-8
by Chris Morgan 08 Oct '19

08 Oct '19

Minutes from todays meeting are here: 10:56 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:56 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:56 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… The Ops Community attending the upcoming Summit in Shanghai will have one Forum session (ops war stories). On day 4 we will also have a 3 hours session for further ops related topic discussion. Details still to be arranged. Chris - on behalf of the openstack ops meetups team -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[cinder] Train release status
by Brian Rosmaita 08 Oct '19

08 Oct '19

You may have noticed that RC-2 was released yesterday. We aren't planning to do an RC-3 unless a critical bugfix is approved for backport. Here's the timeline: - Now through Friday 11 October: RC-3, etc. are cut as necessary - The "final RC" is whatever RC-n exists on 11 October - The coordinated release date is 16 October * Any bugfixes caught after 11 Oct can be merged into stable/train, but it is up to the release team whether they can be included in the release. Please do some exploratory testing on the 15.0.0.0rc2 tag (which right now is the HEAD of stable/train). If you find a critical bug, please file it in Launchpad and tag it 'train-rc-potential'. Also add it to the etherpad: https://etherpad.openstack.org/p/cinder-train-backport-potential and make some noise in #openstack-cinder so we are all aware of it. cheers, brian

1 0

Re: cinder 15.0.0.0rc2 (train)
by Thomas Goirand 08 Oct '19

08 Oct '19

On 10/7/19 4:40 PM, no-reply(a)openstack.org wrote: > Hello everyone, > > A new release candidate for cinder for the end of the Train > cycle is available! You can find the source code tarball at: > > https://tarballs.openstack.org/cinder/ Hi, For the 2nd time, could we *please* re-add the tag: [release-announce] when announcing for a release? I don't mind if it's sent to -discuss instead of the announce this, but this breaks mail filters... Cheers, Thomas Goirand (zigo)

2 3

[nova] Request to include routed networks support in the Ussuri cucly goals
by Miguel Lavalle 08 Oct '19

08 Oct '19

Hi Stackers, I want to request the inclusion of the support for Neutron Routed Networks in the Nova goals for the Ussuri cycle. As many of you might know, Routed networks is a feature in Neutron that enables the creation of very large virtual networks that avoids the performance penalties of large L2 broadcast domains ( https://www.openstack.org/videos/summits/barcelona-2016/scaling-up-openstac…) This functionality can be very helpful for large deployers who have the need to have one or a few large virtual networks shared by all their users and has been available in Neutron since very soon after the Barcelona Summit in 2016. But it is really useless until there is code in Nova that can schedule VMs to compute hosts based on the segments topology of the routed networks. Without it, VMs can land in compute hosts where their traffic cannot be routed by the underlying network infrastructure. I would like the Nova team to consider the following when making a decision about this request: 1. Work for Routed Networks was approved as a priority for the Ocata cycle, although it wasn't concluded: https://specs.openstack.org/openstack/nova-specs/priorities/ocata-prioritie… and https://specs.openstack.org/openstack/nova-specs/specs/pike/index.html 2. The are several large deployers that need this feature. Verizon Media, my employer, is one of them. Others that come to mind include GoDaddy and Cern. And I am sure there are others. 3. There is a WIP patch to implement the functionality some of the functionality: https://review.opendev.org/#/c/656885. We, at Verizon Media, are proposing to take over this work and finish its implementation by the end of U. What we are requesting is Nova core reviewers bandwidth to help us merge the code I will be attending the PTG in Shanghai and will make myself available to discuss this further in person any day and any time. Hopefully, we can get this feature lined up very soon Best regards Miguel

5 5

[OSSA-2019-005] Octavia Amphora-Agent not requiring Client-Certificate (CVE-2019-17134)
by Daniel 'f0o' Preussker 08 Oct '19

08 Oct '19

===================================================================== OSSA-2019-005: Octavia Amphora-Agent not requiring Client-Certificate ===================================================================== :Date: October 07, 2019 :CVE: CVE-2019-17134 Affects ~~~~~~~ - Octavia: >=0.10.0 <2.1.2, >=3.0.0 <3.2.0, >=4.0.0 <4.1.0 Description ~~~~~~~~~~~ Daniel Preussker reported a vulnerability in amphora-agent, running within Octavia Amphora Instances which allows unauthenticated access from the management network. This leads to information disclosure and also allows changes to the configuration of the Amphora via simple HTTP requests because cmd/agent.py gunicorn cert_reqs option is incorrectly set to True instead of ssl.CERT_REQUIRED. Patches ~~~~~~~ - https://review.opendev.org/686547 (Ocata) - https://review.opendev.org/686546 (Pike) - https://review.opendev.org/686545 (Queens) - https://review.opendev.org/686544 (Rocky) - https://review.opendev.org/686543 (Stein) - https://review.opendev.org/686541 (Train) Credits ~~~~~~~ - Daniel Preussker (CVE-2019-17134) References ~~~~~~~~~~ - https://storyboard.openstack.org/#!/story/2006660 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17134 Notes ~~~~~ - The stable/ocata and stable/pike branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy.

1 0

[nova] Stepping down from core reviewer
by Kenichi Omichi 07 Oct '19

07 Oct '19

Hello, Today my job description is changed and I cannot have enough time for regular reviewing work of Nova project. So I need to step down from the core reviewer. I spend 6 years in the project, the experience is amazing. OpenStack gave me a lot of chances to learn technical things deeply, make friends in the world and bring me and my family to foreign country from our home country. I'd like to say thank you for everyone in the community :-) My personal private cloud is based on OpenStack, so I'd like to still keep contributing for the project if I find bugs or idea. Thanks Kenichi Omichi ---

11 10

[dev][taskflow] Accepting any decision
by Jiří Rája 07 Oct '19

07 Oct '19

Hi, I wrote the code in the attachment and I would like to ask if it's possible to execute next task (step3) even if one decider returns True (link from step 1 to step 3) and one returns False (link from step 2 to step 3). If it is possible could someone alter the code? Or is there any other way to do it? And if the task wouldn't have to wait for all of the links, it would be great. Thank you! All the best, Rája

2 1

[neutron]: Latest Queens release: dhcp-client takes too long processing messages and falls behind.
by fsbiz＠yahoo.com 07 Oct '19

07 Oct '19

Hi neutron team, We've been troubleshooting an issue with neutron's dhcp-client for sometime now. We were previously on neutron 12.0.5 and observed that upon reloading 5-8 baremetals simultaneously almost always led to a few baremetals failing PXE boot during provisioning and/or cleaning. This was traced to afixed bug. https://bugs.launchpad.net/neutron/+bug/1760047 which was applied to Queens in April 2019. https://review.opendev.org/#/c/649580/ We patched the above fix but found out the problem was not resolved. The fix gets rid of the semaphores by serializing the multiple messages into aPriority Queue. The Priority Queue then drains the messages serially one by one making sure notto yield during the processing of each message. All in all this just seems like a more elegant way ofgetting rid of the semaphores but does not really fix the issue at hand. Below are the logs from dhcp-agent in neutron release 12.0.5. As can be seen the semaphore locks all threads for almost 6 seconds.While the below has been fixed using https://review.opendev.org/#/c/649580/ the underlying problem has not been fixed. The semaphore has been removed but instead the message is being serialized and does not yieldresulting in PXE boot failures on the baremetal nodes. Any pointers would be appreciated. thanks,Fred 2019-10-03 18:07:37.454 318956DEBUG oslo_concurrency.lockutils [req-eac79995-3846-46e6-b946-c5b5ccdb7aa58941137e383548bda725e74a93b2f865 19f6fb7446dc47dd88c63cf03c1cce94 - - -] Acquired semaphore"dhcp-agent-network-lock-077aa2d1-605c-48ec-842d-7dd6767bfd01" lock/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:212 2019-10-03 18:07:37.455 318956DEBUG neutron.agent.dhcp.agent [req-eac79995-3846-46e6-b946-c5b5ccdb7aa5 8941137e383548bda725e74a93b2f86519f6fb7446dc47dd88c63cf03c1cce94 - - -] Calling driver for network:077aa2d1-605c-48ec-842d-7dd6767bfd01 action: reload_allocations call_driver/usr/lib/python2.7/site-packages/neutron/agent/dhcp/agent.py:135 2019-10-03 18:07:37.456 318956DEBUG neutron.agent.linux.utils [req-eac79995-3846-46e6-b946-c5b5ccdb7aa58941137e383548bda725e74a93b2f865 19f6fb7446dc47dd88c63cf03c1cce94 - - -]Running command (rootwrap daemon): ['ip', 'netns', 'exec','qdhcp-077aa2d1-605c-48ec-842d-7dd6767bfd01', 'dhcp_release', 'ns-8387b854-d1','10.33.27.77', '9c:71:3a:cb:7c:43', '01:9c:71:3a:cb:7c:43']execute_rootwrap_daemon/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:108 2019-10-03 18:07:38.101 318956DEBUG neutron.agent.linux.utils [req-eac79995-3846-46e6-b946-c5b5ccdb7aa58941137e383548bda725e74a93b2f865 19f6fb7446dc47dd88c63cf03c1cce94 - - -]Running command (rootwrap daemon): ['ip', 'netns', 'exec','qdhcp-077aa2d1-605c-48ec-842d-7dd6767bfd01', 'dhcp_release', 'ns-8387b854-d1','10.33.27.75', '9c:71:3a:cb:7b:fb'] execute_rootwrap_daemon/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:108 2019-10-03 18:07:38.717 318956DEBUG neutron.agent.linux.utils [req-eac79995-3846-46e6-b946-c5b5ccdb7aa58941137e383548bda725e74a93b2f865 19f6fb7446dc47dd88c63cf03c1cce94 - - -]Running command (rootwrap daemon): ['ip', 'netns', 'exec','qdhcp-077aa2d1-605c-48ec-842d-7dd6767bfd01', 'dhcp_release', 'ns-8387b854-d1','10.33.27.75', '9c:71:3a:cb:7b:fb', 'ff:3a:cb:7b:fb:00:04:8a:ef:2f:58:b4:20:45:03:80:27:0f:15:84:a4:70:7b']execute_rootwrap_daemon/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:108 2019-10-03 18:07:39.631 318956DEBUG neutron.agent.linux.dhcp [req-eac79995-3846-46e6-b946-c5b5ccdb7aa58941137e383548bda725e74a93b2f865 19f6fb7446dc47dd88c63cf03c1cce94 - - -]Building host file: /var/lib/neutron/dhcp/077aa2d1-605c-48ec-842d-7dd6767bfd01/host_output_hosts_file/usr/lib/python2.7/site-packages/neutron/agent/linux/dhcp.py:695 2019-10-03 18:07:39.632 318956DEBUG neutron.agent.linux.dhcp [req-eac79995-3846-46e6-b946-c5b5ccdb7aa58941137e383548bda725e74a93b2f865 19f6fb7446dc47dd88c63cf03c1cce94 - - -] Donebuilding host file/var/lib/neutron/dhcp/077aa2d1-605c-48ec-842d-7dd6767bfd01/host_output_hosts_file/usr/lib/python2.7/site-packages/neutron/agent/linux/dhcp.py:734 2019-10-03 18:07:39.633 318956DEBUG neutron.agent.linux.utils [req-eac79995-3846-46e6-b946-c5b5ccdb7aa58941137e383548bda725e74a93b2f865 19f6fb7446dc47dd88c63cf03c1cce94 - - -]Running command (rootwrap daemon): ['ip', 'netns', 'exec','qdhcp-077aa2d1-605c-48ec-842d-7dd6767bfd01', 'ip', 'addr', 'show','ns-8387b854-d1'] execute_rootwrap_daemon/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:108 2019-10-03 18:07:40.263 318956DEBUG neutron.agent.linux.utils [req-eac79995-3846-46e6-b946-c5b5ccdb7aa58941137e383548bda725e74a93b2f865 19f6fb7446dc47dd88c63cf03c1cce94 - - -]Running command (rootwrap daemon): ['kill', '-HUP', '319109']execute_rootwrap_daemon/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:108 2019-10-03 18:07:40.843 318956DEBUG neutron.agent.linux.dhcp [req-eac79995-3846-46e6-b946-c5b5ccdb7aa58941137e383548bda725e74a93b2f865 19f6fb7446dc47dd88c63cf03c1cce94 - - -]Reloading allocations for network: 077aa2d1-605c-48ec-842d-7dd6767bfd01reload_allocations/usr/lib/python2.7/site-packages/neutron/agent/linux/dhcp.py:524 2019-10-03 18:07:40.843 318956DEBUG neutron.agent.linux.utils [req-eac79995-3846-46e6-b946-c5b5ccdb7aa58941137e383548bda725e74a93b2f865 19f6fb7446dc47dd88c63cf03c1cce94 - - -]Running command (rootwrap daemon): ['ip', 'netns', 'exec','qdhcp-077aa2d1-605c-48ec-842d-7dd6767bfd01', 'ip', '-4', 'route', 'list','dev', 'ns-8387b854-d1'] execute_rootwrap_daemon/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:108 2019-10-03 18:07:41.462 318956DEBUG neutron.agent.linux.utils [req-eac79995-3846-46e6-b946-c5b5ccdb7aa5 8941137e383548bda725e74a93b2f86519f6fb7446dc47dd88c63cf03c1cce94 - - -] Running command (rootwrap daemon):['ip', 'netns', 'exec', 'qdhcp-077aa2d1-605c-48ec-842d-7dd6767bfd01', 'ip','-6', 'route', 'list', 'dev', 'ns-8387b854-d1'] execute_rootwrap_daemon /usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:108 2019-10-03 18:07:42.101 318956DEBUG oslo_concurrency.lockutils [req-eac79995-3846-46e6-b946-c5b5ccdb7aa58941137e383548bda725e74a93b2f865 19f6fb7446dc47dd88c63cf03c1cce94 - - -] Releasing semaphore"dhcp-agent-network-lock-077aa2d1-605c-48ec-842d-7dd6767bfd01" lock/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:228

1 0

[all][requirements] requirements branched train - cycle-trailing are on notice that master is now ussuri
by Matthew Thode 07 Oct '19

07 Oct '19

Just a friendly ping that the train keeps rolling. Master is now ussuri. https://releases.openstack.org/constraints/upper/ussuri should work soon for those that want to switch their install_command in tox.ini within master earlier in the cycle (rather than having things pile up). I'll email again once it's working. cycle-trailing projects are on notice that if they track master, the dependencies may change from what they are currently working on (train). If you have any questions please let me know (in the #openstack-requirements channel preferably). P.S. FFE season is over -- Matthew Thode

1 1

[all] Final PTG Schedule
by Kendall Nelson 07 Oct '19

07 Oct '19

Hello Everyone! After a few weeks of shuffling and changes, we have a final schedule! It can be seen here on the 'Schedule' tab[1]. -Kendall (diablo_rojo) [1] https://www.openstack.org/PTG

1 0

Re: [Release-job-failures] Tag of openstack/cinder for ref refs/tags/15.0.0.0rc2 failed
by Thierry Carrez 07 Oct '19

07 Oct '19

zuul(a)openstack.org wrote: > Build failed. > > - publish-openstack-releasenotes-python3 https://zuul.opendev.org/t/openstack/build/965908bbf69141c393d4728f7de07f7d : POST_FAILURE in 29m 45s Looks like a transient failure Collect sphinx build html: ssh: connect to host 162.242.237.111 port 22: Connection timed out rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.1] Collect artifacts: ssh: connect to host 162.242.237.111 port 22: Connection timed out rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.1] Release notes should be picked up at the next RC or the final, so no need to retry/reenqueue? -- Thierry Carrez (ttx)

2 1

[all][tc][ptl] "Meet the project leaders" opportunities in Shanghai
by Thierry Carrez 07 Oct '19

07 Oct '19

Hi everyone, The summit is going to mainland China for the first time. It's a great opportunity to meet the Chinese community, make ourselves available for direct discussion, and on-board new team members. In order to facilitate that, the TC has been suggesting that the Foundation organizes two opportunities to "meet the project leaders" during the Summit in Shanghai: one around the Monday evening marketplace mixer, and one around the Wednesday lunch: https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24417/ https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24426… OpenStack PTLs, TC members, core reviewers, UC members interested in meeting the local community are all welcome. We'll also have leaders from the other OSF-supported projects around. See you there! -- Thierry Carrez (ttx)

8 11

[oslo] FFE: Support "qemu-img info" virtual size in QEMU 4.1 and late
by Herve Beraud 07 Oct '19

07 Oct '19

Hi, I request a late feature freeze exception (FFE) for https://review.opendev.org/#/c/686598/ and https://github.com/openstack/oslo.utils/commit/89bccdee95f81ddb54b427d6af17… -- "Support "qemu-img info" virtual size in QEMU 4.1 and later". It will fix an issue that can be blocking for users so it's can be really valuable for operators, if we release it ASAP. They would be delighted if it were included in Train. Please let me know if you have any concerns or questions. Thank you for your consideration. Hervé -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

3 2

[cloudkitty] 07/10 IRC meeting recap
by Luka Peschke 07 Oct '19

07 Oct '19

Hello everybody, This is the recap for today's IRC meeting of the cloudkitty team. The agenda can be found at [1] and the logs can be found at [2]. cloudkitty 11.0.0 and python-cloudkittyclient 3.1.0 =================================================== Cloudkitty 11.0.0 has been released on september 25th. If no critical bug is reported, it will be final release for the train cycle. The release notes for the train cycle can be found at [3]. New meeting schedule ==================== As discussed, the cloudkitty IRC meeting will now happen on the 1st and 3rd monday of each month at 14h00 UTC. This time has been chosen because cloudkitty's main contributors are split between montreal and france. Of course, if anyone from an incompatible timezone would like to take part in the meetings, we can re-adjust the schedule. From now on, we'll provide a recap to the ML after each meeting. New features / specs / projects =============================== First, I'd like to welcome our two new contributors, Quentin Anglade (qanglade) and Julien Pinchelimouroux (julien-pinchelim). Quentin has been working on porting some v1 API endpoints to v2, more specifically the ones used for rating module configuration (/v1/rating/modules). These endpoints will be included in the Ussuri version. Julien is working on a standalone dashboard for cloudkitty. It will be compatible with the standalone mode, but will also support keystone integration. It should provide a more modern and easier to use interface than the cloudkitty-dashboard horizon plugin. It will require the v2 API to work. I've been busy with some improvements to v2 API performance, in particular regarding driver loading. The spec can be found at [4]. Tempest plugin ============== Justin (jferrieu) has been working on the tempest plugin. Now that the Elasticsearch v2 storage driver is supported in devstack, we plan to add a lot more tests and some complete scenarios. Some of Justin's work on differenciating v1 and v2 API tempest tests can be found at [5]. The next meeting will happen on October 21st at 14h00 UTC. Cheers, -- Luka Peschke (peschk_l) [1] https://etherpad.openstack.org/p/cloudkitty-meeting-topics [2] http://eavesdrop.openstack.org/meetings/cloudkitty/2019/cloudkitty.2019-10-… [3] https://docs.openstack.org/releasenotes/cloudkitty/train.html [4] https://review.opendev.org/#/c/686391/ [5] https://review.opendev.org/#/c/686210/

1 0

cinder 15.0.0.0rc2 (train)
by no-reply＠openstack.org 07 Oct '19

07 Oct '19

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

1 0

storlets 4.0.0.0rc2 (train)
by no-reply＠openstack.org 07 Oct '19

07 Oct '19

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

1 0

octavia 5.0.0.0rc2 (train)
by no-reply＠openstack.org 07 Oct '19

07 Oct '19

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

1 0

Re: [Airship-discuss] Fwd: OOK,Airship
by Roman Gorshunov 07 Oct '19

07 Oct '19

Thanks Ashlee! Charles, A few companies who work on development of Airship do use it, including production uses: AT&T, SUSE, Mirantis, Ericsson, SK Telekom and others. Many of those companies (if not all) use Airship + OpenStack Helm as well. Airship, as you have mentioned, is a collection of components for undercloud control plane, which helps to deploy nodes with OS+Docker+Kubernetes on it, configure/manage it all in GitOps way, and then help to maintain the configuration. It also allows to manage deploys and maintenance of whatever runs on top of Kubernetes cluster, would that be OpenStack Helm or other software packaged in Helm format. OpenStack Helm does not really require to be running on Airship-managed cluster. It could run standalone. Yes, you can roll out an open source production grade Airship/Openstack Helm deployment today. Good example of production grade configuration could be found in airship/treasuremap repository [0] as 'seaworthy' site definition. You are welcome to try, of course. For the questions - reach out to us on IRC #airshipit@Freenode of via Airship-discuss mailing list. [0] https://opendev.org/airship/treasuremap Best regards, -- Roman Gorshunov On Wed, Oct 2, 2019 at 9:27 PM Ashlee Ferguson <ashlee(a)openstack.org> wrote: > > Hi Charles, > > Glad to hear you’re interested! Forwarding this to the Airship ML since there may be folks on this mailing list that will have pointers who didn't see the openstack-discuss post. > > Ashlee > > > > Begin forwarded message: > > From: Charles <cems(a)ebi.ac.uk> > Subject: OOK,Airship > Date: October 2, 2019 at 5:39:16 PM GMT+2 > To: openstack-discuss(a)lists.openstack.org > > Hi, > > > We are interested in OOK and Openstack Helm. > > Has anyone any experience with Airship (now that 1.0 is out)? > > Noticed that a few Enterprise distributions are looking at managing the Openstack control plane with Kubernetes and have been testing Airship with a view to rolling it out (Mirantis,SUSE) > > Is this a signal that there is momentum around Openstack Helm? > > Is it possible to roll out an open source production grade Airship/Openstack Helm deployment today, or is it too early? > > > Thoughts? > > > Charles > > > > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss(a)lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss

3 2

[kolla] Feature freeze
by Mark Goddard 07 Oct '19

07 Oct '19

Hello Koalas, We are now in feature freeze for the Train release. Cores, please do not approve feature patches on the master branch until we have created the stable/train branch. We will allow some exceptions which must be approved by the core team. Currently, we have nova cells support and IPv6-only mode. Please apply for feature freeze exceptions either on openstack-discuss or during the weekly IRC meeting. The deadline for merging features with exceptions is Friday 18th October. Please now focus on bug fixing and testing. Thanks, Mark

1 0

[neutron] Bug deputy report (week starting on 2019-09-30)
by Bernard Cafarelli 07 Oct '19

07 Oct '19

Hello Neutrinos, train is almost ready to leave the station, and it is time for a new bug deputy rotation cycle! I was on duty last week, triaging bugs up to 1846703 included A quiet week, with most bugs having potential fixes or good discussions. First one listed could benefit from another pair of eyes Undecided: * neutron-openvswitch-agent and IPv6 - https://bugs.launchpad.net/neutron/+bug/1846494 Can not use an IPv6 address for OpenFlow connections listening address (of_listen_address) High: * Pyroute2 can return dictionary keys in bytes instead of strings - https://bugs.launchpad.net/neutron/+bug/1846360 Fix in progress: https://review.opendev.org/686206 * [mysql8] Unknown column 'public' in 'firewall_rules_v2' - https://bugs.launchpad.net/neutron/+bug/1846606 neutron-fwaas db creation failing with mysql 8 Fix in progress: https://review.opendev.org/686753 <https://review.opendev.org/#/c/686753/> Medium: * Designate integration not fully multi region safe - https://bugs.launchpad.net/neutron/+bug/1845891 Fix released: https://review.opendev.org/684854 RFE: * routed network for hypervisor - https://bugs.launchpad.net/neutron/+bug/1846285 Proposition to have routed networks separation at hypervisor level directly, apparently already running in-house at bug reporter's Wishlist: * Avoid neutron to return error 500 when deleting port if designate is down - https://bugs.launchpad.net/neutron/+bug/1846703 Another bug for Designate support, port create and delete operations do not react the same when designate is down Some discussions also in https://review.opendev.org/685644 Opinion: * ovs VXLAN over IPv6 conflicts with linux native VXLAN over IPv4 using standard port - https://bugs.launchpad.net/neutron/+bug/1846507 Configuration issue in kolla-ansible CI, ovs-agent and CI configuration competing for IPv6 binding address. Neutron listed for possible insights on the issue Invalid: * ha router appear double vip - https://bugs.launchpad.net/neutron/+bug/1845900 Kolla issue with HA controllers when stopping L3 agent - keepalived processes are in same container and are killed at same time as agent, added Kolla to affected projects * packet loss during active L3 HA agent restart - https://bugs.launchpad.net/neutron/+bug/1846198 Similar issue for openstack-ansible, it kills all processes in control group (including keepalived processes) when restarting the systemd unit - added OSA as affected project Thanks! Passing the deputy role to slaweq -- Bernard Cafarelli

1 0

ANNOUNCE: Train packages repository for Debian Buster is now available and tested
by Thomas Goirand 06 Oct '19

06 Oct '19

Hi, It's been a few days already, there's some fully working (and tested) Debian repositories backported to Buster for train. The URLs are using the usual scheme: deb http://buster-train.debian.net/debian/ buster-train-backports main deb-src http://buster-train.debian.net/debian/ buster-train-backports main deb http://buster-train.debian.net/debian/ buster-train-backports-nochange main deb-src http://buster-train.debian.net/debian/ buster-train-backports-nochange main Early last week, I was able to test this, doing my first deployment, and starting my first VM on it. I haven't run tempest on this yet, though my manual tests went well (ie: floating IP, ssh to instance, mounting a cinder volume over Ceph and LVM, etc.). Please do test this, and report any eventual issue. If everything goes as planned, I'll be at the Debian cloud sprint in Boston the week of the release, discussing the Debian official images for the cloud. So I will only be able to upload the final versions of projects for Train only then after (probably, during the week-end, so it's available on Monday). Cheers, Thomas Goirand (zigo)

2 1

Neutron Dhcp-agent
by Jyoti Dahiwele 06 Oct '19

06 Oct '19

Dear Team, Please clarify on how can I use dhcp-agent of neutron as a relay and to use existing dhcp for allocation of IPs to instances?

3 2

[keystone] Keystone Team Update - Week of 30 September 2019
by Colleen Murphy 04 Oct '19

04 Oct '19

# Keystone Team Update - Week of 30 September 2019 ## News Quiet week as we wait for the final release and start preparing for Forum and next cycle. ## Action Items Team members: see action required regarding the new roadmap tracker[1]. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/009942.… ## Office Hours When there are topics to cover, the keystone team holds office hours on Tuesdays at 17:00 UTC. We won't plan to hold office hours next week. 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 7 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 33 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 1 new bugs and closed 3. Bugs opened (1) Bug #1846817 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1846817 Bugs fixed (3) Bug #968696 (keystone:High) fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/968696 Bug #1630434 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1630434 Bug #1806762 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1806762 Notably, we closed #968696 *for keystone*, as we have completed the migration of our policies to understand system scope and, when [oslo_policy]/enforce_scope is set to true and deprecated policies are overridden, system-wide requests won't respond to project-scoped tokens. This does not mean the "admin"-ness problem is solved across OpenStack, as it will have to be addressed on a service-by-service basis. ## Milestone Outlook https://releases.openstack.org/train/schedule.html Next week will be the last chance to release another RC if we need one. Please help triage and address any RC-critical bugs should they come up. Also, the release schedule for Ussuri has been published: https://releases.openstack.org/ussuri/schedule.html ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[oslo][nova] Revert of oslo.messaging JSON serialization change
by Ben Nemec 04 Oct '19

04 Oct '19

Hi, I've just proposed https://review.opendev.org/#/c/685724/ which reverts a change that recently went in to make the fake driver in oslo.messaging use jsonutils for message serialization instead of json.dumps. As explained in the commit message on the revert, this is problematic because the rabbit driver uses kombu's default serialization method, which is json.dumps. By changing the fake driver to use jsonutils we've made it more lenient than the most used real driver which opens us up to merging broken changes in consumers of oslo.messaging. We did have some discussion of whether we should try to override the kombu default and tell it to use jsonutils too, as a number of other drivers do. The concern with this was that the jsonutils handler for things like datetime objects is not tz-aware, which means if you send a datetime object over RPC and don't explicitly handle it you could lose important information. I'm open to being persuaded otherwise, but at the moment I'm leaning toward less magic happening at the RPC layer and requiring projects to explicitly handle types that aren't serializable by the standard library json module. If you have a different preference, please share it here. Thanks. -Ben

4 5

Proposed Forum Schedule
by Jimmy Mcarthur 04 Oct '19

04 Oct '19

The forum schedule is now live: https://www.openstack.org/summit/shanghai-2019/summit-schedule/global-searc… If you'd prefer to use the spreadsheet view: https://drive.google.com/file/d/1qp0I9xnyOK3mhBitQnk2a7VuS9XClvyF Please let Kendall Nelson or myself know as soon as possible if you see any conflicts. Cheers, Jimmy

1 0

[Glance][PTG]Shanghai PTG planning
by Abhishek Kekane 04 Oct '19

04 Oct '19

Hello Everyone, I have prepared an etherpad [1] to plan the Shanghai PTG discussion topics for glance. The etherpad contains template to add the topic for discussion. It has also references of previous PTG planning etherpads. Even if anyone is not going to attend the PTG but wants there topic needs to be discussed can add as well. Kindly add your topics. [1] https://etherpad.openstack.org/p/Glance-Ussuri-PTG-planning Thanks, Abhishek Kekane

1 0

[release] Release countdown for week R-1, October 7-11
by Sean McGinnis 03 Oct '19

03 Oct '19

Development Focus ----------------- We are on the final mile of this Train ride! (You can thank Thierry for that one ^) Remember that the Train final release will include the latest release candidate (for cycle-with-rc deliverables) or the latest intermediary release (for cycle-with-intermediary deliverables) available. Thursday, October 10th is the deadline for final Train release candidates as well as any last cycle-with-intermediary deliverables. We will then enter a quiet period until we tag the final release on October 16th. Teams should be prioritizing fixing release-critical bugs, before that deadline. Otherwise it's time to start planning the Ussuri development cycle, including discussing Forum and PTG sessions content, in preparation of the Summit in Shanghai next month. Actions --------- Watch for any translation patches coming through on the stable/train branch and merge them quickly. If you discover a release-critical issue, please make sure to fix it on the master branch first, then backport the bugfix to the stable/train branch before triggering a new release. Please drop by #openstack-release with any questions or concerns about the upcoming release! Upcoming Deadlines & Dates -------------------------- Final Train release: October 16 Forum+PTG at Shanghai summit: November 4

1 0

[keystone] Ussuri roadmap
by Colleen Murphy 03 Oct '19

03 Oct '19

Hi team, In past cycles we used Trello for tracking our goals throughout a cycle, which gave us flexibility and visibility over the cycle plans as a whole in conjunction with specs and launchpad bugs. Trello is a proprietary platform and in the last few months changed its ToS to limit the number of public boards an organization can have, and the keystone team has reached that limit. Rather than try to backup and archive our old boards or create another team or a non-team board, for Ussuri I would like to try using a board on a different platform, Taiga: https://tree.taiga.io/project/keystone-ussuri-roadmap/kanban Taiga is AGPLv3 and has no restrictions on its hosted version that I've discovered yet. Many thanks to Morgan for discovering and researching it. I've copied over our incomplete stories from the Train roadmap[1] and arranged the kanban board more or less the same way as the old Trello board, but the platform seems to be very flexible and we could change the layout and workflows in any way that makes sense. For instance, while I only enabled the kanban feature, there is also a sprints/backlog mode if we wanted to take advantage of that. I can grant administrator privileges to anyone who is interested in investigating all the configuration options (or you can create your own sandbox projects to play with). The main deficiency seems to be the lack of support for "teams" or "organizations"[2], but users can be added to the board individually. Action required: * If you were a member of the old Trello keystone team and would to be a member of this board, send me an email address that I can send an invite to * Once you have an account and are added to the board, please have a look at the stories that are already there an assign yourself to the ones you are working on or plan to work on, and update their status or add relevant reviews as comments. Feel free to play with the platform's features and provide feedback in this thread or at next week's team meeting. Please also let me know if you have concerns about using this platform. Colleen [1] https://trello.com/b/ClKW9C8x/keystone-train-roadmap [2] https://tree.taiga.io/project/taiga/us/2129

1 0

[requirements][mistral][amqp] Failing “docs” job due to the upper constraint conflict for amqp
by Renat Akhmerov 03 Oct '19

03 Oct '19

Hi, We have a failing “docs” ([1]) CI job that fails because it implicitly brings amqp 2.5.2 but this lib is not allowed to be higher than 2.5.1 in the upper-constraings.txt in the requirements project ([2]). We see that there’s the patch [3] generated by the proposal bot that bumps the constraint to 2.5.2 for amqp (among others) but it was given -2. Please assist on how to address in the best way. Should we bump only amqp version in upper constraints for now? [1] https://zuul.opendev.org/t/openstack/build/6fe7c7d3e60b40458d2a98f3a293f412… [2] https://github.com/openstack/requirements/blob/master/upper-constraints.txt… [3] https://review.opendev.org/#/c/681382 Thanks Renat Akhmerov @Nokia

2 3

Proposed Forum Schedule
by Jimmy McArthur 03 Oct '19

03 Oct '19

Hello! I'm attaching a PDF of the proposed Shanghai Forum Schedule. I'll publish the same on the actual website later this afternoon. However, there is still time for feedback/time changes, assuming there aren't conflicts for speakers/moderators. This is also available for download here: https://drive.google.com/file/d/1qp0I9xnyOK3mhBitQnk2a7VuS9XClvyF/view?usp=… Please respond to this thread with any concerns. Cheers, Jimmy

1 0

[nova][kolla] questions on cells
by Mark Goddard 03 Oct '19

03 Oct '19

Hi, I'm currently working (with dougsz) on adding support for nova cells v2 in Kolla Ansible. I have a few questions, and things that I'd like confirming. 1. Is there any benefit to not having a superconductor? Presumably it's a little more efficient in the single cell case? Also IIUC it only requires a single message queue so is a little simpler? 2. Do console proxies need to live in the cells? This is what devstack does in superconductor mode. I did some digging through nova code, and it looks that way. Testing with novncproxy agrees. This suggests we need to expose a unique proxy endpoint for each cell, and configure all computes to use the right one via e.g. novncproxy_base_url, correct? 3. Should I upgrade the superconductor or conductor service first? 4. Does the cell conductor need access to the API DB? 5. What DB configuration should be used in nova.conf when running online data migrations? I can see some migrations that seem to need the API DB, and others that need a cell DB. If I just give it the API DB, will it use the cell mappings to get to each cell DB, or do I need to run it once for each cell? 6. After an upgrade, when can we restart services to unpin the compute RPC version? Looking at the compute RPC API, it looks like the super conductor will remain pinned until all computes have been upgraded. For a cell conductor, it looks like I could restart it to unpin after upgrading all computes in that cell, correct? 7. Which services require policy.{yml,json}? I can see policy referenced in API, conductor and compute. I'm trying to design it such that it's possible to deploy a new cell in an existing environment, and upgrade one cell at a time. Getting the ordering right for this is fiddly, and I expect I'll be back to get some eyes on my plan. Cheers, Mark

6 16

[all] Planned Ussuri release schedule published
by Sean McGinnis 03 Oct '19

03 Oct '19

Hey everyone, The proposed release schedule for Ussuri was up for a few weeks with only cosmetic issues to address. The proposed schedule has now been merged and published to: https://releases.openstack.org/ussuri/schedule.html Barring any new issues with the schedule being raised, this should be our schedule for the Ussuri development cycle. The planned Ussuri release date is May 13, 2020. Thanks! Sean

6 11

[i18n] Request to be added as Vietnamese translation group coordinators
by Trinh Nguyen 03 Oct '19

03 Oct '19

Hi i18n team, Dai and I would like to volunteer as the coordinators of the Vietnamese translation group. If you find us qualified, please let us know. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

5 7