- openstack-discuss - lists.openstack.org

Linstor volume driver
by Jyoti Dahiwele 19 Jul '19

19 Jul '19

Dear Team, Does stein cinder support drbd linstor driver?

3 2

[all] [ptls] [tc] [nova] [neutron] Volunteers that know TeX for PDF community goal
by Alexandra Settle 19 Jul '19

19 Jul '19

Hi all, The work for the Train community goal - PDF support for project docs - is well underway. [1] Now, we're looking for volunteers to help test the implementation. We'll need someone to help build the docs into PDFs and determine things we can fix through tweaks to our docs, or if they're bugs in Sphinx. AKA: We need a troubleshoot artist. If you can volunteer, please add yourself to the wiki table here [2]. I've added neutron and nova specifically here as we need someone who is familiar with the project and it's dependencies to help us get that setup. Any questions? Reach out. Cheers, Alex [1] https://review.opendev.org/#/q/topic:build-pdf-docs+(status:open+OR+status:… [2] https://wiki.openstack.org/wiki/Documentation#PDF_for_Project_Docs_-_Commun…

8 12

[glance][ops] (OSSN-0075) Obfuscate deleted records in glance image table
by Belmiro Moreira 19 Jul '19

19 Jul '19

Hi, because OSSN-0075 (https://wiki.openstack.org/wiki/OSSN/OSSN-0075) we don't purge the glance "images" table. This means that we continue to have information about the deleted images in the DB. For several reasons I would like to not keep data of deleted images that can point to users activity. Currently we simply "obfuscate" all this data. See: https://review.opendev.org/#/c/671707/ I'm curious to know how this problem has been addressed by other deployments. Belmiro CERN

1 0

[placement] update 19-28
by Chris Dent 19 Jul '19

19 Jul '19

HTML: https://anticdent.org/placement-update-19-28.html This is pupdate 19-28. Next week is the Train-2 milestone. # Most Important Based on the discussion on the [PTG attendance thread](http://lists.openstack.org/pipermail/openstack-discuss/2019-July/00… and the notes on the [related etherpad](https://etherpad.openstack.org/p/placement-shanghai-ptg) I'm going to tell the Foundation there will be approximately seven Placement team members at Shanghai but formal space or scheduling will not be required. Instead any necessary discussions will be arranged on premise. If you disagree with this, please speak up soon. The main pending feature is consumer types, see below. # What's Changed * A bug in the resource class cache used in the placement server was found and [fixed](https://review.opendev.org/671341). It will be interesting to see how this impacts performance. While it increases database reads by one (for most requests) it removes a process-wide lock, so things could improve in threaded servers. * os-resource-classes [0.5.0](https://pypi.org/project/os-resource-classes/) was released, adding FPGA and PGPU resource classes. It's been discussed in IRC that we may wish to make 1.x releases of both os-resource-classes and os-traits at some point to make it clear that they are "real". If we do this, I recommend we do it near a cycle boundary. * An [integrated-gate-placement](https://review.opendev.org/669309) zuul template has merged. A [placement change to use it](https://review.opendev.org/671257) is ready and waiting to merge. This avoids running some tests which are unrelated; for example, cinder-only tests. # Specs/Features Since spec freeze for most projects is next week and placement has merged all its specs, until U opens, I'm going to skip this section. # Stories/Bugs (Numbers in () are the change since the last pupdate.) There are 22 (-1) stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement). 0 (0) are [untagged](https://storyboard.openstack.org/#!/worklist/580). 2 (-1) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 5 (0) are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 10 (-1) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 4 (0) are [docs](https://storyboard.openstack.org/#!/worklist/637). If you're interested in helping out with placement, those stories are good places to look. * Placement related nova [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 17 (1). * Placement related nova [in progress bugs](https://goo.gl/vzGGDQ) on launchpad: 4 (0). # osc-placement osc-placement is currently behind by 11 microversions. * <https://review.opendev.org/666542> Add support for multiple member_of. There's been some useful discussion about how to achieve this, and a consensus has emerged on how to get the best results. # Main Themes ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. * <https://review.opendev.org/#/q/topic:bp/support-consumer-types> This is currently the migration to add the necessary table and column. ## Cleanup Cleanup is an overarching theme related to improving documentation, performance and the maintainability of the code. The changes we are making this cycle are fairly complex to use and are fairly complex to write, so it is good that we're going to have plenty of time to clean and clarify all these things. As mentioned for a few weeks, one of the important cleanup tasks that is not yet in progress is updating the [gabbit](https://opendev.org/openstack/placement/src/branch/master/gate/gabb… that creates the nested topology that's used in nested performance testing. We've [asked the startlingx community](http://lists.starlingx.io/pipermail/starlingx-discuss/2019-July/005330.html) for input. Another cleanup that needs to start is satisfying the community wide goal of [PDF doc generation](https://storyboard.openstack.org/#!/story/2006110). I did some experimenting on this and while I was able to get a book created, the number of errors, warnings, and manual interventions required meant I gave up until there's time to do a more in-depth exploration and learn the tools. # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. There are two [os-traits changes](https://review.opendev.org/#/q/project:openstack/os-traits+status:… being discussed. And zero [os-resource-classes changes](https://review.opendev.org/#/q/project:openstack/os-resource-class… (yay!). # Other Service Users New discoveries are added to the end. Merged stuff is removed. Anything that has had no activity in 4 weeks has been removed. * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.openstack.org/650188> nova-spec: Allow compute nodes to use DISK_GB from shared storage RP * <https://review.opendev.org/659233> Cyborg: Placement report * <https://review.opendev.org/662229> helm: add placement chart * <https://review.opendev.org/656023> Nova: Use OpenStack SDK for placement * <https://review.opendev.org/612497> Nova: Spec: Provider config YAML file * <https://review.opendev.org/634551> libvirt: report pmem namespaces resources by provider tree * <https://review.opendev.org/660852> Nova: Remove PlacementAPIConnectFailure handling from AggregateAPI * <https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports> Nova: support move ops with qos ports * <https://review.opendev.org/664689> Nova: get_ksa_adapter: nix by-service-type confgrp hack * <https://review.opendev.org/666202> Blazar: Create placement client for each request * <https://review.opendev.org/667952> nova: Support filtering of hosts by forbidden aggregates * <https://review.opendev.org/669079> blazar: Send global_request_id for tracing calls * <https://review.opendev.org/668252> Nova: Update HostState.\*\_allocation_ratio earlier * <https://review.opendev.org/670112> Nova: WIP: Add a placement audit command * <https://review.opendev.org/586960> zun: [WIP] Use placement for unified resource management * <https://review.opendev.org/671371> neutron: Filter placement API endpoint by type too * <https://review.opendev.org/671638> OSA: Install placement osc plugin on utility machines * <https://review.opendev.org/671478> Kayobe: Build placement images by default * <https://review.opendev.org/671312> blazar: Fix placement operations in multi-region deployments # End If you've done any performance or scale testing with placement, I'd love to hear about your observations. Please let me know. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[cloudkitty] Stepping down from the core team
by Gauvain Pocentek 19 Jul '19

19 Jul '19

Hi all, I am stepping down from the Cloudkitty Core team: I have not been able to contribute for a while, and I'm moving to a new position that doesn't involve Cloudkitty at all. Gauvain Pocentek +46 768 54 12 56 www.objectif-libre.com | @OLNordics | www.linkedin.com/company/objectif-libre

1 0

RE: [networking-ovs-dpdk
by Erik Olof Gunnar Andersson 19 Jul '19

19 Jul '19

Maybe the compute isn't yet mapped to the cell. * nova-manage cell_v2 discover_hosts --verbose Best Regards, Erik Olof Gunnar Andersson From: Li, Cheng1 <cheng1.li(a)intel.com> Sent: Wednesday, July 17, 2019 7:00 PM To: Elanchezian Settu <elanchezian.settu(a)gigamon.com>; openstack-dev(a)lists.openstack.org Subject: RE: [networking-ovs-dpdk Please check the nova-compute log on os-compute-01 to see if any useful info. It may locate at /var/log/nova/ Thanks, Cheng From: Elanchezian Settu [mailto:elanchezian.settu@gigamon.com] Sent: Wednesday, July 17, 2019 2:14 PM To: openstack-dev(a)lists.openstack.org<mailto:openstack-dev@lists.openstack.org> Subject: [networking-ovs-dpdk Hi, I'm trying to setup a multi-node OpenStack environment with OVS-DPDK. Unfortunately I'm running into issue that compute node not getting listed in hypervisor list as below screenshot. Due to this I'm unable to create instances on compute node. Herewith I had attached the local.conf files of both controller and compute node. Can someone help me to resolve this issue. Thanks & Regards, Elan

2 1

[ops][nova] Quick show of hands: any use Intel (non-CMT) `perf` events?
by Kashyap Chamarthy 18 Jul '19

18 Jul '19

Heya folks, While removing some dead code I was wondering if anyone here uses "non-CMT" (Cache Monitoring Technology) performance events events? I'm referring to the events here[0], besides the first three, which are CMT-related. Background ---------- The Intel CMT events (there are three of them) were deprecated during the Rocky release, in this[1] commit, and with this rationale: Upstream Linux kernel has deleted[*] the `perf` framework integration with Intel CMT (Cache Monitoring Technology; or "CQM" in Linux kernel parlance), because the feature was broken by design -- an incompatibility between Linux's `perf` infrastructure and Intel CMT hardware support. It was removed in upstream kernel version v4.14; but bear in mind that downstream Linux distributions with lower kernel versions than 4.14 have backported the said change. Nova supports monitoring of the above mentioned Intel CMT events (namely: 'cmt', 'mbm_local', and 'mbm_total') via the configuration attribute `[libvirt]/enabled_perf_events`. Given that the underlying Linux kernel infrastructure for Intel CMT is removed, we should remove support for it in Nova too. Otherwise enabling them in Nova, and updating to a Linux kernel 4.14 (or above) will result in instances failing to boot. To that end, deprecate support for the three Intel CMT events in "Rocky" release, with the intention to remove support for it in the upcoming "Stein" release. Note that we cannot deprecate / remove `enabled_perf_events` config attribute altogether -- since there are other[+] `perf` events besides Intel CMT. Whether anyone is using those other events with Nova is a good question to which we don't have an equally good answer for, if at all. Now we're removing[2] support for CMT events altogether. Question -------- What I'm wondering now is the answer to the last sentence in the above quoted commit: "Whether anyone is using those other events with Nova is a good question to which we don't have an equally good answer for, if at all". If we know that "no one" (as if we can tell for sure) is using them, we can get rid of more dead code. So, any operators using the non-CMT events from here[0]? [0] https://libvirt.org/formatdomain.html#elementsPerf [1] https://opendev.org/openstack/nova/commit/fc4794acc6 —libvirt: Deprecate support for monitoring Intel CMT `perf` events [2] https://review.opendev.org/669129 — libvirt: Remove support for Intel CMT `perf` event -- /kashyap

2 1

[k8s][magnum] Kubernetes In Tree Provider Scheduled for Removal in 1.17
by Chris Hoge 18 Jul '19

18 Jul '19

After speaking with the SIG-Cloud-Provider leadership this week about the status of the in-tree OpenStack provider for Kubernetes, we’ve decided that barring a major blocker we will be removing the code during the 1.17 release cycle. This means that any code that depends on the in-tree provider will not work with the Kubernetes 1.17 release and after. The in-tree code has been deprecated for over a year now[1], and SIG-OpenStack has maintained an external provider[2] that has moved beyond the in-tree code in features and support. Old releases of Kubernetes will continue to ship with the OpenStack provider code and work with existing projects. While I would strongly prefer to just remove the code in the 1.16 release, the logistics just aren't feasible.[3] It's time for us to turn our support fully to the external provider and stop depending on the in-tree code. Thanks, Chris Hoge SIG-OpenStack and SIG-Cloud-Provider co-lead [1] https://github.com/kubernetes/kubernetes/pull/63524 [2] https://github.com/kubernetes/cloud-provider-openstack [3] https://github.com/kubernetes/kubernetes/pull/80027

2 1

[all][ops][User-Committee] OpenStack User Survey
by Belmiro Moreira 18 Jul '19

18 Jul '19

Hi, The User Survey as been an instrumental source of information that helps improve OpenStack. It provides important feedback to all the different projects. Don't miss the opportunity to register or update your OpenStack deployment information. https://www.openstack.org/user-survey/survey-2019 The 2019 User Survey will close on Thursday, August 22 at 11:59pm UTC. Thank you for your collaboration, Belmiro on behalf of the User-Committee

1 0

[kolla] [freezer] freezer scheduler auth_url error
by Fioravanti, Alessio 18 Jul '19

18 Jul '19

Hi, this is my first post here. I'm experiencing a problem using freezer-scheduler component. When I create a job and schedule it from Horizon, freezer-scheduler always fails. The error shown in freezer-scheduler.log (from fluentd container) is: 2019-07-17 07:48:23.294 6 WARNING freezer.scheduler.scheduler_job [-] Job 1754ea4157b94acb916f8b9911886792 failed backup action, retrying in 60 seconds 2019-07-17 07:49:24.342 6 ERROR freezer.scheduler.scheduler_job [-] Freezer client error: Critical Error: auth_url required to authenticate. Make sure to export OS_AUTH_URL=http://keystone_url:5000/v3 The instance has been deployed with Kolla. Here some details: Environment kolla version: 8.0.1rc1 openstack release: stein base container: centos host os: ubuntu 18.04 environment: 1 controller on a dedicated host + 1 compute on a dedicated host Can you please give me your help? Thanks, Alessio

5 6

[Security SIG] Weekly Newsletter July 18th 2019
by Gage Hugo 18 Jul '19

18 Jul '19

## Week of: 18 July 2019 - Security SIG Meeting Info: http://eavesdrop.openstack.org/#Security_SIG_meeting - Weekly on Thursday at 1500 UTC in #openstack-meeting - Agenda: https://etherpad.openstack.org/p/security-agenda - https://security.openstack.org/ - https://wiki.openstack.org/wiki/Security-SIG ## Meeting Notes - Summary: http://eavesdrop.openstack.org/meetings/security/2019/security.2019-07-18-1… - Shanghai PTG - The Security SIG will not have a designated room for the Shanghai PTG, however fungi will likely be in attendance and is happy to discuss how security is a good thing. - Syntribos - We will send out an email later this week and see about retiring the project. - Newsletter etherpad corruption - The etherpad that hosts the templates and past newsletters became corrupt sometime over the holiday. Big thanks to fungi for helping fix it! ## VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - No new public security bugs this week

1 0

[baremetal-sig][ironic][il8n] Updated whitepaper timeline
by Chris Hoge 18 Jul '19

18 Jul '19

Hi everyone, I’ve updated the bare metal whitepaper draft to include an editorial schedule (also included in this email) for the planned November publication date. Please take a look and offer feedback, particularly the internationalzation and translation team. With the publication planned to coincide with the Shanghai Summit, we would like to offer a translation in Chinese if possible. https://docs.google.com/document/d/1KBhJcmpCTm8hn0BX-jO5MAyBYf2RHM5Jh5ib7GT… July 22 - Solicit contributions from Bare Metal SIG. July 29 - Review existing document and outline. August 5 - Assign sections to Bare Metal SIG volunteers. September 2 - Review of existing work, graphic and design requests to OSF. October 1 - Content finalized for editorial review and final graphics production. October 1 - Content to Il8n team for translation October 21 - Content (text and graphics) finalized for final copy preparation. November 4 - Publication for OpenInfrastructure Summit Shanghai. Thanks! Chris

1 0

[stein][ceilometer] file/directory structure changes in ceilometer/agent and compute/pollsters with respect to liberty ceilometer
by Sanjay K 18 Jul '19

18 Jul '19

Hi All, Currently we are trying to upgrade our older customized openstack deployment by upgrading it to Openstack Stein release from Openstack liberty release. In the older version, we had customized ceilometer source to integrate graphite so that we can send some metrices information to the carbon db which will be consumed by some other UI tools or application. For that we modified code in ceilometer/opts.py in list_opts() with - *('graphite_config', ceilometer.graphite.dispatcher_opts),* and defined dispatcher_opts for graphite host and ports in a new graphite.py file. Also we did some changes in ceilometer/agent/manager.py to import graphite config values like - *cfg.CONF.import_group('graphite_config', 'ceilometer.graphite')* In compute/pollsters, we modified cpu.py, memory.py and net.py files to send the metric data to graphite adding new function for it. *cfg.CONF.import_group('graphite_config', 'ceilometer.service')availability_zone = cfg.CONF.graphite_config.availability_zonehostname = socket.gethostname()CARBON_SERVER = cfg.CONF.graphite_config.graphite_hostCARBON_PORT = cfg.CONF.graphite_config.graphite_port* *def send_to_graphite(self,instance,cpupercent): path = 'ceilometer.' + availability_zone + '.' + hostname + '.' + instance + '.cpu.utilization' timestamp = int(time.time()) message = '%s %s %d\n' % (path, cpupercent, timestamp) sock = socket.socket() sock.connect((CARBON_SERVER, CARBON_PORT)) sock.sendall(message) sock.close()* The same function we redefined for cpu, memory and net. We also used this function inside get_sample() function to send the data to graphite. As I was applying the same changes into stein ceilometer, I found there are lot of structural changes in files and source code level. I was trying to correlate the old change with respect to new source in stein. However the files/directory structure is changed inside ceilometer/agent and compute/pollsters. Can you please guide me how these agent and pollsters changes can be mapped into the newer source code so that I can apply my old code changes in the latest ceilometer source files? As being new to openstack system, I don't have complete knowledge of what happened to the code in between liberty and stein version though I have gone through release notes and few details about these openstack services. Any pointers to specs/code reviews with respect to these structural changes will be helpful to me. Thank you for your help and pointers on this. best regards, Sanjay

1 0

[networking-ovs-dpdk
by Elanchezian Settu 18 Jul '19

18 Jul '19

Hi, I'm trying to setup a multi-node OpenStack environment with OVS-DPDK. Unfortunately I'm running into issue that compute node not getting listed in hypervisor list as below screenshot. Due to this I'm unable to create instances on compute node. Herewith I had attached the local.conf files of both controller and compute node. Can someone help me to resolve this issue. [cid:image001.jpg@01D53C94.E3DEBF30] Thanks & Regards, Elan This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the intended recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such unauthorized use. NOTE that all incoming emails sent to Gigamon email accounts will be archived and may be scanned by us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavior, and/or eliminate unsolicited promotional emails ("spam").

2 3

Barbican support for Window
by Garaga Rayudu 18 Jul '19

18 Jul '19

Hi Team, Is it supported for window OS. If Yes, please let me know more details about installation. Also let me know should I integrate with our product freely to support key management. Since it look like open source product. Thanks, Rayudu

2 1

[blazar] IRC meeting today: upstream contributions
by Pierre Riteau 18 Jul '19

18 Jul '19

Hello, We have our biweekly Blazar IRC meeting in around one hour on #openstack-meeting-alt: https://wiki.openstack.org/wiki/Meetings/Blazar#Agenda_for_18_Jul_2019_.28A… I would like to focus the discussion on the status of upstream contributions from our user community. Everyone is welcome to join. Cheers, Pierre

1 0

opensips with asterisk integration question
by Satish Patel 18 Jul '19

18 Jul '19

I am trying to conigured opensips as registar and asterisk for media services using this doc: https://www.opensips.org/Documentation/Tutorials-OpenSIPSAsteriskIntegration so far everything went well and i am able to use VoiceMail, MeetMe etc. but when i am trying to dial any SIP phone getting following error Asterisk logs: [Jul 17 15:23:05] NOTICE[9933][C-00000001]: chan_sip.c:31847 build_peer: The 'username' field for sip peers has been deprecated in favor of the term 'defaultuser' [Jul 17 15:23:05] WARNING[9933][C-00000001]: sip/config_parser.c:817 sip_parse_nat_option: nat=yes is deprecated, use nat=force_rport,comedia instead [Jul 17 15:23:05] WARNING[9972][C-00000001]: sip/config_parser.c:817 sip_parse_nat_option: nat=yes is deprecated, use nat=force_rport,comedia instead [Jul 17 15:23:05] NOTICE[9933][C-00000001]: chan_sip.c:24288 handle_response_invite: Failed to authenticate on INVITE to '"1001" <sip:1001@opensips.org>;tag=as1986a977' voip*CLI> In mysql sipusers look like following: *************************** 3. row *************************** name: 1001 username: 1001 type: friend secret: NULL host: opensips.org callerid: NULL context: default mailbox: 1001 nat: yes qualify: no fromuser: 1001 authuser: NULL fromdomain: opensips.org insecure: NULL canreinvite: no disallow: NULL allow: NULL restrictcid: NULL defaultip: opensips.org ipaddr: opensips.org port: 5060 regseconds: NULL basis dialplan ; announcement demo exten => 2000,1,Ringing exten => 2000,2,Playback(welcome) exten => 2000,3,Hangup ; voicemail exten => 777,1,Ringing exten => 777,n,Wait(1) exten => 777,n,Answer exten => 777,n,Wait(1) exten => 777,n,VoiceMailMain(@default) exten => 777,n,Hangup exten => 1001,1,Dial(SIP/1001) exten => 1002,1,Dial(SIP/1002)

2 1

[doc8] future development and maintenance
by Sorin Sbarnea 18 Jul '19

18 Jul '19

It seems that the doc8 project is lacking some love, regardless the fact that is used by >90 projects from opendev.org. https://review.opendev.org/#/q/project:x/doc8 Last merge and release was more than 2 years ago and no reviews were performed either. I think it would be in our interest to assure that doc8 maintenance continues and that we can keep it usable. I would like to propose extenting the list of cores from the current 4 ones that I already listed in CC with 3 more, so we can effectively make a change that gets merged and later released (anyone willing to help?) If current cores agree, I would be happy to help with maintenance. I estimate that the effort needed would likely be less than 1h/month in longer term. If there is a desire to move it to github/travis, I would not mind either. Thanks Sorin Sbarnea Red Hat TripleO CI

2 3

[nova] API updates week 19-29
by Ghanshyam Mann 18 Jul '19

18 Jul '19

Hello Everyone, Please find the Nova API updates of this week. API Related BP : ============ COMPLETED: 1. Support adding description while locking an instance: - https://blueprints.launchpad.net/nova/+spec/add-locked-reason Code Ready for Review: ------------------------------ 1. Add host and hypervisor_hostname flag to create server - Topic: https://review.opendev.org/#/q/topic:bp/add-host-and-hypervisor-hostname-fl… - Weekly Progress: API patch is merged. Oonly left is OSC patch and doc patch which is already +A. 2. Specifying az when restore shelved server - Topic: https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-… - Weekly Progress: Brin updated the patch after review comments. Schema and tests are fixed now and ready for next round of review. 3. Nova API cleanup - Topic: https://review.opendev.org/#/q/topic:bp/api-consistency-cleanup+(status:ope… - Weekly Progress: Updated patch with latest microverion. Ready for review. This is in runway round for next week. Specs are merged and code in-progress: ------------------------------ ------------------ 4. Nova API policy improvement - Topic: https://review.openstack.org/#/q/topic:bp/policy-default-refresh+(status:op… - Weekly Progress: No much progress on this. Last week, I started the testing coverage of the existing policies with little refactoring on John PoC. 5. Detach and attach boot volumes: - Topic: https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+O… - Weekly Progress: No Progress. Patches are in merge conflict. Spec Ready for Review: ----------------------------- 1. Support for changing deleted_on_termination after boot -Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: No update this week. Pending on Lee Yarwood proposal after PTG discussion. 3. Support delete_on_termination in volume attach api -Spec: https://review.openstack.org/#/c/612949/ - Weekly Progress: No updates this week. matt recommend to merging this with 580336 which is pending on Lee Yarwood proposal. Previously approved Spec needs to be re-proposed for Train: --------------------------------------------------------------------------- 1. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-… - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-na… - I remember I planned this to re-propose but could not get time. If anyone would like to help on this please repropose. otherwise I will start this in U cycle. 2. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(… - This also need volutneer - http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007411.html Others: 1. Add API ref guideline for body text - 2 api-ref are left to fix. Bugs: ==== No progress report in this week. NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes.

1 0

[sigs][publiccloud][publiccloud-wg][publiccloud-sig][billing] Meeting today at 1400 UTC regarding billing initiative
by Tobias Rydberg 17 Jul '19

17 Jul '19

Hi all, This is a reminder for todays meeting for the Public Cloud SIG - 1400 UTC in #openstack-publiccloud. The topic of the day will be continued discussions regarding the billing initiative. More information about that at https://etherpad.openstack.org/p/publiccloud-sig-billing-implementation-pro… See you all later today! 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

ImportError: No module named django.core.wsgi - DevStack
by Manula Thantriwatte 17 Jul '19

17 Jul '19

Hi All, I have successfully install DevStack in Ubuntu 18.04. But when I'm accessing the dashboard I'm getting 500 error. What I'm getting in horizon_error.log is, 2019-07-15 14:10:43.218296 mod_wsgi (pid=31763): Target WSGI script '/opt/stack/horizon/openstack_dashboard/wsgi.py' cannot be loaded as Python module. 2019-07-15 14:10:43.218323 mod_wsgi (pid=31763): Exception occurred processing WSGI script '/opt/stack/horizon/openstack_dashboard/wsgi.py'. 2019-07-15 14:10:43.218349 Traceback (most recent call last): 2019-07-15 14:10:43.218370 File "/opt/stack/horizon/openstack_dashboard/wsgi.py", line 21, in <module> 2019-07-15 14:10:43.218401 from django.core.wsgi import get_wsgi_application 2019-07-15 14:10:43.218422 ImportError: No module named django.core.wsgi Python Version is : 3.6.8 Django version is : 2.0.5 I tried with uninstalling Djanago and reinstalling it. But it didn't work for me. Can someone help me on how to resole this issue ? Thanks ! -- Regards, Manula Chathurika Thantriwatte phone : (+94) 772492511 email : manulachathurika(a)gmail.com Linkedin : *http://lk.linkedin.com/in/manulachathurika <http://lk.linkedin.com/in/manulachathurika>* blog : http://manulachathurika.blogspot.com/

3 5

kolla-ansible 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 17 Jul '19

17 Jul '19

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

1 0

kolla 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 17 Jul '19

17 Jul '19

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

1 0

[octavia] Shanghai PTG planning etherpad
by Michael Johnson 17 Jul '19

17 Jul '19

Hello Octavia! I have created an etherpad to start tracking topics for the Shanghai (U) PTG: https://etherpad.openstack.org/p/octavia-shanghai-U-ptg Michael

1 0

[oslo][walkthrough] How openstack services use the oslo.messaging rabbitmq driver
by Herve Beraud 17 Jul '19

17 Jul '19

Hello, During my working period related to the issue with the oslo.messaging rabbitmq heartbeat [1], I'd to studied how service consume oslo.messaging drivers to understand of things works together and also the execution model behind the scene. So during this period I wrote a walkthrough [2] to observe how nova-api use and consume the oslo.messaging rabbitmq driver. As I sayed, my walkthrough is focused on the studying of the nova-api, it start from how service are runned (the puppet steps), through how nova-api is runned by using mod_wsgi, to going to at least to how to nova-api instanciate the oslo.messaging rabbitmq driver. I also explain different solutions to fix the heartbeat rabbitmq driver issue and more globaly why potentially we facing this problem with apache, and the role of the MPM prefork module inside the issue. I think that some parts of this article and especially my walkthrough can be useful for other persons and openstackers, so I want share it with you. I surely wrote some erroned things in my article, so please do not hesitate to fix it if you see one and to send me a pull request [3]. Else if see other interesting things to add to it do not hesitate too. Enjoy your reading and I hope you will find some useful info by reading my article. Thank you for your attention. [1] https://bugs.launchpad.net/nova/+bug/1825584 [2] https://herve.beraud.io/openstack/nova/oslo.messaging/rabbitmq/driver/2019/… [3] https://github.com/4383/4383.github.io -- 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-----

1 0

[Nova] Instances can't be started after compute nodes unexpectedly shut down because of power outage
by Gökhan IŞIK 17 Jul '19

17 Jul '19

Hi folks, Because of power outage, Most of our compute nodes unexpectedly shut down and now I can not start our instances. Error message is "Failed to get "write" lock another process using the image?". Instances Power status is No State. Full error log is http://paste.openstack.org/show/754107/. My environment is OpenStack Pike on Ubuntu 16.04 LTS servers and Instances are on a nfs shared storage. Nova version is 16.1.6.dev2. qemu version is 2.10.1. libvirt version is 3.6.0. I saw a commit [1], but it doesn't solve this problem. There are important instances on my environment. How can I rescue my instances? What would you suggest ? Thanks, Gökhan [1] https://review.opendev.org/#/c/509774/

2 10

Fwd: [openstack-community] [openstack-ansible] do I need deploymenthost on same br-mgmt network
by Amy Marrich 17 Jul '19

17 Jul '19

Rakesh, Forwarding this to the discuss list for more attention. Keep in mind OSA does take some time to run so including at what point you're failing would be helpful. Thanks, Amy (spotz) ---------- Forwarded message --------- From: rakesh zingade <rakeshzingade(a)gmail.com> Date: Wed, Jul 17, 2019 at 3:11 AM Subject: [openstack-community] [openstack-ansible] do I need deploymenthost on same br-mgmt network To: <community(a)lists.openstack.org> Hi, I am pretty new to openstack and openstack ansible. I am trying to install openstack in our lab. So lab server are on different network ( 10.200.105.0/24 [external] and 10.200.75.0/24 [internal-within lab servers]) I suppose to deploy openstack by accessing remote connection and I am on different network (10.200.104.0/24) in same private lan & can access target hosts on ssh. my openstack_user_config.yml as below: cidr_networks: container: 10.200.105.0/24 storage: 10.200.75.0/24 tunnel: 10.200.105.0/24 used_ips: - "10.200.105.200,10.200.105.201" - "10.200.105.1,10.200.105.50" global_overrides: internal_lb_vip_address: 10.200.105.200 external_lb_vip_address: 10.200.105.200 management_bridge: "br-mgmt" provider_networks: - network: container_bridge: br-mgmt container_interface: eth1 container_type: veth group_binds: - all_containers - hosts ip_from_q: container is_container_address: true type: raw - network: container_bridge: br-storage container_interface: eth2 container_mtu: "9000" container_type: veth group_binds: - glance_api - cinder_api - cinder_volume - nova_compute - swift_proxy ip_from_q: storage type: raw - network: container_bridge: br-vxlan container_interface: eth10 container_mtu: "9000" container_type: veth group_binds: - neutron_linuxbridge_agent ip_from_q: tunnel net_name: vxlan range: "1:1000" type: vxlan - network: container_bridge: br-vlan container_interface: eth11 container_type: veth group_binds: - neutron_linuxbridge_agent net_name: vlan range: "101:200,301:400" type: vlan - network: container_bridge: br-vlan container_interface: eth12 container_type: veth group_binds: - neutron_linuxbridge_agent host_bind_override: eth12 net_name: flat type: flat shared-infra_hosts: infra1: container_vars: container_tech: lxc ip: 10.200.105.200 My deployment gets hanged after deploying lxc containers? any clue why this is happening? is my network is incorrect? do I have to deploy from same network i.e. 10.200.105.0/24 or 10.200.75.0/24? please let me know Thanks, -- Rakesh P. Zingade _______________________________________________ Community mailing list Community(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/community

2 1

[puppet] retiring puppet-crane
by Alex Schultz 17 Jul '19

17 Jul '19

Hello, We're going through the process to retire puppet-crane. It wasn't ever used and it was decided not to proceed forward with using crane (due to lack of python3 support). Thanks, -Alex

1 0

[openstack-ansible][neutron] Drop of the legacy neutron L3 HA tool
by Dmitriy Rabotyagov 17 Jul '19

17 Jul '19

Hi everyone, We're about to drop our legacy L3 HA tooling [1], since neutron has built-in HA for a long time. So in case you still need it please consider either switching to the native L3 HA or creating custom roles to deploy it afterwards. If you have any questions or suggestions regarding this, you are always welcome. [1] https://review.opendev.org/671247/ -- Kind regards, Dmitriy Rabotyagov

1 0

[oslo] PTG Planning Etherpad
by Ben Nemec 17 Jul '19

17 Jul '19

Hi, I've created a planning etherpad for Shanghai: https://etherpad.openstack.org/p/oslo-shanghai-topics We need to know by Aug. 11 if we want to request PTG space this time around so when you find out if you're going please add yourself to the list on the etherpad. There's also the usual space for topics if you know of anything we need to discuss already. Thanks. -Ben

2 1

Re: Linux bridge agent Agent out of sync with plugin!
by Slawek Kaplonski 17 Jul '19

17 Jul '19

Hi, Please continue this discussion on ML that anyone can see it :) What agents do You exactly see in “neutron agent-list” command then? What You have set as “host” value in linuxbridge agent’s config on different nodes? Can You enable DEBUG log and send it also? > On 17 Jul 2019, at 04:05, zhenhua_huang(a)trendmicro.com wrote: > > Hello: > > Thank you for reading my letter. .I mean that neutron-linuxbridge-agent from compute node is not visible in “neutron agent-list” result. > The compute node's linuxbridge-agent.log. is as follows: > 2019-07-16 02:12:48.328 20720 INFO neutron.plugins.ml2.drivers.agent._common_agent [-] Stopping Linux bridge agent agent. > 2019-07-16 02:12:50.468 21622 INFO neutron.common.config [-] Logging enabled! > 2019-07-16 02:12:50.468 21622 INFO neutron.common.config [-] /usr/bin/neutron-linuxbridge-agent version 11.0.8 > 2019-07-16 02:12:50.468 21622 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Interface mappings: {'provider': 'ens192'} > 2019-07-16 02:12:50.468 21622 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Bridge mappings: {} > 2019-07-16 02:12:50.485 21622 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Agent initialized successfully, now running... > 2019-07-16 02:12:50.865 21622 INFO oslo_rootwrap.client [req-7cca3135-d8f4-4156-98dd-9d123c492a85 - - - - -] Spawned new rootwrap daemon process with pid=21636 > 2019-07-16 02:12:50.906 21622 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-7cca3135-d8f4-4156-98dd-9d123c492a85 - - - - -] RPC agent_id: lb525400810624 > 2019-07-16 02:12:50.912 21622 INFO neutron.agent.agent_extensions_manager [req-7cca3135-d8f4-4156-98dd-9d123c492a85 - - - - -] Loaded agent extensions: [] > 2019-07-16 02:12:51.143 21622 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-7cca3135-d8f4-4156-98dd-9d123c492a85 - - - - -] Linux bridge agent Agent RPC Daemon Started! > 2019-07-16 02:12:51.143 21622 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-7cca3135-d8f4-4156-98dd-9d123c492a85 - - - - -] Linux bridge agent Agent out of sync with plugin! > 2019-07-16 02:12:51.154 21622 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect [req-7cca3135-d8f4-4156-98dd-9d123c492a85 - - - - -] Clearing orphaned ARP spoofing entries for devices [] > > > The controller node's linuxbridge-agent.log. is as follows: > 2019-07-16 21:37:32.127 15465 INFO neutron.plugins.ml2.drivers.agent._common_agent [-] Stopping Linux bridge agent agent. > 2019-07-16 21:37:32.138 15465 INFO oslo_rootwrap.client [-] Stopping rootwrap daemon process with pid=15491 > 2019-07-16 21:37:33.738 15657 INFO neutron.common.config [-] Logging enabled! > 2019-07-16 21:37:33.739 15657 INFO neutron.common.config [-] /usr/bin/neutron-linuxbridge-agent version 11.0.8 > 2019-07-16 21:37:33.740 15657 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Interface mappings: {'provider': 'ens192'} > 2019-07-16 21:37:33.740 15657 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Bridge mappings: {} > 2019-07-16 21:37:33.754 15657 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Agent initialized successfully, now running... > 2019-07-16 21:37:34.063 15657 INFO oslo_rootwrap.client [req-7df1f224-2dcd-4193-bcf1-d6c0b66f5c90 - - - - -] Spawned new rootwrap daemon process with pid=15683 > 2019-07-16 21:37:34.093 15657 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-7df1f224-2dcd-4193-bcf1-d6c0b66f5c90 - - - - -] RPC agent_id: lb525400be6607 > 2019-07-16 21:37:34.100 15657 INFO neutron.agent.agent_extensions_manager [req-7df1f224-2dcd-4193-bcf1-d6c0b66f5c90 - - - - -] Loaded agent extensions: [] > 2019-07-16 21:37:34.341 15657 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-7df1f224-2dcd-4193-bcf1-d6c0b66f5c90 - - - - -] Linux bridge agent Agent RPC Daemon Started! > 2019-07-16 21:37:34.342 15657 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-7df1f224-2dcd-4193-bcf1-d6c0b66f5c90 - - - - -] Linux bridge agent Agent out of sync with plugin! > 2019-07-16 21:37:34.350 15657 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect [req-7df1f224-2dcd-4193-bcf1-d6c0b66f5c90 - - - - -] Clearing orphaned ARP spoofing entries for devices [] > 2019-07-16 21:58:49.471 15657 INFO neutron.plugins.ml2.drivers.agent._common_agent [-] Stopping Linux bridge agent agent. > 2019-07-16 21:58:51.033 16466 INFO neutron.common.config [-] Logging enabled! > 2019-07-16 21:58:51.033 16466 INFO neutron.common.config [-] /usr/bin/neutron-linuxbridge-agent version 11.0.8 > 2019-07-16 21:58:51.034 16466 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Interface mappings: {'provider': 'ens192'} > 2019-07-16 21:58:51.034 16466 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Bridge mappings: {} > 2019-07-16 21:58:51.046 16466 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Agent initialized successfully, now running... > 2019-07-16 21:58:51.356 16466 INFO oslo_rootwrap.client [req-705ff1b1-c733-411f-a355-498369153e65 - - - - -] Spawned new rootwrap daemon process with pid=16492 > 2019-07-16 21:58:51.415 16466 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-705ff1b1-c733-411f-a355-498369153e65 - - - - -] RPC agent_id: lb525400be6607 > 2019-07-16 21:58:51.421 16466 INFO neutron.agent.agent_extensions_manager [req-705ff1b1-c733-411f-a355-498369153e65 - - - - -] Loaded agent extensions: [] > 2019-07-16 21:58:51.729 16466 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-705ff1b1-c733-411f-a355-498369153e65 - - - - -] Linux bridge agent Agent RPC Daemon Started! > 2019-07-16 21:58:51.730 16466 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-705ff1b1-c733-411f-a355-498369153e65 - - - - -] Linux bridge agent Agent out of sync with plugin! > 2019-07-16 21:58:51.739 16466 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect [req-705ff1b1-c733-411f-a355-498369153e65 - - - - -] Clearing orphaned ARP spoofing entries for devices [] > 2019-07-16 21:59:38.037 16466 INFO neutron.plugins.ml2.drivers.agent._common_agent [-] Stopping Linux bridge agent agent. > 2019-07-16 21:59:38.045 16466 INFO oslo_rootwrap.client [-] Stopping rootwrap daemon process with pid=16492 > 2019-07-16 21:59:39.679 16592 INFO neutron.common.config [-] Logging enabled! > 2019-07-16 21:59:39.679 16592 INFO neutron.common.config [-] /usr/bin/neutron-linuxbridge-agent version 11.0.8 > 2019-07-16 21:59:39.679 16592 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Interface mappings: {'provider': 'ens192'} > 2019-07-16 21:59:39.680 16592 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Bridge mappings: {} > 2019-07-16 21:59:39.694 16592 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Agent initialized successfully, now running... > 2019-07-16 21:59:40.043 16592 INFO oslo_rootwrap.client [req-eb16336e-e18d-4b80-b75c-718645f045c2 - - - - -] Spawned new rootwrap daemon process with pid=16618 > 2019-07-16 21:59:40.085 16592 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-eb16336e-e18d-4b80-b75c-718645f045c2 - - - - -] RPC agent_id: lb525400be6607 > 2019-07-16 21:59:40.092 16592 INFO neutron.agent.agent_extensions_manager [req-eb16336e-e18d-4b80-b75c-718645f045c2 - - - - -] Loaded agent extensions: [] > 2019-07-16 21:59:40.243 16592 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-eb16336e-e18d-4b80-b75c-718645f045c2 - - - - -] Linux bridge agent Agent RPC Daemon Started! > 2019-07-16 21:59:40.243 16592 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-eb16336e-e18d-4b80-b75c-718645f045c2 - - - - -] Linux bridge agent Agent out of sync with plugin! > 2019-07-16 21:59:40.254 16592 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect [req-eb16336e-e18d-4b80-b75c-718645f045c2 - - - - -] Clearing orphaned ARP spoofing entries for devices [] > 2019-07-16 22:02:15.863 16592 INFO neutron.plugins.ml2.drivers.agent._common_agent [-] Stopping Linux bridge agent agent. > 2019-07-16 22:02:15.867 16592 INFO oslo_rootwrap.client [-] Stopping rootwrap daemon process with pid=16618 > 2019-07-16 22:02:17.347 16795 INFO neutron.common.config [-] Logging enabled! > 2019-07-16 22:02:17.348 16795 INFO neutron.common.config [-] /usr/bin/neutron-linuxbridge-agent version 11.0.8 > 2019-07-16 22:02:17.348 16795 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Interface mappings: {'provider': 'ens192'} > 2019-07-16 22:02:17.348 16795 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Bridge mappings: {} > 2019-07-16 22:02:17.361 16795 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Agent initialized successfully, now running... > 2019-07-16 22:02:17.677 16795 INFO oslo_rootwrap.client [req-baf4316e-3d5a-41ce-a3cb-aece7104a568 - - - - -] Spawned new rootwrap daemon process with pid=16820 > 2019-07-16 22:02:17.707 16795 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-baf4316e-3d5a-41ce-a3cb-aece7104a568 - - - - -] RPC agent_id: lb525400be6607 > 2019-07-16 22:02:17.720 16795 INFO neutron.agent.agent_extensions_manager [req-baf4316e-3d5a-41ce-a3cb-aece7104a568 - - - - -] Loaded agent extensions: [] > 2019-07-16 22:02:17.908 16795 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-baf4316e-3d5a-41ce-a3cb-aece7104a568 - - - - -] Linux bridge agent Agent RPC Daemon Started! > 2019-07-16 22:02:17.908 16795 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-baf4316e-3d5a-41ce-a3cb-aece7104a568 - - - - -] Linux bridge agent Agent out of sync with plugin! > 2019-07-16 22:02:17.917 16795 INFO neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect [req-baf4316e-3d5a-41ce-a3cb-aece7104a568 - - - - -] Clearing orphaned ARP spoofing entries for devices [] > look forward to your reply. > -----Original Message----- > From: Slawek Kaplonski <skaplons(a)redhat.com> > Sent: 2019年7月17日 4:14 > To: Zhenhua Huang (RD-CN) <zhenhua_huang(a)trendmicro.com> > Cc: openstack-discuss(a)lists.openstack.org > Subject: Re: Linux bridge agent Agent out of sync with plugin! > > Hi, > > What exactly do You mean by saying “the compute node is not found”? Is neutron-linuxbridge-agent from compute node not visible in “neutron agent-list” result or it is visible but down? > Or something else? > Also, please send logs as plain text instead of screenshots - it will be much easier to read :) > >> On 16 Jul 2019, at 11:47, zhenhua_huang(a)trendmicro.com wrote: >> >> Hello, I am a newcomer to openstack. I have a problem. >> When I enter the command "openstack network agent list" on the controller node, the compute node is not found. Below are the output of the compute node's and controller node’s linuxbridge-agent.log.look forward to your reply. >> >> >> <image002.png><image002.png> >> compute node >> >> <image003.png><image003.png> >> controller node >> >> TREND MICRO EMAIL NOTICE >> The information contained in this email and any attachments is >> confidential and may be subject to copyright or other intellectual property protection. >> If you are not the intended recipient, you are not authorized to use >> or disclose this information, and we request that you notify us by >> reply mail or telephone and delete the original message from your mail system. >> >> For details about what personal information we collect and why, please >> see our Privacy Notice on our website at: [ >> https://www.trendmicro.com/privacy >> ] >> > > — > Slawek Kaplonski > Senior software engineer > Red Hat > > > <table class="TM_EMAIL_NOTICE"><tr><td><pre> > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > For details about what personal information we collect and why, please see our Privacy Notice on our website at: [ https://www.trendmicro.com/privacy] > </pre></td></tr></table> — Slawek Kaplonski Senior software engineer Red Hat

