- openstack-discuss - lists.openstack.org

[GNOCCHI] Regarding wrong ports in gnocchi-api and gnocchi-common packages
by Nehal Bansal 15 Jul '19

15 Jul '19

Hi, I am installing ceilometer queens version. While installing gnocchi-api, gnocchi-metricd and python-gnocchiclient packages I encountered the error Registering service and endpoints for gnocchi with type metric at http://192.168.133.81:8041 Failed to discover available identity versions when contacting http://127.0.0.1:35357/v3/. Attempting to parse version from URL. Unable to establish connection to http://127.0.0.1:35357/v3/auth/tokens: HTTPConnectionPool(host='127.0.0.1', port=35357): Max retries exceeded with url: /v3/auth/tokens (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fa1c8b0cb90>: Failed to establish a new connection: [Errno 111] Connection refused',)) dpkg: error processing package gnocchi-api (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: gnocchi-api E: Sub-process /usr/bin/dpkg returned an error code (1) I checked the postinst scripts of the packages and found that port 35357 has been configured instead of 5000. Therefore, I fetched the deb packages separately and edited the postinst files of the packages, repackaged it and installed the packages with dpkg -i <deb-file>. Now the logs are (Reading database ... 154597 files and directories currently installed.) Preparing to unpack .../python3-gnocchi_4.2.5-0ubuntu1~cloud0_all.deb ... Unpacking python3-gnocchi (4.2.5-0ubuntu1~cloud0) over (4.2.5-0ubuntu1~cloud0) ... Setting up python3-gnocchi (4.2.5-0ubuntu1~cloud0) ... 2019-07-15 16:48:48,434 - INFO - executing "dpkg -i /var/cache/apt/archives/packages/fixed-gnocchi-common.deb" ... (Reading database ... 154597 files and directories currently installed.) Preparing to unpack .../fixed-gnocchi-common.deb ... Unpacking gnocchi-common (4.2.5-0ubuntu1~cloud0) over (4.2.5-0ubuntu1~cloud0) ... Setting up gnocchi-common (4.2.5-0ubuntu1~cloud0) ... 2019-07-15 16:48:49,324 - INFO - executing "dpkg -i /var/cache/apt/archives/packages/fixed-gnocchi-api.deb" ... Selecting previously unselected package gnocchi-api. (Reading database ... 154597 files and directories currently installed.) Preparing to unpack .../packages/fixed-gnocchi-api.deb ... Unpacking gnocchi-api (4.2.5-0ubuntu1~cloud0) ... Setting up gnocchi-api (4.2.5-0ubuntu1~cloud0) ... Registering service and endpoints for gnocchi with type metric at http://192.168.133.81:8041 Service already registered: skipping service endpoint creation. apache2_invoke: Enable site gnocchi-api.conf 2019-07-15 16:49:01,438 - INFO - executing "dpkg -i /var/cache/apt/archives/packages/gnocchi-metricd_4.2.5-0ubuntu1~cloud0_all.deb" ... Selecting previously unselected package gnocchi-metricd. (Reading database ... 154601 files and directories currently installed.) Preparing to unpack .../gnocchi-metricd_4.2.5-0ubuntu1~cloud0_all.deb ... Unpacking gnocchi-metricd (4.2.5-0ubuntu1~cloud0) ... Setting up gnocchi-metricd (4.2.5-0ubuntu1~cloud0) ... Processing triggers for systemd (229-4ubuntu21.22) ... Processing triggers for ureadahead (0.100.0-19.1) ... 2019-07-15 16:49:02,416 - INFO - executing "dpkg -i /var/cache/apt/archives/packages/python-gnocchiclient_7.0.1-0ubuntu1~cloud0_all.deb" ... Selecting previously unselected package python-gnocchiclient. (Reading database ... 154606 files and directories currently installed.) Preparing to unpack .../python-gnocchiclient_7.0.1-0ubuntu1~cloud0_all.deb ... Unpacking python-gnocchiclient (7.0.1-0ubuntu1~cloud0) ... Setting up python-gnocchiclient (7.0.1-0ubuntu1~cloud0) ... update-alternatives: using /usr/bin/python2-gnocchi to provide /usr/bin/gnocchi (gnocchi) in auto mode The service gnocchi-metricd gets created but there are no signs of gnocchi-api in /etc/init.d/. Kindly, tell me how to proceed. Thank you. Regards, Nehal

1 0

OpenStack Neutron IPv6
by Md. Farhad Hasan Khan 15 Jul '19

15 Jul '19

Hi, How to configure IPv6 in OpenStack Rocky neutron? Please help me. Thanks & B'Rgds, Rony

2 1

[Ceilometer] [gnocchi] Regarding problem in installation of gnocchi-api
by Nehal Bansal 15 Jul '19

15 Jul '19

Hi, I am trying to install Ceilometer service with Openstack queens release. On installing gnocchi-api with apt-get install gnocchi-api I get the following error: Registering service and endpoints for gnocchi with type metric at http://192.168.133.81:8041 Failed to discover available identity versions when contacting http://127.0.0.1:35357/v3/. Attempting to parse version from URL. Unable to establish connection to http://127.0.0.1:35357/v3/auth/tokens: HTTPConnectionPool(host='127.0.0.1', port=35357): Max retries exceeded with url: /v3/auth/tokens (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f0bf2672250>: Failed to establish a new connection: [Errno 111] Connection refused',)) Warning - data is empty Failed to discover available identity versions when contacting http://127.0.0.1:35357/v3/. Attempting to parse version from URL. Unable to establish connection to http://127.0.0.1:35357/v3/auth/tokens: HTTPConnectionPool(host='127.0.0.1', port=35357): Max retries exceeded with url: /v3/auth/tokens (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fa1c8b0cb90>: Failed to establish a new connection: [Errno 111] Connection refused',)) dpkg: error processing package gnocchi-api (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: gnocchi-api E: Sub-process /usr/bin/dpkg returned an error code (1) Kindly, let me know how to proceed from here. Regards, Nehal

3 2

[searchlight] Team meeting today
by Trinh Nguyen 14 Jul '19

14 Jul '19

Hi team, Train-2 milestone is coming. Let's get together for a team meeting today if possible. There are a couple things we need to finish. Yours, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

Horizon and nova-cli inconsistency in live migration parameters
by Mary Atakova 14 Jul '19

14 Jul '19

Hi everyone, I think I have found an inconsistency between nova cli and Horizon in the way they send live migration commands to nova API. I'm not sure where this needs to be fixed, so please advise on that. The situation: I try to live-migrate a VM, and I do it through nova cli and through Horizon, and nova-api logs contain different data depending on the way I do it. 1. nova cli I run the command: nova live-migration 17359460-d23c-4acc-a9b1-5cf117b54430 and it shows up in nova-api logs as: {"os-migrateLive": {"block_migration": "auto", "host": null}} 2. horizon I run live migration via Horizon with unchecked Disk Overcommit and unchecked Block Migration. It shows up in nova-api logs as: {"os-migrateLive": {"disk_over_commit": false, "block_migration": false, "host": null}} This difference can lead to different parameters provided for live migration when block_migration: auto is translated into block_migration: true. My environment: Openstack Stein CentOS Linux release 7.6.1810 nova versions: # yum list installed | grep nova openstack-nova-api.noarch 1:19.0.1-1.el7 @centos-openstack-stein openstack-nova-common.noarch 1:19.0.1-1.el7 @centos-openstack-stein openstack-nova-conductor.noarch 1:19.0.1-1.el7 @centos-openstack-stein openstack-nova-console.noarch 1:19.0.1-1.el7 @centos-openstack-stein openstack-nova-novncproxy.noarch openstack-nova-placement-api.noarch openstack-nova-scheduler.noarch 1:19.0.1-1.el7 @centos-openstack-stein python2-nova.noarch 1:19.0.1-1.el7 @centos-openstack-stein python2-novaclient.noarch 1:13.0.0-1.el7 @centos-openstack-stein horizon version: # yum list installed | grep dashboard openstack-dashboard.noarch 1:15.1.0-1.el7 @centos-openstack-stein openstack-dashboard-theme.noarch 1:15.1.0-1.el7 @centos-openstack-stein Thank you in advance for your attention Best regards, Mary

