15:00:18 #startmeeting monasca 15:00:23 Meeting started Wed Mar 29 15:00:18 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:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:27 The meeting name has been set to 'monasca' 15:00:41 \o 15:00:42 \o/ 15:00:44 o/ 15:00:46 https://etherpad.openstack.org/p/monasca-team-meeting-agenda 15:00:47 \m/ 15:00:57 Agenda for Wednesday March 29 2017 (15:00 UTC) 15:00:57 1.  Reviews 15:00:57 1. https://storyboard.openstack.org/#!/story/1670277 15:00:57 1. See last comments in the bottom (from trebskit) 15:00:57 2. https://review.openstack.org/#/q/topic:bug/1670277 15:00:57 2. https://review.openstack.org/#/c/447010/ 15:00:58 3. https://review.openstack.org/#/c/409252/ 15:00:58 4. https://review.openstack.org/#/c/379093/ - how to proceed, see comments 15:00:58 5. https://review.openstack.org/450868 (WIP - Request for feedback) 15:00:59 \o 15:00:59 2. Monasca Grafana App: http://lists.openstack.org/pipermail/openstack-dev/2017-March/114637.html 15:00:59 3. Standardizing ElasticSearch template [schema] [log-query-api] [Story: 2000934, Task: 4078] 15:01:04 o/ 15:01:06 wow, lot's of topics 15:01:17 o/ 15:01:20 hi 15:01:34 #topic reviews 15:01:41 o/ 15:01:46 https://storyboard.openstack.org/#!/story/1670277 15:02:02 that's me 15:02:18 you have the floor 15:02:23 I think that it'd be for the best to just refer to this https://storyboard.openstack.org/#!/story/1670277#comment-10348 15:02:32 instead of writing it all over again 15:02:34 :) 15:02:37 if that's fine with you all 15:03:04 are there othre projects using gunicorn and oslo.cfg? 15:03:09 no[e 15:03:11 *nope 15:03:24 as a matter a fact, I could not find any openstack application using gunicorn 15:03:40 kornica: it may be freezer 15:03:44 everything (or at least several I checked) uses oslo_services 15:03:56 sc: ok, might be worth checking how they resolved that 15:04:40 no, just checked in source 15:05:17 they;re using either uwsgi or simply mod-wsgi for apache 15:05:40 Alwa: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 15:06:00 nevertheless the core of the problem is inability of monasca-api, monasca-log-api to accept CLI opts as defined by them 15:06:09 assuming launching them with gunicorn 15:06:17 a.k.a gunicorn --paste /etc/monasca/some-api.ini 15:07:16 gunicorn does not clean sys.argv from its arguments and they are all available for the actual application 15:07:29 and argparse their throws error about unknown cli opt 15:08:02 so, i got a question 15:08:06 ? 15:08:13 are we fixing issues because they are causing problems somewhere 15:08:48 or are we just fixing problems, but there isn't a problem somewhere 15:09:04 the actual issue is that configuration of both apis is hardcoded 15:09:06 the folder 15:09:07 i'm spending a lot of time on reviews 15:09:15 and the names of the files 15:09:23 but, i'm not aware of any issues that this is causing folks 15:09:45 was this a bug that you ran into that was causing deploy issues 15:09:49 for you or someone else 15:09:55 pretty much 15:10:28 is that this was causing problems? 15:10:48 we've entered that when we're working on rpm-packaging and their convention was to have /etc/{component_name} so (/etc/monasca-api) but it turned out to be immposible to use such location 15:11:00 i see 15:11:05 because monasca-api expects /etc AFAIR 15:11:11 and log-api expects /etc/monasca 15:11:31 ok, i'll review closer 15:11:44 i don't see any major issues/problems 15:11:58 just need a minute to get my mind wrapped around it further 15:12:20 well, it's not major - but annoying for sure, I mean I'd expect that I can pass some arguments of my app using CLI 15:12:53 ok, i will look at further 15:13:05 thx, guess that's all 15:13:21 thanks kornica 15:13:52 https://review.openstack.org/#/c/447010/ 15:14:36 mine - think it might be ready, maybe perhaps probably? 15:14:45 Internal interfaces for log listing API implementation 15:14:50 yes, i +1'd 15:15:19 ok, i just +2'd 15:15:28 it is in flight being merged 15:15:34 I have one minor comment, but I think that can be handled (it necessary) in following changes 15:16:18 cool, thanks both 15:16:26 oops, missed the comment 15:16:32 oh...just realized I didn;t check the generated documentation 15:16:34 saw the +2 from tomasz 15:16:54 sc: I think you missed updating docs to include new packages there 15:17:23 rhochmuth: mine comment was really sth to keep in mind, not enforcing sc to fix that right away or anything close to that 15:17:39 sc: I think we can do this in another change 15:17:56 next review, https://review.openstack.org/#/c/409252/ 15:18:02 thanks kornica 15:18:11 https://review.openstack.org/#/c/409252/ 15:18:14 ooops 15:18:28 mine again 15:18:51 oh looks like tomasz has already done it, ta 15:19:06 yeah, but python gate failed 15:19:19 thought artur fix for recent gate failure will handle that 15:19:21 that's wierd, it's only a readme change 15:19:46 yeah, but monasca-api itself started to fail (app) because of oslo.cfg or oslo.db bump...or something els 15:19:59 anyway, turned out that one of the params in oslo.db config setup was removed 15:20:04 in library 15:20:11 but monasca-api had it still in its source code 15:20:49 ah ok - makes sense now 15:21:09 anyway: change is ok, I walked through it and managed to run monasca-persister using recipe there directly from CLI and using service code from example 15:21:13 *from README.md 15:21:25 kornica: sorry for the delay (I'm at customer site) but I agree 15:22:31 so, that review looks good to me 15:23:37 thanks kornica 15:23:45 rhochmuth: sure 15:24:26 https://review.openstack.org/#/c/447010/ 15:24:49 ooops 15:25:14 https://review.openstack.org/#/c/379093/ 15:25:24 grabbed the wrong link 15:25:28 that's mine 15:25:34 i think i'm on track again 15:25:42 yeah, you are :) 15:26:27 ok, this change is similar to others were monasca was migrated to use ostestr and what's more important bandid 15:26:30 *bandit 15:26:35 for code analysis 15:26:36 jenkins says merge conflict 15:26:46 yeah, but that's not the actual problem I have with it 15:26:47 but looks like it is ready, other than that 15:26:53 i see 15:27:07 well Craig pointed out that amount of disabled checks from bandit it quite large 15:27:43 I agreed with that previously and recently tried to fix category 6XX (mainly process.Popen related) 15:27:57 but turned out that fixing one, creates different violations 15:28:15 all in all - I don't know which course is better 15:28:24 to spend time fixing bandit violations 15:28:33 or to accept that without bandit 15:28:57 or maybe accept with disabled bandit checks but still providing ostestr, coverage and so on 15:29:19 just want to say hi. I am a developer from OP5 monitoring and we are building a mon product with monasca. hopefully could contribute somehow to the project. 15:29:33 hi hum 15:30:10 kornica: i would accept without bandit fixes 15:30:14 then try and resolve 15:30:17 over time 15:30:50 agree 15:31:18 ok, I will rebase that tommorow and leave it for you or another CR to accept 15:31:29 thanks kornica 15:31:41 that's all about it 15:32:01 thanks 15:32:30 https://review.openstack.org/#/c/450868/ 15:32:34 oh no 15:33:10 stevejms 15:33:15 u there? 15:33:19 mine - don't have to discuss now, just wanted to request some feedback 15:33:37 will try and get too 15:33:49 trying to still catch-up on other reviews 15:33:53 still 15:34:17 https://storyboard.openstack.org/#!/story/2000954 15:34:22 ok thanks 15:34:51 Yes, that storyboard is for a Ceilosca change 15:35:10 thanks joadavis 15:35:11 Just wanted to share it, in case someone on the broader Monasca team had interest and wanted to comment 15:35:50 there might be some feedback from fabio giannetti and sriniva from cisco 15:36:01 i haven't been looking at the ceilosca code for a while 15:36:23 i'm trying to think of others using ceilosca, besides suse/hpe 15:36:31 Yes, I'll be sure to contact them too. I also requested comment from Pablo, who wrote a similar blueprint, though I don't know if he is involved still 15:36:35 i will try and take a look 15:36:52 thanks joadavis 15:37:36 in storyboard i havent' adjusted status 15:37:44 but, if there is anything i need to do on this, let me know 15:37:51 I think that is all I had for that storyboard, aside from my general opinion that there will need to be some changes down the road for Ceilosca due to all the churn over in Ceilometer 15:37:55 in general, it all sounds good 15:38:02 thanks 15:38:20 http://lists.openstack.org/pipermail/openstack-dev/2017-March/114637.html 15:38:33 stevejis: you are up 15:38:47 that's mine 15:39:00 i'm really excited about this 15:39:02 yes something we have built for a client - wanted to gauge upstream interest 15:39:02 thanks for doing this 15:39:20 no problem 15:39:26 well, i was talking to grafanalabs about that very topic before i saw your email 15:39:36 like an hour before 15:39:57 would be useful for testing without horizon as well, like monasca docker. 15:39:58 grafanalabs isn't too excited about adding direct support for our alarm definitions, alarms, notification directly to grafana 15:40:11 they would prefer an app plugin 15:40:14 ha, that's a coincidence 15:40:32 yes, i was a little dissapointed after to talkign to them about that 15:40:46 but you changed my day 15:40:48 i'd certainly use an app plugin if it was available. 15:40:49 yes notq i also thought it might benefit monasca-docker 15:41:03 it sure will 15:41:13 i'm wondering how far do you plan to take it 15:41:23 i don't know about our ability to help write code 15:41:36 for this area 15:41:43 so we're happy to put more time into it 15:41:52 but, i can help on reviews and advice 15:41:56 at least for the items i mentioned on the list 15:42:13 we spent a lot of time developing our own dashboard for helion openstack, 15:42:26 but, that doesnt' help us for kubernetes/docker deployjments 15:42:47 so, would you like to add this as an openstack repo 15:42:56 or keep this on the side at the moment 15:43:02 outside of openstack 15:43:11 gerrit could slow you down 15:43:15 at least initially 15:43:49 but, it woudl be nice to have in openstack, since we have the monasca-grafana-datasource there 15:43:55 anyway, up to you 15:44:06 it might hinder in the short term, but we're keen to have it upstream, as with everything we're working on 15:44:37 got it, so lot's consider have it moved to upstream after it is in better shape 15:44:54 i'll try and look at it 15:45:02 i don't know how to get others involved right now 15:45:08 from hpe 15:45:24 @stevejims - let me know when it's together, i can test and provide feedback. we have our own dashboard as well, and it makes development a bit strange. would be great to use it with docker env 15:45:27 yes it might be worth doing after i've got the remaining basics in e.g. alarm history 15:45:28 other than a contractor, or me working 24x7 15:45:42 i can supply requirements 15:46:03 what preparation would be needed for upstreaming, i can start work on that in parallel 15:46:05 i'm sure you have your own list though 15:46:19 whenever it is ready 15:46:47 thanks notq - the code that is up is completely functional 15:47:08 just missing some pages e.g. alarm history 15:47:20 when ryan bak added the grafana datasource, there weren't additional steps 15:47:26 requirements 15:47:43 there are a couple of config files in openstack-infra 15:47:51 which have to be updated 15:47:54 requirements would be great rhochmuth 15:48:06 when you navigate, are you using metrics names, dimension names and dimension values reqoures 15:48:12 that would be fastest 15:48:40 sweet, i'll try installing it and using it today. maybe we can get it in the docker-compose automatically, which would be best. 15:48:43 if you use the metrics resource to query metrics, at some point, that will be a performance problem 15:48:47 so the places that have dimension name as input do suggests using those resources, yes 15:49:02 the alarm definition editor is currently a text-box, that is high on the todo list to improve 15:49:31 kornica did a nice job on the alarm expression editor 15:50:06 i think good support for filtering, grouping and ordering is really important 15:50:13 rhochmuth: my idea, at least for UI, was using ACE with alarm expression syntax 15:50:14 as well as pagination 15:50:31 everything will be ok with a small set of alarms 15:50:54 but, as some point just querying alarms and doing client side ops will breakdown 15:51:06 all sounds good - i'll put it on the list 15:51:09 so, using all the server side query parameters for that is really important 15:51:34 yes notq it should be fairly straightforward to add it to the docker compose environment 15:51:52 the alarm counts is really good for the overall counts of alarms 15:52:11 as the anme suggests 15:52:14 there's already an init for grafana, so should be adding it through that. 15:52:51 i guess i'll see, either way, fills a need. thanks stevejims 15:52:52 also, you'll want to track the reviews in progress for alarm silencing, inhibition and grouping 15:53:11 those have ui components that need to be added too 15:53:17 but it isn't completed yet 15:53:37 sure, we're going to want those features too 15:54:04 evenutally MQL will be supported, but rbrandt got side-tracked for the moment 15:54:11 so that is further out 15:55:19 shall i collect this discussion into a storyboard? 15:55:26 i think views like display alarms in the ALARM'd state, ordered by severity and timestamp are good 15:55:31 that might be a good idea 15:55:39 with a goal of moving upstream once feature complete 15:55:50 yes, sounds good 15:56:06 ok will do 15:56:10 thx 15:56:22 #topic Standardizing ElasticSearch template [schema] [log-query-api] [Story: 2000934, Task: 4078] 15:56:24 last one 15:56:25 who from the monasca-docker repo would be worth pinging? 15:56:44 michael hoppal 15:56:51 and tim buckley 15:57:08 ok thanks 15:57:16 if you ned emial let me know 15:57:41 so, i don't think we'll cover your last topic 15:57:49 as we have to close the meeting down 15:58:00 no problem - we can do it offline 15:58:04 thanks 15:58:06 ok, sounds good 15:58:14 stevejims: I can help with any monasca-docker things 15:58:22 bye 15:58:42 bye hamil_ 15:58:48 thanks timothyb89 15:58:50 thanks timothyb89 15:59:01 stevejims was asking about monasca-docker 15:59:27 so, i'll let you two shat off-line as we are out of time 15:59:32 chat 15:59:35 ha 15:59:37 lol 15:59:42 :) 15:59:47 i'm good for now... 15:59:48 yeah, that was one letter away from being somethign else 16:00:06 :) 16:00:20 ok everyone, thanks 16:00:23 see you next week, cheers. 16:00:28 thank you 16:00:29 i'm trying to get more engaged again 16:00:36 so will try and get some reviews in this week 16:00:41 bye everyone 16:00:50 #endmeeting