1 0

[devstack] [trove] Enabling other datastores, plugin variable design less than tidy
by Mark Kirkwood 17 Jul '19

17 Jul '19

Hi, I'm doing some work with the Trove Postgres datastore. So the first thing I did was attempt to get Devstack to set up a stack with Postgres instead of Mysql. Reading the docs, it seemed that all I needed to do was this: $ cat local.conf [[local|localrc]] ADMIN_PASSWORD=password DATABASE_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD TROVE_DATASTORE_TYPE=postgresql TROVE_DATASTORE_VERSION=9.6 TROVE_DATASTORE_PACKAGE=postgresql-9.6 enable_plugin trove https://opendev.org/openstack/trove Wrong! After watching the plugin try to build a Mysql guest image of version 9.6 (!), I realized that more reading of the plugin source was required. So iteration 2 (or maybe it was 3...lol), of my local.conf is: [[local|localrc]] ADMIN_PASSWORD=password DATABASE_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD TROVE_DATASTORE_TYPE=postgresql TROVE_DATASTORE_VERSION=9.6 TROVE_DATASTORE_PACKAGE=postgresql-9.6 SERVICE_TYPE=$TROVE_DATASTORE_TYPE DATASTORE_VERSION=$TROVE_DATASTORE_VERSION VM=/opt/stack/images/ubuntu_postgresql/ubuntu_postgresql enable_plugin trove https://opendev.org/openstack/trove This works. However, it seems like those last 3 variable substitutions should not be required. i.e: - SERVICE_TYPE should not exist (we should use TROVE_DATASTORE_TYPE) - DATASTORE_VERSION should not exist (we should use TROVE_DATASTORE_VERSION) - VM should be constructed out of DISTRO and TROVE_DATASTORE_TYPE Thoughts? regards Mark