1 0

OpenInfra Days Vietnam 2019 (Hanoi) - Call For Presentations
by Trinh Nguyen 12 Jul '19

12 Jul '19

Hello, Hope you're doing well :) The OpenInfra Days Vietnam 2019 [1] is looking for speakers in many different topics (e.g., container, CI, deployment, edge computing, etc.). If you would love to have a taste of Hanoi, the capital of Vietnam, please join us this one-day event and submit your presentation [2]. *- Date:* 24 AUGUST 2019 *- Location:* INTERCONTINENTAL HANOI LANDMARK72, HANOI, VIETNAM Especially this time, we're honored to have the Upstream Institute Training [3] hosted by the OpenStack Foundation on the next day (25 August 2019). [1] http://day.vietopeninfra.org/ [2] https://forms.gle/iiRBxxyRv1mGFbgi7 [3] https://docs.openstack.org/upstream-training/upstream-training-content.html See you in Hanoi! Bests, On behalf of the VietOpenInfra Group. -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 2

[keystone] Keystone Team Update - Week of 8 July 2019
by Colleen Murphy 12 Jul '19

12 Jul '19

# Keystone Team Update - Week of 8 July 2019 ## News ### Midcycle Planning We've set dates for the week of Milestone 2 for our virtual midcycle[1]. Topic suggestion is still open[2] and I will try to propose a draft agenda early next week. You can help by adding votes to topics you think are especially wortwhile in the etherpad. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007593.html [2] https://etherpad.openstack.org/p/keystone-train-midcycle-topics ### PTG Planning It's also already time to start thinking about the PTG[3]. If you have an inkling of whether you will be able to attend the PTG in Shanghai in November and would participate in the keystone room, please add your name to the planning etherpad[4]. [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007639.html [4] https://etherpad.openstack.org/p/keystone-shanghai-ptg ### Handling Defunct APIs While cleaning up deprecated config options related to PKI tokens[5], we found that these config options affect the OS-SIMPLE-CERT API and discussed[6][7] how best to handle the changing API without needing a version change. If you have thoughts on this matter, let us know in the review. [5] https://review.opendev.org/659434 [6] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-07-09-1… [7] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.… ### External Auth Prior to federated authentication, we supported external authentication using the REMOTE_USER HTTPD variable. Now that we have federated authentication available to us, we discussed whether it's time to discourage the use of regular external authentication[8]. If you are using external authentication or have an opinion about it, please join in the discussion with us[9]. [8] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… [9] https://review.opendev.org/669959 ## Open Specs Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh Since we do not have anyone who can commit to the implementation of the "Expose root domain as assignment target" spec[10] for Train, the latest patchset proposes it to the backlog rather than to the Train cycle. [10] https://review.opendev.org/661837 ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 10 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 46 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 1 new bugs and closed 1. Bugs opened (1) Bug #1836390 (oslo.policy:Undecided) opened by Vadym Markov https://bugs.launchpad.net/oslo.policy/+bug/1836390 Bugs fixed (1) Bug #1811771 (keystone:Low) fixed by Vishakha Agarwal https://bugs.launchpad.net/keystone/+bug/1811771 Although we did not open many new bugs this week, the backlog of unconfirmed and untriaged bugs has been slowly growing[11], please help by reproducing and triaging new bugs. [11] https://bugs.launchpad.net/keystone/+bugs?search=Search&field.status=New ## Milestone Outlook https://releases.openstack.org/train/schedule.html Milestone 2 is in two weeks, which means spec freeze is coming up followed closely by feature proposal freeze. ## Shout-outs Big thanks to Guang Yee for taking on an overhaul of the tokenless authentication documentation[12] which has been in severe need of an update and cleanup. [12] https://review.opendev.org/669790 ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[goal][python3] Train unit tests weekly update (goal-9)
by Corey Bryant 12 Jul '19

12 Jul '19

This is the goal-9 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 9 weeks remaining for completion of Train community goals [2]. == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. For complete details please see [1]. == Ongoing Work == Patches have been submitted for all applicable projects except for one, OpenStack Charms. I hope to have those submitted next week. Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-train+is:open Failing patches: https://review.openstack.org/#/q/topic:python3-train+status:open+(+label:Ve… Patch automation scripts needing review: https://review.opendev.org/#/c/666934 == Completed Work == Merged patches: https://review.openstack.org/#/q/topic:python3-train+is:merged == How can you help? == Please take a look at the failing patches and help fix any failing unit tests for your projects. Python 3.7 unit tests will be self-testing in Zuul. == Reference Material == [1] Goal description: https://governance.openstack.org/tc/goals /train/python3-updates.html [2] Train release schedule: https://releases.openstack.org/train/schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/story/2005924 Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… Thanks, Corey

1 0

[tripleo] tripleo-ci team investigating lowering the time check jobs are waiting
by Sorin Sbarnea 12 Jul '19

12 Jul '19

Tripleo CI team is trying to find ways to lower the resource loads on upstream zuul by identifying jobs running in check or gate which should have being skipped. This is an exercise in tuning which jobs launch against the various TripleO gerrit repos and not a complete overhaul of the coverage. There have been some obvious mistakes made in the zuul configurations in the past, we are looking to resolve all these issues, but also wanted to reach out to the broader community for more input. Since yesterday we started to track the queue lengths for both tripleo-check and tripleo-gate [1], so soon we will be able to see some trends. We have also been monitoring the number of jobs launched in both check and gate and their pass rates [2][3] Even if you only have some doubts about some jobs, it would be useful to report them to us so we can investigate further. Report on: https://etherpad.openstack.org/p/tripleo-jobs-tunning [1] http://dashboard-ci.tripleo.org/d/cEEjGFFmz/cockpit?orgId=1&fullscreen&pane… [2] check http://dashboard-ci.tripleo.org/d/cEEjGFFmz/cockpit?orgId=1&fullscreen&pane… [3] gate http://dashboard-ci.tripleo.org/d/cEEjGFFmz/cockpit?orgId=1&fullscreen&pane… Thanks, Sorin Sbarnea TripleO CI

1 0

[nova-lxd] retiring nova-lxd
by James Page 12 Jul '19

12 Jul '19

Hi All I’m slightly sad to announce that we’re retiring the LXD driver for Nova aka “nova-lxd”. Developing a driver for Nova for container based machines has been a fun and technically challenging ride over the last four years but we’ve never really seen any level of serious production deployment; as a result we’ve decided that it’s time to call it a day for nova-lxd. I’d like to thank all of the key contributors for their efforts over the years - specifically Chuck Short, Paul Hummer, Chris MacNaughton, Sahid Orentino and Alex Kavanaugh who have led or contributed to the development of the driver over its lifetime. I’ll be raising a review to leave a note for future followers as to the fate of nova-lxd. If anyone else would like to continue development of the driver they are more than welcome to revert my commit and become a part of the development team! We’ll continue to support our current set of stable branches for another ~12 months. Note that development of LXD and the pylxd Python module continues; its just the integration of OpenStack with LXD that we’re ceasing development of. Regards James

5 4

[manila][ptg] Manila PTG planning
by Tom Barron 12 Jul '19

12 Jul '19

>From our weekly community meetings [1] we know there are five or six people expecting to participate in the Shanghai PTG this coming November. But those meetings are at 1500 UTC -- not the best time for folks in Asia -- so let's check via email as well. Please update the Manila Shanghai PTG Planning etherpad [2] to indicate if you plan (or are trying) to attend the PTG in person or remotely. There's also a section for Topic Proposals, so we can start adding to it now as well. Thanks! -- Tom Barron [1] https://wiki.openstack.org/wiki/Manila/Meetings [2] https://etherpad.openstack.org/p/manila-shanghai-ptg-planning

1 0

[queens][nova] nova host-evacuate errot
by Ignazio Cassano 12 Jul '19

12 Jul '19

