July 2019 - openstack-discuss - lists.openstack.org

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

19 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 19 Jul '19

19 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 19 Jul '19

19 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 19 Jul '19

19 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 19 Jul '19

19 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 19 Jul '19

19 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 19 Jul '19

19 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 19 Jul '19

19 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 19 Jul '19

19 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 19 Jul '19

19 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 18 Jul '19

18 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 18 Jul '19

18 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 18 Jul '19

18 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 18 Jul '19

18 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 18 Jul '19

18 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 18 Jul '19

18 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