15:00:29 #startmeeting monasca 15:00:30 Meeting started Wed Apr 26 15:00:29 2017 UTC and is due to finish in 60 minutes. The chair is rbrndt. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:35 The meeting name has been set to 'monasca' 15:00:39 Hello 15:00:42 hi 15:01:24 hello 15:01:31 hello 15:01:52 o/ 15:02:02 o/ 15:02:03 I see we have something on the agenda this time, specifically the keystone uwsgi item 15:02:20 hello 15:02:33 yes, it's a little more than this actually 15:02:37 I have one more item to discuss 15:03:03 Jose Romero from op5 15:03:30 Alright, well perhaps we can start with the keystone item on the agenda first, which is also from you? 15:03:40 yep 15:03:47 Take it away 15:04:15 Keystone is from me 15:04:35 Sorry, I was just going off who entered it on the agenda 15:04:39 we have investigated failing gate jobs in the last week 15:04:59 and found out that devstack moved to using uwsgi 15:06:28 keystone and other services are hosted on apache now with port 80 and aliases 15:07:38 Tomasz and Artur try to adapt the devstack plugin to reflect that 15:08:07 but we still have errors on Java tempest tests 15:09:43 so the current status is, that for about two weeks now we cannot merge anything because of failing tempests 15:10:07 python looks good now, Java still not ready 15:10:50 Do you have some output or a failing review with the errors from the java side? Would be good to have on the meeting record 15:10:56 I was wondering if we could set Java tempests as non-voting until we solve the issue? 15:12:54 I'm generally against turning off tests, because it is very easy to never turn them back on. 15:14:03 That being said, we have been planning on moving away from java, and most new features are not planned to be added to the java side 15:15:12 Anyone else have an opinion? 15:16:41 I generally agree with you about switching off the tests not being goot, but it is quite a blocker at the moment 15:18:14 Alright, well I think Roland should probably way in on this, but if you want to submit a review to change the tests to non-voting perhaps we can discuss more there 15:18:28 for my prespective as new java is only necesary for legacy then... we had this problem this week and we checkout a a previos version of devstack 15:19:20 which is not best but helps to have it all working 15:20:12 The java has long been a bit of a thorn in the side when dealing with devstack and CI, so dealing with it in a long term solution could be very helpful 15:21:06 Any last thoughts on that topic? 15:22:09 I will add the change to project-config and let's discuss in review 15:22:32 Sounds good. That covers the agenda then. Neptu, you had another topic? 15:22:37 yes 15:22:54 ty witek 15:23:01 we just got started with monasca here at op5 to use it as core of one of the new products 15:23:16 so we have been analizing the different parts 15:23:23 and we see an issue with influxdb 15:23:36 since after version 0.9 the cluster side is paid version 15:23:59 so we cannot really scale up monasca without paying licences 15:24:07 and I was wondering ig there is something on the roadmap 15:24:40 to add support for cluster of the metridb throw another persistor to ... other metric db 15:25:29 That is something that has been a bother for a while. We've explored several options, with cassandra being the most promising 15:26:03 However, there are issues with the data model required for cassandra at higher metrics loads. It seems not viable for large scale. 15:26:22 graphite cairos maybe? 15:27:07 donno i just want to undestand that is not an stopper and we could integrate with something else semi-easily 15:27:27 we are 3 ingeneers now in the project and growing but we lack the experience on monasca 15:27:52 but we could code another persistor if its a must 15:28:13 Let me see if I can find some documentation of our research into cassandra. Modifying the persister should be the easy part 15:28:36 i think so 15:28:42 The API needs a new respository as well which is a little more involved, but still very doable 15:28:59 The real key is the data model 15:29:25 The API is setup to slice and dice the data a lot of different ways, which doesn't work well in cassandra 15:29:38 and most other cassandra based options 15:30:05 Neptu: which data rates are you aiming, how many metrics/s do you want to store? 15:30:05 We had vertica integrated for a while, but that is also a paid option 15:30:13 so you kind of build different representation of the same data 15:30:25 Yes 15:30:32 witek: conceptually management is talking about 9M /minute 15:30:38 Good question wwitek 15:30:44 maybe more 15:31:15 I know from some other companies had that done with monasca here in stockholm 15:31:29 so should be duable with influx 15:31:37 but maybe we do not have influx any more 15:31:37 ... 15:31:49 9M /minute is about ... 15:32:12 150,000 / sec 15:32:18 9M/minute is a buzzword here in the office 15:32:23 that's generally higher than we've run monasca before 15:32:23 InfluxDB reported 900k/s on single node 15:32:37 metrics 15:32:53 or Kbps 15:32:55 In our testing, influx has been significantly lower than the 900k /s 15:33:13 metrics 15:33:35 i mean at this point i have no requirement of how many instances i need to spin to get the job done 15:33:58 the question is with a single machine is a bottlenek for sure 15:34:03 https://docs.influxdata.com/influxdb/v1.1/administration/differences/ 15:34:28 for HA you can use influxdb-relay or kafka 15:34:54 In deed. I think the simplest answer (though not the easiest) is if you can find a replacement, we'd love to have a non-paid one. 15:35:01 but influx is used only for storage or aswell runs statistics and searches... 15:35:22 i have experience with mongodb but might not be the best one 15:35:41 i would like to further talk with someone that has the experience 15:35:47 so we can maybe solve this somehow 15:35:57 we can allocate resources probably for it 15:36:04 is a question of proper guidance 15:36:25 so we do code and recode 10 times before is workcable 15:36:34 I would be happy to talk to you about it in more detail sometime. I can also raise this to roland who probably has the data from our week investigating cassandra 15:36:49 awesome 15:37:19 jromero@op5.com 15:37:26 pop me a mail and we continue from there 15:37:32 Sounds good. 15:37:39 please put me on cc 15:37:46 yep 15:37:55 will be nice if you had a #monasca channel 15:38:02 im always on irc 15:38:08 #openstack-monasca :) 15:38:12 am 15:38:13 good 15:38:23 :) 15:38:23 You can usually find me in the monasca channel if you have quick questions 15:38:39 yes i will add it to my znc 15:38:55 Alright, I think that wraps that up for now. Anyone else have any topics? Open floor 15:38:57 thanks so we continue from there 15:39:23 I wanted to ask, who will attend the Summit? 15:39:37 I'm going 15:39:46 I was mistaken in the last meeting, Roland will be attending as usual 15:40:20 Dan and myself (from Suse) will be going 15:41:05 sc: I'm sorry, I cannot 'decode' your nick :( 15:41:23 sc@linux.it aka stefano.canepa@hpe.com 15:41:30 :) 15:41:36 sorry 15:42:02 witek: NP, if you need help for the training session just drop me an email 15:42:21 Cristiano and me will join from Fujitsu EST 15:42:43 sc: thanks, I'm still working on material 15:42:49 Witek: as you know, I will join from Fujitsu Japan 15:43:33 witek: I'm starting to prepare my slides tomorrow ;-) 15:43:41 :) 15:43:53 Hope it goes well 15:44:19 Ok, well any more topics? 15:44:30 if not we can all have 15 minutes back 15:44:59 thank you Ryan 15:45:21 Thanks everyone 15:45:28 see you 15:45:37 #endmeeting