Hello All, on ocata when I poweroff a node with active instance , doing a nova host-evacuate works fine and instances are restartd on an active node. On queens it does non evacuate instances but nova-api reports for each instance the following: 2019-07-11 10:19:54.745 13811 INFO nova.api.openstack.wsgi [req-daad0a7d-87ce-41bf-b096-a70fc306db5c 0c7a2d6006614fe2b3e81e47377dd2a9 c26f8d35f85547c4add392a221af1aab - default default] HTTP exception thrown: Cannot 'evacuate' instance e8485a5e-3623-4184-bcce-cafd56fa60b3 while it is in task_state powering-off So it poweroff all instance on the failed node but does not start them on active nodes What is changed ? Ignazio

2 11

[nova][ec2] Removal of unused utility methods from 'nova.api.ec2'
by Stephen Finucane 12 Jul '19

12 Jul '19

I have a couple of patches up to remove what looks like a large chunk of unused ec2 API code from nova. The patches start at [1] and notes are provided in earlier revisions of those reviews ([2], [3], [4]) about why I'm able to remove some things and not others. I have a DNM patch proposed against the ec2-api [5] to ensure that things really don't break there but in case someone is maintaining something outside of opendev.org (I'd have found it on codesearch.openstack.org) that really needs these, you need to speak up on the review asap. If not, we'll get going with this. Stephen PS: To be clear, ec2-api *will still work*. None of the things we're removing are used by that project or we wouldn't be removing them :) [1] https://review.opendev.org/#/c/662501/ [2] https://review.opendev.org/#/c/662501/1/nova/api/ec2/ec2utils.py [3] https://review.opendev.org/#/c/662502/1/nova/objects/ec2.py [4] https://review.opendev.org/#/c/662503/1/nova/api/ec2/cloud.py [5] https://review.opendev.org/#/c/663386/

1 0

Cinder issue with DataCore
by Grant Morley 12 Jul '19

12 Jul '19

Hi All, We are trying to test DataCore storage backend for cinder ( running on Queens ). We have everything installed and have the cinder config all setup. However whenever we try and start the "cinder-volume" service, we get the following error: 2019-07-11 12:30:06.977 1909533 ERROR cinder.volume.manager File "/openstack/venvs/cinder-17.1.2/lib/python2.7/site-packages/cinder/volume/manager.py", line 456, in init_host 2019-07-11 12:30:06.977 1909533 ERROR cinder.volume.manager self.driver.do_setup(ctxt) 2019-07-11 12:30:06.977 1909533 ERROR cinder.volume.manager File "/openstack/venvs/cinder-17.1.2/lib/python2.7/site-packages/cinder/volume/drivers/datacore/iscsi.py", line 83, in do_setup 2019-07-11 12:30:06.977 1909533 ERROR cinder.volume.manager super(ISCSIVolumeDriver, self).do_setup(context) 2019-07-11 12:30:06.977 1909533 ERROR cinder.volume.manager File "/openstack/venvs/cinder-17.1.2/lib/python2.7/site-packages/cinder/volume/drivers/datacore/driver.py", line 116, in do_setup 2019-07-11 12:30:06.977 1909533 ERROR cinder.volume.manager self.configuration.datacore_api_timeout) 2019-07-11 12:30:06.977 1909533 ERROR cinder.volume.manager File "/openstack/venvs/cinder-17.1.2/lib/python2.7/site-packages/cinder/volume/drivers/datacore/api.py", line 176, in __init__ 2019-07-11 12:30:06.977 1909533 ERROR cinder.volume.manager raise datacore_exceptions.DataCoreException(msg) 2019-07-11 12:30:06.977 1909533 ERROR cinder.volume.manager DataCoreException: Failed to import websocket-client python module. Please, ensure the module is installed. We have the "websocket-client" installed also: pip freeze | grep websocket websocket-client==0.44.0 The datacore libraries also appear to be available in our venvs dirs: ls /openstack/venvs/cinder-17.1.2/lib/python2.7/site-packages/cinder/volume/drivers/datacore api.py driver.py exception.py fc.py __init__.py iscsi.py passwd.py utils.py We are a bit stumped at the moment and wondered if anyone knew what might be causing the error? We have managed to get Ceph and SolidFire working fine. Regards, -- Grant Morley Cloud Lead, Civo Ltd www.civo.com <https://www.civo.com/>| Signup for an account! <https://www.civo.com/signup>

2 2

Flow of instance creation
by Jyoti Dahiwele 11 Jul '19

11 Jul '19

Dear Everyone, Can you explain me the flow of instance creation in stein ?

1 0

[Security SIG] Shanghai PTG Attendence
by Gage Hugo 11 Jul '19

11 Jul '19

Hello everyone, We have been asked to look into how many are planning on attending the PTG/Forum for the Security SIG. I have created an etherpad to collect a list of people who are planning on attending[0]. If you are interested in Security or the SIG, please update the etherpad. Thanks! [0] https://etherpad.openstack.org/p/security-shanghai-ptg-planning

1 0

[security sig] Weekly Newsletter July 11th 2019
by Gage Hugo 11 Jul '19

11 Jul '19

#Week of: 11 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-11-1… - Image Encryption Pop-Up Team Meeting - The image encryption pop-up team has an official meeting! See http://eavesdrop.openstack.org/#Image_Encryption_Popup-Team_Meeting - Syntribos still in use - It appears that there is an occasional update to the Syntribos project (outside of maintenance patches). There will be another email send out to see if this project is still being used. - Security Guide Cleanup - nickthetait has been looking into cleaning up & updating the OpenStack Security Guide, yay! - Shanghai PTG Attendance - We have been asked to check how many people are planning on attending the PTG/Forum for the Security SIG. There will be another email sent out for this. # 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

[placement][ptg] Shanghai attendance
by Chris Dent 11 Jul '19

11 Jul '19

As with nova [1] and keystone [2], placement needs to decide what kind of presence it would like to have at the PTG portion of the event in Shanghai in November, and let the Foundation know. I've already expressed that I don't intend to go [3] and in that message asked for feedback from the rest of the placement team on whether we need to do any placement work there, given the value we got out of the virtual pre-PTG in April. Let me ask again: Do we need a presence at the PTG in Shanghai? I've created an etherpad where we can track who will be there for sure and who will not, and start making note of relevant topics. https://etherpad.openstack.org/p/placement-shanghai-ptg [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007640.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007639.html [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007527.html -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

4 6

[I18n][ptg] Shanghai PTG/Forum Attendance
by Ian Y. Choi 11 Jul '19

11 Jul '19

Hello, Like other official teams, I18n team has been also asked to get an idea of how many people are planning to attend the PTG and/or Forum. I have created an Etherpad to start collecting topics as well as a list of people who are planning to attend [1], and if you think you may be in Shanghai or are in a timezone that can participate remotely, please update the Etherpad. Note that this upcoming PTG/Forum is very Asia-timezone friendly - I highly encourage people in Asia countries (including China, surely) to participate offline or remotely. Thanks! With many thanks, /Ian [1] https://etherpad.openstack.org/p/i18n-shanghai-ptg-planning

1 0

[cinder] Shanghai PTG/Forum Attendance ...
by Jay Bryant 11 Jul '19

11 Jul '19

All, We have been asked to get an idea of how many people are planning to attend the PTG and/or Forum for Cinder. I have created an etherpad to start collecting topics as well as a list of people who are planning to attend [1]. If you think you may be in Shanghai or are in a timezone that can participate remotely, please update the etherpad. For fun, I have also created a Twitter Poll [2]. If you want to vote there to indicate attendance/non-attendance, please do so! Thanks! Jay (irc: jungleboyj) [1] https://etherpad.openstack.org/p/cinder-shanghai-ptg-planning [2] https://twitter.com/jungleboyj/status/1149045308271333378

1 0

root disk for instance
by Jyoti Dahiwele 11 Jul '19

11 Jul '19

Dear Team, Please clear me my following doubts. When I use image from source option and mini flavor to create an instace, from which storage pool instance will get root disk ? From cinder or glance?

3 5

[glance] Train: Milestone 2 review priorities
by Abhishek Kekane 11 Jul '19

11 Jul '19

