January 2020 - openstack-discuss - lists.openstack.org

[ops] live-migration progress
by Martin Gehrke 16 Jan '20

16 Jan '20

Hi, Last week at the Openstack Operators meetup in London, someone mentioned that there was an issue with the progress updates during a live migration and that by turning it off you could increase your success rate. Does anyone know more TIA Martin Gehrke DevOps Manager & OpenStack Tech Lead Two Sigma Investments, LP New York, NY

1 0

[cinder] consistency group not working
by Francois Scheurer 16 Jan '20

16 Jan '20

Dear Cinder Experts We are running the rocky release. |We can create a consistency group: openstack consistency group create --volume-type b9f67298-cf68-4cb2-bed2-c806c5f83487 fsc-consgroup Bug 1: but adding volumes is not working: openstack consistency group add volume c3f49ef0-601e-4558-a75a-9b758304ce3b b48752e3-641f-4a49-a892-6cb54ab6b74d c0022411-59a4-4c7c-9474-c7ea8ccc7691 0f4c6493-dbe2-4f75-8e37-5541a267e3f2 => Invalid volume: Volume is not local to this node. (HTTP 400) (Request-ID: req-7f67934a-5835-40ef-b25c-12591fd79f85) Bug 2: deleting consistency group is also not working (silently failing): openstack consistency group delete c3f49ef0-601e-4558-a75a-9b758304ce3b |||=> AttributeError: 'RBDDriver' object has no attribute 'delete_consistencygroup'| See details below. Using the --force option makes no difference and the consistency group is not deleted. Do you think this is a bug or a configuration issue? Thank you in advance. | Cheers Francois |Details: ==> /var/lib/docker/volumes/kolla_logs/_data/cinder/cinder-api-access.log <== 10.0.129.17 - - [27/Sep/2019:12:16:24 +0200] "POST /v3/f099965b37ac41489e9cac8c9d208711/consistencygroups/3706bbab-e2df-4507-9168-08ef811e452c/delete HTTP/1.1" 202 - 109720 "-" "python-cinderclient" ==> /var/lib/docker/volumes/kolla_logs/_data/cinder/cinder-volume.log <== 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server [req-9010336e-d569-47ad-84e2-8dd8b729939c b141574ee71f49a0b53a05ae968576c5 f099965b37ac41489e9cac8c9d208711 - default default] Exception during message handling: AttributeError: 'RBDDriver' object has no attribute 'delete_consistencygroup' 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 163, in _process_incoming 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 265, in dispatch 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/osprofiler/profiler.py", line 159, in wrapper 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server result = f(*args, **kwargs) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/cinder/volume/manager.py", line 3397, in delete_group 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server vol_obj.save() 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server self.force_reraise() 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/cinder/volume/manager.py", line 3362, in delete_group 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server self.driver.delete_consistencygroup(context, cg, 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server AttributeError: 'RBDDriver' object has no attribute 'delete_consistencygroup' 2019-09-27 12:16:24.491 30 ERROR oslo_messaging.rpc.server| -- EveryWare AG François Scheurer Senior Systems Engineer Zurlindenstrasse 52a CH-8003 Zürich tel: +41 44 466 60 00 fax: +41 44 466 60 10 mail: francois.scheurer(a)everyware.ch web: http://www.everyware.ch

2 2

[blazar] No IRC meeting today
by Pierre Riteau 16 Jan '20

16 Jan '20

Hello, Similarly to Tuesday, I have to cancel today's Blazar IRC meeting. Sorry for the late notice. Thanks, Pierre Riteau (priteau)

1 0

[tc][all] Updates on Ussuri cycle community-wide goals
by Ghanshyam Mann 16 Jan '20

16 Jan '20

Hello Everyone, We have two goals with their champions ready for review. Please review and provide your feedback on Gerrit. 1. Add goal for project specific PTL and contributor guides - Kendall Nelson - https://review.opendev.org/#/c/691737/ 2. Propose a new goal to migrate all legacy zuul jobs - Luigi Toscano - https://review.opendev.org/#/c/691278/ We are still looking for the Champion volunteer for RBAC goal[1]. If you have any new ideas for goal, do not hesitate to add in etherpad[2] [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010291.… [2] https://etherpad.openstack.org/p/PVG-u-series-goals -gmann & diablo_rojo

1 2

Re: [magnum]: K8s cluster creation times out. OpenStack Train : [ERROR]: Unable to render networking. Network config is likely broken
by Feilong Wang 16 Jan '20

16 Jan '20

Hi Donny, Do you mean Fedore CoreOS or just CoreOS? The current CoreOS driver is not actively maintained, I would suggest migrating to Fedora CoreOS and I'm happy to help if you have any question. Thanks. On 14/01/20 9:57 AM, Donny Davis wrote: > FWIW I was only able to get the coreos image working with magnum oob.. > the rest just didn't work. > > On Mon, Jan 13, 2020 at 2:31 PM feilong <feilong(a)catalyst.net.nz > <mailto:feilong@catalyst.net.nz>> wrote: > > Hi Bhupathi, > > Firstly, I would suggest setting the use_podman=False when using > fedora atomic image. And it would be nice to set the "kube_tag", > e.g. v1.15.6 explicitly. Then please trigger a new cluster > creation. Then if you still run into error. Here is the debug steps: > > 1. ssh into the master node, check log /var/log/cloud-init-output.log > > 2. If there is no error in above log file, then run journalctl -u > heat-container-agent to check the heat-container-agent log. If > above step is correct, then you must be able to see something > useful here. > > > On 11/01/20 12:15 AM, Bhupathi, Ramakrishna wrote: >> >> Wang, >> >> Here it is . I added the labels subsequently. My nova and >> neutron are working all right as I installed various systems >> there working with no issues.. >> >> >> >> >> >> *From:*Feilong Wang [mailto:feilong@catalyst.net.nz] >> *Sent:* Thursday, January 9, 2020 6:12 PM >> *To:* openstack-discuss(a)lists.openstack.org >> <mailto:openstack-discuss@lists.openstack.org> >> *Subject:* Re: [magnum]: K8s cluster creation times out. >> OpenStack Train : [ERROR]: Unable to render networking. Network >> config is likely broken >> >> >> >> Hi Bhupathi, >> >> Could you please share your cluster template? And please make >> sure your Nova/Neutron works. >> >> >> >> On 10/01/20 2:45 AM, Bhupathi, Ramakrishna wrote: >> >> Folks, >> >> I am building a Kubernetes Cluster( Openstack Train) and >> using fedora atomic-29 image . The nodes come up fine ( I >> have a simple 1 master and 1 node) , but the cluster creation >> times out, and when I access the cloud-init logs I see this >> error . Wondering what I am missing as this used to work >> before. I wonder if this is image related . >> >> >> >> [ERROR]: Unable to render networking. Network config is >> likely broken: No available network renderers found. Searched >> through list: ['eni', 'sysconfig', 'netplan'] >> >> >> >> Essentially the stack creation fails in “kube_cluster_deploy” >> >> >> >> Can somebody help me debug this ? Any help is appreciated. >> >> >> >> --RamaK >> >> The contents of this e-mail message and >> any attachments are intended solely for the >> addressee(s) and may contain confidential >> and/or legally privileged information. If you >> are not the intended recipient of this message >> or if this message has been addressed to you >> in error, please immediately alert the sender >> by reply e-mail and then delete this message >> and any attachments. If you are not the >> intended recipient, you are notified that >> any use, dissemination, distribution, copying, >> or storage of this message or any attachment >> is strictly prohibited. >> >> -- >> Cheers & Best regards, >> Feilong Wang (王飞龙) >> Head of R&D >> Catalyst Cloud - Cloud Native New Zealand >> -------------------------------------------------------------------------- >> Tel: +64-48032246 >> Email: flwang(a)catalyst.net.nz <mailto:flwang@catalyst.net.nz> >> Level 6, Catalyst House, 150 Willis Street, Wellington >> -------------------------------------------------------------------------- >> The contents of this e-mail message and >> any attachments are intended solely for the >> addressee(s) and may contain confidential >> and/or legally privileged information. If you >> are not the intended recipient of this message >> or if this message has been addressed to you >> in error, please immediately alert the sender >> by reply e-mail and then delete this message >> and any attachments. If you are not the >> intended recipient, you are notified that >> any use, dissemination, distribution, copying, >> or storage of this message or any attachment >> is strictly prohibited. > > -- > Cheers & Best regards, > Feilong Wang (王飞龙) > ------------------------------------------------------ > Senior Cloud Software Engineer > Tel: +64-48032246 > Email: flwang(a)catalyst.net.nz <mailto:flwang@catalyst.net.nz> > Catalyst IT Limited > Level 6, Catalyst House, 150 Willis Street, Wellington > ------------------------------------------------------ > > > > -- > ~/DonnyD > C: 805 814 6800 > "No mission too difficult. No sacrifice too great. Duty First" -- Cheers & Best regards, Feilong Wang (王飞龙) Head of R&D Catalyst Cloud - Cloud Native New Zealand -------------------------------------------------------------------------- Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------

5 7

[infra] Retire x/zmq-event-publisher
by Andreas Jaeger 16 Jan '20

16 Jan '20

This repo is not used anymore, it was forked and is maintained for Jenkins now elsewhere. I'll retire the repo now with topic retire-zmq-event-publisher, Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

1 0

[tripleo] Switch to tripleo-container-manage by default (replacing Paunch)
by Emilien Macchi 15 Jan '20

15 Jan '20

Hi folks, Some work has been done to replace Paunch and use the new "podman_container" Ansible module; It's possible thanks to a role that is now documented here: https://docs.openstack.org/tripleo-ansible/latest/roles/role-tripleo-contai… While some efforts are still ongoing to replace container-puppet.py (which uses Paunch to execute a podman run); the tripleo-container-manage role has reached stability and enough maturity to be the default now. I would like to give it a try and for that I have 2 patches that would need to be landed: https://review.opendev.org/#/c/700737 https://review.opendev.org/#/c/700738 The most popular question that has been asked about $topic so far is: how can I run paunch debug to print the podman commands. Answer: https://docs.openstack.org/tripleo-ansible/latest/roles/role-tripleo-contai… Please raise any concern here and we'll address it. Hopefully we can make the default on time before U cycle ends. On a side note: I prepared all the backports to stable/train so the feature will be available in that branch as well. Thanks, -- Emilien Macchi

3 4

[deployment][kolla][tripleo][osa][docs] Intro to OpenStack
by Radosław Piliszek 15 Jan '20

15 Jan '20

Hiya, Folks! I had some thought after talking with people new to OpenStack - our deployment tools are too well-hidden in the ecosystem. People try deploying devstack for fun (and some still use packstack!) and then give up on manual installation for production due to its complexity and fear of upgrades. I also got voices that Kolla/TripleO/OSA (order random) is an "unofficial" way to deploy OpenStack and the installation guide is the only "official" one (whatever that may mean in this very context). So I decided I go the "newbie" route and inspected the website. https://www.openstack.org invites us to browse: https://www.openstack.org/software/start/ which is nice and dandy, presents options of enterprise-grade solutions etc. but fails to really mention OpenStack has deployment tools (if one does not look at the submenu bar) and instead points the "newbie" to the installation guide: https://docs.openstack.org/install-guide/overview.html which kind-of negates that OpenStack ecosystem has any ready tools of deployment by saying: "After becoming familiar with basic installation, configuration, operation, and troubleshooting of these OpenStack services, you should consider the following steps toward deployment using a production architecture: ... Implement a deployment tool such as Ansible, Chef, Puppet, or Salt to automate deployment and management of the production environment." Just some food for thought. Extra for Kolla and OSA: https://docs.openstack.org/train/deploy/ seems we no longer deploy OpenStack since Train. -yoctozepto

3 5

[nova] Removal of 'deallocate_networks_on_reschedule' virt driver API method
by Stephen Finucane 15 Jan '20

15 Jan '20

Just FYI, the 'deallocate_networks_on_reschedule' method of the nova virt driver API has been removed in [1]. It was only used for nova- network based flows and is therefore surplus to requirements. Third party drivers that implement this function can now remove it. Stephen [1] https://review.opendev.org/#/c/696516/