2 2

[kolla][nova][neutron] Access to VMs is slow when running on a remote compute host
by Giuseppe Sannino 17 Jul '19

17 Jul '19

Hi community, I need your help ,tips, advices. *> Environment <* I have deployed Openstack "Stein" using the latest kolla-ansible on the following deployment topology: 1) OS Controller running as VM on a "cloud" location 2) OS Compute running on a baremetal server remotely (wrt OS Controller) location 3) Network node running on the Compute host As per the above info, Controller and compute run on two different networks. Kolla-Ansible is not really designed for such scenario but after manipulating the globals.yml and the inventory files (basically I had to move node specific network settings from the globals to the inventory file), eventually the deployment works fine. *> Problem <* I have no specific issue working with this deployment except the following: "SSH connection to the VM is quite slow". It takes around 20 seconds for me to log into the VM (Ubuntu, CentOS, whatever). *> Observations <* - Except for the slowness during the SSH login, I don't have any further specific issue working with this envirorment - With the Network on the Compute I can turn the OS controller off with no impact on the VM. Still the connection is slow - I tried different type of images (Ubuntu, CentOS, Windows) always with the same result. - SSH connection is slow even if I try to login into the VM within the IP Namespace >From the ssh -vvv, I can see that the authentication gets stuck here: debug1: Authentication succeeded (publickey). Authenticated to ***** debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug3: send packet: type 90 debug1: Requesting no-more-sessions(a)openssh.com debug3: send packet: type 80 debug1: Entering interactive session. debug1: pledge: network >>>>> 10 to 15 seconds later debug3: receive packet: type 80 debug1: client_input_global_request: rtype hostkeys-00(a)openssh.com want_reply 0 debug3: receive packet: type 91 debug2: callback start debug2: fd 3 setting TCP_NODELAY debug3: ssh_packet_set_tos: set IP_TOS 0x10 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 Have you ever experienced such issue ? Any suggestion? Many thanks /Giuseppe