Dear Reviewers/Developers, Train milestone two is just two weeks away from now. I have created one etherpad [1] which lists the priority patches for glance, glance_store, python-glanceclient and glance-specs which will be good to have merged before Train 2 milestone. Feel free to add if you think any patch which I have missed is good to have during this milestone 2. Request all reviewers to review these patches so that we can have smooth milestone 2 release. Highlight of this milestone 2 release is that we are planning to roll out glance-store version 1.0 which will officially mark the multiple-stores feature of glance as a stable feature, [1] https://etherpad.openstack.org/p/Glance-Train-MileStone-2-Release-Plan Thanks & Best Regards, Abhishek Kekane

1 0

trying to understand steal time with cpu pinning
by Manuel Sopena Ballesteros 11 Jul '19

11 Jul '19

Dear Openstack community, Please correct me if I am wrong. As far as I understand `steal time > 0` means that the hypervisor has replaced a vcpu with a different one on the physical cpu. Also, cpu pinning allocates a vcpu to a physical cpu permanently. I have a vm setup with cpu pinning and numa affinity and realized, that cpu steal time is between 1% and 0%. Why is that? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

2 1

FWaaS in Stein - NoMatches: No 'neutron.service_plugins' driver found, looking for 'firewall'
by Teckelmann, Ralf, NMU-OIP 11 Jul '19

11 Jul '19

Good Morning everyone, We like to have FWaaS enabled for a Stein-based OpenStack installation. Using linuxbridges we are not able to use FWaaS_v2, because it only seems to work with ovs. We thus tried FWaaS (v1) following https://docs.openstack.org/openstack-ansible-os_neutron/latest/configure-ne… . However, all we get from it is (1). Are we missing a point or is FWaaS_V1 just not supported in Stein anymore? If so, this would mean for a setup Stein+Linuxbridges no FWaaS is actually available, right? (1) grep firewall /var/log/neutron/neutron-server.log 2019-07-05 10:10:55.693 29793 ERROR neutron_lib.utils.runtime NoMatches: No 'neutron.service_plugins' driver found, looking for 'firewall' 2019-07-05 10:10:55.694 29793 ERROR neutron.manager [req-394624b6-e638-45ec-be7c-ce86793fdbc4 - - - - -] Plugin 'firewall' not found. 2019-07-05 10:11:00.046 29979 INFO neutron.manager [req-e86af4f4-afae-46d7-ac5e-51585a12083b - - - - -] Loading Plugin: firewall 2019-07-05 10:11:00.046 29979 ERROR neutron_lib.utils.runtime [req-e86af4f4-afae-46d7-ac5e-51585a12083b - - - - -] Error loading class by alias: NoMatches: No 'neutron.service_plugins' driver found, looking for 'firewall' Best regards, Ralf T.

3 7

[nova] API updates week 19-28
by Ghanshyam Mann 11 Jul '19

11 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: matt is +2 on this. Need another core reviewer. 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. Ready for another round of review. 3. Nova API cleanup - Topic: https://review.opendev.org/#/c/666889/ - Weekly Progress: Code is up for review. 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: Spec is merged. 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 - Need another +2 on this - https://review.opendev.org/#/c/668234/ - after that, 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. -gmann

1 0

g-placement / g-api didn't start in devstack
by Manula Thantriwatte 11 Jul '19

11 Jul '19

I'm installing DevStack in Ubuntu 18.04. I'm using stable/stein branch for the installation. When I running the stach.sh I'm getting following error. I have updated the timeout to 300 seconds as well. But still I'm not able to run the DevStack. Could you please help me on this issue? Is there specific python version do I need to install. In my PC I have python version 3.6.8. ++:: curl -g -k --noproxy '*' -s -o /dev/null -w '%{http_code}' http://192.168.9.10/image +:: [[ 503 == 503 ]] +:: sleep 1 +functions:wait_for_service:431 rval=124 +functions:wait_for_service:436 time_stop wait_for_service +functions-common:time_stop:2317 local name +functions-common:time_stop:2318 local end_time +functions-common:time_stop:2319 local elapsed_time +functions-common:time_stop:2320 local total +functions-common:time_stop:2321 local start_time +functions-common:time_stop:2323 name=wait_for_service +functions-common:time_stop:2324 start_time=1562654135525 +functions-common:time_stop:2326 [[ -z 1562654135525 ]] ++functions-common:time_stop:2329 date +%s%3N +functions-common:time_stop:2329 end_time=1562654195603 +functions-common:time_stop:2330 elapsed_time=60078 +functions-common:time_stop:2331 total=93 +functions-common:time_stop:2333 _TIME_START[$name]= +functions-common:time_stop:2334 _TIME_TOTAL[$name]=60171 +functions:wait_for_service:437 return 124 +lib/glance:start_glance:353 die 353 'g-api did not start' +functions-common:die:195 local exitcode=0 [Call Trace] ./stack.sh:1261:start_glance /opt/stack/devstack/lib/glance:353:die [ERROR] /opt/stack/devstack/lib/glance:353 g-api did not start Error on exit Traceback (most recent call last): File "/opt/stack/devstack/tools/worlddump.py", line 255, in <module> sys.exit(main()) File "/opt/stack/devstack/tools/worlddump.py", line 239, in main 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/

2 1

[queens][magnuma] kubernetes cluster
by Ignazio Cassano 11 Jul '19

11 Jul '19

Hi All, I just installed openstack kolla queens with magnum but trying to create a kubernetes cluster the master nodes does not terminate installation: it loops with the following message: curl --silent http://127.0.0.1:8080/healthz + '[' ok = '' ']' + sleep 5 Anyone can help ? Best Regards Ignazio

3 5

Glusterfs support in stein
by Jyoti Dahiwele 11 Jul '19

11 Jul '19

Dear team, Do stein support glusterfs backend in cinder configuration? If yes plz share configuration document.

3 3

trying to understand steal time with cpu pinning
by Manuel Sopena Ballesteros 11 Jul '19

11 Jul '19

Dear Openstack community, Please correct me if I am wrong. As far as I understand `steal time > 0` means that the hypervisor has replaced a vcpu with a different one on the physical cpu. Also, cpu pinning allocates a vcpu to a physical cpu permanently. I have a vm setup with cpu pinning and numa affinity and realized, that cpu steal time is between 1% and 0%. [cid:image002.png@01D53803.C9C9F190] Why is that? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

1 0

Re:[devstack] Deploy issue on Ubuntu 16.04. (Guannan)
by Guannan GN2 Sun 11 Jul '19

11 Jul '19

Thanks Chric and Sean, I run unstack.sh, remove the files in /etc/apache2/sites-enabled and /etc/apaceh2/sites-available, and rerun stack.sh, that works for me! Although I'm still run master branch of devstack on Ubuntu 16.04, as Sean say, I may move to Ubuntu 18.04 later. Thank you! Best Regards, Guannan

1 0

[nova][ptg] Shanghai attendance
by Eric Fried 10 Jul '19

10 Jul '19

We (nova) need to let the foundation know about our planned presence at the Shanghai PTG for the U release. To that end, I've seeded an etherpad [1]. If you are a contributor or operator with an interest in nova, please add your name to the Attendance section, even (especially) if you know you are not attending. I need this information by the beginning of August, even if it's tentative. Thanks! efried [1] https://etherpad.openstack.org/p/nova-shanghai-ptg

6 8

openstack-sdk API - Get all flavors for all projects.
by Laurent Dumont 10 Jul '19

10 Jul '19

Hi everyone, I'm trying to map the relationship between projects, host-aggregate and computes. I'm trying to find a way to use the Openstack Python SDK in order to list all existing flavors and the "access_project_ids" seems to be the best way to see which project is associated with the flavor. That said, it seems that the python SDK does not expose the value when querying using "get_flavor". Anyone know of way of getting the information from the SDK? Thanks!

1 0

[tc] agenda for Technical Committee Meeting 11 July 2019 @ 1400 UTC
by Thierry Carrez 10 Jul '19

10 Jul '19