1 0

[scientific-sig] IRC Meeting today 1100UTC - large scale & planning for 2020
by Stig Telfer 15 Jan '20

15 Jan '20

Hi All - We have a Scientific SIG meeting today at 1100UTC (about 30 minutes time) in channel #openstack-meeting. Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_15th_2020 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_15th_2020> We’d like to gather some datapoints for the Large Scale SIG, and talk CFPs and conferences for 2020. Cheers, Stig

1 0

[mistral][core] Promoting Eyal Bar-Ilan to the Mistral core team
by Renat Akhmerov 15 Jan '20

15 Jan '20

Hi, I’d like to promote Eyal Bar-Ilan to the Mistral core team since he’s shown a great contribution performance in the recent months. Eyal always reacts on various CI issues timely and provides fixes very quickly. He’s also completed a number of useful functional Mistral features in Train and Ussuri. And his overall statistics for Ussuri ([1]) makes him a clear candidate for core membership. Core reviewers, please let me know if you have any objections. [1] https://www.stackalytics.com/?module=mistral-group&release=ussuri&user_id=e… Thanks Renat Akhmerov @Nokia

4 4

RE: Designate zone troubleshooting [designate]
by Albert Braden 15 Jan '20

15 Jan '20

1 0

[tripleo] rocky builds
by Wesley Hayutin 14 Jan '20

14 Jan '20

Greetings, I've confirmed that builds from the Rocky release will no longer be imported. Looking for input from the upstream folks with regards to maintaining the Rocky release for upstream. Can you please comment if you have any requirement to continue building, patching Rocky as I know there are active reviews [1]. I've added this topic to be discussed at the next meeting [2] Thank you! [1] https://review.opendev.org/#/q/status:open+tripleo+branch:stable/rocky [2] https://etherpad.openstack.org/p/tripleo-meeting-items

3 2

[cyborg] enable launchpad or storyboard for Cyborg
by Brin Zhang(张百林) 14 Jan '20

14 Jan '20

Hi Sundar and all: I think we should enable launchpad for the Cyborg project to record its reported bugs, submitted blueprints, etc., so that we can keep track of project updates and changes. Now I found there are some specifications in the cyborg-specs, and there has not been management by the Launchpad (https://launchpad.net/cyborg) or storyboard (https://storyboard.openstack.org/#!/project/openstack/cyborg) Personally recommend using Launchpad, it looks very intuitive. brinzhang

3 2

[all] DevStack jobs broken due to setuptools not available for Python 2
by Radosław Piliszek 14 Jan '20

14 Jan '20

Hi all, I noticed DevStack jobs fail all over the place [1] due to: UnsupportedPythonVersion: Package 'setuptools' requires a different Python: 2.7.17 not in '>=3.5' Bug reported in [2]. Notice USE_PYTHON3=True does not help as stack.sh is hardcoded to versionless Python. [1] https://zuul.opendev.org/t/openstack/builds?result=RETRY_LIMIT&result=FAILU… [2] https://bugs.launchpad.net/devstack/+bug/1859350 -yoctozepto

6 8

Designate zone troubleshooting
by Albert Braden 14 Jan '20

14 Jan '20

1 0

[ops] No ops meetup team meeting tomorrow (2020/1/14) on IRC
by Chris Morgan 14 Jan '20

14 Jan '20

We had a great OpenStack Ops meetup last week in London. Those involved now need to catch up on other work, so we'll resume regular meetings on Jan 21st. Our thanks to everyone who attended and/or helped make it one of the best meetups in a while. Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[blazar] No IRC meeting tomorrow
by Pierre Riteau 13 Jan '20

13 Jan '20

Hello, As announced in the last meeting, due to travel the weekly Blazar IRC meeting of January 14 is cancelled. The next meeting will be held on Jan 21. Thanks, Pierre Riteau (priteau)

1 0

Re: [magnum]: K8s cluster creation times out. OpenStack Train : [ERROR]: Unable to render networking. Network config is likely broken
by feilong 13 Jan '20

13 Jan '20

Hi Bhupathi, Firstly, I would suggest setting the use_podman=False when using fedora atomic image. And it would be nice to set the "kube_tag", e.g. v1.15.6 explicitly. Then please trigger a new cluster creation. Then if you still run into error. Here is the debug steps: 1. ssh into the master node, check log /var/log/cloud-init-output.log 2. If there is no error in above log file, then run journalctl -u heat-container-agent to check the heat-container-agent log. If above step is correct, then you must be able to see something useful here. On 11/01/20 12:15 AM, Bhupathi, Ramakrishna wrote: > > Wang, > > Here it is . I added the labels subsequently. My nova and neutron are > working all right as I installed various systems there working with no > issues.. > > > > > > *From:*Feilong Wang [mailto:feilong@catalyst.net.nz] > *Sent:* Thursday, January 9, 2020 6:12 PM > *To:* openstack-discuss(a)lists.openstack.org > *Subject:* Re: [magnum]: K8s cluster creation times out. OpenStack > Train : [ERROR]: Unable to render networking. Network config is likely > broken > > > > Hi Bhupathi, > > Could you please share your cluster template? And please make sure > your Nova/Neutron works. > > > > On 10/01/20 2:45 AM, Bhupathi, Ramakrishna wrote: > > Folks, > > I am building a Kubernetes Cluster( Openstack Train) and using > fedora atomic-29 image . The nodes come up fine ( I have a simple > 1 master and 1 node) , but the cluster creation times out, and > when I access the cloud-init logs I see this error . Wondering > what I am missing as this used to work before. I wonder if this > is image related . > > > > [ERROR]: Unable to render networking. Network config is likely > broken: No available network renderers found. Searched through > list: ['eni', 'sysconfig', 'netplan'] > > > > Essentially the stack creation fails in “kube_cluster_deploy” > > > > Can somebody help me debug this ? Any help is appreciated. > > > > --RamaK > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. > > -- > Cheers & Best regards, > Feilong Wang (王飞龙) > Head of R&D > Catalyst Cloud - Cloud Native New Zealand > -------------------------------------------------------------------------- > Tel: +64-48032246 > Email: flwang(a)catalyst.net.nz <mailto:flwang@catalyst.net.nz> > Level 6, Catalyst House, 150 Willis Street, Wellington > -------------------------------------------------------------------------- > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. -- Cheers & Best regards, Feilong Wang (王飞龙) ------------------------------------------------------ Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington ------------------------------------------------------

1 0

[cinder] ussuri virtual mid-cycle next week
by Brian Rosmaita 13 Jan '20

13 Jan '20

The poll results are in. There was only one time when everyone can meet (apologies to the "if need be" people, but the need be). Session One of the Cinder Ussuri virtual mid-cycle will be held: DATE: 21 JANUARY 2020 TIME: 1300-1500 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Please add topics to the planning etherpad: https://etherpad.openstack.org/p/cinder-ussuri-mid-cycle-planning cheers, brian

1 0

[horizon][stein]issue:
by prashant 13 Jan '20

13 Jan '20

when i m deleting multiple instances into the stein, could not able to see all remaining instances until i refresh instances list again.

1 0

[all] Announcing OpenStack Victoria!
by Sean McGinnis 13 Jan '20

13 Jan '20

Hello everyone, The polling results are in, and the legal vetting process has now completed. We now have an official name for the "V" release. The full results of the poll can be found here: https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_13ccd49b6… While Victoria and Vancouver were technically a tie, based on the Minimax rankingi, it puts Victoria slightly ahead of Vancouver based on the votes. In addition to that, we chose to have the TC do a tie breaker vote which confirmed Victoria as the winner. Victoria is the capital city of British Columbia: https://en.wikipedia.org/wiki/Victoria,_British_Columbia Thank you all for participating in the release naming! Sean

2 1

[neutron] Bug deputy report - Jan 06 to 12
by Hongbin Lu 12 Jan '20

12 Jan '20

1 0

[tripleo][ci] Proposing Sorin Barnea as TripleO-CI core
by Marios Andreou 12 Jan '20

12 Jan '20

I would like to propose Sorin Barnea (ssbarnea(a)redhat.com) as core on tripleo-ci repos (tripleo-ci, tripleo-quickstart, tripleo-quickstart-extras). Sorin has been a member of the tripleo-ci team for over one and a half years and has made many contributions across the tripleo-ci repos and beyond - highlights include helping the team to adopt molecule testing, leading linting efforts/changes/fixes and many others. Please vote by replying to this thread with +1 or -1 for any objections thanks marios

9 8

[tripleo][ci] Proposing Chandan Kumar and Arx Cruz as TripleO-CI cores
by Ronelle Landy 11 Jan '20

11 Jan '20

Hello All, I'd like to propose Arx Cruz (arxcruz(a)redhat.com) and Chandan Kumar ( chkumar(a)redhat.com) as core on tripleo-ci repos (tripleo-ci, tripleo-quickstart, tripleo-quickstart-extras). In addition to the extensive work that Arx and Chandan have done on the Tempest-related repos ( and Tempest interface/settings within the Tripleo CI repos) , they have become active contributors to the core Tripleo CI repos, in general, in the past two years. Please vote by replying to this thread with +1 or -1 for any objections. We will close the vote 7 days from now. Thank you, Ronelle

5 5

[keystone] Keystone Team Update - Week of 6 January 2020
by vishakha agarwal 11 Jan '20

11 Jan '20

# Keystone Team Update - Week of 6 January 2020 ## News ### User Support and Bug Duty The person in-charge for bug duty for current and upcoming week can be seen on the etherpad [1] [1] https://etherpad.openstack.org/p/keystone-l1-duty ## Action Items The one-fourth of the ussuri cycle is almost over. We need to find a new mechanism for the retrospective and to check our progress for this cycle which is more convenient and less time consuming for the members. ## Open Specs Ussuri specs: https://bit.ly/2XDdpkU Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 19 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 37 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Community Goals https://review.opendev.org/#/c/699127/ [ussuri][goal] Drop python 2.7 support and testing keystone-tempest-plugin https://review.opendev.org/#/c/699126/ [ussuri][goal] Drop python 2.7 support and testing ldappool https://review.opendev.org/#/c/699119/ [ussuri][goal] Drop python 2.7 support and testing python-keystoneclient * Special Requests https://review.opendev.org/#/c/662734/ Change the default Identity endpoint to internal https://review.opendev.org/#/c/699013/ Always have username in CADF initiator https://review.opendev.org/#/c/700826/ Fix role_assignments role.id filter ## Bugs This week we opened 3 new bugs and closed 5. Bugs opened (3) Bug #1858410 (keystone:Low): Got error 'NoneType' when executing unittest on stable/rocky - Opened by Eric Xie https://bugs.launchpad.net/keystone/+bug/1858410 Bug #1858186 (keystoneauth:Undecided): http_log_request will print debug info include pki certificate which is unsafety - Opened by kuangpeiling https://bugs.launchpad.net/keystoneauth/+bug/1858186 Bug #1858189 (keystoneauth:Undecided): http_log_request will print debug info include pki certificate which is unsafety - Opened by kuangpeiling https://bugs.launchpad.net/keystoneauth/+bug/1858189 Bugs closed (5) Bug #1858186 (keystoneauth:Undecided) https://bugs.launchpad.net/keystoneauth/+bug/1858186 Bug #1856881 (keystone:Medium): keystone-manage bootstrap fails with ambiguous role names - Fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1856881 Bug #1856962 (keystone:Undecided): openid method failed when federation_group_ids is empty list - Fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1856962 Bug #1857086 (keystone: Won't Fix) https://bugs.launchpad.net/keystone/+bug/1857086 Bug #1831018 (keystone: Invalid)https://bugs.launchpad.net/keystone/+bug/1831018 ## Milestone Outlook https://releases.openstack.org/ussuri/schedule.html Spec freeze is on the week of 10 February. All the specs targeted for this cycle should be ready for the review soon. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[aodh][keystone] handling of webhook / alarm authentication
by info＠dantalion.nl 11 Jan '20

11 Jan '20

Hello, I was wondering how a service receiving an aodh webhook could perform authentication? The documentation describes the webhook as a simple post-request so I was wondering if a keystone token context is available when these requests are received? If not, I was wondering if anyone had any recommendation on how to perform authentication upon received post-requests? So far I have come up with limiting the functionality of these webhooks such as rate-limiting and administrators having to explicitly enable these webhooks before they work. Hope anyone else could provide further valuable information. Kind regards, Corne Lukken Watcher core-reviewer

3 4

[release] Release countdown for week R-17, January 13-17
by Sean McGinnis 11 Jan '20

11 Jan '20

Development Focus ----------------- The Ussuri-2 milestone will happen in next month, on February 13. Ussuri-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/ussuri/schedule.html for details. General Information ------------------- Please remember that libraries need to be released at least once per milestone period. At milestone 2, the release team will propose releases for any library that has not been otherwise released since milestone 1. Other non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. At milestone-2 we also freeze the contents of the final release. If you have a new deliverable that should be included in the final release, you should make sure it has a deliverable file in: https://opendev.org/openstack/releases/src/branch/master/deliverables/ussuri You should request a beta release (or intermediary release) for those new deliverables by milestone-2. We understand some may not be quite ready for a full release yet, but if you have something minimally viable to get released it would be good to do a 0.x release to exercise the release tooling for your deliverables. See the MembershipFreeze description for more details: https://releases.openstack.org/ussuri/schedule.html#u-mf Finally, now may be a good time for teams to check on any stable releases that need to be done for your deliverables. If you have bugfixes that have been backported, but no stable release getting those. If you are unsure what is out there committed but not released, in the openstack/releases repo, running the command "tools/list_stable_unreleased_changes.sh <cycle_name>" gives a nice report. Upcoming Deadlines & Dates -------------------------- Ussuri-2 Milestone: February 13 (R-13 week)

1 0

[tripleo] introducing zuul-runner
by Wesley Hayutin 11 Jan '20

11 Jan '20

Greetings, Hey everyone I want to highlight work that some of our good friends in zuul are working another way to try and help everyone debug their jobs. The tool is called zuul-runner and the spec is here [1], code is here [2] Please have a look through the spec and vote to show support for Tristan's work. Thanks to Arx Cruz for contributing and testing it as well w/ TripleO jobs. This will be another very nice tool in the toolbox for us if we can get it through. Thanks! [1] https://review.opendev.org/#/c/681277/ [2] https://review.opendev.org/#/c/607078/

1 0

[neutron][rabbitmq] Neutron-server service shows deprecated "AMQPDeprecationWarning"
by Amjad Kotobi 10 Jan '20

10 Jan '20

Hi, Today we are facing losing connection of neutron especially during instance creation or so as “systemctl status neutron-server” shows below message be deprecated in amqp 2.2.0. Since amqp 2.0 you have to explicitly call Connection.connect() before using the connection. W_FORCE_CONNECT.format(attr=attr))) /usr/lib/python2.7/site-packages/amqp/connection.py:304: AMQPDeprecationWarning: The .transport attribute on the connection was accessed before the connection was established. This is supported for now, but will be deprecated in amqp 2.2.0. Since amqp 2.0 you have to explicitly call Connection.connect() before using the connection. W_FORCE_CONNECT.format(attr=attr))) OpenStack release which we are running is “Pike”. Is there any way to remedy this? Thanks Amjad

