15:00:43 #startmeeting monasca 15:00:47 Meeting started Wed Mar 8 15:00:43 2017 UTC and is due to finish in 60 minutes. The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:47 \0 15:00:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:50 The meeting name has been set to 'monasca' 15:00:56 https://etherpad.openstack.org/p/monasca-team-meeting-agenda 15:00:58 o/ 15:01:01 o/ 15:01:01 o/ 15:01:03 o/ 15:01:07 o/ 15:01:08 o/ 15:01:11 o/ 15:01:29 hi everyone, and welcome to another installment of monasca, where all your monitoring dreams can come trye 15:01:32 true 15:01:49 o/ 15:01:53 :) 15:02:01 sorry folks, i've been pretty sick this past week 15:02:07 hello 15:02:08 lol...I am gonna get a pony...finally :D 15:02:14 good morning :) 15:02:17 so, i've been out of commission 15:02:26 Dr. Monasca's been sick ? that is unheard of 15:02:26 bummer 15:02:46 yeah, we've noticed lack of -1 @ gerrit :P 15:03:10 ok, well we might as well get started with the agenda 15:03:17 https://etherpad.openstack.org/p/monasca-team-meeting-agenda 15:03:24 1. Reviews: 15:03:24 1.1 https://review.openstack.org/#/c/437159/ 15:03:24 2.2 https://review.openstack.org/#/c/433016/ 15:03:24 2.3 https://review.openstack.org/#/c/442957 15:03:24 2.4 https://review.openstack.org/#/c/395897/ 15:03:25 2.5 https://review.openstack.org/#/c/422108/ 15:03:25 2. Colon in dimension key + value 15:03:26 2.1 https://review.openstack.org/#/c/439612/5 15:03:27 2.2 https://bugs.launchpad.net/monasca/+bug/1668937 15:03:27 Launchpad bug 1668937 in Monasca "Dimensions with Colons raises malformed exception in monasca-api" [High,New] 15:03:28 2.3 https://bugs.launchpad.net/monasca/+bug/1671085 15:03:32 o/ 15:03:35 Launchpad bug 1671085 in Monasca "Allow colon in dimension key" [Medium,New] 15:03:44 #topic https://review.openstack.org/#/c/437159/ 15:03:50 that one is me 15:04:11 it was a patch following up on a conversation we had about a month ago 15:04:13 so, i think this is ready to go, thanks for updating the docs 15:04:21 i just +1'd 15:04:27 u bet -- i'll merge if we're ok with it 15:04:33 lgtm 15:04:38 +2 15:04:52 awesome 15:05:02 #topic https://review.openstack.org/#/c/433016/ 15:06:16 nothing much to add there, personally I think that it is in good shape, we had rbrandt to do some checks againts metric api compatybility 15:06:29 witek: you think we're cool with as in current shape 15:06:31 thanks kornica 15:06:38 thanks rbrandt 15:06:51 i think it looks good to me 15:06:59 i have +2 already 15:07:00 i had reviewed earlier, but didn't leave comments 15:07:23 i can take another quick look, but i think it is ready to merge 15:07:32 concur with witek 15:08:27 #topic https://review.openstack.org/#/c/442957 15:08:55 kornica? 15:09:00 it's us...had bunch of issues with it in devstack at this point, so just python code for now 15:09:17 we have follow-up for the feature: https://review.openstack.org/#/c/442365/ 15:09:25 do you want to add support for the java code too? 15:09:25 witek, successfully tested on master 15:09:35 is that necessary? 15:09:53 no, I don't think so, but we actually did not think about Java here 15:10:07 is what necessary ? WSGI or devstack mod ? 15:10:19 just wondering if the python is sufficient 15:11:23 well mod-wsgi is meant for python, but I know as much about wsgi as I've learned during past few days 15:11:28 so, I might be wrong 15:11:44 anyway, we did not take Java into account while doing WSGI for monasca-api 15:11:47 good point 15:11:51 i wasn't thinking 15:12:13 but you had mentioned just python code for now 15:12:39 so, i think the answer is just python code for now and no java code changes expected 15:12:57 at this point, yes 15:13:13 Tomasz thought about integrating it to devstack, I don't know if that is necessary at all 15:13:20 so, i'll hopefully start catching up on my review backlog, but i'll try and bring up a new devstack environment and validate 15:13:54 i'm not sure it is necessary either 15:14:00 well, I only did so to have a proof that it actually works + monasca-log-api devstack can run monasca-log-api under wsgi 15:14:24 so was only natural for me to have it in monasca-api devstack 15:15:18 anyway, we don't have time to work on this now, so assuming it would be needed or I;d have somet in, not so near, future - I could add this as non-invasive change to plugin 15:16:59 #topic https://review.openstack.org/#/c/395897/ 15:17:50 kornica: do you believe that this one is ready too? 15:17:55 it's quite old, but together with Li I think we managed to integrate oslo.db + keep old configuration option that Craig has doubts about 15:18:02 *had 15:18:30 rhochmuth: I think it is though I wouldn't mind extra test from someone 15:18:39 just to ensure that we don't break anything with it 15:18:51 so, basically the old config options are supported and the new oslo.db 15:19:27 as far as I looked into that, the only problematic option was that in old code there was url opt and in new there will be connection 15:19:46 so in recent PS I think I found a way to support both + marked url as deprecated 15:19:59 or at least I hope so 15:19:59 ok, thanks 15:20:00 :) 15:20:16 is the default oslo.db? 15:20:20 in devstack? 15:20:34 you mean, if other projects rely on oslo.db ? 15:20:57 no, i meant if you bring up a new devstack environment will it use your changes? 15:22:21 from python-gate log 15:22:29 Successfully installed .... oslo.db-4.17.0 15:23:09 and gate used commit->f379d71 Use oslo.db for sqla driver 15:23:21 so that says that, it will 15:23:29 thx 15:23:48 ok, i'll install, but i'll assume this is ready to merge 15:23:55 I guess Artur said he'll test that tommorow 15:24:13 but I might be wrong, I was leaving when I think he was telling that :P 15:24:22 #topic https://review.openstack.org/#/c/422108/ 15:24:41 bklei: is this one for you? 15:24:44 i'll take that one 15:25:01 yeah -- been sitting a while -- not sure if kevin needs to do more work 15:25:26 i think he's addressed hoppal's comments 15:25:34 looks like multiple +1's already 15:26:07 i added a +1 15:26:25 i had reviewed earlier, but didn't add any comments for some reason 15:26:37 cool -- if nobody objects, i'll merge 15:27:35 #topic https://review.openstack.org/#/c/439612/5 15:28:20 kamil_: are you there? 15:28:25 yes 15:28:38 just a second 15:28:53 We found a bug in the monasca-api python version 15:29:23 yes, that was a nasty one 15:29:24 It is currently not possible to query for metrics withs dimensions like url:http://localhost:5050 15:29:52 yup, agree 15:29:54 So, we were thinking how to solve this issue and took a look into the java implementation 15:30:32 And there we found that the dimension is always splitted on the first occured colon. Indepentend how many colon will folow 15:31:15 but this means, that if the key can have a colon. But this is not explicit restricted 15:31:39 right, ":" is not a restricted char 15:32:05 In the first step we want to implement the same functionality in the python implementation as it is in java. Just to get rid of this bug 15:32:32 sounds good 15:32:41 that is this review, https://review.openstack.org/#/c/439612/5/monasca_api/tests/test_query_helpers.py 15:32:44 right? 15:32:52 And as an extension, we thought we could try to refactor the syntax for the dimensions. For example starting and ending with quotation marks 15:33:01 yes 15:33:37 Like: dimension='"url":"http://localhost:5050/"' 15:34:04 why would that be necessary? 15:34:19 Because then you will be able to have colon in the key 15:34:58 I don't know if this is a real usecase. But the spec is not restricting the colon for the key 15:35:08 we could also just restrict the colon in the key 15:35:17 is it due to how influxdb stores data that this occurs? 15:35:27 i'm wondering if the latter is a better option 15:35:32 influx is able to handle keys with colon 15:35:36 I checked it 15:36:08 rhochmuth: the latter is cheaper for sure 15:36:28 we could also try the enhancement with the latter 15:36:36 i think i'm missing the part where we require either quotes or to restrict it 15:37:06 can't we fix the issue in a way that doesn't require restricting chars or adding quotes? 15:37:19 if we split on the first colon, you cannot correctly read dimension keys with colon 15:37:55 it could be hard. Because you will never know what is the key and what the value in this example: service:name:monasca-api 15:38:16 so the db is using : as a delimiter 15:38:28 for key, value 15:38:44 and then we use that to split on 15:39:07 isn't that written somewhere that dimension key suppose to use . (dot) to split segments ? 15:39:19 service.name:monasca-api 15:39:23 using example aboce 15:39:24 that is a convention, not a requirement 15:39:31 ah, right 15:39:45 well, looking at code and the bug looks more like requirements for me 15:40:18 So, the api gets a request like this: http://192.168.10.5/dashboard/monitoring/proxy/metrics/measurements/?dimensions=url:http%253A%252F%252Flocalhost%253A8191%252Fhealthcheck,hostname:monasca.cmm,component:monasca-persister,service:monitoring&name=http_status&start_time=2017-03-01T09:13:51Z 15:40:56 i'm wondering if restricting is a better option then 15:41:13 it seems like no one should be using the : 15:41:26 if they were, they would have had a pretty significant bug in dimenion keys 15:41:34 is there a way to escape it 15:41:46 that was the only other idea 15:41:48 i had 15:42:42 hmmm. maybe escaping could also work 15:43:10 well, it still implies a change 15:43:25 yes, unfortunately. 15:43:44 And if we change the api then we need to change all clients too 15:45:11 Okay just to understand. As a first step, we are okay with having the same functionality for dimension spliting in python-api as it is in java-api 15:45:14 ? 15:45:28 yes 15:46:19 Great. Thanks. And afterwards we can work on the "colon in key" problematic 15:46:26 sounds good 15:46:50 Thanks. That's all from my side 15:46:58 for which a doc change and parser change to restrict it in the dimension key is the easiest solution 15:47:07 i believe 15:47:27 yes, i think too 15:47:42 thanks Kamil and Roland 15:47:54 welcome 15:48:09 so, i think that covers that section in the agenda 15:48:17 thanks kamil_ for working on this 15:48:57 are there any other topics to discuss? 15:49:02 #topic open floor 15:49:09 @rhochmuth welcome 15:49:35 witek: are we every going to cover the neutron topic that we didn't get to at the mid-cycle 15:49:48 i was just wondering if we needed to cover that still? 15:50:03 we could, if there is interest 15:50:51 i thought you needed to discuss this with the monasca project as there might be something that neutron need to add/implment 15:51:36 we need to add cross-tenannt functionality to log agent 15:51:44 that's all actually 15:51:49 i see 15:51:54 most of the changes are on Neutron side 15:52:00 if that is all, then i'm not sure we need to discuss 15:52:37 but, if the neutron folks wantted to have a design discussion then i'm certainly open to accomodating that 15:53:24 OK, I'll let you know 15:53:29 thanks 15:55:00 ok, i think we can close the meeting a little early then if there are no other topics 15:55:28 bye everyone 15:55:35 thank you Roland 15:55:41 and everyone 15:55:42 bye 15:55:56 #endmeeting