8 12

[Mistral] Guaranteed notification delivery
by Лапин Артем 16 Jul '19

16 Jul '19

Good day, please look at https://blueprints.launchpad.net/mistral/+spec/guaranteed-notifies. I would like to know your opinion about this feature.

2 1

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

16 Jul '19

Hi all, 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

Linux bridge agent Agent out of sync with plugin!
by zhenhua_huang＠trendmicro.com 16 Jul '19

16 Jul '19

Hello, I am a newcomer to openstack. I have a problem. When I enter the command "openstack network agent list" on the controller node, the compute node is not found. Below are the output of the compute node's and controller node's linuxbridge-agent.log.look forward to your reply. [cid:image002.png@01D53BFE.57DAB2A0][cid:image002.png@01D53BFE.57DAB2A0] compute node [cid:image003.png@01D53BFE.57DAB2A0][cid:image003.png@01D53BFE.57DAB2A0] controller node <table class="TM_EMAIL_NOTICE"><tr><td><pre> TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. For details about what personal information we collect and why, please see our Privacy Notice on our website at: [ https://www.trendmicro.com/privacy] </pre></td></tr></table>

2 1

Community Voting is now Open!
by Jimmy McArthur 16 Jul '19

16 Jul '19

Community voting for the Open Infrastructure Summit Shanghai sessions is open! You can VOTE HERE <https://www.openstack.org/summit/shanghai-2019/vote-for-speakers>, but what does that mean? Now that the Call for Presentations has closed, all submissions are available for community vote and input. After community voting closes, the volunteer Programming Committee members will receive the results to review to help them determine the final selections for Summit schedule. While community votes are meant to help inform the decision, Programming Committee members are expected to exercise judgment in their area of expertise and help ensure diversity of sessions and speakers. View full details of the session selection process <https://cfp.openstack.org/#selection-process>. In order to vote, you need an OSF community membership. If you do not have an account, please create one by going to openstack.org/join <https://www.openstack.org/join>. If you need to reset your password, you can do that here <https://www.openstack.org/Security/lostpassword>. Hurry, voting closes Monday, July 22 at 11:59pmPacific Time (Tuesday, July 23 at 6:59 UTC). Continue to visit https://www.openstack.org/summit/shanghai-2019 for all Summit-related information. REGISTER Register for the Summit <https://www.openstack.org/summit/shanghai-2019> before prices increase on August 7th! VISA APPLICATION PROCESS Make sure to secure your Visa soon. More information <https://www.openstack.org/summit/shanghai-2019/travel/#travel-support> about the Visa application process. TRAVEL SUPPORT PROGRAM August 8th is the last day to submit applications. Please submit your applications <https://openstackfoundation.formstack.com/forms/travelsupportshanghai> by 11:59pm Pacific Time (August 9th at 6:59am UTC). If you have any questions, please email summit(a)openstack.org <mailto:summit@openstack.org>. Cheers, Jimmy

1 0

[docs][tc][infra] what to do with developer.openstack.org and api-site?
by Andreas Jaeger 16 Jul '19

16 Jul '19

The website developer.openstack.org has the tagline "Development resources for OpenStack clouds" and hosts development and API information, especially: * An index page * The OpenStack api-guide * The document "Writing Your First OpenStack Application" ("firstapp guide") * The individual api-guides and api-references which are published from the individual projects like Nova or Keystone. The index page, the OpenStack api-guide and the document "Writing your first OpenStack Application" are hosted in the api-site repository which was formerly part of the docs team but is now orphaned. Let's look at the content hosted in api-site repository * The index page needs little updates * The OpenStack Api-Guide: This is a small guide that needs little maintenance (when projects create/retire API versions) * Writing your first OpenStack Application: This was never finished and only covers a few programming language, it's dead. With moving the repo out of docs (see https://review.opendev.org/485249 for change), the hope was that somebody took it over - but this did not happen. We have an official entry point for OpenStack's development resources and it is served by api-site repo and I suggest we look at the situation and solve it fully. I see the following options: 1) Retiring developer.openstack.org completely, this would mean we would host the api-guides and api-references on docs.openstack.org (perhaps with moving them into doc/source). If we go down this road, we need to discuss what this means (redirects) and what to do with the Api-Guide and the FirstApp guide. 2) Fully revitialize the repo and have it owned by an official team or SIG (this means reverting parts of https://review.opendev.org/485249/) 3) Retire the document "Writing your first OpenStack Application", and unretire api-site and have it owned by some official team/SIG. Any other options? What shall we do? Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg GF: Nils Brauckmann, Felix Imendörffer, Enrica Angelone, HRB 247165 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

5 16

[dev][release][qa] patrole stable/stein is created by mistake ?
by Ghanshyam Mann 16 Jul '19

16 Jul '19

Hi Release team, Today I noticed while doing patrole review that stable/stain has been created for patrole which is wrong. Patrole is branchless[1] and I remember I have not requested the stable branch while releasing the patrole. Is it created by mistakenly ? or intentional? [1] https://docs.openstack.org/patrole/latest/overview.html#release-versioning -gmann

4 9

[nova] [ops] Problems running db sync for nova (Ocata --> Pike)
by Massimo Sgaravatto 16 Jul '19

16 Jul '19

Resending with the right tags in the subject line ... Hi We are trying to update our Ocata cloud to Pike (this is the first step: we will go through Ocata --> Pike --> Queens --> Rocky) but we have a problem with nova-manage db sync: [root@cld-ctrl-01 ~]# su -s /bin/sh -c "nova-manage db sync" nova ERROR: Could not access cell0. Has the nova_api database been created? Has the nova_cell0 database been created? Has "nova-manage api_db sync" been run? Has "nova-manage cell_v2 map_cell0" been run? Is [api_database]/connection set in nova.conf? Is the cell0 database connection URL correct? Error: "Database schema file with version 390 doesn't exist." We have these settings in nova.conf: [database] connection = mysql+pymysql://nova_prod:xyz@192.168.60.10:6306/nova_prod [api_database] connection = mysql+pymysql:// nova_api_prod:xyz@192.168.60.10:6306/nova_api_prod I can't see problems accessing the databases. i.e. these commands work: mysql -u nova_api_prod -pxyz -h 192.168.60.10 -P 6306 nova_api_prod mysql -u nova_prod -pxyz -h 192.168.60.10 -P 6306 nova_prod mysql -u nova_prod -pxyz -h 192.168.60.10 -P 6306 nova_prod_cell0 If I try to rerun nova-manage cell_v2 map_cell0: [root@cld-ctrl-01 ~]# nova-manage cell_v2 map_cell0 Cell0 is already setup [root@cld-ctrl-01 ~]# su -s /bin/sh -c "nova-manage api_db version" nova 45 [root@cld-ctrl-01 ~]# su -s /bin/sh -c "nova-manage db version" nova 362 [root@cld-ctrl-01 ~]# nova-manage cell_v2 list_cells +-------+--------------------------------------+--------------------------------------------------+-------------------------------------------------------------------+ | Name | UUID | Transport URL | Database Connection | +-------+--------------------------------------+--------------------------------------------------+-------------------------------------------------------------------+ | cell0 | 00000000-0000-0000-0000-000000000000 | none:/// | mysql+pymysql://nova_prod:****@ 192.168.60.10:6306/nova_prod_cell0 | | cell1 | 5e42faa0-710b-4967-bb42-fcf53602c96e | rabbit://openstack_prod:****@192.168.60.183:5672 | mysql+pymysql://nova_prod:****@192.168.60.10:6306/nova_prod | +-------+--------------------------------------+--------------------------------------------------+-------------------------------------------------------------------+ Following some doc we also tried to specify the --database_connection / --database-connection argument, but this seems not working Setting nova in debug mode, this is the last entry in the nova-manage log file: 2019-07-16 12:11:42.774 22013 DEBUG migrate.versioning.repository [req-8ca52407-dbe1-4a62-ad6c-16631c2a9a06 - - - - -] Config: OrderedDict([('db_settings', OrderedDict([('__name__', 'db_settings'), ('repository_id', 'nova'), ('version_table', 'migrate_version'), ('required_dbs', '[]')]))]) __init__ /usr/lib/python2.7/site-packages/migrate/versioning/repository.py:83 Any hints ? Thanks, Massimo OpenStack Discuss

2 5

[TripleO] Scaling node counts with only Ansible (N=1)
by James Slagle 16 Jul '19

16 Jul '19

There's been a fair amount of recent work around simplifying our Heat templates and migrating the software configuration part of our deployment entirely to Ansible. As part of this effort, it became apparent that we could render much of the data that we need out of Heat in a way that is generic per node, and then have Ansible render the node specific data during config-download runtime. To illustrate the point, consider when we specify ComputeCount:10 in our templates, that much of the work that Heat is doing across those 10 sets of resources for each Compute node is duplication. However, it's been necessary so that Heat can render data structures such as list of IP's, lists of hostnames, contents of /etc/hosts files, etc etc etc. If all that was driven by Ansible using host facts, then Heat doesn't need to do those 10 sets of resources to begin with. The goal is to get to a point where we can deploy the Heat stack with a count of 1 for each role, and then deploy any number of nodes per role using Ansible. To that end, I've been referring to this effort as N=1. The value in this work is that it directly addresses our scaling issues with Heat (by just deploying a much smaller stack). Obviously we'd still be relying heavily on Ansible to scale to the required levels, but I feel that is much better understood challenge at this point in the evolution of configuration tools. With the patches that we've been working on recently, I've got a POC running where I can deploy additional compute nodes with just Ansible. This is done by just adding the additional nodes to the Ansible inventory with a small set of facts to include IP addresses on each enabled network and a hostname. These patches are at https://review.opendev.org/#/q/topic:bp/reduce-deployment-resources and reviews/feedback are welcome. Other points: - Baremetal provisioning and port creation are presently handled by Heat. With the ongoing efforts to migrate baremetal provisioning out of Heat (nova-less deploy), I think these efforts are very complimentary. Eventually, we get to a point where Heat is not actually creating any other OpenStack API resources. For now, the patches only work when using pre-provisioned nodes. - We need to consider how we'd manage the Ansible inventory going forward if we open up an interface for operators to manipulate it directly. That's something we'd want to manage and preserve (version control) as it's critical data for the deployment. Given the progress that we've made with the POC, my sense is that we'll keep pushing in this overall direction. I'd like to get some feedback on the approach. We have an etherpad we are using to track some of the work at a high level: https://etherpad.openstack.org/p/tripleo-reduce-deployment-resources I'll be adding some notes on how I setup the POC to that etherpad if others would like to try it out. -- -- James Slagle --

8 16

[lists.openstack.org代发]Re: [docs][tc][infra] what to do with developer.openstack.org and api-site?
by Brin Zhang(张百林) 16 Jul '19

16 Jul '19

>>> Yeah, this link is used very frequently by many developers as well as by users. Redirect is something much needed for this site. +1, yeah. https://developer.openstack.org/api-ref/compute/ is used at the highest frequency, I think redirect this is necessary. ---- On Mon, 15 Jul 2019 23:28:33 +0900 Sean Mooney <smooney(a)redhat.com> wrote ---- > On Mon, 2019-07-15 at 11:50 +0200, Thierry Carrez wrote: > > Andreas Jaeger wrote: > > > [...] > > > I see the following options: > > > > > > 1) Retiring developer.openstack.org completely, this would mean we would > > > host the api-guides and api-references on docs.openstack.org (perhaps > > > with moving them into doc/source). If we go down this road, we need to > > > discuss what this means (redirects) and what to do with the Api-Guide > > > and the FirstApp guide. > > > > > > 2) Fully revitialize the repo and have it owned by an official team or > > > SIG (this means reverting parts of https://review.opendev.org/485249/) > > > > > > 3) Retire the document "Writing your first OpenStack Application", and > > > unretire api-site and have it owned by some official team/SIG. > > > > > > Any other options? What shall we do? > > > > Thanks Andreas for raising this. > > > > As an extra data point, my long-term plan was to have SDKs and CLIs > > properly listed in the Software pages under SDKs[1], including > > third-party ones in their own subtab, all driven from the > > osf/openstack-map repository[2]. > > > > With that in mind, I think it would make sense to look into retiring > > developer.openstack.org, > i use https://developer.openstack.org/api-ref/compute/ almost daily so unless > we host the api ref somwhere else and put redirect in place i would hope we > can keep this inplace. Yeah, this link is used very frequently by many developers as well as by users. Redirect is something much needed for this site. -gmann > if we move it under docs like the config stuff > https://docs.openstack.org/nova/latest/configuration/config.html > or somewhere else that is fine but i fine it very useful to be able > to link the rendered api docs to people on irc that ask questions. > > i can obviosly point peple to github > https://github.com/openstack/nova/blob/master/api-ref/source/servers.inc > but unlike the configs the api ref is much less readable with out rendering > it with sphinx > > > and move docs to docs.openstack.org. We could > > also revive https://www.openstack.org/appdev/ and use it as the base > > landing page to direct application-side people to the various pieces. > > > > [1] https://www.openstack.org/software/project-navigator/sdks > > [2] https://opendev.org/osf/openstack-map/ > > > > >

1 0

[monasca] Virtual Midcycle Meeting scheduling
by Witek Bedyk 16 Jul '19

16 Jul '19

Hello, as discussed in the last team meeting, we will hold a virtual Midcycle Meeting. The goal is to sync on the progress of the development and update the stories if needed. I plan with 2 hours meeting. Please select the times which work best for you: https://doodle.com/poll/zszfxakcbfm6sdha Please fill in the topics you would like to discuss or update on in the etherpad: https://etherpad.openstack.org/p/monasca-train-midcycle Thanks Witek

2 1

Problems running db_sync for nova (Ocata --> Pike)
by Massimo Sgaravatto 16 Jul '19

16 Jul '19

Hi We are trying to update our Ocata cloud to Pike (this is the first step: we will go through Ocata --> Pike --> Queens --> Rocky) but we have a problem with nova-manage db sync: [root@cld-ctrl-01 ~]# su -s /bin/sh -c "nova-manage db sync" nova ERROR: Could not access cell0. Has the nova_api database been created? Has the nova_cell0 database been created? Has "nova-manage api_db sync" been run? Has "nova-manage cell_v2 map_cell0" been run? Is [api_database]/connection set in nova.conf? Is the cell0 database connection URL correct? Error: "Database schema file with version 390 doesn't exist." We have these settings in nova.conf: [database] connection = mysql+pymysql://nova_prod:xyz@192.168.60.10:6306/nova_prod [api_database] connection = mysql+pymysql:// nova_api_prod:xyz@192.168.60.10:6306/nova_api_prod I can't see problems accessing the databases. i.e. these commands work: mysql -u nova_api_prod -pxyz -h 192.168.60.10 -P 6306 nova_api_prod mysql -u nova_prod -pxyz -h 192.168.60.10 -P 6306 nova_prod mysql -u nova_prod -pxyz -h 192.168.60.10 -P 6306 nova_prod_cell0 If I try to rerun nova-manage cell_v2 map_cell0: [root@cld-ctrl-01 ~]# nova-manage cell_v2 map_cell0 Cell0 is already setup [root@cld-ctrl-01 ~]# su -s /bin/sh -c "nova-manage api_db version" nova 45 [root@cld-ctrl-01 ~]# su -s /bin/sh -c "nova-manage db version" nova 362 [root@cld-ctrl-01 ~]# nova-manage cell_v2 list_cells +-------+--------------------------------------+--------------------------------------------------+-------------------------------------------------------------------+ | Name | UUID | Transport URL | Database Connection | +-------+--------------------------------------+--------------------------------------------------+-------------------------------------------------------------------+ | cell0 | 00000000-0000-0000-0000-000000000000 | none:/// | mysql+pymysql://nova_prod:****@ 192.168.60.10:6306/nova_prod_cell0 | | cell1 | 5e42faa0-710b-4967-bb42-fcf53602c96e | rabbit://openstack_prod:****@192.168.60.183:5672 | mysql+pymysql://nova_prod:****@192.168.60.10:6306/nova_prod | +-------+--------------------------------------+--------------------------------------------------+-------------------------------------------------------------------+ Following some doc we also tried to specify the --database_connection / --database-connection argument, but this seems not working Setting nova in debug mode, this is the last entry in the nova-manage log file: 2019-07-16 12:11:42.774 22013 DEBUG migrate.versioning.repository [req-8ca52407-dbe1-4a62-ad6c-16631c2a9a06 - - - - -] Config: OrderedDict([('db_settings', OrderedDict([('__name__', 'db_settings'), ('repository_id', 'nova'), ('version_table', 'migrate_version'), ('required_dbs', '[]')]))]) __init__ /usr/lib/python2.7/site-packages/migrate/versioning/repository.py:83 Any hints ? Thanks, Massimo

1 0

[Tacker] Proposing changes in Tacker core team
by Dharmendra Kushwaha 16 Jul '19

16 Jul '19

Hello Team, I am proposing below changes in Team: I would like to propose Hiroyuki Jo to join Tacker core team. Hiroyuki Jo have lead multiple valuable features level activities like affinity policy, VDU-healing, and VNF reservation [1] in Rocky & Stein cycle, and made it sure to be completed timely. And currently working on VNF packages [2] and ETSI NFV-SOL specification support [3]. Hiroyuki has a good understanding of NFV and Tacker project, and helping team by providing sensible reviews. I believe it is a good addition in Tacker core team, and Tacker project will benefit from this nomination. On the other hand, I wanted to thank to Bharath Thiruveedula for his great & valuable contribution in the project. He helped a lot to make Tacker better in early days. But now he doesn't seem to be active in project and he decided to step-down from core team. Whenever you will decide to come back to the project, I will be happy to add you in core-team. Core-Team, Please respond with your +1/-1. If no objection, I will do these changes in next week. [1] https://review.opendev.org/#/q/project:openstack/tacker-specs+owner:%22Hiro… [2] https://blueprints.launchpad.net/tacker/+spec/tosca-csar-mgmt-driver [3] https://blueprints.launchpad.net/tacker/+spec/support-etsi-nfv-specs Thanks & Regards Dharmendra Kushwaha

1 1

[tripleo][cinder][netapp]
by Tomáš Bredár 15 Jul '19

15 Jul '19

Hi community, I'm trying to define multiple NetApp storage backends via Tripleo installer. According to [1] the puppet manifest supports multiple backends. The current templates [2] [3] support only single backend. Does anyone know how to define multiple netapp backends in the tripleo-heat environment files / templates? You help is appreciated. Tomas [1] https://opendev.org/openstack/puppet-cinder/src/branch/stable/queens/manife… [2] https://opendev.org/openstack/tripleo-heat-templates/src/branch/stable/quee… [3] https://opendev.org/openstack/tripleo-heat-templates/src/branch/stable/quee…

3 7

[tc] Weekly update
by Mohammed Naser 15 Jul '19

15 Jul '19

Hi everyone, This is the weekly update for what happened inside the OpenStack TC, you can get more information by checking for changes in the openstack/governance repository. # Retired projects - release-schedule-generator (from releases) - tripleo-ansible-roles (from tripleo) - docs-specs (from docs) # New projects - octavia-diskimage-retrofit (under charms) - kayobe (under kolla) # General changes - The "U" release will be based in the China region as per the upcoming summit. - The documentation team is starting a transition to a SIG - Few changes to the PDF goal proposal patches alongside storyboard links - Typo fixes (we can't spell liaison apparently!) - Jeremy Stanley has volunteered to become TC liaison for the image encryption popup team - Each project has been assigned 2 TC liaisons to provide assistance within our community. Thanks for tuning in :) Regards, Mohammed

1 0

[nova][neutron][CI] test_server_connectivity_cold_migration_revert failing again
by Artom Lifshitz 15 Jul '19

15 Jul '19

Looks like we merged [1] too soon, and despite external events handling during migration revert now being handled correctly in Nova with the merger of [2], there's something else broken, perhaps at the Neutron level, that prevents test_server_connectivity_cold_migration_revert from consistently passing. Until we figure out what that "something" is, I've proposed to skip the test in tempest [3] and filed a bug for it [4]. The bug is filed under Neutron, but that's more of a placeholder based on preliminary guessing. We can easily change it to Nova or some other component once we understand better what's going on. [1] https://review.opendev.org/#/c/663405/ [2] https://review.opendev.org/#/c/667177/ [3] https://review.opendev.org/#/c/670848/1 [4] https://bugs.launchpad.net/neutron/+bug/1836595

1 0

Configuring the network interfaces of an instance
by Mauricio Tavares 15 Jul '19

15 Jul '19

If I have an instance (vm guest) with more than one network interface, how can I tell it during the install process to use a specific one?

1 0

[telemetry] Gnocchi: Aggregates Operation Syntax
by Blom, Merlin, NMU-OI 15 Jul '19

15 Jul '19

Hey, I would like to aggregate data from the gnocchi database by using the gnocchi aggregates function of the CLI/API The documentation does not cover the operations that are available nor the syntax that has to be used: <https://gnocchi.xyz/gnocchiclient/shell.html?highlight=reaggregation#aggreg ates> https://gnocchi.xyz/gnocchiclient/shell.html?highlight=reaggregation#aggrega tes Searching for more information I found a GitHub Issue: <https://github.com/gnocchixyz/gnocchi/issues/393> https://github.com/gnocchixyz/gnocchi/issues/393 But I cannot use the syntax from that ether. My use case: I want to aggregate the vcpus hours per month, vram hours per month, . per server or project. - when an instance is stopped only storage is counted - the exact usage is used e.g. 2 vcpus between 1st and 7th day 4vcpus between 8th and last month no mean calculations Do you have detailed documentation about the gnocchi Aggregates Operation Syntax? Do you have complex examples for gnocchi aggregations? Especially when using the python bindings: conn_gnocchi.metric.aggregation(metrics="memory", query=[XXXXXXXX], resource_type='instance', groupby='original_resource_id') Can you give me advice regarding my use case? Do's and don'ts. Thank you for your help in advance! Merlin Blom

1 0