TC Members, Our next meeting will be this Thursday, 11 July at 1400 UTC in #openstack-tc. I'll be your chair and we'll rely on mugsie to keep the GIF game level high. This email contains the agenda for the meeting, based on the content of the wiki [0]. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee * Follow up on past action items ** Health check changes: asettle to update community (done), fungi to update wiki (done), mugise to update yaml file with liasons and mnaser to update the tooling ** Help-most-needed list: AlanClark and zaneb to update investment opportunities document [0] https://etherpad.openstack.org/p/2019-upstream-investment-opportunities-ref… [1] https://review.opendev.org/#/c/657447/ ** Goal selection: lbragstad to prune the community-goals etherpad [2] https://etherpad.openstack.org/p/community-goals ** Pop-up teams: ttx to define pop-up teams [3] https://review.opendev.org/#/c/661356/ [4] https://review.opendev.org/#/c/661983/5 ** SIG governance: tc-members to review goal, popup, and SIG project etherpad [5] https://etherpad.openstack.org/p/explain-team-formate-differentiate ** Review PTL Guide: asettle ttx ricolin to sync up and review the PTL section of the project teams guide to improve the PTL experience [6] https://review.opendev.org/#/c/665699/ * Active initiatives ** Python 3: mnaser to sync up with swift team on python3 migration and mugsie to sync with dhellmann or release-team to find the code for the proposal bot ** Forum follow-up: ttx to organise Milestone 2 forum meeting with tc-members ** Make goal selection a two-step process (needs reviews at https://review.opendev.org/#/c/667932/) * Update on U release naming process * What are retired repos ? Regards, -- Thierry Carrez (ttx)

1 0

[openstack-dev] [neutron] [ptg] Start planning for the PTG in Shanghai
by Miguel Lavalle 10 Jul '19

10 Jul '19

Dear Neutrinos, We need to help the Foundation to plan for the the PTG in Shanghai. To that end, I have created an etherpad to start collecting the names of the team members who plan to attend and also topics to be discussed during our meetings: https://etherpad.openstack.org/p/Shanghai-Neutron-Planning I need to respond back to the Foundation's survey by August 11th. So it will be very helpful if all of you who plan to be in Shanghai add your names and irc nicks to the "Attendees" section no later than August 4th. This deadline doesn't apply to the proposed topics section. For that, we have more time. Regards Miguel

1 0

[horizon] django-pyscss unmaintained?
by Thomas Goirand 10 Jul '19

10 Jul '19

Hi, As I'm maintaining python-django-pyscss in Debian, I've noticed that there's no commit since 2015 on the Github repository, and no pypi release either. I've sent a new pull request here: https://github.com/fusionbox/django-pyscss/pull/45 so that pyscss continues to pass unit tests with Django 2.2, but I have very little hope for it to be merged, as the previous pull request for Django 1.11 was never merged. Is it time to take over the project? Can someone from the Horizon team get in touch with the previous maintainer? Cheers, Thomas Goirand (zigo)

2 1

[ironic] Shanghai PTG/Forum
by Julia Kreger 10 Jul '19

10 Jul '19

Greetings fellow ironic contributors! I've created an initial planning/discussion etherpad for the upcoming Shanghai summit[0]. I need a count of contributors that intend to attend with-in the next few weeks. If you plan on or intend to attend, please indicate so on the etherpad. I look forward to ideas and items for discussion! -Julia [0]: https://etherpad.openstack.org/p/PVG-Ironic-Planning

1 0

[placement] mascot/logo live
by Chris Dent 10 Jul '19

10 Jul '19

https://www.openstack.org/project-mascots has been updated to have the Placement mascot/logo. Here's a sample: https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c0… Thanks very much to the Foundation and their designers for making this happen. In case you missed the discussion [1] about this a while back, we know it looks a bit cranky. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/thread.htm… -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[devstack] Deploy issue on Ubuntu 16.04.
by Guannan GN2 Sun 10 Jul '19

10 Jul '19

Hi team, I meet some problem when deploying devstack(from https://github.com/openstack/devstack master branch) on Ubuntu 16.04. It seems something is wrong with placement-api error message as following: curl -g -k --noproxy '*' -s -o /dev/null -w '%{http_code}%' http://10.240.24.138/placement [[503 == 503]] [ERROR] /opt/stack/devstack/lib/placement:156 placement-api did not start However when I check its status using "systemctl status devstack@placement-api", it is active and running. I also change to "stein" branch and try to deploy again, but still meet the same problem. Does someone meet similar issue before or could someone help me to debug this issue? Below is my local.conf file. Thank you! local.conf: #################################################### [[local|localrc]] # Credentials ADMIN_PASSWORD=password DATABASE_PASSWORD=password RABBIT_PASSWORD=password SERVICE_PASSWORD=password SERVICE_TOKEN=password SWIFT_HASH=password SWIFT_TEMPURL_KEY=password GIT_BASE=${GIT_BASE:-https://git.openstack.org} # A clean install every time RECLONE=yes # Enable Ironic plugin IRONIC_USING_PLUGIN=true enable_plugin ironic git://github.com/openstack/ironic # Enable Tempest enable_service tempest # Disable nova novnc service, ironic does not support it anyway. disable_service n-novnc # Enable Swift for the direct deploy interface. enable_service s-proxy enable_service s-object enable_service s-container enable_service s-account enable_service placement-api enable_service placement-client # Disable Horizon disable_service horizon # Disable Cinder disable_service cinder c-sch c-api c-vol # Swift temp URL's are required for the direct deploy interface SWIFT_ENABLE_TEMPURLS=True # Tempest related options BUILD_TIMEOUT=3000 IRONIC_CALLBACK_TIMEOUT=3000 POWER_TIMEOUT=600 SERVICE_TIMEOUT=600 TEMPEST_PLUGINS+=' /opt/stack/ironic-tempest-plugin' # Ironic related options IRONIC_IS_HARDWARE=true VIRT_DRIVER=ironic IRONIC_HW_NODE_CPU=1 IRONIC_HW_NODE_RAM=4096 IRONIC_HW_NODE_DISK=20 IRONIC_BAREMETAL_BASIC_OPS=True DEFAULT_INSTANCE_TYPE=baremetal # Enable additional hardware types, if needed. IRONIC_ENABLED_HARDWARE_TYPES=ipmi,fake-hardware,xclarity # Don't forget that many hardware types require enabling of additional # interfaces, most often power and management: IRONIC_ENABLED_MANAGEMENT_INTERFACES=ipmitool,fake,xclarity IRONIC_ENABLED_POWER_INTERFACES=ipmitool,fake,xclarity # The 'ipmi' hardware type's default deploy interface is 'iscsi'. # This would change the default to 'direct': #IRONIC_DEFAULT_DEPLOY_INTERFACE=direct # Change this to alter the default driver for nodes created by devstack. # This driver should be in the enabled list above. IRONIC_DEPLOY_DRIVER=ipmi # The parameters below represent the minimum possible values to create # functional nodes. #IRONIC_VM_SPECS_RAM=1280 #IRONIC_VM_SPECS_DISK=10 # Size of the ephemeral partition in GB. Use 0 for no ephemeral partition. IRONIC_VM_EPHEMERAL_DISK=0 # By default, DevStack creates a 10.0.0.0/24 network for instances. # If this overlaps with the hosts network, you may adjust with the # following. PUBLIC_NETWORK_GATEWAY=10.240.24.1 FLOATING_RANGE=10.240.24.0/24 FIXED_RANGE=10.0.0.0/24 HOST_IP=10.240.24.138 SERVICE_HOST=$HOST_IP FIXED_NETWORK_SIZE=256 # Neutron options Q_USE_PROVIDERNET_FOR_PUBLIC=True PUBLIC_INTERFACE=ens9 OVS_PHYSICAL_BRIDGE=br-ens9 PUBLIC_BRIDGE=br-ens9 OVS_BRIDGE_MAPPINGS=public:br-ens9 ALLOCATION_POOL=start=10.0.0.30,end=10.0.0.100 # Log all output to files LOGFILE=/opt/stack/devstack.log LOGDIR=/opt/stack/logs IRONIC_VM_LOG_DIR=/opt/stack/ironic-bm-logs #################################################### Best Regards, Guannan

3 2

[auto-scaling] Auto-scaling SIG update
by Rico Lin 10 Jul '19

10 Jul '19

It has been two months after Summit and PTG [3], and we now have collected some use cases [1], and general documents for auto-scaling [2] (Great thanks to Joseph Davis and Adam Spiers). *Use Cases needed* We need more use cases from all, for autoscaling on/with OpenStack. For example, autoscaling k8s on OpenStack is already a thing, so IMO we need to put some words in use cases too. *Help to improve documents* Please check our new document and help to improve it if you think of any. *Join us* We have IRC channel and meeting so please join us in irc: #openstack-auto-scaling so we can hear you and you can help us. *Add request to our StoryBoard* If you have any feature requests or WIP plan, you can use our storyboard[4] as root trace for them all like request for `Integrate Monasca and Senlin`. *Open for bug?* One question I would like to bring to the team is should we open our storyboard[4] for bug collection? We have some good hands from multiple teams, who can help with bugs. And like feature requests, a top-level story for a bug should be very helpful, but what we need from the reporter in order to get better information about that bug, and also what part should we help? IMO we can make sure bug are well documented, trace bug progress (from top-level view), and help to raise attention(in ML and in events). Would like to hear more opinions on this. *PTG* I already sign up for half-day PTG schedule(as the team still under developing, I would not expect that we need more for now), so I see you all there if you will be there too! [1] https://docs.openstack.org/auto-scaling-sig/latest/use-cases.html [2] https://docs.openstack.org/auto-scaling-sig/latest/theory-of-auto-scaling.h… [3] https://etherpad.openstack.org/p/DEN-auto-scaling-SIG [4] https://storyboard.openstack.org/#!/project/openstack/auto-scaling-sig [5] https://storyboard.openstack.org/#!/story/2005627 -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

2 1

[tc] Assuming control of GitHub organizations
by Jim Rollenhagen 10 Jul '19

10 Jul '19

Hi, The opendev team reached out to me about handing off administrative access of the "openstack" and related organizations on GitHub. They think it would be best if the TC took control of that, or at least took control of delegating that access. In general, the goal here is to support OpenStack's presence and visibility on GitHub. Per Jim Blair: > In the long run, this shouldn't entail a lot of work, generally creating new > repos on GitHub to accept mirroring from opendev systems, performing renames, > handling transfer requests when repos move out of the openstack namespace, > setting and updating descriptions, and curating the list of pinned > repositories. In the short term, we have some archiving and moving to do.[0] Do TC members want to manage this, or should we delegate? One thing to figure out is how to grant that access. The opendev team uses a shared account with two-factor authentication provided by a shared shell account. This mitigates accidental pushes or settings changes when an admin is using their usual GitHub account. The TC (or its delegates) probably doesn't have a shared shell account to do this with. Some options: * each admin creates a second GitHub account for this purpose use a shared * account without 2FA use a shared account with 2FA, share the one time secret * with everyone to configure their own token generator use personal accounts * but be very careful Thoughts on these options? [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006829.html // jim

8 15

[image-encryption][nova][cinder][glance][barbican]Image Encryption popup team meeting
by Josephine Seifert 10 Jul '19

10 Jul '19

Hello, starting with next week, there will be a weekly meeting on *Monday, 13 UTC *[1]**for the Image Encryption popup team. Please feel free to join us :) Greetings Josephine [1] http://eavesdrop.openstack.org/#Image_Encryption_Popup-Team_Meeting