3 4

Re: [charms][watcher] OpenStack Watcher Charm
by Corey Bryant 10 Jan '20

10 Jan '20

On Fri, Jan 10, 2020 at 6:12 AM James Page <james.page(a)canonical.com> wrote: > Hi Stamatis > > Thankyou for this work! > > I'll take a look at your charm over the next few days. > > On Wed, Jan 8, 2020 at 11:25 AM Stamatis Katsaounis < > skatsaounis(a)admin.grnet.gr> wrote: > >> Hi all, >> >> Purpose of this email is to let you know that we released an unofficial >> charm of OpenStack Watcher [1]. This charm gave us the opportunity to >> deploy OpenStack Watcher to our charmed OpenStack deployment. >> >> After seeing value in it, we decided to publish it through GRNET GitHub >> Organization account for several reasons. First of all, we would love to >> get feedback on it as it is our first try on creating an OpenStack reactive >> charm. Secondly, we would be glad to see other OpenStack operators deploy >> Watcher and share with us knowledge on the project and possible use cases. >> Finally, it would be ideal to come up with an official OpenStack Watcher >> charm repository under charmers umbrella. By doing this, another OpenStack >> project is going to be available not only for Train version but for any >> future version of OpenStack. Most important, the CI tests are going to >> ensure that the code is not broken and persuade other operators to use it. >> >> Before closing my email, I would like to give some insight on the >> architecture of the code base and the deployment process. To begin with, >> charm-watcher is based on other reactive OpenStack charms. During its >> deployment Barbican, Designate, Octavia and other charms' code bases were >> counseled. Furthermore, the structure is the same as any official OpenStack >> charm, of course without functional tests, which is something we cannot >> provide. >> > I'd suggest that we initiate the process to include your watcher charm as > part of the OpenStack Charmers project on opendev.org; once the initial > migration completes adding some functional tests should be fairly easy as > you'll be able to run them on the Canonical 3rd party CI infrastructure. > > This requires that a couple of reviews be raised - here are examples for > the new Manila Ganesha charms: > > https://review.opendev.org/#/c/693463/ > https://review.opendev.org/#/c/693462/ > > One is for the infrastructure setup, the other is to formally include the > repositories as part of the TC approved project. If you would like to > raise them for the watcher charm I'm happy to review with Frode (who is the > current PTL). > >> Speaking about the deployment process, apart from having a basic charmed >> OpenStack deployment, operator has to change two tiny configuration options >> on Nova cloud controller and Cinder. As explained in the Watcher >> configuration guide, special care has to be done with Oslo notifications >> for Nova and Cinder [2]. In order to achieve that in charmed OpenStack some >> issues were met and solved with the following patches [3], [4], [5], [6]. >> With these patches, operator can set the extra Oslo configuration and this >> is the only extra configuration needs to take place. Finally, with [7] >> Keystone charm can accept a relation with Watcher charm instead of ignoring >> it. >> >> To be able to deploy GRNET Watcher charm on Train, patches [3], [4], [5] >> and [7] have to be back-ported to stable/19.10 branch but that will require >> the approval of charmers team. Please let me know if such an option is >> available and in that case I am going to open the relevant patches. >> Furthermore, if you think that it could be a good option to create a spec >> and then introduce an official Watcher charm, I would love to help on that. >> > I'd rather we wait until the 20.02 charm release - dependent changes have > all landed and will be included. > > I wish all a happy new year and I am looking forward to your response and >> possible feedback. >> > > Happy new year to you as well! > > PS. If we could have an Ubuntu package for watcher-dashboard [8] like >> octavia-dashboard [9] we would release a charm for it as well. >> > > I'll chat with coreycb and see if we might be able to package that for > 20.04/Ussuri. > > Hi, I'll take a look at packaging watcher-dashboard. Corey Cheers > > James > >> >> -- Corey

1 0

[largescale-sig] Next meeting: Jan 15, 9utc
by Thierry Carrez 10 Jan '20

10 Jan '20

Hi everyone, The Large Scale SIG will have a meeting next week on Wednesday, Jan 15 at 9 UTC[1] in #openstack-meeting on IRC. I'll not be around but Belmiro Moreira volunteered to chair the meeting. [1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200115T09 We had several TODOs out of our December meeting, so I invite you to review the summary of that meeting in preparation of the next: http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011667… As always, the agenda for the meeting next week is available at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez (ttx)

1 0

[kolla] Kayobe 7.0.0 released for Train
by Mark Goddard 10 Jan '20

10 Jan '20

Hi, I'm pleased to announce the release of Kayobe 7.0.0 - the first release in the Train series, and the first release as a deliverable of the Kolla project. Full details are available in the release notes which are available here: https://docs.openstack.org/releasenotes/kayobe/train.html We anticipate significant changes during the Train release series to support a migration to CentOS 8. We will communicate which releases are affected. Thanks to everyone who contributed to this release, and for the Kolla project for accepting us. I look forward to the continued integration of these teams. Cheers, Mark

1 0

[release] decentralising release approvals
by Mark Goddard 10 Jan '20

10 Jan '20

Hi, If this topic has been discussed many times already then someone please say so and we can leave it alone. As kolla PTL and ironic release liaison I've proposed a number of release patches recently. Generally the release team is good at churning through these, but sometimes patches can hang around for a while. Usually a ping on IRC will get things moving again within a day or so (thanks in particular to Sean who has been very responsive). Related to the recent discussion about decentralising stable branch maintenance, should we do this for releases too? To be clear, I'm proposing giving project teams more control over their own releases. I brought this up in IRC recently and there was a brief discussion. I suggested that releases are hard to undo, and Monty corrected me by saying they are impossible to undo. Still, if teams (or a subset of their members) had more ownership of their releases, they would become more familiar with the process, and the risk would be reduced. I'm not suggesting that release team should be disbanded - there is clearly work to do to maintain the tooling, determine and communicate the schedule, and more. But there's a lot of toil involved in checking and approving patches to the releases repo, and it's done by some of our most senior, busy colleagues. There are a number of checks that are performed automatically by the tooling and used to gate merges. I have a few questions for the release team about these reviews. * What manual checks do you do beyond those that are currently automated? * Could the above checks be automated? * What issues have you caught that were not caught by CI jobs? Hopefully I haven't offended anyone here. There's often more involved with these things than you first suspect. Cheers, Mark

5 10

[ops][largescale-sig] Collecting scaling stories
by Thierry Carrez 10 Jan '20

10 Jan '20

Hi everyone, As part of its goal of further pushing back scaling limits within a given cluster, the Large Scale SIG would like to collect scaling stories from OpenStack users. There is a size/load limit for single clusters past which things in OpenStack start to break, and we need to start using multiple clusters or cells to scale out. The SIG is interested in hearing: - what broke first for you, is it RabbitMQ or something else - what were the first symptoms - at what size/load did it start to break This will be a great help to document expected limits, and identify where improvements should be focused. You can contribute your experience by replying directly to this thread, or adding to the following etherpad: https://etherpad.openstack.org/p/scaling-stories Thanks in advance for your help ! -- Thierry Carrez (ttx) on behalf of the Large Scale SIG

1 0

Re: [charms][watcher] OpenStack Watcher Charm
by James Page 10 Jan '20

10 Jan '20

Dropping direct recipients as this causes a reject from openstack-discuss! On Fri, Jan 10, 2020 at 11:12 AM James Page <james.page(a)canonical.com> wrote: > Hi Stamatis > > Thankyou for this work! > > I'll take a look at your charm over the next few days. > > On Wed, Jan 8, 2020 at 11:25 AM Stamatis Katsaounis < > skatsaounis(a)admin.grnet.gr> wrote: > >> Hi all, >> >> Purpose of this email is to let you know that we released an unofficial >> charm of OpenStack Watcher [1]. This charm gave us the opportunity to >> deploy OpenStack Watcher to our charmed OpenStack deployment. >> >> After seeing value in it, we decided to publish it through GRNET GitHub >> Organization account for several reasons. First of all, we would love to >> get feedback on it as it is our first try on creating an OpenStack reactive >> charm. Secondly, we would be glad to see other OpenStack operators deploy >> Watcher and share with us knowledge on the project and possible use cases. >> Finally, it would be ideal to come up with an official OpenStack Watcher >> charm repository under charmers umbrella. By doing this, another OpenStack >> project is going to be available not only for Train version but for any >> future version of OpenStack. Most important, the CI tests are going to >> ensure that the code is not broken and persuade other operators to use it. >> >> Before closing my email, I would like to give some insight on the >> architecture of the code base and the deployment process. To begin with, >> charm-watcher is based on other reactive OpenStack charms. During its >> deployment Barbican, Designate, Octavia and other charms' code bases were >> counseled. Furthermore, the structure is the same as any official OpenStack >> charm, of course without functional tests, which is something we cannot >> provide. >> > I'd suggest that we initiate the process to include your watcher charm as > part of the OpenStack Charmers project on opendev.org; once the initial > migration completes adding some functional tests should be fairly easy as > you'll be able to run them on the Canonical 3rd party CI infrastructure. > > This requires that a couple of reviews be raised - here are examples for > the new Manila Ganesha charms: > > https://review.opendev.org/#/c/693463/ > https://review.opendev.org/#/c/693462/ > > One is for the infrastructure setup, the other is to formally include the > repositories as part of the TC approved project. If you would like to > raise them for the watcher charm I'm happy to review with Frode (who is the > current PTL). > >> Speaking about the deployment process, apart from having a basic charmed >> OpenStack deployment, operator has to change two tiny configuration options >> on Nova cloud controller and Cinder. As explained in the Watcher >> configuration guide, special care has to be done with Oslo notifications >> for Nova and Cinder [2]. In order to achieve that in charmed OpenStack some >> issues were met and solved with the following patches [3], [4], [5], [6]. >> With these patches, operator can set the extra Oslo configuration and this >> is the only extra configuration needs to take place. Finally, with [7] >> Keystone charm can accept a relation with Watcher charm instead of ignoring >> it. >> >> To be able to deploy GRNET Watcher charm on Train, patches [3], [4], [5] >> and [7] have to be back-ported to stable/19.10 branch but that will require >> the approval of charmers team. Please let me know if such an option is >> available and in that case I am going to open the relevant patches. >> Furthermore, if you think that it could be a good option to create a spec >> and then introduce an official Watcher charm, I would love to help on that. >> > I'd rather we wait until the 20.02 charm release - dependent changes have > all landed and will be included. > > I wish all a happy new year and I am looking forward to your response and >> possible feedback. >> > > Happy new year to you as well! > > PS. If we could have an Ubuntu package for watcher-dashboard [8] like >> octavia-dashboard [9] we would release a charm for it as well. >> > > I'll chat with coreycb and see if we might be able to package that for > 20.04/Ussuri. > > Cheers > > James > >> >>

