14:00:06 #startmeeting cloudkitty 14:00:07 Meeting started Mon Jan 11 14:00:06 2021 UTC and is due to finish in 60 minutes. The chair is rafaelweingartne. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:10 The meeting name has been set to 'cloudkitty' 14:00:20 Hello guys, happy new year! 14:00:30 Roll count 14:02:15 o/ 14:02:19 Happy new year rafaelweingartne! 14:05:42 priteau: it seems that it is just us today 14:05:51 And maybe mkarpiarz? 14:06:10 Hi, I'm here! 14:06:11 hmm... mkarpiarz: are you going to participate in the meeting? 14:06:14 ah.. cool! 14:06:24 #topic Review priorities 14:06:38 We have reviewed and merged some patches in the past week. 14:07:13 Do you guys have some review priorities for us to focus on? 14:08:26 Nothing in the pipeline from my side. 14:09:02 Nothing special from me either. 14:09:05 But I was trying to assign priorities to tasks from our PTG meeting. 14:09:51 And also add tasks that could kickstartdevelopment for each section. 14:11:08 I see 14:11:34 My idea was to try and focus on ideas we came up during the PTG. 14:12:09 I agree 14:12:25 I confess that I have not had time to address those issues 14:12:40 mkarpiarz: When you said "last 4 main points" in your email, did you mean top level items in the etherpad? 14:12:51 I have been working lately on other components only; what I an able to do for now is to review patches only 14:12:56 4 bottom ones 14:13:00 i.e. 1) Stop processing resources that have been deleted/removed and do not have data anymore, 2) Reprocessing API?, etc.? 14:13:11 Yep 14:13:21 OK 14:13:43 So one question, for item 3 "Cleanups of the database to remove old/legacy unwanted data objects", are we actually talking about dataframes? 14:14:10 mkarplarz: I guess, you as the contributor should have the ability to choose where you want to work 14:14:44 priteau: I thought that this issue refered to the that table where we have the reference for the projects to be processed 14:15:08 Maybe it does, that's why I am asking :) 14:15:40 that table only grows, and as projects/resources get deleted, they are not cleaned up. Therefore, CloudKitty still processes projects that do not have usage data anymore 14:17:19 I thought it was up to fetchers to decide what projects to process 14:18:08 but the problem is that they always process all of them 14:18:30 them=all available in the database and that were not processed in that timeframe 14:19:08 therefore, the projects/resources table to be processed only grows, and slows down the system (Cloudkitty) 14:19:10 Interesting, I didn't know it worked like that 14:19:34 I do not know the initial design, but that is how it is working right now 14:19:44 So if you use the keystone fetcher, start rating on a project, then remove the cloudkitty rating role from that project, it is still processed? 14:19:56 then, the fetcher fetches the usage data from the backend (e.g. gnocchi) for each project/or resource in that table 14:20:26 priteau: as far as we have seen yes, because cloudkitty will collect data from gnocchi 14:20:31 you mean the collector 14:20:57 and there is no access control there with respect to project 14:21:09 I mean, that I recall that Gnocchi is doing 14:21:24 I did not test removing a role, but we noticed that happening with delete/removed projects 14:21:42 they are still being processed, even though there is no data in Gnocchi 14:22:02 I would say it depends on the fetcher being used 14:22:23 We noticed this with Keystone fetcher 14:22:45 oh, no, I mean Gnocchi 14:23:05 OK, for Gnocchi fetcher it makes less sense that it would work like this 14:23:40 yes, we do use Gnocchi 14:23:41 backend = gnocchi 14:23:48 Rather than clean up old projects via API we may want to change the fetcher to update the list? 14:24:02 yes, exactly that would be even more interesting 14:24:13 we just could not figure out a method to check that 14:24:24 if a resource/project was deleted in Gnocchi for instance 14:24:35 that is why one of the ideas was to enable this process via an API call 14:26:06 If the metrics are deleted you won't be able to find any data for the project in Gnocchi, but we could detect that and mark the project as inactive in CloudKitty or delete the row 14:26:18 ah 14:26:21 that would be a good idea 14:26:27 inactive project 14:26:36 We did not think that 14:27:13 Merged openstack/cloudkitty-tempest-plugin master: Use tempest's ServiceClients rather than Manager https://review.opendev.org/c/openstack/cloudkitty-tempest-plugin/+/767714 14:28:27 I could work on that this week 14:28:56 Sounds good to me! 14:29:30 The advantage of marking it as inactive is that you would keep the record and be able to see when it was last updated 14:29:36 Could be useful for debugging 14:29:38 exactly 14:29:45 I like this solution better 14:32:18 Cool, so sounds like we have a plan for this point. 14:32:34 to give you an idea of the problem, we have 337 active projects, and in Cloudkitty storage states, there are 990 projects being processed 14:32:52 I understand, it must slow down processing quite a bit 14:32:58 yes, it does 14:34:38 "Allow for a free USAGE consumption (e.g. First 1GB free, then 3 Cent/GB)" 14:34:46 Can't you do that with thresholds? 14:35:03 yes, you can 14:35:09 but there was a bug 14:35:13 I had a patch for that 14:35:28 Also, remember that you can write custom pyscripts rules (although I've never tried it) 14:35:33 https://review.opendev.org/c/openstack/python-cloudkittyclient/+/752956 14:36:05 exactly 14:36:22 "Reprocessing API?" > I think this is important. When setting up CloudKitty and tuning rating rules, it's a pain to have to clear SQL and storage backend 14:36:36 yes exactly 14:36:43 that is where this proposal comes from 14:37:02 I do not have time for this month to work on this, but I could devote some time, maybe next month 14:37:46 And what do you think has to be done? Maybe someone else can pick this up? 14:38:22 first, a specification needs to be written down. I have not put much thinking on this yet 14:39:17 I was going to start working on custom mutators as I feel this is important (especially for Prometheus) but can looks into something else instead. 14:39:39 Yes, design first for this as it involves new API 14:39:51 that would be interesting, either one of them this reprocessing API, or the custom mutators 14:40:26 Ah, it sounds like reprocessing API is above my abilities, so I'll stick with mutators for now. ;) 14:41:13 :) 14:42:55 Hopefully we will have some new reviews to discuss during the next meeting then. 14:43:11 exactly 14:44:54 Should we move on to the next point on the agenda of this meeting? 14:45:40 We need to keep an eye on the release schedule 14:46:01 yes 14:46:08 I will ask for your help when the time comes 14:46:10 If we want to ship new APIs with client support, client release is March 11 14:46:14 this will be my first release 14:46:33 Making the release is the easy part 14:46:45 It's writing the code in time that's the hard part :P 14:46:55 xD 14:47:09 :) 14:47:48 I will open for general topics now 14:47:49 https://review.opendev.org/c/openstack/python-cloudkittyclient/+/752956 14:47:51 ops 14:47:57 wrong paste 14:48:02 #topic AOB 14:49:39 Nothing on my side. 14:50:07 Nothing special from me either. 14:50:34 Great 14:50:42 Thank you guys for participating. Have a nice week. 14:50:47 Thank you guys for participating. Have a nice week. 14:50:57 #endmeeting