February 2021 - openstack-discuss

[security][security-sig] Change meeting frequency/reschedule
by Gage Hugo 19 Feb '21

19 Feb '21

Hello everyone, The security SIG is still meeting each week at our usual time and over the past year there have often been meetings without any topics. One idea that has been thrown around was to reduce the frequency of meetings to either every other week or even once a month. We are also floating the idea of rescheduling to a new time-slot that is more available for folks. Was wondering if anyone had any opinions/insights on this. We can discuss more during next week's meeting. Thanks!

3 2

[oslo] February 22 meeting is canceled
by Herve Beraud 19 Feb '21

19 Feb '21

Hello Osloers, I will be on PTO all next week so I won't be around to run the meeting. If someone else from the Oslo team wants to run it, please feel free. Thanks for your reading -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

3 2

[victoria][cinder] Extending attached volume
by Ammad Syed 19 Feb '21

19 Feb '21

Hi, I am trying to extend attached volume from openstack client. Exporting the volume API version 3.62, its giving me below error. root@controller ~(keystone_ubuntu20_new)# openstack volume list volume version 3.62 is not in supported versions: 1, 2, 3 Invalid volume client version '3.62'. must be one of: 2, 3 However the attached volume extension from cinder cli was successful. Its shows updated volume size. root@controller ~(keystone_ubuntu20_new)# OS_VOLUME_API_VERSION=3.62 cinder extend test 13 However the volume size was not updated in vm. Checking the cinder volume logs, found below error. 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova [req-93a79710-96df-4e4f-9a0c-d4457d289122 2af528fdf3244e15b4f3f8fcfc0889c5 890eb2b7d1b8488aa88de7c34d08817a - - -] Failed to notify nova on events: [{'name': 'volume-extended', 'server_uuid': '0e9512fb-fb18-4572-8aec-b7508c9f6cc0', 'tag': 'af80330c-f910-46cb-9654-3290e047fbed'}].: keystoneauth1.exceptions.http.BadRequest: Expecting to find domain in project. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) (Request-ID: req-bb86ee85-f6ba-4135-ac55-5917c8658e5c) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova Traceback (most recent call last): 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/cinder/compute/nova.py", line 149, in _send_events 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova response = nova.server_external_events.create(events) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/novaclient/v2/server_external_events.py", line 38, in create 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova return self._create('/os-server-external-events', body, 'events', 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/novaclient/base.py", line 363, in _create 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova resp, body = self.api.client.post(url, body=body) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/keystoneauth1/adapter.py", line 401, in post 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova return self.request(url, 'POST', **kwargs) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/novaclient/client.py", line 69, in request 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova resp, body = super(SessionClient, self).request(url, 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/keystoneauth1/adapter.py", line 554, in request 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova resp = super(LegacyJsonAdapter, self).request(*args, **kwargs) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/keystoneauth1/adapter.py", line 257, in request 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova return self.session.request(url, method, **kwargs) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/keystoneauth1/session.py", line 780, in request 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova auth_headers = self.get_auth_headers(auth) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/keystoneauth1/session.py", line 1191, in get_auth_headers 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova return auth.get_headers(self, **kwargs) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/keystoneauth1/plugin.py", line 95, in get_headers 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova token = self.get_token(session) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/keystoneauth1/identity/base.py", line 88, in get_token 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova return self.get_access(session).auth_token 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/keystoneauth1/identity/base.py", line 134, in get_access 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova self.auth_ref = self.get_auth_ref(session) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/keystoneauth1/identity/generic/base.py", line 208, in get_auth_ref 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova return self._plugin.get_auth_ref(session, **kwargs) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/keystoneauth1/identity/v3/base.py", line 187, in get_auth_ref 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova resp = session.post(token_url, json=body, headers=headers, 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/keystoneauth1/session.py", line 1139, in post 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova return self.request(url, 'POST', **kwargs) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova File "/usr/lib/python3/dist-packages/keystoneauth1/session.py", line 976, in request 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova raise exceptions.from_response(resp, method, url) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova keystoneauth1.exceptions.http.BadRequest: Expecting to find domain in project. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) (Request-ID: req-bb86ee85-f6ba-4135-ac55-5917c8658e5c) 2021-02-19 10:23:25.787 22742 ERROR cinder.compute.nova 2021-02-19 10:23:25.791 22742 INFO cinder.message.api [req-93a79710-96df-4e4f-9a0c-d4457d289122 2af528fdf3244e15b4f3f8fcfc0889c5 890eb2b7d1b8488aa88de7c34d08817a - - -] Creating message record for request_id = req-93a79710-96df-4e4f-9a0c-d4457d289122 2021-02-19 10:23:25.807 22742 INFO cinder.volume.manager [req-93a79710-96df-4e4f-9a0c-d4457d289122 2af528fdf3244e15b4f3f8fcfc0889c5 890eb2b7d1b8488aa88de7c34d08817a - - -] Extend volume completed successfully. Any advice? - Ammad