1 0

[watcher] nova cdm builder performance optimizations - summary
by Matt Riedemann 09 Jul '19

09 Jul '19

I wanted to summarize a series of changes which have improved the performance of the NovaClusterDataModel builder for audits across single and multiple cells (in the CERN case) by a factor of 20-30%. There were initially three changes involved (in order): 1. https://review.opendev.org/#/c/659688/ - Optimize NovaClusterDataModelCollector.add_instance_node Reports on that patch alone said it fixed a regression introduced in Stein with scoped audits: "I checked this patch on the my test environment on the stable/stein branch. I have more than 1000 virtual servers (some real, some dummy). Previously, in the stable/rocky branch, the time to build a cluster was about 15-20 minutes, in the Stein branch there was a regression and the time increased to 90 minutes. After this patch, the build time is only 2 minutes." That change was backported to stable/stein. 2. - https://review.opendev.org/#/c/661121/ - Optimize hypervisor API calls (which requires https://review.opendev.org/#/c/659886/) As noted that change requires a patch to python-novaclient if you are looking to backport the change. We can't backport that upstream because of the python-novaclient dependency since it would require bumping the minimum required version of the library on a stable branch which is against stable branch policy (minimum version of library dependencies are more or less frozen on stable branches). That change also requires configuring watcher with: [nova_client] api_version = 2.53 # or greater; train now requires at least 2.56 3. - https://review.opendev.org/#/c/662089/ - Optimize NovaHelper.get_compute_node_by_hostname This optimizes code used to build/update the nova CDM during notification processing and also fixes a bug about looking up the compute service properly. After those three changes were merged, Corne Lukken (Dantali0n) started doing scale and performance testing with and without the changes in a CERN 5-cell test cluster. Corne identified a regression for which Canwei Li determined the root cause and chenker fixed: 4. https://review.opendev.org/#/c/668100/ - Reduce the query time of the instances when call get_instance_list() With that fix applied Corne reported the overall improvement of 20-30% when building the nova CDM during an audit in various scenarios. The actual performance numbers will be sent later as part of a thesis Corne is working on. I want to thank Dantali0n, licanwei and chenker for all of their help with this series of improvements. -- Thanks, Matt

2 1

[nova][ironic] Lock-related performance issue with update_resources periodic job
by Jason Anderson 09 Jul '19

09 Jul '19

Hey OpenStackers, I work on a cloud that allows users to reserve and provision bare metal instances with Ironic. We recently performed a long-overdue upgrade of our core components, all the way from Ocata up through Rocky. During this, we noticed that instance build requests were taking 4-5x (!!) as long as before. We have two deployments, one with ~150 bare metal nodes, and another with ~300. These are each managed by one nova-compute process running the Ironic driver. After investigation, the root cause appeared to be contention between the update_resources periodic task and the instance claim step. There is one semaphore "compute_resources" that is used to control every access within the resource_tracker. In our case, what was happening was the update_resources job, which runs every minute by default, was constantly queuing up accesses to this semaphore, because each hypervisor is updated independently, in series. This meant that, for us, each Ironic node was being processed and was holding the semaphore during its update (which took about 2-5 seconds in practice.) Multiply this by 150 and our update task was running constantly. Because an instance claim also needs to access this semaphore, this led to instances getting stuck in the "Build" state, after scheduling, for tens of minutes on average. There seemed to be some probabilistic effect here, which I hypothesize is related to the locking mechanism not using a "fair" lock (first-come, first-served) by default. Our fix was to drastically increase the interval this task runs at--from every 1 minute to every 12 hours. We only provision bare metal, so my rationale was that the periodic full resource sync was less important and mostly helpful for fixing weird things where somehow Placement's state got out of sync with Nova's somehow. I'm wondering, after all this, if it makes sense to rethink this one-semaphore thing, and instead create a per-hypervisor semaphore when doing the resource syncing. I can't think of a reason why the entire set of hypervisors needs to be considered as a whole when doing this task, but I could very well be missing something. TL;DR: if you have one nova-compute process managing lots of Ironic hypervisors, consider tweaking the update_resources_interval to a higher value, especially if you're seeing instances stuck in the Build state for a while. Cheers, Jason Anderson Cloud Computing Software Developer Consortium for Advanced Science and Engineering, The University of Chicago Mathematics & Computer Science Division, Argonne National Laboratory

5 11

[scientific-sig] IRC today
by Stig Telfer 09 Jul '19

09 Jul '19

Hi All - We have a Scientific SIG IRC meeting coming up at 2100 UTC (about 15 minutes time) in channel #openstack-meeting. Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_July_9th_2019 If you’d like to add anything to the agenda, come along to the meeting and bring it up. Cheers, Stig

