14:00:10 #startmeeting cloudkitty 14:00:11 Meeting started Mon Feb 8 14:00:10 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:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:14 The meeting name has been set to 'cloudkitty' 14:00:19 Roll count 14:00:45 Hi! 14:01:47 o/ 14:05:27 #topic Review priorities 14:05:43 I do not have any review priority for today's meeting 14:05:47 do you guys have any? 14:06:33 Any thoughts on https://review.opendev.org/c/openstack/cloudkitty/+/774084? 14:06:56 I have not seen this one 14:06:58 (it's a WIP but feel free to comment on the idea) 14:07:01 I will note it here to review 14:07:03 Hi mkarpiarz. I haven't had the chance to look at it yet, slowly getting back to reviews. 14:08:03 Sure, no problem. Whenever you guys have some spare time. :) 14:08:49 It's a simple change that basically adds another "if" to the mutator() function. 14:09:45 I think we could do with cleaning this function up so it's not just a bunch of ifs 14:10:05 but for now I just want to add the functionality the simplest way possible. 14:10:38 Also, there is this idea: https://storyboard.openstack.org/#!/story/2008584 14:12:33 It might be useful to have a "keystone" module (seperate from the Keystone fetcher) 14:13:15 that could do things like translation of project names to UUIDs 14:13:43 The main question is whether we want the complexity to be in CloudKitty or in the deployment tool 14:14:25 Do keep in mind that you'll need to deal with user domains and project domains 14:16:58 Do you mean situations in which the rating user/project is in a different domain than the tenant storing metrics? 14:19:14 We are setting all the required auth parameters when configuring the Monasca collector so we can always use these credentials. 14:19:35 I mean to do a lookup against keystone v3 you'll have to handle domain information as well 14:20:37 And potentially the metrics user could be under a different domain than the cloudkitty service user? 14:21:42 Not that I am against the idea, just letting you know about the potential complexity :) 14:23:54 OK, so what do you think would the best way for interacting with external services be? 14:25:06 What kind of external service do you have in mind? 14:25:27 I'm asking a general question because one can imagine a usecase where users would want to call not only Keysone but maybe some other APIs. 14:26:01 Let's limit the question to REST-based HTTP APIs. :) 14:27:08 Are we still talking about fetching some information to replace what's in the metrics file? 14:28:43 I would be OK with some code to handle a project name instead of ID but I don't think we want to encourage cloudkitty to interact with various external APIs unless there is a strong use case for it 14:29:54 I see. It's a fair point. 14:30:00 Sorry, I lost the connection 14:33:28 Just to clarify that the idea behind translation of project names to UUIDs is affecting the query 14:34:33 Hum, I thought it was just to get around the forced_project_id key in metrics.yml 14:34:54 that we run against the database with metrics and is not going to affect the metrics.yml file. 14:36:25 "external services" could come in when you have other parameters that you want to define in metrics.yml and then tell Cloudkitty how to translate these into elements of the query. 14:36:56 In this case you can think of Keystone as an "external service". :) 14:37:44 Apologis if the Story description was not clear but the idea is to introduce the `forced_project_name` parameter 14:38:05 that would then be translated by Cloudkitty to the project UUID. 14:39:43 If these elements in metrics.yml can be determined at deployment time and don't tend to change, I would prefer if it was the job of the deployment system to figure out the right parameters 14:40:09 except for keystone project name -> id which is a very common use case 14:41:49 OK, so a different approach maybe: 14:42:35 We can tell collectors to add metadata parameters to metrics, right? 14:44:31 Instead of authenticating against Keystone from Cloudkitty we could ask Monasca to add the "project_name" parameter to each measurement. 14:45:34 Then we'd only need to adjust the query that Cloudkitty sends to, say, Influx so that it includes the metadata parameter. 14:45:58 That is possible already in the sumary V2 endpoint 14:46:11 one can customize the projection/output of the summary request 14:47:41 Right, but doesn't the /v2/summary endpoint work on data that's been processed to quantities and rates? 14:48:08 (so stuff that is in the "cloudkitty" database and not in, say, the "monasca" one) 14:49:02 it works on the influx database 14:49:17 Ah, I didn't know that! 14:49:20 I mean the endpoint consumes it, and it would normally only return the quantity and price 14:49:29 but I extended it to allow us to project more 14:49:39 this allows one to create richer reports 14:49:52 using the metadata that we have stored in Influx 14:50:24 #link https://docs.openstack.org/cloudkitty/latest/api-reference/v2/index.html?expanded=get-a-rating-summary-detail#get-a-rating-summary 14:51:49 Interesting, thanks! 14:52:17 I'll have a look then. 14:52:43 (into what the /v2/summary endpoint can do) 14:53:45 Guys, I guess we will have to end the meeting, as we are running out of time 14:53:49 I don't want to keep you guys on this tangent so feel free to move to the next item. 14:54:06 We do not have any other defined topics 14:54:07 #topic AOB 14:54:11 Haha, good tming. ;) 14:54:11 Now, I open for general questions and topics that people might have. 14:54:35 I will wait for another 5min. before ending the meeting 14:54:45 Nothing on my side. 14:56:48 Nothing special from me either 14:58:48 Thank you guys for participating. Have a nice week. 14:58:52 #endmeeting