13:00:09 #startmeeting monasca 13:00:09 Meeting started Tue Dec 1 13:00:09 2020 UTC and is due to finish in 60 minutes. The chair is chaconpiza. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:12 The meeting name has been set to 'monasca' 13:00:19 Hi 13:00:35 hi 13:00:37 The agenda as usual https://etherpad.opendev.org/p/monasca-team-meeting-agenda 13:00:41 Hi Witek 13:01:50 Dobek wrote to me. I have already the password of the DockerHub's monascazuulci account. 13:02:28 Alright, let's start with the topics. 13:02:42 #topic Fix Zuul Publish Job 13:03:51 Besides the password of monascazuulci account, Dobek explainedme in detail the process to encrypt the text 13:04:39 I see your change actually doesn't touch the encrypted secret 13:05:00 Yes, it is true 13:05:22 Before to encrypt there, I saw this discrepancy: 13:05:25 https://github.com/openstack/monasca-tempest-plugin/blob/master/.zuul.yaml#L40 13:05:45 https://github.com/openstack/monasca-tempest-plugin/blob/master/playbooks/docker-publish.yml#L5 13:06:19 doker_hub_login_tempest vs doker_hub_login_log_tempest 13:06:31 good catch 13:06:33 I think this is the problem 13:06:47 just a simple mistake. 13:07:08 Anyways the cypher user and password could be wrong. 13:07:56 Every time you cypher them, the encrypted text is different, there should be a hash method in the cypher process. 13:08:43 what now is blocking this and almost all rest of changes is: 13:08:59 #topic Broken monasca-tempest-python3-influxdb Zuul Job 13:10:00 from few days ago (12 more or less) this Zuul Job is failing 13:10:22 I investigated the root cause: new influxdb-python 5.3.1 13:10:51 I don't mean the InfluxDB but the influxdb python library 13:11:00 https://github.com/openstack/requirements/commit/937ccadec9b94ebb111bbde8d4a9b5eb6690365e#diff-449046f51430a028478d668e3d3150c5b8f80e1a2682f1df9fd264dd6a42681aL231 13:11:07 it's strange that is 5.3.1 tagged as unreleased in GitHub 13:11:26 Yes, it is strange. But in Pypi is available 13:11:42 https://pypi.org/project/influxdb/ 13:12:02 Maybe in Github they forgot to create the tag 13:12:17 was it passing with 5.3.0? 13:12:21 Github is for this library the official repository 13:12:49 alright, time ago I found that version 5.3.0 is not completly functional 13:13:20 https://github.com/influxdata/influxdb-python/issues/820 13:13:48 I wrote there, and as well I ask to block this version from the upper-constraints. 13:14:28 I am playing with the version 5.3.1 and it looks ok 13:14:41 But there are small changes: 13:16:05 1. Same like in 5.3.0 SHOW DIAGNOSTICS is not the best way to get the version, there is a command for that: PING 13:17:40 2. Getting metric measurements we get a timestamp with 6 digits instead of 3 digits for decimals of seconds 13:18:01 I mean in version 5.2.3 we got something like: 2018-07-31T11:00:03.790Z 13:18:12 in versino 5.3.1 2018-07-31T11:00:03.790000Z 13:18:32 does it cause the tempest tests to fail? 13:18:36 it breakes 5 tempest tests 13:18:38 yes 13:19:32 So, the fix... better I will call it the update requires: 13:19:35 out of 21, right? 13:19:51 Use Ping instead of Show diagnostics 13:20:03 then this failing 21 goes to only 5 13:20:29 and then solve the problem with the 6 digits 13:20:59 for the firts problem, about Show Diagnostics I was working on: https://review.opendev.org/c/openstack/monasca-api/+/725779/ 13:22:14 This file monasca_api/common/repositories/influxdb/metrics_repository.py handles versions of InfluxDB (the Database) <0.11.0 13:22:27 This code should be remove, since it is quite old 13:23:27 Well, this is a blocker. I am working on it. I hope to have the solution today. 😉 13:24:26 There are several changes waiting for this blocker to be resolved. 13:25:14 Ok, continuing with InfluxDB (the Database) 13:25:23 #topic Tests with influxdb 1.8 13:26:09 This is just informational topic 13:26:48 We executed several stress and performance tests with influxdb 1.8, with all possible options, regarding indexing structure. 13:27:11 Up to now, no issues at all (waiting for completion of endurance test) 13:27:35 No improvements measured either - but this was not the target of the test 13:29:24 thanks for the update, good to hear that 13:29:44 I expect it may be not that smooth when upgrading to 2.0 13:30:24 I haven't checked for the changes in 2.0 yet, since it wasn't available as released version when we started testing 13:31:27 Matthias, about the migration to 1.8 you mentioned before (internally), that it is based on the shards 13:31:58 can you briefly explain it 13:32:00 Well, my proposal how to handle - in Fujitsu product as well as in community: 13:32:27 - Use new indexing structure automatically (can be enabled with env. ment variable) 13:32:42 Describe migration. 13:33:03 If no migration is done, the database will use new indexing structure for new shards 13:33:40 I.e., depending on retention time setting (30d/60d), it will smoothly transition to "use new indexing structure only" 13:34:49 thanks Matthias 13:35:17 Besides the topics from the agenda, this weeks is the Wallaby-1 milestone 13:35:24 *this week 13:36:47 Ok, those were the topics for today. 13:37:38 thanks for the updates and your work 13:37:53 Thanks, bye! 13:38:24 thanks for the attendance, I will come back to solve the blocker. See you next week. 13:38:31 thanks for the update 13:38:38 Bye 😉 13:38:47 see you, have a good week 13:39:04 #endmeeting