1 0

[tripleo] [cisco] [bigswitch] [midonet] Composable Services for Neutron plugins
by Emilien Macchi 09 Jul '19

09 Jul '19

With that thread I'm hoping to reach out some of the folks who were involved in TripleO services for some of the Neutron plugins like Cisco, Bigswitch and Midonet. Some of them still use ExtraConfig interface which isn't super ideal. I'm willing to help convert them into composable services but I'll need help on the reviews and more importantly the actual testing. If you're in CC and can help, good please let me know. If you're not involved anymore, please give me a name if possible. If you were involved and know the plugin doesn't need maintenance, let me know as well, it'll save me time. I started with the Cisco UCSM: https://review.opendev.org/669931 -- Emilien Macchi

1 0

[cinder][stable-maint] July releases from the stable branches
by Brian Rosmaita 09 Jul '19

09 Jul '19

I've posted release patches for the stable branches: https://review.openstack.org/#/q/topic:cinderproject-july-2019 Notes on what is/isn't being released are on the etherpad: https://etherpad.openstack.org/p/cinder-releases-tracking I have a question about the semver for the cinder stable/stein release; it's noted on the patch: https://review.opendev.org/669771 cheers, brian

2 1

[Glance][PTL] Vacation time
by Erno Kuvaja 09 Jul '19

09 Jul '19

Hi all, I'll be away for couple of weeks. I'll be back Wed 24th of July. - Erno "jokke" Kuvaja

1 0

[docs][fuel][infra][ironic][neutron][charms][openstack-ansible][solum][tc] proper retirement of repos
by Mohammed Naser 08 Jul '19

08 Jul '19

Hi everyone, One of the issue that we recently ran into was the fact that there was some inconsistency about merging retirement of repositories inside governance without the code being fully removed. In order to avoid this, I've made a change to our governance repository which will enforce that no code exists in those retired repositories, however, this has surfaced that some repositories were retired with some stale files, some are smaller littler files, some are entire projects still. I have compiled a list for every team, with the repos that are not properly retired that have extra files (using this change which should eventually +1 once we fix it all: https://review.opendev.org/669549) [Documentation] openstack/api-site has extra files, please remove: .gitignore, .zuul.yaml, LICENSE, api-quick-start, api-ref, bindep.txt, common, doc-tools-check-languages.conf, firstapp, test-requirements.txt, tools, tox.ini, www [Documentation] openstack/faafo has extra files, please remove: .gitignore, CONTRIBUTING.rst, LICENSE, Vagrantfile, bin, contrib, doc, etc, faafo, requirements.txt, setup.cfg, setup.py, test-requirements.txt, tox.ini [fuel] openstack/fuel-agent has extra files, please remove: .gitignore, LICENSE, MAINTAINERS, cloud-init-templates, contrib, debian, etc, fuel_agent, requirements.txt, run_tests.sh, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [fuel] openstack/fuel-astute has extra files, please remove: .gitignore, .rspec, .ruby-version, Gemfile, LICENSE, MAINTAINERS, Rakefile, astute.gemspec, astute.service, astute.sysconfig, bin, bindep.txt, debian, examples, lib, mcagents, run_tests.sh, spec, specs, tests [fuel] openstack/fuel-library has extra files, please remove: .gitignore, CHANGELOG, Gemfile, LICENSE, MAINTAINERS, Rakefile, debian, deployment, files, graphs, logs, specs, tests, utils [fuel] openstack/fuel-main has extra files, please remove: .gitignore, 00-debmirror.patch, LICENSE, MAINTAINERS, Makefile, config.mk, fuel-release, iso, mirror, packages, prepare-build-env.sh, report-changelog.sh, repos.mk, requirements-fuel-rpm.txt, requirements-rpm.txt, rules.mk, sandbox.mk, specs [fuel] openstack/fuel-menu has extra files, please remove: .gitignore, MAINTAINERS, MANIFEST.in, fuelmenu, run_tests.sh, setup.py, specs, test-requirements.txt, tox.ini [fuel] openstack/fuel-mirror has extra files, please remove: .gitignore, .mailmap, MAINTAINERS, perestroika, tox.ini [fuel] openstack/fuel-nailgun-agent has extra files, please remove: .gitignore, Gemfile, LICENSE, MAINTAINERS, Rakefile, agent, debian, nailgun-agent.cron, nailgun-agent.gemspec, run_tests.sh, specs [fuel] openstack/fuel-ostf has extra files, please remove: .gitignore, LICENSE, MAINTAINERS, MANIFEST.in, etc, fuel_health, fuel_plugin, ostf.service, pylintrc, requirements.txt, run_tests.sh, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [fuel] openstack/fuel-qa has extra files, please remove: .coveragerc, .gitignore, .pylintrc, .pylintrc_gerrit, MAINTAINERS, core, doc, fuel_tests, fuelweb_test, gates_tests, packages_tests, pytest.ini, run_system_test.py, run_tests.sh, system_test, tox.ini, utils [fuel] openstack/fuel-ui has extra files, please remove: .eslintignore, .eslintrc.yaml, .gitignore, LICENSE, MAINTAINERS, fixtures, gulp, gulpfile.js, karma.config.js, npm-shrinkwrap.json, package.json, run_real_plugin_tests.sh, run_real_plugin_tests_on_real_nailgun.sh, run_ui_func_tests.sh, specs, static, webpack.config.js [fuel] openstack/fuel-virtualbox has extra files, please remove: .gitignore, MAINTAINERS, actions, clean.sh, config.sh, contrib, drivers, dumpkeys.cache, functions, iso, launch.sh, launch_16GB.sh, launch_8GB.sh [fuel] openstack/fuel-web has extra files, please remove: .gitignore, LICENSE, MAINTAINERS, bin, build_docs.sh, debian, docs, nailgun, run_tests.sh, specs, systemd, tools, tox.ini [fuel] openstack/shotgun has extra files, please remove: .coveragerc, .gitignore, .testr.conf, CONTRIBUTING.rst, HACKING.rst, LICENSE, MAINTAINERS, MANIFEST.in, bin, etc, requirements.txt, setup.cfg, setup.py, shotgun, specs, test-requirements.txt, tox.ini [fuel] openstack/fuel-dev-tools has extra files, please remove: .coveragerc, .gitignore, .mailmap, .testr.conf, CONTRIBUTING.rst, HACKING.rst, LICENSE, MAINTAINERS, babel.cfg, contrib, doc, fuel_dev_tools, openstack-common.conf, requirements.txt, setup.cfg, setup.py, test-requirements.txt, tox.ini, vagrant [fuel] openstack/fuel-devops has extra files, please remove: .coveragerc, .gitignore, .pylintrc, .pylintrc_gerrit, LICENSE, MAINTAINERS, bin, devops, doc, run_tests.sh, samples, setup.cfg, setup.py, test-requirements.txt, tox.ini [fuel] openstack/fuel-docs has extra files, please remove: .gitignore, Makefile, _images, _templates, common_conf.py, conf.py, devdocs, examples, glossary, index.rst, make.bat, plugindocs, requirements.txt, setup.cfg, setup.py, tox.ini, userdocs [fuel] openstack/fuel-nailgun-extension-cluster-upgrade has extra files, please remove: .coveragerc, .gitignore, AUTHORS, LICENSE, MANIFEST.in, bindep.txt, cluster_upgrade, conftest.py, nailgun-test-settings.yaml, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [fuel] openstack/fuel-nailgun-extension-iac has extra files, please remove: .gitignore, LICENSE, MANIFEST.in, doc, fuel_external_git, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [fuel] openstack/fuel-nailgun-extension-converted-serializers has extra files, please remove: .coveragerc, .gitignore, LICENSE, MANIFEST.in, bindep.txt, conftest.py, converted_serializers, nailgun-test-settings.yaml, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [fuel] openstack/fuel-octane has extra files, please remove: .coveragerc, .gitignore, .mailmap, Gemfile, Gemfile.lock, HACKING.rst, LICENSE, MAINTAINERS, MANIFEST.in, Rakefile, bindep.txt, deploy, deployment, docs, misc, octane, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tox.ini [fuel] openstack/fuel-upgrade has extra files, please remove: .gitignore [fuel] openstack/tuning-box has extra files, please remove: .coveragerc, .gitignore, .mailmap, .testr.conf, CONTRIBUTING.rst, HACKING.rst, LICENSE, MAINTAINERS, MANIFEST.in, TODO, alembic.ini, babel.cfg, bindep.txt, doc, examples, openstack-common.conf, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini, tuning_box [fuel] openstack/fuel-plugins has extra files, please remove: .gitignore, CHANGELOG.md, CONTRIBUTING.rst, HACKING.rst, LICENSE, MAINTAINERS, examples, fuel_plugin_builder, requirements.txt, run_tests.sh, setup.cfg, setup.py, test-requirements.txt, tox.ini [fuel] openstack/fuel-plugin-murano has extra files, please remove: .gitignore, LICENSE, components.yaml, deployment_scripts, deployment_tasks.yaml, docs, environment_config.yaml, functions.sh, metadata.yaml, node_roles.yaml, pre_build_hook, releasenotes, repositories, test-requirements.txt, tox.ini, volumes.yaml [fuel] openstack/fuel-plugin-murano-tests has extra files, please remove: .gitignore, murano_plugin_tests, openrc.default, requirements.txt, tox.ini, utils [fuel] openstack/fuel-specs has extra files, please remove: .gitignore, .testr.conf, LICENSE, doc, images, policy, requirements.txt, setup.cfg, setup.py, specs, tests, tools, tox.ini [fuel] openstack/fuel-stats has extra files, please remove: .gitignore, LICENSE, MAINTAINERS, MANIFEST.in, analytics, collector, migration, requirements.txt, setup.py, test-requirements.txt, tools, tox.ini [fuel] openstack/python-fuelclient has extra files, please remove: .gitignore, .testr.conf, MAINTAINERS, MANIFEST.in, fuelclient, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [Infrastructure] opendev/puppet-releasestatus has extra files, please remove: .gitignore [ironic] openstack/python-dracclient has extra files, please remove: .gitignore, CONTRIBUTING.rst, HACKING.rst, LICENSE, doc, dracclient, requirements.txt, setup.cfg, setup.py, test-requirements.txt, tox.ini [neutron] openstack/networking-calico has extra files, please remove: .coveragerc, .gitignore, .mailmap, .testr.conf, .zuul.yaml, CONTRIBUTING.rst, HACKING.rst, LICENSE, MANIFEST.in, RELEASING.md, babel.cfg, debian, devstack, doc, networking_calico, playbooks, requirements.txt, rpm, setup.cfg, setup.py, test-requirements.txt, tox.ini [neutron] openstack/networking-l2gw has extra files, please remove: .coveragerc, .gitignore, .testr.conf, .zuul.yaml, CONTRIBUTING.rst, HACKING.rst, LICENSE, MANIFEST.in, babel.cfg, bindep.txt, contrib, debian, devstack, doc, etc, lower-constraints.txt, networking_l2gw, openstack-common.conf, requirements.txt, setup.cfg, setup.py, specs, test-requirements.txt, tools, tox.ini [neutron] openstack/networking-l2gw-tempest-plugin has extra files, please remove: .gitignore, .zuul.yaml, CONTRIBUTING.rst, HACKING.rst, LICENSE, babel.cfg, contrib, doc, networking_l2gw_tempest_plugin, requirements.txt, setup.cfg, setup.py, test-requirements.txt, tox.ini [neutron] openstack/networking-onos has extra files, please remove: .coveragerc, .gitignore, .mailmap, .pylintrc, .testr.conf, CONTRIBUTING.rst, HACKING.rst, LICENSE, PKG-INFO, TESTING.rst, babel.cfg, devstack, doc, etc, lower-constraints.txt, networking_onos, package, rally-jobs, releasenotes, requirements.txt, setup.cfg, setup.py, test-requirements.txt, tools, tox.ini [neutron] openstack/neutron-vpnaas has extra files, please remove: .coveragerc, .gitignore, .mailmap, .pylintrc, .stestr.conf, .zuul.yaml, CONTRIBUTING.rst, HACKING.rst, LICENSE, TESTING.rst, babel.cfg, devstack, doc, etc, lower-constraints.txt, neutron_vpnaas, playbooks, rally-jobs, releasenotes, requirements.txt, setup.cfg, setup.py, test-requirements.txt, tools, tox.ini [OpenStack Charms] openstack/charm-ceph has extra files, please remove: .gitignore [OpenStackAnsible] openstack/openstack-ansible-os_monasca has extra files, please remove: tests, tox.ini [solum] openstack/solum-infra-guestagent has extra files, please remove: .coveragerc, .gitignore, .mailmap, .testr.conf, CONTRIBUTING.rst, HACKING.rst, LICENSE, MANIFEST.in, babel.cfg, config-generator, doc, etc, requirements.txt, setup.cfg, setup.py, solum_guestagent, test-requirements.txt, tox.ini I'd like to kindly ask the affected teams to help out with this, or any member of our community is more than welcome to push a change to those repos and work with the appropriate teams to help land it. Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