3 3

Network policer behavior
by Vladimir Prokofev 19 Feb '21

19 Feb '21

I've encountered some really bizarre things today, and want to discuss it for a sanity check. This is probably more appropriate for a libvirt mailing list, but I want some second opinion first. Openstack Queens libvirtd (libvirt) 4.0.0 qemu-x86_64 version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.15) 2 instances were launched a while ago with Zabbix Appliance 5.0.7 LTS inside. Both of them were "hacked" shortly after and became a part of a botnet that participated in DDOS attacks via SYN-flood. Sad, but nothing out of the ordinary so far. Now to the bizarre part. Both of the instances had QoS configured via instance metadata that limited them for 100Mb/s in/out[1]. I've checked it on the compute side - it was correctly applied there too[2]. This metadata was tested years ago with usual iperf tcp/udp tests with 1-10 flows - it worked perfectly. Both of the instances landed on the same compute node. And both of them are ignoring network policer and sending about 400Mb/s of SYN-flood traffic each on their respective tap interface, so about 800Mb/s were flowing out of the compute node switch port. So I've shut down 1 instance - 2nd one traffic rose to about 600Mb/s - ok, they probably were contesting some resources. Now I apply a qos-policy to the port of the remaining instance[3] - that does the trick, I can see on the switch port that compute node traffic went down to the expected level, but CPU context switches on the compute node increased almost 3 times, and traffic on the tap interface rise to 1.6Gb/s! What I can't understand is why libvirt network policer does not handle this case? Why does implementing qos-policy actually increase traffic on the tap interface? I can't exactly say if it's the tc that is responsible for context switches increase, or traffic generated by the instance. At first I thought that my Zabbix went crazy, so I double checked. It seems it takes its data for net.if.in key from /proc/net/dev and it appears to be correct. Any ideas appreciated. [1] quota:vif_inbound_average='12500', quota:vif_inbound_burst='3125', quota:vif_inbound_peak='12500', quota:vif_outbound_average='12500', quota:vif_outbound_burst='3125', quota:vif_outbound_peak='12500' [2] compute2:~$ virsh domiftune instance-0000141d tap834d76e9-5f inbound.average: 12500 inbound.peak : 12500 inbound.burst : 3125 inbound.floor : 0 outbound.average: 12500 outbound.peak : 12500 outbound.burst : 3125 [3] openstack port set --qos-policy 100Mbps 834d16e9-5f85-4e82-a834-bdae613cfc23

1 0

[release] Release countdown for week R-7 Feb 22 - Feb 26
by Herve Beraud 19 Feb '21

19 Feb '21

Greetings everyone, Development Focus ----------------- We are entering the last weeks of the Wallaby development cycle. From now until the final release, we'll send a countdown email like this every week. It's probably a good time for teams to take stock of their library and client work that needs to be completed yet. The non-client library freeze is coming up, followed closely by the client lib freeze. Please plan accordingly to avoid any last minute rushes to get key functionality in. General Information ------------------- Next week is the Extra-ATC freeze, in preparation for elections. All contributions to OpenStack are valuable, but some are not expressed as Gerrit code changes. Please list active contributors to your project team who do not have a code contribution this cycle, and therefore won't automatically be considered an Active Technical Contributor and allowed to vote. This is done by adding extra-atcs to https://opendev.org/openstack/governance/src/branch/master/reference/projec… before the Extra-ATC freeze on 25 February, 2021. A quick reminder of the upcoming freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (4 March, 2021). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (11 March, 2021) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, 11 March, 2021. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (22 March, 2021) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (5 April, 2021) Finally, now is also a good time to start planning what highlights you want for your deliverables in the cycle highlights. The deadline to submit an initial version for those is set to Feature freeze (11 March, 2021). Background on cycle-highlights: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html Project Team Guide, Cycle-Highlights: https://docs.openstack.org/project-team-guide/release-management.html#cycle… knelson [at] openstack.org/diablo_rojo on IRC is available if you need help selecting or writing your highlights. Upcoming Deadlines & Dates -------------------------- Cross-project events: - Extra-ATC freeze: 25 February, 2021 (R-7 week) - Non-client library freeze: 4 March, 2021 (R-6 week) - Client library freeze: 11 March, 2021 (R-5 week) - Wallaby-3 milestone: 11 March, 2021 (R-5 week) Project-specific events: - Oslo Feature Freeze: 25 February, 2021 (R-7 week) - Cinder Driver Features Declaration: 12 March, 2021 (R-5 week) Thanks for your attention -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[all][TC] March k8s Steering Committee Meeting?
by Kendall Nelson 19 Feb '21