1 0

[infra][stable] python3 is used by default in older stable branches
by Akihiro Motoki 10 Jan '20

10 Jan '20

Hi, The horizon team recently noticed that python3 is used as a default python interpreter in older stable branches like pike or ocata. For example, horizon pep8 job in stable/pike and stable/ocata fails [1][2]. We also noticed that some jobs which are expected to run with python2 (using the tox default interpreter as of the release) are now run with python3 [3]. What is the recommended way to cope with this situation? Individual projects can cope with the default interpreter change repo by repo, but this potentially affects all projects with older stable branches. This is the reason I am sending this mail. Best Regards, Akihiro Motoki (amotoki) [1] https://zuul.opendev.org/t/openstack/build/daaeaedb0a184e29a03eeaae59157c78 [2] https://zuul.opendev.org/t/openstack/build/525dc7f926684e54be8b565a7bbf7193 [3] https://zuul.opendev.org/t/openstack/build/adbc53b8d1f74dac9cd606f4a796c442…

3 3

[neutron][vpnaas] New neutron-vpnaas maintainer and core reviewer
by Slawek Kaplonski 10 Jan '20

10 Jan '20

Hi, After our last call for volunteers to maintain some of the neutron stadium projects, we have new neutron-vpnaas maintainer now \o/ Dongcan Ye just stepped up to take care of this project. After discussion with other neutron-vpnaas core reviewers I added him to neutron-vpnaas core team. He works on neutron-vpnaas since some time already and in our opinion he knows this project good enough to be core reviewer there. Thank You very much Dongcan Ye for help with neutron-vpnaas project :) — Slawek Kaplonski Senior software engineer Red Hat

1 0

[magnum]: K8s cluster creation times out. OpenStack Train : [ERROR]: Unable to render networking. Network config is likely broken
by Bhupathi, Ramakrishna 10 Jan '20

10 Jan '20

Folks, I am building a Kubernetes Cluster( Openstack Train) and using fedora atomic-29 image . The nodes come up fine ( I have a simple 1 master and 1 node) , but the cluster creation times out, and when I access the cloud-init logs I see this error . Wondering what I am missing as this used to work before. I wonder if this is image related . [ERROR]: Unable to render networking. Network config is likely broken: No available network renderers found. Searched through list: ['eni', 'sysconfig', 'netplan'] Essentially the stack creation fails in "kube_cluster_deploy" Can somebody help me debug this ? Any help is appreciated. --RamaK E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

2 1

Re: [Release-job-failures] release-post job for openstack/releases for ref refs/heads/master failed
by Sean McGinnis 10 Jan '20

10 Jan '20

On Thu, Jan 09, 2020 at 08:32:28PM +0000, zuul(a)openstack.org wrote: > Build failed. > > - tag-releases https://zuul.opendev.org/t/openstack/build/deb8b8d5504b4689ab6d669eac92f979 : FAILURE in 3m 46s > - publish-tox-docs-static https://zuul.opendev.org/t/openstack/build/None : SKIPPED > This failure can be safely ignored. This was a side effect of marking some older independent repos as 'abandoned' in https://review.opendev.org/#/c/700013/. These are old repos that are no longer under governance and/or retired. The failure itself appears to be from one of the retired repos, before we had specified in the retire procedure that the gitreview file should be kept around. Since these are no longer active, and there wasn't actually anything to tag and release, no need to worry about this failure. Sean

1 0

[qa][infra][stable] Stable branches gate status: tempest-full-* jobs failing for stable/ocata|pike|queens
by Ghanshyam Mann 09 Jan '20

09 Jan '20

Hello Everyone, tempest-full-* jobs are failing on stable/queens, stable/pike, and stable/ocata(legacy-tempest-dsvm-neutron-full-ocata) [1].ld Please hold any recheck till fix is merged. whoami-rajat reported about the tempest-full-queens-py3 job failure and later while debugging we found that same is failing for pike and ocata(job name there - legacy-tempest-dsvm-neutron-full-ocata). Failure is due to "Timeout on connecting the vnc console url" because there is no 'n-cauth' service running which is required for these stable branches. In Ussuri that service has been removed from nova. 'n-cauth' has been removed from ENABLED_SERVICES recently in - https://review.opendev.org/#/c/700217/ which effected only stable branches till queens. stable/rocky|stein are working because we have moved the services enable things from devstack-gate's test matrix to devstack base job[2]. Patch[2] was not backported to stable/queens and stable/pike which I am not sure why. We have two ways to fix the stable branches gate: 1. re-enable the n-cauth in devstack-gate. Hope all other removes services create no problem. pros: easy to fix, fix for all three stable branches. patch- https://review.opendev.org/#/c/701404/ 2. Backport the 546765[2] to stable/queens and stable/pike. pros: this removes the dependency form test-matrix which is the overall goal to remove d-g dependency. cons: It cannot be backported to stable/ocata as no zuulv3 base jobs there. This is already EM and anyone still cares about this? I think for fixing the gate (Tempest master and stable/queens|pike|ocata), we can go with option 1 and later we backport the devstack migration. [1] - http://zuul.openstack.org/builds?job_name=tempest-full-queens-py3 - http://zuul.openstack.org/builds?job_name=tempest-full-pike - http://zuul.openstack.org/builds?job_name=legacy-tempest-dsvm-neutron-full-… - reported bug - https://bugs.launchpad.net/devstack/+bug/1858666 [2] https://review.opendev.org/#/c/546765/ -gmann

1 1

[tripleo] tripleo-operator-ansible start and request for input
by Alex Schultz 09 Jan '20

09 Jan '20