8 11

neutron netns arp issue
by Satish Patel 08 Jul '19

08 Jul '19

Hello, I am deploying openstack-ansible with octavia and i can see neutron created network for lb-mgmt-net which also created dhcp namespace for that network which is in vlan27 so far everything good so for testing i have created vm and it didn't get IP address so i have started troubleshooting and i found my namespace sending arp request but not getting reply back. [root@ostack-infra-2-2 ~]# ip netns exec qdhcp-2b94d9df-dd49-45b5-a992-63fee27bfa77 ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ns-5604eec1-20@if132: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether fa:16:3e:c2:b3:4d brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 172.27.12.3/21 brd 172.27.15.255 scope global ns-5604eec1-20 valid_lft forever preferred_lft forever inet 169.254.169.254/16 brd 169.254.255.255 scope global ns-5604eec1-20 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fec2:b34d/64 scope link valid_lft forever preferred_lft forever This is my linuxbridge [root@ostack-infra-2-2 ~]# brctl show brq2b94d9df-dd bridge name bridge id STP enabled interfaces brq2b94d9df-dd 8000.16d25dbea2cc no br-vlan.27 tap5604eec1-20 on same controller node "ostack-infra-2-2" i have br-lbaas network which has same VLAN 27 subnet IP. now when i ping from dhcp-namespace to outside host on same vlan 27, i can see ARP going out and remote host replying back but my reply coming on br-lbaas interface. [root@ostack-infra-2-2 ~]# ip netns exec qdhcp-2b94d9df-dd49-45b5-a992-63fee27bfa77 ping 172.27.8.4 PING 172.27.8.4 (172.27.8.4) 56(84) bytes of data. >From 172.27.12.3 icmp_seq=1 Destination Host Unreachable >From 172.27.12.3 icmp_seq=2 Destination Host Unreachable on other terminal i am running tcpdump on br-lbaas and i am seeing remote host ARP reply coming on that interface but not going to br-vlan.27 which neutron created. [root@ostack-infra-2-2 network-scripts]# tcpdump -i br-lbaas -nn tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br-lbaas, link-type EN10MB (Ethernet), capture size 262144 bytes 22:41:38.920858 ARP, Reply 172.27.8.4 is-at 32:7c:a1:91:79:7c, length 46 22:41:39.922167 ARP, Reply 172.27.8.4 is-at 32:7c:a1:91:79:7c, length 46 22:41:40.924052 ARP, Reply 172.27.8.4 is-at 32:7c:a1:91:79:7c, length 46 Do you think i can't create two same subnet bridge on same host?

1 0

[Neutron] NUMA aware VxLAN
by Guo, Ruijing 08 Jul '19

08 Jul '19

Hi, Existing neutron ML2 support one VxLAN for tenant network. In NUMA case, VM 0 can be created in node 0 and VM 1 can be created in node 1 and VxLAN is in node 0. VM1 need to cross node, which cause some performance downgrade. Does someone have this performance issue? Does Neutron community have plan to enhance it? Thanks, -Ruijing

3 2