19 Feb '21

Hello! I wanted to make everyone aware that I was able to coordinate time with the k8s Steering Committee to have some cross community discussions at their next public monthly meeting. I wanted to kick-off collection of topics early and I figured we could keep using the etherpad[1] we used for our last discussions with them. Please add ideas! Also, if you are interested in attending, please do! It's a public community meeting and all are welcome. -Kendall (diablo_rojo) [1] https://etherpad.opendev.org/p/kubernetes-cross-community-topics

1 0

[ops] How to enable Live Migrate option in instance dropdown in Horizon?
by Linebarger, John 19 Feb '21

19 Feb '21

Precisely how do I enable a Live Migrate option in the instance dropdown menu in Horizon? I've been following the instructions at this link, but a Live Migrate option (or any migrate option at all) never appears in Horizon despite restarting nova-compute and the openstack dashboard service. We are using a libvirt VM-based implementation of Canonical Charmed OpenStack (Stein). Somewhere there's a trick or a detail that we are missing. https://docs.openstack.org/nova/victoria/admin/configuring-migrations.html#… Thanks! Enjoy! John M. Linebarger, PhD, MBA Principal Member of Technical Staff Sandia National Laboratories (Work) 505-845-8282 (Cell) 505-681-4879 [cid:image006.jpg@01D705FE.47F9E330]<http://www.sandia.gov/>[AWS Certified Solutions Architect - Professional]<https://www.youracclaim.com/badges/24fe4e43-2f72-4ecc-a11a-783d21dada0f>[AWS Certified Solutions Architect - Associate]<https://www.youracclaim.com/badges/707a5f6f-d919-4daa-bbc4-81b5a779a6cd>[AWS Certified Developer - Associate]<https://www.youracclaim.com/badges/b52ac093-5415-4493-85c3-b77e055211f5>[cid:image003.png@01D705FD.A88014F0]<https://www.youracclaim.com/badges/d6e5a453-0e61-4dbe-9716-6af51f364710/pub…>[cid:image007.png@01D705FE.47F9E330]<https://www.youracclaim.com/badges/035d4967-f77d-476e-915b-1061bb789ec3/pub…>

3 2

Trove Instance fails in build stage
by Abhinav Tyagi 19 Feb '21

19 Feb '21

