15:00:08 #startmeeting monasca 15:00:09 Meeting started Wed Oct 14 15:00:08 2015 UTC and is due to finish in 60 minutes. The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:13 The meeting name has been set to 'monasca' 15:00:14 role call 15:00:16 o/ 15:00:21 0/ 15:00:22 o/ 15:00:28 0/ 15:00:32 o/ 15:00:34 o/ 15:00:35 o/ 15:01:01 give it a minute or two 15:01:24 we only have one agenda topic listed 15:01:31 1. Fujitsu: 15:01:32 a. paging issue for monasca-api 15:01:44 If anyone else has anthing to add please doo 15:01:52 Tomasz wanted to bring it up, but i don't see him :( 15:01:53 last week we were completely booked 15:02:01 Here is the link, https://etherpad.openstack.org/p/monasca-team-meeting-agenda 15:02:20 i think i saw some reviews for the paging issue 15:02:39 is thing something that we just need to get some reviers looking at, or is it something else 15:02:55 I think it's a bigger issue 15:03:01 ohhh 15:03:14 not really an "issue", rather an extension 15:03:31 so, basically new features 15:03:38 yes 15:03:56 do you want to try and discuss now or wait until tomasz is available 15:04:02 one use case in which it came up was when one wants to sort the alarms on the Horizon page, e.g. by severity 15:04:14 I think that makes sense 15:04:21 absolutely 15:04:27 we've had similar discussion here 15:04:44 I just remember that Tomasz mentioned that an API change would be necessary to get this sorting feature on the UI 15:04:47 ok 15:05:03 right now we can only filter on certain fields, like severity, but we can't order by 15:05:28 so, if you wanted to page through your alarm ordered by state and severity, you can't really do that 15:05:35 so, i think that would be extremely useful 15:05:45 currently, we are doing client side processing 15:05:45 have you ever discussed that before? 15:05:55 but that implies brining in the entire list 15:05:58 yes, that's the problem I guess 15:06:07 we have just had some discussion on the hp team locally 15:06:11 nothing to detailed 15:06:26 our ui/ux team has had some requests in this area 15:06:35 but we aren't working on them yet 15:07:03 so, i think we are all in agreement that this would be extremely useful 15:07:11 the only problem is getting resources to address it 15:07:23 ok.. on the Fujitsu side, this topic is not urgent. But I think that at some point we will start working on it 15:07:31 yes, I know this problem :) 15:07:42 ok, whoever gets to it first can do it 15:07:56 yes 15:07:58 i don't think it is a difficult area 15:08:06 and is probably low hanging fruit 15:08:13 easy to add, with a big benefit 15:08:26 that sounds good 15:08:47 I guess that's all I can say to it. Tomasz knows the details 15:08:56 ok 15:09:03 how about we move on then 15:09:20 no one has added more agenda topics 15:09:29 i think discussing status would be good 15:09:30 If you like, you can give us a status update on your work at HP on the logging stuff 15:09:36 sounds good 15:09:51 I remember that TSV wanted to start looking into it in September or October or so 15:10:11 yes, i think we are starting to free up 15:10:21 our original dates got pushed out 15:10:31 same thing on our side 15:10:40 so in another week or two i think we'll be available to start working on the logging stuff again 15:10:56 so, let's say after the tokyo summit 15:11:00 sounds great 15:11:00 to be safe 15:11:31 we are really incented to get this work completed 15:11:32 we can also discuss more about that in Tokyo.. split up work etc. 15:11:42 so i think you'll see a very strong commitment from hp in this area 15:11:52 ok, great 15:12:13 sure, yest we can discuss in tokyo 15:12:23 will TSV be there? 15:12:29 tsv won't be going as it turns out, but we'll have another representative from teh logging team 15:12:53 so we'll have enough representation 15:13:17 has anyone looked at devstack 15:13:29 or the Tempest tests 15:13:40 the tempest tests have been up for review for a while 15:13:48 i would like to get them merged 15:14:00 if folks can at least take a quick look and +1 taht would help 15:14:13 if not, we'll probably get them merged real soon anyway 15:14:32 mroderus, will start looking at this from next week. I will not be there for the summit but would like to be involved in any mail/chat discussions if possible. thanks 15:14:51 thansk tsv 15:15:01 you'll be involved in everything of-course 15:15:40 Here is the review for the Tempest Test, https://review.openstack.org/#/c/228122/ 15:15:40 tsv: sounds good. we'll surely involve you in the discussions 15:16:06 there are of-course lot's of enhancements to continue to add 15:16:15 but i think it is in reasonable state to merge 15:16:27 then it will be much easier to collaborate with others on with 15:17:04 hopefully, the overall organization and framework seems reasonable to folks, although much of this was dictated by the conventions that had already been put in place 15:17:31 There is also a README at, https://review.openstack.org/#/c/228122/23/monasca_tempest_tests/README.md, that descriebs how to run them 15:17:42 using the monasca vagrant environment 15:17:51 it should be really easy to run them 15:17:58 but if anyone has any issues please let me know 15:18:45 Devstack is also getting in good shape 15:19:15 However, I've been trying to use the Monasca Devstack with a Vagrant virtualbox vm, and hitting an issue 15:19:25 Everything is working for Deklan pergectly though 15:19:37 but he was smart enough to build his own VM from scratch 15:19:49 and i'm too stubborn to do that 15:20:10 anyway, it is very easy to get started with DevStack 15:20:28 you'll need to use a ubuntu trusty os 15:21:12 There is a nice README at, https://github.com/stackforge/monasca-api/tree/master/devstack, that describes the variables to set 15:21:44 We've been potentially discussing if the monasca devstack works whether it will maek sense to continue with the monasca-vagrant environment 15:21:54 so, that is a potential topic for the future 15:22:27 how many environments do we have at the moment? DevStack, Vagrant and Docker? 15:22:45 yes, i think that is all 15:22:50 ok 15:22:57 \o 15:23:20 so, unless questions on tempest and devstack let's move on 15:23:46 Are there any reviews that folks are pushing to get reviewed? 15:24:01 i'd like to see https://review.openstack.org/#/c/234266/ get merged.. 15:24:17 monasca-api change (Check entire set of value_meta key/value pairs for length) 15:24:23 yes 15:24:30 deklan did you take a look at that one 15:24:31 i take a look at it today 15:24:36 gracias 15:24:53 i looked at it and it looks fine to me 15:25:00 i guess i didn't +1 15:25:22 but i will soon 15:25:23 thx -- we expanded our db today for value_meta to 8192 15:25:31 in production? 15:25:35 yup 15:25:42 how did that go? 15:25:51 no issues! 15:25:56 awesome 15:26:12 thanks for doing that 15:26:14 now we can bring in new monasca-agent with all the goodness libvirt fixes next week 15:26:16 np 15:26:23 :) 15:26:50 I'd quite like to progress https://review.openstack.org/228975 (or equivalent) as I'm otherwise I'm maintaining an internal fork 15:27:27 tomasz left some comments 15:27:37 but he was overall happy with it 15:28:25 ok, i'll take another look and get some eye on it here 15:28:31 great, thanks 15:28:33 i don't see any issues with it 15:28:38 if someone could +2 this that would be great https://review.openstack.org/#/c/234464/ 15:29:47 i just +1'd 15:29:54 straight-forward fix 15:30:04 if others agree, please +1 or +2 15:30:18 looks like a simple fix that will address some lingering issues in the python api 15:30:47 yea, measurements list does not work in python api without this fix 15:31:31 so, did this work at one point, and then influxdb broke us 15:31:57 this problem was not discovered because the python api was developed using the java persister 15:32:09 ohhh, yeah i recall now 15:32:15 now that devstack is up and running, we can have both python persister and python api running at same time 15:32:45 some incompatibilities were exposed 15:33:23 ddieterly: let me know if my response to your comment in https://review.openstack.org/#/c/234252/ doesn't make sense 15:33:26 so, that is also worth pointing out with the devstack is that there is an easy way to select either the jave or python components 15:33:40 bklei: ok 15:34:16 yes, the goal is to test for an upper bound 15:34:58 i think we need to determine the actual encoding of the chars in vertica 15:35:04 i don't think it is worth converting the value meta to UTF32 and then testing for an exact fit 15:35:40 the vertica support folks indicated UTF-16, but roland found some links that seemed to imply it could end up being UTF32 15:35:47 just being safe 15:36:00 (other reviews roland has up do X4) 15:36:04 sorry, i think you are correct on the utf16 15:36:14 but that still means it can be 4 bytes 15:36:25 similar to how utf16 can either be 1, 2, 3 or 4 bytes 15:36:46 well, maybe not 1 15:36:50 gotcha, then as a rule i agree with chars X 4 for safety 15:36:58 also, does the varchar(n) specify chars or bytes? 15:37:13 varchar is bytes 15:37:16 right 15:37:19 that is what the document says 15:37:25 should have been varbytes 15:37:31 :-) 15:37:34 lol 15:37:44 that does not seem right to me 15:37:46 sorry 15:37:57 what doesn't seem right? 15:38:02 that varchar is bytes? 15:38:12 if i say varchar(1), and i stick a 2 byte char in there, then it would blow up? 15:38:24 that is my understanding 15:39:03 doesn't that seem counterintuitive? 15:39:14 https://my.vertica.com/docs/5.0/HTML/Master/1231.htm 15:39:16 sorry old link 15:39:24 The maximum length parameter for VARCHAR and CHAR data type refers to the number of octets that can be stored in that field and not number of characters. 15:39:33 that is a quote 15:39:42 well, if that is what is says... 15:39:48 When using multibyte UTF-8 characters, the fields must be sized to accommodate from 1 to 4 octets per character, depending on the data. 15:39:59 that is another quote 15:40:18 those whacky vertica folks 15:40:33 hey man -- your company 15:40:55 There si also the review i submitted at, https://review.openstack.org/#/c/231741/ 15:41:14 i need to address tomasz comment 15:41:30 but it is a similar change 15:41:53 but in the persister 15:42:38 I'll +1 that when you add comment as to why x4 15:42:47 but agree with the change 15:43:07 i think i'll just introduce a static var with a good name 15:43:13 cool 15:43:27 so unless more reviews to talk about 15:43:33 we can move on 15:43:43 i was wondering about grafana 2.0 support 15:43:54 has that progressed further? 15:43:55 rbak: you here? 15:44:07 yep, sorry 15:44:39 I'm finally getting some time to actually work on grafana, but I don't have a whole lot to give an update on 15:45:04 sounds goo 15:45:24 do you think you'll be able to make some progress over the next few weeks then? 15:46:15 Yeah, definitely 15:46:34 does it make sense to start talking to the Grafana project at this state or should we wait till we've implemented our changes and then try to get our changes merged? 15:46:50 I would wait 15:46:54 ok 15:47:05 It shouldn't take too long as long as I can focus some time on it 15:47:57 ok, i've run out of topics 15:48:05 i have a question 15:48:12 #questions 15:48:18 #topic questions 15:48:21 is anyone trying to run the python code? 15:48:43 not yet at twc 15:48:49 i've found 3 bugs that would prevent the api from working 15:49:02 bmotz: aren't you doing something with the python? 15:49:38 crickets out there 15:50:02 well, that's all i got ;-) 15:50:04 one question for rhochmuth -- any progress on caching in api? 15:50:12 no progress 15:50:15 sorry 15:50:34 ok -- i hope to make https://review.openstack.org/#/c/221492/ more comprehensive -- this week 15:50:43 (avoiding multiple inner joins) 15:50:54 sounds good 15:51:01 bklei: sweet! 15:51:17 starting weekly meetings with vertica folks -- they're pushing back on that, caching, etc. 15:51:54 bklei: we eagerly await your submission for review ;-) 15:51:56 as for VER-40005 -- that fix is a lon way out 15:51:59 :) 15:52:32 s/lon/long 15:52:33 InfluxDB is claiming 300K metrics per seconds 15:52:37 See, https://influxdb.com/blog/2015/10/07/the_new_influxdb_storage_engine_a_time_structured_merge_tree.html 15:52:56 Time Structured Merge Tree or TSM Tree for short 15:53:08 would like to see if that's really true and the cluster stays up/stable 15:53:29 but promising 15:53:32 Yes, I agree 15:53:45 Sounds like they are making progress though 15:54:24 Anyway, it is an interesting read 15:54:49 i wonder if that's another complete re-write 15:55:27 ok, time is winding down 15:55:52 should we adjourn? 15:55:58 +1 15:56:09 whoops, sorry - missed that 15:56:17 hold-on 15:56:20 I've been evaluating the python API, but not using it in anger 15:56:28 (in answer to ddieterly's question) 15:56:36 thanks bmotz 15:56:49 bmotz: what's 'anger'? 15:56:54 ddieterly has made some recent changes 15:57:02 a real deployment 15:57:34 I found quite a few bugs using it casually, so didn't want to go further until tempest tests, etc, were in place 15:57:43 and there was some confidence around it 15:58:01 i see 15:58:20 we'll be getting it into shape more now 15:58:30 sounds good 15:58:36 i'm fixing more bugs today 15:58:40 great :) 15:58:45 ddieterly: vertica support in python? 15:58:57 lol, no 15:59:06 is helion going to switch to python? 15:59:19 that is the goal 15:59:25 that is the long-term goal 15:59:45 cool 15:59:51 does vertica have python drivers? 15:59:51 so, our focus will start to transition 15:59:56 ok, winding down 16:00:09 can research ddieterly 16:00:17 by everyone 16:00:21 thx roland 16:00:24 ciao 16:00:26 thanks, bye! 16:00:35 Bye 16:00:40 bye 16:00:41 #endmeeting