[Hello folks, I've begun the basic start of the tripleo-operator-ansible collection work[0]. At the start of this work, I've chosen the undercloud installation[1] as the first role to use to figure out how we the end user's to consume these roles. I wanted to bring up this initial implementation so that we can discuss how folks will include these roles. The initial implementation is a wrapper around the tripleoclient command as run via openstackclient. This means that the 'tripleo-undercloud' role provides implementations for 'openstack undercloud backup', 'openstack undercloud install', and 'openstack undercloud upgrade'. In terms of naming conventions, I'm proposing that we would name the roles "tripleo-<command-base>" with the last part of the command action being an "action". Examples: "openstack undercloud *" -> role: tripleo-undercloud action: (backup|install|upgrade) "openstack undercloud minion *" -> role: tripleo-undercloud-minion action: (install|upgrade) "openstack overcloud *" -> role: tripleo-overcloud action: (deploy|delete|export) "openstack overcloud node *" -> role: tripleo-overcloud-node action: (import|introspect|provision|unprovision) In terms of end user interface, I've got two proposals out in terms of possible implementations. Tasks from method: The initial commit propose that we would require the end user to use an include_role/tasks_from call to perform the desired action. For example: - hosts: undercloud gather_facts: true tasks: - name: Install undercloud collections: - tripleo.operator import_role: name: tripleo-undercloud tasks_from: install vars: tripleo_undercloud_debug: true Variable switch method: I've also proposed an alternative implementation[2] that would use include_role but require the end user to set a specific variable to change if the role runs 'install', 'backup' or 'upgrade'. With this patch the playbook would look something like: - hosts: undercloud gather_facts: true tasks: - name: Install undercloud collections: - tripleo.operator import_role: name: tripleo-undercloud vars: tripleo_undercloud_action: install tripleo_undercloud_debug: true I would like to solicit feedback on which one of these is the preferred integration method when calling these roles. I have two patches up in tripleo-quickstart-extras to show how these calls could be run. The "Tasks from method" can be viewed here[3]. The "Variable switch method" can be viewed here[4]. I can see pros and cons for both methods. My take would be: Tasks from method: Pros: - action is a bit more explicit - dynamic logic left up to the playbook/consumer. - May not have a 'default' action (as main.yml is empty, though it could be implemented). - tasks_from would be a global implementation across all roles rather than having a changing variable name. Cons: - internal task file names must be known by the consumer (though IMHO this is no different than the variable name + values in the other implementation) - role/action inclusions is not dynamic in the role (it can be in the playbook) Variable switch method: Pros: - inclusion of the role by default runs an install - action can be dynamically changed from the calling playbook via an ansible var - structure of the task files is internal to the role and the user of the role need not know the filenames/structure. Cons: - calling playbook is not explicit in that the action can be switched dynamically (e.g. intentionally or accidentally because it is dynamic) - implementer must know to configure a variable called `tripleo_undercloud_action` to switch between install/backup/upgrade actions - variable names are likely different depending on the role My personal preference might be to use the "Tasks from method" because it would lend itself to the same implementation across all roles and the dynamic logic is left to the playbook rather than internally in the role. For example, we'd end up with something like: - hosts: undercloud gather_facts: true collections: - tripleo.operator tasks: - name: Install undercloud import_role: name: tripleo-undercloud tasks_from: install vars: tripleo_undercloud_debug: true - name: Upload images import_role: name: tripleo-overcloud-images tasks_from: upload vars: tripleo_overcloud_images_debug: true - name: Import nodes import_role: name: tripleo-overcloud-node tasks_from: import vars: tripleo_overcloud_node_debug: true tripleo_overcloud_node_import_file: instack.json - name: Introspect nodes import_role: name: tripleo-overcloud-node tasks_from: introspect vars: tripleo_overcloud_node_debug: true tripleo_overcloud_node_introspect_all_manageable: True tripleo_overcloud_node_introspect_provide: True - name: Overcloud deploy import_role: name: tripleo-overcloud tasks_from: deploy vars: tripleo_overcloud_debug: true tripleo_overcloud_deploy_environment_files: - /home/stack/params.yaml The same general tasks performed via the "Variable switch method" would look something like: - hosts: undercloud gather_facts: true collections: - tripleo.operator tasks: - name: Install undercloud import_role: name: tripleo-undercloud vars: tripleo_undercloud_action: install tripleo_undercloud_debug: true - name: Upload images import_role: name: tripleo-overcloud-images vars: tripleo_overcloud_images_action: upload tripleo_overcloud_images_debug: true - name: Import nodes import_role: name: tripleo-overcloud-node vars: tripleo_overcloud_node_action: import tripleo_overcloud_node_debug: true tripleo_overcloud_node_import_file: instack.json - name: Introspect nodes import_role: name: tripleo-overcloud-node vars: tripleo_overcloud_node_action: introspect tripleo_overcloud_node_debug: true tripleo_overcloud_node_introspect_all_manageable: True tripleo_overcloud_node_introspect_provide: True - name: Overcloud deploy import_role: name: tripleo-overcloud vars: tripleo_overcloud_action: deploy tripleo_overcloud_debug: true tripleo_overcloud_deploy_environment_files: - /home/stack/params.yaml Thoughts? Thanks, -Alex [0] https://blueprints.launchpad.net/tripleo/+spec/tripleo-operator-ansible [1] https://review.opendev.org/#/c/699311/ [2] https://review.opendev.org/#/c/701628/ [3] https://review.opendev.org/#/c/701034/ [4] https://review.opendev.org/#/c/701628/

7 7

[infra] Retire openstack/js-openstack-lib repository
by Andreas Jaeger 09 Jan '20

09 Jan '20

The js-openstack-lib repository is orphaned and has not seen any real merges or contributions since February 2017, I propose to retire it. I'll send retirement changes using topic retire-js-openstack-lib, Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

5 10

[largescale-sig] Meeting summary and next actions
by Thierry Carrez 09 Jan '20

09 Jan '20

Hi everyone, The Large Scale SIG held a meeting earlier today. You can access the summary and logs of the meeting at: http://eavesdrop.openstack.org/meetings/large_scale_sig/2019/large_scale_si… This meeting was focused on immediate next steps on the two initial goals for the SIG. For the "Scaling within one cluster, and instrumentation of the bottlenecks" goal, after the holidays we will collect user stories of what happens (or what breaks first) as you scale up single clusters. We will also produce a first RFC draft for an oslo.metric blueprint, and learn more about the "Golden signals" concept. Standing TODOs: - all prepare a short description of what happens (what breaks first) when scaling up a single cluster - ttx to prepare etherpad and send ML thread asking for user scaling stories, to be posted after the end-of-year holidays - masahito to produce first draft for the oslo.metric blueprint - all learn more about golden signals concept as described in https://landing.google.com/sre/book.html For the "Document large scale configuration and tips &tricks" goal we will start collecting relevant articles and blogposts. We agreed that in order to properly document large scale configuration defaults, we should probably both patch existing docs and create new documentation. Standing TODOs: - all add links to relevant articles around large scale openstack (if you find any) to the etherpad - oneswig to follow up with Scientific community to find such articles - amorin to start a thread on documenting configuration defaults for large scale, introduce the "mixture of both" tactic The next meeting will happen on January 15, at 9:00 UTC on #openstack-meeting. Cheers, -- Thierry Carrez (ttx)

3 4

[scientific][www] Unable to download OpenStack for Scientific Research book
by Pierre Riteau 09 Jan '20

09 Jan '20

Hello, I tried to download the book at https://www.openstack.org/science/ but the link doesn't work. Could this please be fixed? I looked on openstack.org for a contact address, but couldn't find one. Please let me know if there is a specific address I should use next time. Thanks, Pierre

2 2

[tripleo] Use Podman 1.6 in CI
by Luke Short 09 Jan '20

09 Jan '20

Hey folks, We have been running into a situation where an older version of Podman is used in CI that has consistent failures. It has problems deleting storage associated with a container. A possible workaround (originally created by Damien) can be found here [1]. A few of us been in talks with the Podman team about this problem and have tested with a newer version of it (1.6.4, to be exact) and found that it is no longer an issue. The most ideal situation is to simply use this newer version of Podman instead of adding hacky workarounds that we will soon revert. However, I am unsure about how we would go about doing this upstream. RHEL will soon get an updated Podman version but CentOS always lags behind. Even CentOS 8 Stream does not contain the newer version [2]. The question/ask I have is can we ship/use a newer version of Podman in our upstream CI? Or should we continue our efforts on making a workaround? 1. https://review.opendev.org/#/c/698999/ 2. http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/Packages/ Sincerely, Luke Short

5 6

[Multi-Arch SIG] summary and actions from last meeting
by Rico Lin 09 Jan '20

09 Jan '20

Hi all Thanks to all who sign up and help to form Multi-Arch SIG We hosted our two initial meetings this week [1] and both successful. And for who cares about multi-arch (for example like ARM support in community), feel free to join our future meetings [2]. Here are some actions from this week's meetings: * Create StoryBoard for Multi-Arch SIG (ricolin) * Build multi-arch SIG repo (ricolin) * Collect update ppc64le actions and resources in community if see any (mrda) * Help with documentations once Multi-Arch SIG repo is ready (jeremyfreudberg) * Update governance-sigs to make a more clear description for Multi-Arch SIG (jeremyfreudberg) There are two docs. ideas `oh, on arm64 you need to do XYZ in other way - here is how and why` and `use cases, who, and issues they had`. Both of them seem like great docs. to start with. So that I assume will be something this SIG will try to work on as one of our first step goals. We need more people to help and more resource in CI as well. There's a lot of WIP resources and CI jobs in our community and all of them are collected in our etherpad [3] now. Feel free to update that etherpad and also sign you or your organization's name on it. Please join us:) Once we have our StoryBoard ready, we should be able to create tasks on it so everyone can create and track tasks like CI job, documentations, etc. last but not least, we are looking for people to nominate or volunteer for chair roles (which can be multiple). There are some really experienced community members been nominated and I will check with them if willing to take the role. On the other hand, I'm volunteering to apply for one of SIG chair seats and help to build this SIG, but happy to give it to others if we can have more people sign up for that role:) So let me know if you're interested. [1] http://eavesdrop.openstack.org/meetings/multi_arch/2020/ [2] http://eavesdrop.openstack.org/#Multi-Arch_SIG_Meeting [3] https://etherpad.openstack.org/p/Multi-arch -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[cinder] ussuri virtual mid-cycle poll
by Brian Rosmaita 09 Jan '20

09 Jan '20

As determined at the virtual PTG (which seems like it happened only a few weeks ago), we'll be doing a two-phase virtual mid-cycle, meeting for two hours the week of 20 January (before the spec freeze) and again around the week of 16 March (the Cinder new feature status checkpoint). There's a poll up to determine a suitable time for the first virtual mid-cycle meeting: https://doodle.com/poll/n3tmq8ep43dyi7tv Please fill out the poll as soon as you can. If all the times are horrible for you, please suggest an alternative in a comment on the poll. The poll will close at 23:59 UTC on Saturday 11 January. (I know it's soon, but that way we'll have time to make adjustments if necessary.) cheers, brian

1 0

[all][infra] Compressed job log artifacts not loading in browser
by Clark Boylan 08 Jan '20

08 Jan '20

Over the holidays the infra team noticed that some of our release artifacts were in the wrong file format. On further investigation we discovered the reason for this was some swift implementations were inflating compressed tarballs when retrieved by clients not setting accept-encoding: gzip. We then ended up with tar files when we expected .tar.gz format files. This behavior seems to be controlled by the content-encoding we set on object upload. If we tell swift that the object is a gzip'd file on upload then the webservers helpfully inflate them when a client retrieves them. In order to fix our release artifacts we have updated our swift upload tooling to stop setting content-type on gzip files. This forces the swift implementation to return the files in the same format they are uploaded when retrieved. A side effect of this is that any gzip'd files (like testr_results.html.gz) are no longer automatically decompressed for you when you retrieve them. We have fixes up to handle common occurrences of this at https://review.opendev.org/#/c/701578/ and https://review.opendev.org/701282 (note the second case is already handled on OpenDev's Zuul). If you run into other files you expect to be browesable but get compressed instead, the fix is to stop compressing the files explicitly in the job. We will still upload files in compressed form to swift for efficiency but we should operate on these files as if they were uncompressed. Then for files that should be compressed (like .tar.gz files) we can pass them through as is avoiding any format change problems. Clark

2 1

[cliff][docs][requirements] new cliff versions causes docs to fail to build
by Matthew Thode 08 Jan '20

08 Jan '20

Looks like some things changed in the new version that we depended upon and are now causing failures. Exception occurred: File "/home/zuul/src/opendev.org/openstack/python-openstackclient/.tox/docs/lib/python3.6/site-packages/cliff/sphinxext.py", line 245, in _load_app if not issubclass(cliff_app_class, app.App): TypeError: issubclass() arg 1 must be a class -- Matthew Thode

4 6

[Manila] First meeting of 2020
by Tom Barron 08 Jan '20

08 Jan '20

Hey Zorillas! Just a reminder of our first meeting in 2020, 9 January at 1500 UTC on Freenode #openstack-meeting-alt. Feel free to update the agenda [1]. -- Tom [1] https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting

1 0

Compute node NIC bonding for increased instance throughput
by shubjero 08 Jan '20

08 Jan '20

Good day, I have a question for the OpenStack community, hopefully someone can help me out here. Goal ------------------ Provision an NFS instance capable of providing 20Gbps of network throughput to be used by multiple other instances within the same project/network. Background ------------------ We run an OpenStack Stein cluster on Ubuntu 18.04. Our Neutron architecture is using openvswitch and GRE. Our compute nodes have two 10G NIC's and are configured in a layer3+4 LACP to the Top of Rack switch. Observations ------------------ Successfully see 20Gbps of traffic balanced across both slaves in the bond when performing iperf3 tests at the *baremetal/os/ubuntu* layer with two other compute nodes as iperf3 clients. Problem ------------------ We are unable to achieve 20Gbps at the instance level. We have tried multiple iperf3 connections from multiple other instances on different compute nodes and we are only able to reach 10Gbps and notice that traffic is not utilizing both slaves in the bond. One slave gets all of the traffic while the other slave sits basically idle. I have some configuration output here: http://paste.openstack.org/show/QdQq76q6VI1XN5tLW0xH/ Any help would be appreciated! Jared Baker Cloud Architect, Ontario Institute for Cancer Research

2 1

Re: OIDC/OAuth2 token introspection in Keystone
by Nikolla, Kristi 08 Jan '20

08 Jan '20

There is an patch to improve the documentation for using the CLI with OIDC, but it hasn't merged yet. See here https://review.opendev.org/#/c/693838 Keystoneauth has plugins in place for authenticating with the OIDC IdP in multiple ways, including using an access token, see here https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/identit… Best, Kristi On Jan 8, 2020, at 10:31 AM, mcarpene <m.carpen(a)cineca.it<mailto:m.carpen@cineca.it>> wrote: Many thanks Nikolla, I was able to federate using OIDC IdP via the dashboard. I meant the problem is authenticating via CLI providing a OIDC token via command line, but maybe you already answered to my request. BR, Michele On 08/01/20 16:28, wrote: Hi Michele, We just approved a feature request for that [0], however it was merged to backlog, meaning no specific timeline for it being implemented yet. With the current implementation, you can use OAuth 2.0 Access Tokens with Keystone, however the token introspection endpoint will be used, therefore only the claims contained in the access token will be returned. I am assuming your question is with regards to the userinfo endpoint and OIDC claims, which we do not currently support. [0]. https://review.opendev.org/#/c/373983/ On Jan 8, 2020, at 8:01 AM, mcarpene <m.carpen(a)cineca.it<mailto:m.carpen@cineca.it>> wrote: Hi all, my question is: could OS Keystone support OIDC/OAuth2 token introspection/validation. I mean for example executing a swift command via CLI adding a OIDC token bearer as a parameter to the swift command. In this case Keystone should validate the OIDC token towards and external IdP (using introspection endpoint/protocol for oidc). Is this currently supported, or eventually would be done in the near future? thanks Michele -- Michele Carpené SuperComputing Applications and Innovation Department CINECA - via Magnanelli, 6/3, 40033 Casalecchio di Reno (Bologna) - ITALY Tel: +39 051 6171730 Fax: +39 051 6132198 Skype: mcarpene http://www.hpc.cineca.it/ -- Michele Carpené SuperComputing Applications and Innovation Department CINECA - via Magnanelli, 6/3, 40033 Casalecchio di Reno (Bologna) - ITALY Tel: +39 051 6171730 Fax: +39 051 6132198 Skype: mcarpene http://www.hpc.cineca.it/

1 0

OIDC/OAuth2 token introspection in Keystone
by mcarpene 08 Jan '20

08 Jan '20