Hi, Please help us in using trove. We are using https://tarballs.opendev.org/openstack/trove/images/trove-ussuri-mysql-ubun… image. We have a multi master openstack setup. These are the logs: Feb 18 19:03:30 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:03:30.535 1274599 INFO trove.taskmanager.models [-] Waiting for instance 5fe896f6-dc7b-424a-87c2-64f207f422a2 up and running with timeout 900s Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.940 1274599 ERROR oslo.service.loopingcall [-] Dynamic backoff interval looping call 'trove.common.utils.build_polling_task.<locals>.poll_and_check' failed: oslo_service.loopingcall.LoopingCallTimeOut: Looping call timed out after 893.31 seconds Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.940 1274599 ERROR oslo.service.loopingcall Traceback (most recent call last): Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.940 1274599 ERROR oslo.service.loopingcall File "/usr/lib/python3.6/site-packages/oslo_service/loopingcall.py", line 154, in _run_loop Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.940 1274599 ERROR oslo.service.loopingcall idle = idle_for_func(result, self._elapsed(watch)) Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.940 1274599 ERROR oslo.service.loopingcall File "/usr/lib/python3.6/site-packages/oslo_service/loopingcall.py", line 351, in _idle_for Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.940 1274599 ERROR oslo.service.loopingcall % self._error_time) Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.940 1274599 ERROR oslo.service.loopingcall oslo_service.loopingcall.LoopingCallTimeOut: Looping call timed out after 893.31 seconds Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.940 1274599 ERROR oslo.service.loopingcall Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.941 1274599 ERROR trove.taskmanager.models [-] Failed to create instance 5fe896f6-dc7b-424a-87c2-64f207f422a2, error: Polling request timed out..: trove.common.exception.PollTimeOut: Polling request timed out. Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.960 1274599 ERROR trove.taskmanager.models [-] Service status: ERROR, service error description: guestagent error: trove.common.exception.PollTimeOut: Polling request timed out. Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.970 1274599 DEBUG trove.db.models [-] Saving DBInstance: {'_sa_instance_state': <sqlalchemy.orm.state.InstanceState object at 0x7fb5447bd668>, 'tenant_id': '19aa2578cb444b828549b394eed8ebfb', 'hostname': None, 'shard_id': None, 'server_status': None, 'compute_instance_id': 'b928d7e4-6706-48d2-9fb9-c75e19b9765c', 'type': None, 'deleted': 0, 'id': '5fe896f6-dc7b-424a-87c2-64f207f422a2', 'task_id': 91, 'region_id': 'Bangalore', 'deleted_at': None, 'task_description': 'Build error: guestagent timeout.', 'encrypted_key': '***', 'datastore_version_id': 'b4bbc01c-e785-4944-8a76-6c154c19ddff', 'task_start_time': None, 'created': datetime.datetime(2021, 2, 18, 13, 33, 24), 'configuration_id': None, 'volume_id': '68accc42-34ae-4ac3-93fc-1efb9fed2af9', 'slave_of_id': None, 'updated': datetime.datetime(2021, 2, 18, 13, 48, 33, 969535), 'flavor_id': 'bbf4bad4-e258-45b4-8860-e5a51c86ed6e', 'name': 'trove_instance_15', 'cluster_id': None, 'volume_size': 10, 'errors': {}} save /usr/lib/python3.6/site-packages/trove/db/models.py:65 Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.981 1274599 ERROR trove.taskmanager.models [-] Trove instance status: ERROR, Trove instance status description: Build error: guestagent timeout.: trove.common.exception.PollTimeOut: Polling request timed out. Feb 18 19:18:33 bngoscompn01.comviva.com trove-taskmanager[1274599]: 2021-02-18 19:18:33.994 1274599 DEBUG trove.db.models [-] Saving DBInstanceFault: {'_sa_instance_state': <sqlalchemy.orm.state.InstanceState object at 0x7fb5448688d0>, 'id': 'f0983744-4cfe-4863-b9ae-6fb33cc8a0d2', 'created': datetime.datetime(2021, 2, 18, 13, 48, 33, 994216), 'deleted': False, 'instance_id': '5fe896f6-dc7b-424a-87c2-64f207f422a2', 'message': 'Polling request timed out.', 'details': 'Traceback (most recent call last):\n File "/usr/lib/python3.6/site-packages/trove/common/utils.py", line 207, in wait_for_task\n return polling_task.wait()\n File "/usr/local/lib/python3.6/site-packages/eventlet/event.py", line 125, in wait\n result = hub.switch()\n File "/usr/local/lib/python3.6/site-packages/eventlet/hubs/hub.py", line 309, in switch\n return self.greenlet.switch()\n File "/usr/lib/python3.6/site-packages/oslo_service/loopingcall.py", line 154, in _run_loop\n idle = idle_for_func(result, self._elapsed(watch))\n File "/usr/lib/python3.6/site-packages/oslo_service/loopingcall.py", line 351, in _idle_for\n % self._error_time)\noslo_service.loopingcall.LoopingCallTimeOut:\n Looping call timed out after 893.31 seconds\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File "/usr/lib/python3.6/site-packages/trove/taskmanager/models.py", line 431, in wait_for_instance\n time_out=timeout)\n File "/usr/lib/python3.6/site-packages/trove/common/utils.py", line 222, in poll_until\n return wait_for_task(task)\n File "/usr/lib/python3.6/site-packages/trove/common/utils.py", line 209, in wait_for_task\n raise exception.PollTimeOut\ntrove.common.exception.PollTimeOut: Polling request timed out.\n', 'errors': {}, 'updated': datetime.datetime(2021, 2, 18, 13, 48, 33, 994288)} save /usr/lib/python3.6/site-packages/trove/db/models.py:65

2 1

Some questions regarding OpenStack Trove Victoria release
by Bekir Fajkovic 19 Feb '21

19 Feb '21

Hello! My name is Bekir Fajkovic and i work at City Network cloud service provider mostly as a DBA but i am also involved in many other kind of activities inside the Company. We at City Network are currently in a process of deployment of OpenStack Trove project (latest official release) and are thus preparing a dedicated region inside our OpenStack hosting environment to host it as a beta version internally, to begin with, where we are going to involve some of our customers to evaluate the service after, hopefully, successful installation and configuration. To be totally honest, while there is a whole lot of a certain kind of documentation provided covering many aspects, some other aspects inside the project do not seem to be documented in depth or at all (which of course is totally understandable), so i am forced to ask some questions this way and i hope You find them not to be too annoying to anyone. The questions: ------------------------ Having the fact that Trove Victoria release provides Docker containers as a new way of database instance provisioning, i am wondering how far the project is developed in terms of covering the different types of databases. What i can see by mainly parsing the code provided on Github, those seem to be officially released: - MySQL - MariaDB - PostgreSQL and the rest of the planned database types are in "experimental" phase. And also, regarding certain types of databases (for example MySQL, version 5.7 and 8.0) only certain versions of the datastores seems to be supported, but not all. On the other hand, nothing regarding datastore versions supported for MariaDB and PostgreSQL seems to be mentioned somewhere. Could someone please confirm that as well as give some more details about it? I successfully managed to create certain versions of datastores in my devstack environment, belonging to those 3 database types mentioned above (and based on trovestack-generated dev guest image that is by default delivered with devstack installation), but not without some undesirable events. For example, i am able to register PostgreSQL datastore version 12 and instantiate a database instance of that version but not version 13 and above, where i get some hostname-related errors etc. Also, a question regarding the building of the production-ready guest image. As mentioned, Trovestack script is provided as a possible way of producing the images (by omitting dev option the Trove Guest Agent binaries are deployed into the instantiated VM). How does an image produced this way looks like? From where the base image is fetched, is it a "cloud based image" with cloud-init in it, are the automatic security and software patching features disabled in produced image, so that we do not get unexpected service interruptions when the OS suddenly decides to start updating itself etc.. Regarding the Trove Guest Agent service - i read in some Trove books previously that there are dedicated agents for each and every database type, is it the same situation in Victoria release, or is there an "universal" Guest Agent covering all the database types nowadays? Where is the code that adapts the Agent commands towards the database instances placed inside the project? The backups - as i can see there seem to be some kind of dedicated docker-backup images involved in each database type. Could someone explain the internals of backup mechanisms inside Trove Victoria release in more details? So, that would be all for the moment and although You probably consider my questions being as stupid as possible, i still dared to ask them :) I hope You will be able to provide the answers to at least some of them! Thanks in advance! Best Regards Bekir Fajkovic Senior DBA Mobile: +46 70 019 48 47 www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

3 10

[all][requirements] Pygments 2.8.0 break console blocks
by Dmitriy Rabotyagov 19 Feb '21

19 Feb '21

Hi! After recent upper-constraints bump [1] which upgraded Pygments to version 2.8.0 we got our docs tests broken because of the console blocks [2]. So CI started failing with "Could not lex literal_block as "console". Highlighting skipped." While I can kind of understand some of the issues, with a misleading quotes (while they're fine in bash) some are totally weird. For example it starts complaining on this [3]. I'm not sure if it's intended behaviour of Pygments with 2.8.0 and pretty ok to fix the docs, but I'm not sure I understand the issue here... It feels more like Pygments issue atm. And changelog [4] is pretty excessive... [1] https://opendev.org/openstack/requirements/commit/673ce445d54f8bdf792550e2d… [2] https://zuul.opendev.org/t/openstack/build/6eea1a7099824c90a533b57c1281d478… [3] https://opendev.org/openstack/openstack-ansible/src/branch/master/doc/sourc… [4] https://pygments.org/docs/changelog/#version-2-8-0 -- Kind regards, Dmitriy

1 1