Hi all, my question is: could OS Keystone support OIDC/OAuth2 token introspection/validation. I mean for example executing a swift command via CLI adding a OIDC token bearer as a parameter to the swift command. In this case Keystone should validate the OIDC token towards and external IdP (using introspection endpoint/protocol for oidc). Is this currently supported, or eventually would be done in the near future? thanks Michele -- Michele Carpené SuperComputing Applications and Innovation Department CINECA - via Magnanelli, 6/3, 40033 Casalecchio di Reno (Bologna) - ITALY Tel: +39 051 6171730 Fax: +39 051 6132198 Skype: mcarpene http://www.hpc.cineca.it/

2 1

[charms][watcher] OpenStack Watcher Charm
by Stamatis Katsaounis 08 Jan '20

08 Jan '20

Hi all, Purpose of this email is to let you know that we released an unofficial charm of OpenStack Watcher [1]. This charm gave us the opportunity to deploy OpenStack Watcher to our charmed OpenStack deployment. After seeing value in it, we decided to publish it through GRNET GitHub Organization account for several reasons. First of all, we would love to get feedback on it as it is our first try on creating an OpenStack reactive charm. Secondly, we would be glad to see other OpenStack operators deploy Watcher and share with us knowledge on the project and possible use cases. Finally, it would be ideal to come up with an official OpenStack Watcher charm repository under charmers umbrella. By doing this, another OpenStack project is going to be available not only for Train version but for any future version of OpenStack. Most important, the CI tests are going to ensure that the code is not broken and persuade other operators to use it. Before closing my email, I would like to give some insight on the architecture of the code base and the deployment process. To begin with, charm-watcher is based on other reactive OpenStack charms. During its deployment Barbican, Designate, Octavia and other charms' code bases were counseled. Furthermore, the structure is the same as any official OpenStack charm, of course without functional tests, which is something we cannot provide. Speaking about the deployment process, apart from having a basic charmed OpenStack deployment, operator has to change two tiny configuration options on Nova cloud controller and Cinder. As explained in the Watcher configuration guide, special care has to be done with Oslo notifications for Nova and Cinder [2]. In order to achieve that in charmed OpenStack some issues were met and solved with the following patches [3], [4], [5], [6]. With these patches, operator can set the extra Oslo configuration and this is the only extra configuration needs to take place. Finally, with [7] Keystone charm can accept a relation with Watcher charm instead of ignoring it. To be able to deploy GRNET Watcher charm on Train, patches [3], [4], [5] and [7] have to be back-ported to stable/19.10 branch but that will require the approval of charmers team. Please let me know if such an option is available and in that case I am going to open the relevant patches. Furthermore, if you think that it could be a good option to create a spec and then introduce an official Watcher charm, I would love to help on that. I wish all a happy new year and I am looking forward to your response and possible feedback. PS. If we could have an Ubuntu package for watcher-dashboard [8] like octavia-dashboard [9] we would release a charm for it as well. Best regards, Stamatis Katsaounis [1] https://github.com/grnet/charm-watcher [2] https://docs.openstack.org/watcher/latest/configuration/configuring.html#co… [3] https://review.opendev.org/#/c/699079/ [4] https://review.opendev.org/#/c/699081/ [5] https://review.opendev.org/#/c/699657/ [6] https://github.com/juju/charm-helpers/pull/405 [7] https://review.opendev.org/#/c/699082/ [8] https://github.com/openstack/watcher-dashboard [9] https://launchpad.net/ubuntu/+source/octavia-dashboard -- [cid:part10.101270FA.EDBB3A4A@admin.grnet.gr] Stamatis Katsaounis DevOps Engineer t :(+30) 210 7471130 (ext. 483) f : + 30 210 7474490 GRNET | Networking Research and Education www.grnet.gr<http://www.grnet.gr> | 7, Kifisias Av., 115 23, Athens [Facebook icon]<https://www.facebook.com/grnet.gr/> [Twitter icon] <https://twitter.com/grnet_gr> [Youtube icon] <https://www.youtube.com/user/EDETvideos> [LinkedIn icon] <https://www.linkedin.com/company/55267/> [Instagram icon] <https://www.instagram.com/grnet.gr/>

1 0

[neutron][ironic] dynamic routing protocol status for routed network
by 양유석 08 Jan '20

08 Jan '20

Hi, For ironic flat provider network, I found it's hard to scale manually (for many racks). So I'm trying to use routed network for the purpose. One blur thing for routed network is how we can handle segment connectivity. >From reference (https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html) there is future work about dynamic routing protocol though, I could not find any hints for the functionality. How do you guys using routed network handle the segments' connectivity? Is there any project to speak subnet info via BGP? Thanks in advance.

1 0

VM boot volume disappears from compute's multipath Daemon when NetApp controller is placed offline
by Ahmed ZAKY 07 Jan '20

07 Jan '20

I have a setup where each VM gets assigned two vDisks, one encrypted boot volume and another storage volume. Storage used is NetApp (tripleo-netapp). With two controllers on NetApp side working in active/ active mode. My test case goes as follows: - I stop one of the active controllers. - I stop one of my VMs using OpenStack server stop - I then start my VM one more time using OpenStack server start. - VM fails to start. Here're my findings, hope someone would help if they can explain me the behaviour seen below: My VM: vel1bgw01-MCM2, it is running on compute overcloud-sriovperformancecompute-3.localdomain [root@overcloud-controller-0 (vel1asbc01) cbis-admin]# openstack server show vel1bgw01-MCM2 +--------------------------------------+------------------------------------------------------------------------------------------------------------+ | Field | Value | +--------------------------------------+------------------------------------------------------------------------------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | zone1 | | OS-EXT-SRV-ATTR:host | overcloud-sriovperformancecompute-3.localdomain | | OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-sriovperformancecompute-3.localdomain | | OS-EXT-SRV-ATTR:instance_name | instance-00000 <+4400000>e93 | | OS-EXT-STS:power_state | Running | | OS-EXT-STS:task_state | None | | OS-EXT-STS:vm_state | active | | OS-SRV-USG:launched_at | 2019-12-18T15:49:37.000000 <+4437000000> | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | SBC01_MGW01_TIPC=192.168.48.22 <+441921684822>; SBC01_MGW01_DATAPATH_MATE=192.168.16.11 <+441921681611>; SBC01_MGW01_DATAPATH=192.168.32.8 <+44192168328> | | config_drive | True | | created | 2019-12-18T15:49:16Z | | flavor | SBC_MCM (asbc_mcm) | | hostId | 7886 <+447886>df0f7a3d4e131304 <+44131304>a8eb860e6a704c5fda2a7ed751b544ff2bf5 | | id | 5c70a984-89 <+4498489>a9-44ce-876d-9e2e568eb819 | | image | | | key_name | CBAM-b5fd59a066e8450 <+448450>ca9f104a69da5a043-Keypair | | name | vel1bgw01-MCM2 | | os-extended-volumes:volumes_attached | [{u'id': u'717e5744-4786-42 <+445744478642>dc-9e3e-3c5e6994 <+446994>c482'}, {u'id': u'd6cf0cf9-36d1-4b 62-86 <+446286>b4-faa4a6642166 <+446642166>'}] | | progress | 0 | | project_id | 41777 <+4441777>c6f1e7b4f8d8fd76b5e0f67e5e8 | | properties | | | security_groups | [{u'name': u'vel1bgw01-TIPC-Security-Group'}] | | status | ACTIVE | | updated | 2020-01-07T17:18:32Z | | user_id | be13deba85794016 <+4485794016>a00fec9d18c5d7cf | +--------------------------------------+------------------------------------------------------------------------------------------------------------+ *It is mapped to the following vDisks (seen using virsh list on compute-3)*: - dm-uuid-mpath-3600 <+443600>a098000 <+44098000>d9818 <+449818>b0000185 <+440000185>c5dfa0714 <+440714> è Boot Volume - dm-uuid-mpath-3600 <+443600>a098000 <+44098000>d9818 <+449818>b 000018565 <+44000018565>dfa069e è Storage volume <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source dev='/dev/disk/by-id/dm-uuid-mpath-3600 <+443600>a098000 <+44098000> d9818 <+449818>b0000185 <+440000185>c5dfa0714 <+440714>'/> <backingStore/> <target dev='vda' bus='virtio'/> <serial>717e5744-4786-42 <+445744478642>dc-9e3e-3c5e6994 <+446994> c482</serial> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000 <+440000>' bus='0x00' slot='0x04' function='0x0'/> </disk> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source dev='/dev/disk/by-id/dm-uuid-mpath-3600 <+443600>a098000 <+44098000> d9818 <+449818>b000018565 <+44000018565>dfa069e'/> <backingStore/> <target dev='vdb' bus='virtio'/> <serial>d6cf0cf9-36d1-4b62-86 <+446286>b4-faa4a6642166 <+446642166></serial> <alias name='virtio-disk1'/> <address type='pci' domain='0x0000 <+440000>' bus='0x00' slot='0x08' function='0x0'/> </disk> Name: crypt-dm-uuid-mpath-3600 <+443600>a098000 <+44098000>d9818 <+449818>b 0000185 <+440000185>c5dfa0714 <+440714> State: ACTIVE Read Ahead: 256 Tables present: LIVE Open count: 1 Event number: 0 Major, minor: 253, 5 Number of targets: 1 UUID: CRYPT-LUKS1-769 <+441769>cc20bc5af469c8c9075 <+449075> a2a6fc4aa0-crypt-dm-uuid-mpath-*3600 <+443600>a098000 <+44098000>d9818 <+449818>b0000185 <+440000185>c5dfa0714 <+440714>* Name: *mpathpy* State: ACTIVE Read Ahead: 256 Tables present: LIVE Open count: 1 Event number: 32 Major, minor: 253, *4* Number of targets: 1 UUID: mpath-*3600 <+443600>a098000 <+44098000>d9818 <+449818>b0000185 <+440000185>c5dfa0714 <+440714>* Name: crypt-dm-uuid-mpath-3600 <+443600>a098000 <+44098000>d9818 <+449818>b 000018565 <+44000018565>dfa069e State: ACTIVE Read Ahead: 256 Tables present: LIVE Open count: 1 Event number: 0 Major, minor: 253, 7 Number of targets: 1 UUID: CRYPT-LUKS1-4015 <+4414015>c585a0df4074821 <+444074821> ca312c4caacca-crypt-dm-uuid-mpath-*3600 <+443600>a098000 <+44098000>d9818 <+449818>b000018565 <+44000018565>dfa069e* Name: *mpathpz* State: ACTIVE Read Ahead: 256 Tables present: LIVE Open count: 1 Event number: 28 Major, minor: 253, *6* Number of targets: 1 UUID: mpath-*3600 <+443600>a098000 <+44098000>d9818 <+449818>b000018565 <+44000018565>dfa069e* This means boot volume is represented by dm-4 while storage volume is represented by dm-6 Dumping the multipath daemon on the controller shows that at a steady running state both DMs are accounted for (see below). multipathd> show maps name sysfs uuid *mpathpy dm-4 3600 <+4443600>a098000 <+44098000>d9818 <+449818>b0000185 <+440000185>c5dfa0714 <+440714>* *mpathpz dm-6 3600 <+4463600>a098000 <+44098000>d9818 <+449818>b000018565 <+44000018565>dfa069e* mpathqi dm-12 3600 <+44123600>a098000 <+44098000>d9818 <+449818>b000018 <+44000018>df5dfafd40 mpathqj dm-13 3600 <+44133600>a098000 <+44098000>d9818 <+449818>b000018 <+44000018>de5dfafd10 mpathpw dm-0 3600 <+4403600>a098000 <+44098000>d9818 <+449818>b000018425 <+44000018425>dfa059f mpathpx dm-1 3600 <+4413600>a098000 <+44098000>d9818 <+449818>b0000184 <+440000184>c5dfa05fc mpathqk dm-16 3600 <+44163600>a098000 <+44098000>d9818 <+449818>b000018 <+44000018>eb5dfafe80 mpathql dm-17 3600 <+44173600>a098000 <+44098000>d9818 <+449818>b000018 <+44000018>e95dfafe26 mpathqh dm-9 3600 <+4493600>a098000 <+44098000>d9818 <+449818>b000018 <+44000018>c65dfafa91 These vDisks are mapped to the following multipaths: multipathd> show topology mpathpy (3600 <+443600>a098000 <+44098000>d9818 <+449818>b0000185 <+440000185>c5dfa0714) <+440714> dm-4 NETAPP ,INF-01-00 <+440100> size=21G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 rdac' wp=rw |-+- policy='service-time 0' prio=14 status=active | |- 30:0:0:82 sdm 8:192 active ready running | `- 32:0:0:82 sdk 8:160 active ready running `-+- policy='service-time 0' prio=0 status=enabled |- 33:0:0:82 sdn 8:208 failed faulty running `- 31:0:0:82 sdl 8:176 failed faulty running mpathpz (3600 <+443600>a098000 <+44098000>d9818 <+449818>b000018565 <+44000018565>dfa069e) dm-6 NETAPP ,INF-01-00 <+440100> size=10G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 rdac' wp=rw |-+- policy='service-time 0' prio=14 status=active | |- 30:0:0:229 sdr 65:16 active ready running | `- 32:0:0:229 sdp 8:240 active ready running `-+- policy='service-time 0' prio=0 status=enabled |- 31:0:0:229 sdo 8:224 failed faulty running `- 33:0:0:229 sdq 65:0 failed faulty running Now, it starts getting very interesting, if I shutdown controller-A from NetApp side, dm-4 disappears but dm-6 is still running while detecting the active path is controller B while standby path is controller-A which now is displayed as failed multipathd> show topology mpathpz (3600 <+443600>a098000 <+44098000>d9818 <+449818>b000018565 <+44000018565>dfa069e) dm-6 NETAPP ,INF-01-00 <+440100> size=10G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 rdac' wp=rw |-+- policy='service-time 0' prio=0 status=enabled | |- 30:0:0:229 sdr 65:16 failed faulty running | `- 32:0:0:229 sdp 8:240 failed faulty running `-+- policy='service-time 0' prio=11 status=active |- 31:0:0:229 sdo 8:224 active ready running `- 33:0:0:229 sdq 65:0 active ready running multipathd> show maps name sysfs uuid *mpathpz dm-6 3600 <+4463600>a098000 <+44098000>d9818 <+449818>b000018565 <+44000018565>dfa069e* mpathqi dm-12 3600 <+44123600>a098000 <+44098000>d9818 <+449818>b000018 <+44000018>df5dfafd40 mpathqj dm-13 3600 <+44133600>a098000 <+44098000>d9818 <+449818>b000018 <+44000018>de5dfafd10 mpathpw dm-0 3600 <+4403600>a098000 <+44098000>d9818 <+449818>b000018425 <+44000018425>dfa059f mpathpx dm-1 3600 <+4413600>a098000 <+44098000>d9818 <+449818>b0000184 <+440000184>c5dfa05fc mpathqk dm-16 3600 <+44163600>a098000 <+44098000>d9818 <+449818>b000018 <+44000018>eb5dfafe80 mpathql dm-17 3600 <+44173600>a098000 <+44098000>d9818 <+449818>b000018 <+44000018>e95dfafe26 mpathqg dm-8 3600 <+4483600>a098000 <+44098000>d9818 <+449818>b000018 <+44000018>c75dfafac0 mpathqh dm-9 3600 <+4493600>a098000 <+44098000>d9818 <+449818>b000018 <+44000018>c65dfafa91 If I restore Controller-A into service from NetApp side while fail only the path to controller A from multipathd everything works fine, dm-4 is still present and the VM can be put into service. multipathd> fail path sdk ok multipathd> multipathd> fail path sdm ok mpathpy (3600 <+443600>a098000 <+44098000>d9818 <+449818>b0000185 <+440000185>c5dfa0714) <+440714> dm-4 NETAPP ,INF-01-00 <+440100> size=21G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 rdac' wp=rw |-+- policy='service-time 0' prio=0 status=enabled | |- 32:0:0:82 sdk 8:160 failed faulty running | `- 30:0:0:82 sdm 8:192 failed faulty running `-+- policy='service-time 0' prio=9 status=active |- 31:0:0:82 sdl 8:176 active ready running `- 33:0:0:82 sdn 8:208 active ready running multipathd> reinstate path sdk ok multipathd> multipathd> reinstate path sdm ok mpathpy (3600 <+443600>a098000 <+44098000>d9818 <+449818>b0000185 <+440000185>c5dfa0714) <+440714> dm-4 NETAPP ,INF-01-00 <+440100> size=21G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 rdac' wp=rw |-+- policy='service-time 0' prio=14 status=active | |- 32:0:0:82 sdk 8:160 active ready running | `- 30:0:0:82 sdm 8:192 active ready running `-+- policy='service-time 0' prio=9 status=enabled |- 31:0:0:82 sdl 8:176 active ready running `- 33:0:0:82 sdn 8:208 active ready running It is observed in the working case, the storage volume disappears (which seems normal), also the instance totally vanishes from the virsh list and no trace can be found at the KVM level if we run ps -def | grep fd | grep <instance_ID>. However, the boot volume is always present in the multipathd records when we stop the VM at normal conditions without stopping NetApp controller. Any ideas? Kind regards, Ahmed

1 0

[infra] Retire x/dox
by Andreas Jaeger 07 Jan '20

07 Jan '20

The x/dox repo is unused, let's retire it. I'll put up changes with topic "retire-dox", Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

1 0

[cinder] first meeting of 2020 tomorrow (8 January)
by Brian Rosmaita 07 Jan '20

07 Jan '20

Just wanted to send a quick reminder that the first Cinder team meeting of 2020 well be held tomorrow (8 January) on the usual day (Wednesday) at the usual time (1400 UTC) and in the usual place (#openstack-meeting-4). https://etherpad.openstack.org/p/cinder-ussuri-meetings See you there! brian

1 0

IBM z/VM CI is planning to migrate new environment
by Dong JV Ma 07 Jan '20

07 Jan '20

Hello, Due to the hardware issues, the IBM z/VM CI system [1] is planning to migrate to the new hardware in the next few months, the planning time will be in 3 months. We will do following changes with IBM z/VM CI environment: 1. Migrate the IBM z/VM CI to new hardware 2. Upgrade IBM z/VM CI from python2 to python3 During this time, IBM z/VM CI will not stable, please ignore the IBM z/VM CI failures. For any questions feel free to reach out to me(Dong Ma). [1] https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_z/VM_CI Thanks & Best Regards! Dong Ma (马冬) LinuxONE IaaS Infra & CI/CD, China Systems Lab E-mail: madongma(a)cn.ibm.com IRC: larainema Address: 2/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC

3 2

[tc] Expediting patch to unblock governance's CI
by Jean-Philippe Evrard 07 Jan '20

07 Jan '20

Hello everyone, Our governance repo's testing is currently failing, and I have patches to fix it (short term [1] and long term). Because it's been a while it's in there (and got recently updated), I will now merge the short term fix, even if we don't have enough votes (nor time). It will unblock many patches and prevent useless rechecks, at the expense of being out of policy. I will gladly take the blame, should there be any. Regards, JP [1] https://review.opendev.org/#/c/700422/

1 0

[kolla] neutron-l3-agent namespace NAT table not working?
by Jon Masters 07 Jan '20

07 Jan '20

Hi there, I've got a weird problem with the neutron-l3-agent container on my deployment. It comes up, sets up the iptables rules in the qrouter namespace (and I can see these using "ip netns...") but traffic isn't having DNAT or SNAT applied. What's most strange is that manually adding a LOG jump target to the iptables nat PRE/POSTROUTING chains (after enabling nf logging sent to the host kernel, confirmed that works) doesn't result in any log entries. It's as if the nat table isn't being applied at all for any packets traversing the qrouter namespace. This is driving me crazy :) Anyone got some quick suggestions? (assume I tried the obvious stuff). Jon. -- Computer Architect

8 19

[Scientific] Scientific SIG meeting July 7th 2100 UTC
by Martial Michel 07 Jan '20

07 Jan '20

The first meeting of the new year at 2100 UTC on Tuesday, July 7th. Mostly an Any Other Business meeting to get its participants back from the holidays as reflected by the agenda :) https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_7th_2020

1 0

[all] Is there something I can do to get a simple fix done?
by Neil Jerram 07 Jan '20

07 Jan '20

I'm struggling to say this positively, but... it feels like OpenStack promotes refactoring work that will likely break something, but is very slow when a corresponding fix is needed, even when the fix is trivial. Is there something we could do to get fixes done more quickly when needed? My case in point: my team's networking plugin (networking-calico) does not do "extraroutes", and so was broken by some python-openstackclient change (possibly [1]) that wrongly assumed that. I posted a fix [2] that passed CI on 21st October, and asked for it to be reviewed on IRC a couple of days later. Édouard Thuleau posted a similar fix [3] on 4th December, and we agreed that his was better, so I abandoned mine. His fix attracted a +2 on 11th December, but has been sitting like that ever since. It's a fix that I would expect to be simple to review, so I wonder if there's something else we could have done here to get this moving? Or if there is a systemic problem here that deserves discussion? [1] https://opendev.org/openstack/python-openstackclient/commit/c44f26eb7e41c28… [2] https://review.opendev.org/#/c/685312/ [3] https://review.opendev.org/#/c/697240/ Many thanks, Neil

2 1

[all][neutron][neutron-vpnaas] Maintainers needed
by Slawek Kaplonski 06 Jan '20

06 Jan '20

Hi, Over the past couple of cycles we have noticed that new contributions and maintenance efforts for neutron-vpnaas were almost non existent. This impacts patches for bug fixes, new features and reviews. The Neutron core team is trying to at least keep the CI of this project healthy, but we don’t have enough knowledge about the details of the neutron-vpnaas code base to review more complex patches. During the PTG in Shanghai we discussed that with operators and TC members during the forum session [1] and later within the Neutron team during the PTG session [2]. During these discussions, with the help of operators and TC members, we reached the conclusion that we need to have someone responsible for maintaining project. This doesn’t mean that the maintainer needs to spend full time working on this project. Rather, we need someone to be the contact person for the project, who takes care of the project’s CI and review patches. Of course that’s only a minimal requirement. If the new maintainer works on new features for the project, it’s even better :) If we don’t have any new maintainer(s) before milestone Ussuri-2, which is Feb 10 - Feb 14 according to [3], we will need to mark neutron-vpnaas as deprecated and in “V” cycle we will propose to move the project from the Neutron stadium, hosted in the “openstack/“ namespace, to the unofficial projects hosted in the “x/“ namespace. So if You are using this project now, or if You have customers who are using it, please consider the possibility of maintaining it. Otherwise, please be aware that it is highly possible that the project will be deprecated and moved out from the official OpenStack projects. [1] https://etherpad.openstack.org/p/PVG-Neutron-stadium-projects-the-path-forw… [2] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored - Lines 379-421 [3] https://releases.openstack.org/ussuri/schedule.html -- Slawek Kaplonski Senior software engineer Red Hat

1 1

[neutron] Bug deputy report - week of 30th December
by Slawek Kaplonski 06 Jan '20

06 Jan '20

Hi, I was on bug deputy last week. It was pretty quiet week with only few bugs reported. Below is my summary of it. Critical: https://bugs.launchpad.net/neutron/+bug/1858260 - Upstream CI neutron-tempest-plugin-* fails - I marked it as critical as it cause gate failures, I will have to take a look at it closer next week, Medium: https://bugs.launchpad.net/neutron/+bug/1858086 - qrouter's local link route cannot be restored - confirmed by me on local env, it would be good if someone from L3 subteam can take a look at it, Undecided and others: https://bugs.launchpad.net/neutron/+bug/1858377 - probably bug for openstackclient rather than neutron, but I would like to wait for confirmation from bug reporter first, https://bugs.launchpad.net/neutron/+bug/1858262 - duplicate of other bug, https://bugs.launchpad.net/neutron/+bug/1858419 - docs bug to update config options for large scale deployments, see http://lists.openstack.org/pipermail/openstack-discuss/2020-January/011820.… for details — Slawek Kaplonski Senior software engineer Red Hat

1 0

[oslo][kolla][requirements][release][infra] Hit by an old, fixed bug
by Radosław Piliszek 06 Jan '20

06 Jan '20

Hi Folks, as the subject goes, my installation has been hit by an old bug: https://bugs.launchpad.net/oslo.messaging/+bug/1828841 (bug details not important, linked here for background) I am using Stein, deployed with recent Kolla-built source-based images (with only slight modifications compared to vanilla ones). Kolla's procedure for building source-based images considers upper constraints, which, unfortunately, turned out to be lagging behind a few releases w.r.t. oslo.messaging at least. The fix was in 9.7.0 released on May 21, u-c still point to 9.5.0 from Feb 26 and the latest of Stein is 9.8.0 from Jul 18. It seems oslo.messaging is missing from the automatic updates that bot proposes: https://review.opendev.org/#/q/owner:%22OpenStack+Proposal+Bot%22+project:o… Per: https://opendev.org/openstack/releases/src/branch/master/doc/source/referen… this upper-constraint proposal should be happening for all releases. I would be glad if someone investigated why it happens(/ed) and audited whether other OpenStack projects don't need updating as well to avoid running on old deps when new are awaiting for months. :-) Please note this might apply to other branches as well. PS: for some reason oslo.messaging Stein release notes ( https://docs.openstack.org/releasenotes/oslo.messaging/stein.html ) are stuck at 9.5.0 as well, this could be right (I did not inspect the sources) but I am adding this in PS so you have more things to correlate if they need be. -yoctozepto

5 7

[kolla] Adding Dincer Celik to kolla-core and kolla-ansible-core
by Mark Goddard 06 Jan '20

06 Jan '20

Hi, I recently proposed to the existing cores that we add Dincer Celik (osmanlicilegi) to the kolla-core and kolla-ansible-core groups and we agreed to go ahead. Thanks for your contribution to the project so far Dincer, I'm glad to have you on the team. Cheers, Mark

1 0

[neutron][nova][cinder][glance][largescale-sig] Documentation update for large-scale
by Arnaud Morin 06 Jan '20

06 Jan '20

Hey all, With the new "Large scale SIG", we were thinking about updating documentation to help operators setting up large deployments. To do so, we would like to propose, at least, some documentation changes to identify options that affect large scale. The plan is to have a small note on some options and eventually a link to a specific page for large scale (see attachments). I know that nova started working on collecting those parameters here: https://bugs.launchpad.net/nova/+bug/1838819 Do you know if something similar exists on other projects? Moreover, we would like to collect more parameters that could be tuned on a large scale deployment, for every project. So, if you have any, feel free to answer to this mail or add some info on the following etherpad: https://etherpad.openstack.org/p/large-scale-sig-documentation Thanks for your help! Regards. The large-scale team. -- Arnaud Morin

2 1

[cloudkitty] Stepping down from PTL
by Luka Peschke 06 Jan '20

06 Jan '20

Hi all, I'm moving to a new position that doesn't involve OpenStack, and won't leave me the required time to be Cloudkitty's PTL. This is why I have to step down from the PTL position. jferrieu will take my position for the end of the U cycle (he's been a major contributor recently), with the help of huats, who's been the Cloudkitty PTL before me, and has been around in the community for a long time. I've been the PTL for two and a half cycles, and I think that it is a good thing for the project to take a new lead, with a new vision. I'm grateful for my experience within the OpenStack community. Thanks, -- Luka Peschke (peschk_l)

3 2

[auto-scaling][self-healing] Discussion to merge two SIG to one
by Rico Lin 06 Jan '20

06 Jan '20

Dear all As we discussed in PTG about merge two SIG to one. I would like to continue the discussion on ML. In PTG, Eric proposes the idea to merge two SIG due to the high overlapping of domains and tasks. I think this is a great idea since, over the last 6 months, most of the discussions in both SIG are overlapped. So I'm onboard with this idea. Here's how I think we can continue this idea: 1. Create new SIG (maybe 'Automation SIG'? feel free to propose name which can cover both interest.) 2. Redirect docs and wiki to new SIG. And rework on index so there will be no confusion 3. Move repos from both SIGs to new SIG 4. Mark auto-scaling SIG and self-healing SIG as inactive. 5. remove auto-scaling SIG and self-healing SIG after a reasonable waiting time Let us know what you think about this. Otherwise, we definitely expect this to happen soon. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

4 7

[meta-sig][multi-arch] propose forming a Multi-arch SIG
by Rico Lin 06 Jan '20

06 Jan '20

Dear all In summit, there's a forum for ARM support [1] in Summit which many people show they're interested in ARM support for OpenStack. And since also we have Linaro shows interest in donating servers to OpenStack infra. It's time for community to think about what we should deal with those ARM servers once we have them in community infrastructure. One thing we should do as a community is to gather people for this topic. So I propose we create a Multi-arch SIG and aim to support ARM architecture as very first step. I had the idea to call it ARM SIG before, but since there might be high overlap knowledge between support ARM 64 and other architectures. I propose we go for Multi-arch instead. This SIG will be a nice place to collect all the documents, gate jobs, and to trace tasks. If you're also interested in that group, please reply to this email, introduce yourself and tell us what you would like the group scope and objectives to be, and what you can contribute to the group. [1] https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24355… -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

11 15

About the use of security groups with neutron ports
by ahmed.zaky.abdallah＠gmail.com 04 Jan '20

04 Jan '20

Hi All, I am trying to wrap my head around something I came across in one of the OpenStack deployments. I am running Telco VNFs one of them is having different VMs using SR-IOV interfaces. On one of my VNFs on Openstack, I defined a wrong IPv6 Gm bearer interface to be exactly the same as the IPv6 Gateway. As I hate re-onboarding, I decided to embark on a journey of changing the IPv6 of the Gm bearer interface manually on the application side, everything went on fine. After two weeks, my customer started complaining about one way RTP flow. The customer was reluctant to blame the operation I carried out because everything worked smooth after my modification. After days of investigation, I remembered that I have port-security enabled and this means AAP “Allowed-Address-Pairs” are defined per vPort (AAP contain the floating IP address of the VM so that the security to allow traffic to and from this VIP). I gave it a try and edited AAP “Allowed-Address-Pairs” to include the correct new IPv6 address. Doing that everything started working fine. The only logical explanation at that time is security group rules are really invoked. Now, I am trying to understand how the iptables are really invoked. I did some digging and it seems like we can control the firewall drivers on two levels: * Nova compute * ML2 plugin I was curious to check nova.conf and it has already the following line: firewall_driver=nova.virt.firewall.NoopFirewallDriver However, checking the ml2 plugin configuration, the following is found: 230 [securitygroup] 231 232 # 233 # From neutron.ml2 234 # 235 236 # Driver for security groups firewall in the L2 agent (string value) 237 #firewall_driver = <None> 238 firewall_driver = openvswitch So, I am jumping to a conclusion that ml2 plugin is the one responsible for enforcing the firewall rules in my case. Have you had a similar experience? Is my assumption correct: If I comment out the ml2 plugin firewall driver then the port security carries no sense at all and security groups won’t be invoked? Cheers, Ahmed

4 4

[stein][cinder][backup][swift] issue
by Ignazio Cassano 03 Jan '20

03 Jan '20

Hello All, I configured openstack stein on centos 7 witch ceph. Cinder works fine and object storage on ceph seems to work fine: I can clreate containers, volume etc ..... I configured cinder backup on swift (but swift is using ceph rados gateway) : backup_driver = cinder.backup.drivers.swift.SwiftBackupDriver swift_catalog_info = object-store:swift:publicURL backup_swift_enable_progress_timer = True #backup_swift_url = http://10.102.184.190:8080/v1/AUTH_ backup_swift_auth_url = http://10.102.184.190:5000/v3 backup_swift_auth = per_user backup_swift_auth_version = 1 backup_swift_user = admin backup_swift_user_domain = default #backup_swift_key = <None> #backup_swift_container = volumebackups backup_swift_object_size = 52428800 #backup_swift_project = <None> #backup_swift_project_domain = <None> backup_swift_retry_attempts = 3 backup_swift_retry_backoff = 2 backup_compression_algorithm = zlib If I run a backup as user admin, it creates a container named "volumebackups". If I run a backup as user demo and I do not specify a container name, it tires to write on volumebackups and gives some errors: ClientException: Container PUT failed: http://10.102.184.190:8080/swift/v1/AUTH_964f343cf5164028a803db91488bdb01/v… 409 Conflict BucketAlreadyExists Does it mean I cannot use the same containers name on differents projects ? My ceph.conf is configured for using keystone: [client.rgw.tst2-osctrl01] rgw_frontends = "civetweb port=10.102.184.190:8080" # Keystone information rgw keystone api version = 3 rgw keystone url = http://10.102.184.190:5000 rgw keystone admin user = admin rgw keystone admin password = password rgw keystone admin domain = default rgw keystone admin project = admin rgw swift account in url = true rgw keystone implicit tenants = true Any help, please ? Best Regards Ignazio

3 4

[openstack-ansible] strange execution delays
by Joe Topjian 03 Jan '20

03 Jan '20

Hello, I don't think this is an OSA issue per-se, but it's happening on infrastructure deployed with OSA. Using both the Rocky and Stein releases of OSA on Ubuntu 18.04, we're running into a strange a strange issue where the run times of Ansible will eventually take longer and longer. Digging into the issue more, we find that it's when Ansible executes a command within a container and the call to "su" triggers the delay. Over time, the delay increases more and more. The same behavior is seen if we SSH into containers. The only workaround we've been able to identify that works is to stop and start the containers. We have not been able to identify a root cause of this, nor any consistency to what containers this will happen on. Has anyone run into this? Thanks, Joe

2 5

Re: openstack-discuss Digest, Vol 15, Issue 1
by Soniya Vyas 02 Jan '20

02 Jan '20

> Message: 4 > Date: Tue, 31 Dec 2019 19:03:22 -0600 > From: Ghanshyam Mann <gmann(a)ghanshyammann.com> > To: "openstack-discuss" <openstack-discuss(a)lists.openstack.org> > Subject: [qa] QA Office hour new timing for 2020 > Message-ID: > <16f5ea0ef6f.1010065b175496.3744470588375359656(a)ghanshyammann.com> > Content-Type: text/plain; charset="UTF-8" > > Hello Everyone, > > We have few members who actively started contribution to QA from India as well as from Europe TZ. > The current office hour time is more convenient for CT and JST only and very difficult for members from India > Europe to join. > > I would like to adjust office hour timing to include all four TZs. To do that someone has to wake up early or stay > late at night :). I gave preference to new members and selected Tuesday 13.30 UTC [1]. which will be an early morning > for me and late-night in Tokyo. > > let me know if any objection or better suggestion. Accordingly, I will make the new time effective from 7th Jan. > > Also cancelling the 1st Jan office hour and wish you all a very happy new year. > > [1] https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=… Thanks a lot to whole QA team and Ghanshyam Mann for considering our timing issues. Looking forward to join QA Office hours meeting. Regards, Soniya Vyas

1 0

[manila] No IRC/Community meeting on 2nd January 2020
by Goutham Pacha Ravi 01 Jan '20

01 Jan '20

Hello Zorillas, Due to the holidays we're expecting multiple community members (myself included) to be unavailable for the weekly IRC meeting tomorrow (2nd January 2020, 15:00 UTC), so we'll skip it. Please add any agenda items to the next meeting (9th January 2020, 15:00 UTC) [1]. Happy New Year, and the rest of your holidays! Thanks, Goutham [1] https://wiki.openstack.org/wiki/Manila/Meetings

1 0

[qa] QA Office hour new timing for 2020
by Ghanshyam Mann 01 Jan '20

01 Jan '20

Hello Everyone, We have few members who actively started contribution to QA from India as well as from Europe TZ. The current office hour time is more convenient for CT and JST only and very difficult for members from India Europe to join. I would like to adjust office hour timing to include all four TZs. To do that someone has to wake up early or stay late at night :). I gave preference to new members and selected Tuesday 13.30 UTC [1]. which will be an early morning for me and late-night in Tokyo. let me know if any objection or better suggestion. Accordingly, I will make the new time effective from 7th Jan. Also cancelling the 1st Jan office hour and wish you all a very happy new year. [1] https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=… -gmann

1 0