15:00:17 <rhochmuth> #startmeeting monasca 15:00:17 <openstack> Meeting started Wed Nov 25 15:00:17 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:22 <openstack> The meeting name has been set to 'monasca' 15:00:22 <rhochmuth> o/ 15:00:27 <slaweq_work> bye 15:00:33 <mroderus> o/ 15:00:35 <njohnston> thanks all 15:00:43 <bklei_> o/ 15:00:48 <witek> hello 15:00:53 <bmotz> o/ 15:00:54 <bklei_> hola 15:01:17 <rhochmuth> hi everyone 15:01:24 <bklei_> happy turkey day 15:01:36 <rhochmuth> i'm supposed to be off this week, but i failed in that endeavor again 15:01:44 <bklei_> rats 15:02:15 <rhochmuth> so, i haven't really been responding to emails, and not been doing review 15:02:23 <rhochmuth> or writing code 15:02:33 <rhochmuth> but i'm here 15:02:46 <mroderus> good to read you again :) 15:02:55 <rhochmuth> so, we might as well get started 15:03:13 <rhochmuth> There is a review at, https://review.openstack.org/244483 15:03:36 <witek> thats mine 15:03:47 <rhochmuth> i started to take a look at this last week 15:03:51 <rhochmuth> it looks fine to me 15:03:59 <witek> nice 15:04:02 <rhochmuth> the only reason i haven't merged is test 15:04:12 <rhochmuth> just trying to verify all is good 15:04:19 <rhochmuth> i won't get to it this week 15:04:23 <witek> ok 15:04:44 <rhochmuth> i asked for some help from my team, but obviousely know one else looked at it either 15:04:47 <rhochmuth> so, sorry 15:05:02 <rhochmuth> the bottlneck is just verification 15:05:09 <rhochmuth> that everything still works 15:05:36 <witek> i wanted to push log management into monasca-vagrant 15:05:44 <witek> and it blocks a little 15:05:55 <rhochmuth> unless someone else looks at it, then we'll just have to wait a little longer 15:06:26 <rhochmuth> so the log-api in monasca-vagrant would be another area 15:06:43 <rhochmuth> so, are you blocked on https://review.openstack.org/244483 15:07:01 <rhochmuth> before you want to proceed adding the logging support? 15:07:11 <witek> yes, but I want to sync our ansible roles 15:07:32 <rhochmuth> the only other option is to do the merges and hope for the best 15:08:00 <rhochmuth> i would prefer not doign that 15:08:12 <witek> it's fine 15:08:31 <rhochmuth> so, there changes to three ansible roles and then the monasca-vagrant changes 15:08:48 <witek> that's right 15:08:56 <rhochmuth> are you ok waiting a little longer 15:09:15 <witek> how little is little? :) 15:09:26 <rhochmuth> epsilon 15:09:34 <witek> :) 15:09:39 <witek> it's ok 15:09:52 <rhochmuth> i'll see what i can get done in the background 15:10:04 <rhochmuth> but early next week is what i would target 15:10:10 <witek> great 15:10:35 <rhochmuth> THen there is, https://review.openstack.org/#/c/241626/ 15:10:52 <bklei_> that's me 15:11:00 <bklei_> it's beautiful, no? 15:11:04 <rhochmuth> so, it all looks ready to go 15:11:08 <rhochmuth> i think it is the same issue 15:11:12 <rhochmuth> test/verification 15:11:30 <bklei_> yeah, tests well on my side, but would like others to confirm 15:12:04 <rhochmuth> i think it will be similar situation 15:12:14 <rhochmuth> waiting for more folks to look at it 15:12:15 <bklei_> the good news is, if the new code is broken (don't think it is), only affects if you pass the new parms 15:12:33 <rhochmuth> yes, seems like low risk change 15:12:47 <rhochmuth> as in adds new capabilities, but doesn't impact existing functionality 15:13:02 <bklei_> yeah 15:13:09 <rhochmuth> so, i'll probably get to this on monday/tuesday too 15:13:13 <bklei_> bueno 15:13:23 <rhochmuth> hoping someone else looks at this too 15:13:37 <bklei_> any volunteers? 15:14:09 <bklei_> for the influxdb side of the house, java/python, devstack works well to test 15:14:18 <bklei_> vertica is a bit more complicated 15:14:51 <bklei_> crickets/tumbleweeds 15:14:58 <rhochmuth> ok, next topic 15:14:59 <rhochmuth> Any update on cache fix? 15:15:03 <tomasztrebski> i'd look at this, but I am pretty much blocked by other stuff and this is my recent job...exclusively, I was looking at your change by only looking at the code 15:15:19 <rhochmuth> thanks tomasz 15:15:20 <bklei_> sure, thx tomasztrebski 15:15:20 <tomasztrebski> no chance to do something more for any other change 15:15:36 <bklei_> understood, we're all in that boat 15:15:59 <tomasztrebski> hopefully I see a light in that tunnel and maybe I will get a time to finally do my review-part properly 15:16:21 <rhochmuth> So, I don't have any updates on the cache fix 15:16:27 <rhochmuth> I started writing code last week 15:16:41 <bklei_> that's progress 15:16:48 <rhochmuth> but then was basically inundated with impromtu meetings for 3 days that pretty much killed me 15:17:13 <rhochmuth> i'm a little concerned now with the remainder of Decmber 15:17:20 <rhochmuth> i didn't take any time off all year 15:17:22 <bklei_> yeah, we're doing a datacenter migration, taking 95% of my time instead of wonderful monasca work 15:17:27 <rhochmuth> and now i'm trying to catch-up 15:17:41 <bklei_> better keep that wife happy 15:17:45 <rhochmuth> so, my development time is low 15:18:02 <rhochmuth> rigt now 15:18:29 <rhochmuth> anyway, i'll probably get to this next week too, but i'm not expecting to complete next week 15:18:40 <bklei_> ok, thx for setting expectations 15:19:08 <rhochmuth> Update for pymysql 15:19:21 <rhochmuth> @topic Update for pymysql 15:19:26 <rhochmuth> #topic Update for pymysql 15:19:32 <witek> we are testing the replacement 15:19:39 <rhochmuth> awesome 15:19:44 <witek> and it seems to be straight forward 15:19:58 <rhochmuth> is a drop-in replacement? 15:20:03 <witek> yes 15:20:14 <tomasztrebski> implementing was quite fast, our colleague needed..what..2 days, I guess 15:20:46 <tomasztrebski> along with some testing he's been doing in parallel with mysql 15:20:57 <rhochmuth> so, we did all this work a few months ago for postgres support and hibernate 15:21:26 <rhochmuth> are we goign to need to do somethign similar for the monasca-api 15:21:37 <witek> we would like to 15:21:59 <tomasztrebski> that's another brick actually, completely seperate...we agreed to provide pymysql as replacement so that's the first task to complete 15:22:11 <tomasztrebski> doing hibernate-like stuff and postgres would be next step 15:22:11 <rhochmuth> i see 15:22:32 <rhochmuth> so, possibly adding support for sqlalchemy in the python monasca-api 15:23:03 <tomasztrebski> that's what we have in mind 15:23:13 <rhochmuth> i think everything else is covered 15:23:22 <rhochmuth> python monasca-notification was already converted/added 15:23:30 <rhochmuth> monasca-persister doesn't use mysql 15:23:40 <rhochmuth> all the java code was converted 15:23:43 <witek> monasca-common 15:24:05 <rhochmuth> oh yeah 15:24:06 <rhochmuth> that too 15:24:46 <rhochmuth> so i don't see any problems objections to pymysql 15:25:05 <witek> cool, we'll push the change to review 15:25:23 <rhochmuth> ok, thanks 15:25:44 <rhochmuth> #topic How does tempest know URL of monasca api ? 15:25:45 <witek> we also started working on sqlalchemy 15:26:10 <rhochmuth> thank witek 15:26:21 <rhochmuth> changed topics a bit soon 15:26:50 <rhochmuth> Not sure who asked the question about the Tempest tests 15:26:54 <witek> i'm finished :) 15:27:06 <tomasztrebski> yeah, so that's a question from me...basically I am trying to port log-api tempests to be with the project, and apart from normal issues with first try of new framework 15:27:40 <tomasztrebski> i am a little bit puzzled, where's the information where to look monasca-api server written ? 15:27:48 <rhochmuth> so, the monasca-api registers with keystone 15:28:22 <rhochmuth> there is a file called, ./etc/tempest.conf 15:28:37 <rhochmuth> that has the endpoint information and credentials 15:28:42 <rhochmuth> for keystone 15:28:59 <tomasztrebski> yes, I am looking at it right now 15:29:17 <rhochmuth> Have you seen the directions at, https://github.com/openstack/monasca-api/tree/master/monasca_tempest_tests 15:29:23 <tomasztrebski> and there is services available configuration property in file...config.py, isn't ? 15:29:43 <rhochmuth> hmm, i don't know anything about config.py 15:29:44 <tomasztrebski> yeah, I am basically trying to follow up your setup, because it works 15:30:17 <tomasztrebski> https://github.com/openstack/monasca-api/blob/master/monasca_tempest_tests/config.py#L21 15:30:22 <tomasztrebski> I am talking about that 15:31:02 <rhochmuth> that looks familiar now, i think i wrote that 15:31:32 <rhochmuth> so, for the log api there would be a similar skeleton 15:31:54 <rhochmuth> one possiblity is to create monasca_log_tempest tests in the monasca-log-api repo 15:32:06 <rhochmuth> and then copy/past the code and modify 15:32:42 <tomasztrebski> ok, that clears things a bit, guess I need to understand that to make it work, but I will follow up your suggestion, seems actually so good that I am astonished that I didn't think of it before 15:32:48 <tomasztrebski> :/ 15:33:14 <tomasztrebski> ok, in case of any problems I will probably ask over mail or something like that 15:33:23 <tomasztrebski> I dont want to spent too much time over this topic 15:33:26 <rhochmuth> well, i think it makes sense to have the log api with it's own tempest tests 15:33:26 <tomasztrebski> thanks for your help 15:33:45 <rhochmuth> the other option is to add to the monasca-api directly 15:33:47 <tomasztrebski> it makes perfect sense that's why I am trying to embrace that stuff ;) 15:34:10 <rhochmuth> but, then we start mixing things together 15:34:20 <tomasztrebski> but that does not seem right, after all it was decided some time ago to keep those API seperate 15:34:25 <tomasztrebski> and for me it was good decision 15:34:30 <rhochmuth> ok, well, let me know if you run into any problems 15:34:34 <rhochmuth> i'm not an expert 15:34:40 <tomasztrebski> I hope not, but thx ;) 15:34:49 <rhochmuth> but i did do the original work in that area so might know a little more 15:35:19 <rhochmuth> i heavaily modeled on manila as they seemed to have a really good model 15:35:58 <rhochmuth> ok, next topi 15:36:04 <rhochmuth> #topic Summit videos + slides on Wiki page 15:36:11 <mroderus> that's mine 15:36:20 <rhochmuth> Sounds like a great idea 15:36:27 <rhochmuth> someone was wasking me about that yesterday 15:36:32 <mroderus> I was just wondering if we should add the video links and pdfs on the wiki page 15:36:45 <rhochmuth> yes, i agree 15:36:45 <mroderus> do I have permissions to do that? 15:36:50 <rhochmuth> you should 15:36:59 <mroderus> ok, so I'll put my stuff online 15:37:00 <rhochmuth> i don't know what the permissions on wiki pages are 15:37:13 <rhochmuth> i think anyone can modify 15:37:13 <mroderus> I'll try. If I run into problems I'll ask by email 15:37:22 <rhochmuth> ok, thanks 15:37:44 <mroderus> Fabio is not here today, right? So I'll ping him by email so he also uploads his presentation 15:38:13 <rhochmuth> correct, no fabio 15:38:22 <mroderus> that's all from me 15:38:31 <rhochmuth> ok 15:38:36 <rhochmuth> #topic https://review.openstack.org/#/c/226733/ 15:39:29 <rhochmuth> tomasz i'm guessing you want a +2 15:39:40 <rhochmuth> i see deklan +2'd yesterday 15:39:44 <tomasztrebski> yeap, again me...I hope that now that should be finished and it should have higher chance of acceptance 15:40:28 <rhochmuth> i'll take a quick look and +2 unless i see anything 15:40:35 <rhochmuth> i'm assuming deklan tested well 15:40:50 <tomasztrebski> well, I'd love that +2, however to be fair, I dont know what to think about new gate for tempests, that's another reason why I wanted to bring this topic 15:41:06 <rhochmuth> ok 15:41:10 <tomasztrebski> I assume that gate is experimental, so failure there should not be a reason to worry ? 15:41:32 <rhochmuth> uhhh, the gates are marked as experimental 15:41:44 <rhochmuth> but, we are closing in on 100% passing 15:41:56 <rhochmuth> right now, the last i checked, there were only 5 tests failing 15:41:59 <rhochmuth> as of last night 15:42:04 <rhochmuth> this is against the python api 15:42:10 <rhochmuth> the java api should be completley passing 15:42:20 <tomasztrebski> ok, so please review that and in case of unclear parts just leave a comment 15:42:33 <tomasztrebski> let's hope it does 15:42:40 <rhochmuth> ok 15:43:08 <rhochmuth> ahhh, yes i see at the bottom of the review the failure 15:43:14 <rhochmuth> everyone is getting that right now 15:43:17 <rhochmuth> so, that isn't a problem 15:43:35 <rhochmuth> unless all of a sudden something was failing that was passing previousel 15:43:43 <rhochmuth> it would be difficult for you to know that right now 15:43:54 <rhochmuth> pretty soon, we should be at 100% 15:44:29 <rhochmuth> then we will change from experimental to checks, but not voting i beleive 15:44:34 <rhochmuth> then it will be clearer 15:44:40 <tomasztrebski> ok, I will prepare some fireworks 15:44:41 <tomasztrebski> :) 15:44:45 <rhochmuth> so, no cause to panic 15:45:20 <rhochmuth> ok, moving on 15:45:24 <rhochmuth> #topic Quota status 15:45:33 <mroderus> That's me again. I remember we had some discussions about quotas in Monasca some weeks ago. It was brought up by bklei_ . I was just curious if there have been any actions around this topic during the last weeks 15:45:54 <rhochmuth> There haven't been any actions 15:46:14 <rhochmuth> We should possibly get a blueprint to work on this 15:46:51 <bklei_> i'd love to see that topic move fwd 15:47:01 <mroderus> ok thanks. May be that this will become a topic at Fujitsu as well in the next months 15:47:16 <rhochmuth> Yes, it is important for doing tru monitoring as a service 15:47:26 <rhochmuth> on public cloud endpoints 15:47:28 <bklei_> if you start a blueprint mroderus, i'll help add my thoughts 15:47:47 <mroderus> right. I think that's a fundamental requirement for a monitoring cloud service 15:48:06 <bklei_> from our perspective, one quota we'd like to see is data retention period (per project) 15:48:09 <mroderus> ok bklei_ . I'll ping you as soon as we start working on this 15:48:16 <bklei_> great 15:48:45 <rhochmuth> we might need to get started on that soon too 15:48:53 <mroderus> bklei_: so you mean a maximum time the data is stored, right? 15:48:58 <rhochmuth> we had some requests around this recently 15:49:07 <bklei_> right -- per project is what we need 15:49:13 <bklei_> (keystone project/tenant) 15:49:30 <mroderus> have you also discussed volume-based quotas? 15:49:44 <bklei_> even if the API just tracked what it is, we could just consume that and do what we will with it for starts 15:49:49 <mroderus> such as number of metrics or megabytes 15:50:00 <bklei_> i'm just thinking time 15:50:13 <bklei_> we'll probably default to 6 weeks or something 15:50:23 <bklei_> could be fancier, but that'd get us started 15:50:34 <rhochmuth> we also need quotas on number of alarms 15:50:48 <bklei_> yeah, that could spiral 15:50:49 <mroderus> rhochmuth: right 15:51:08 <rhochmuth> and in addition to time/retention period on metrics, probably the number of metrics too 15:51:45 <rhochmuth> number of notification methods, … 15:51:51 <mroderus> I'm just worrying that time/project may not be enought. A project may have an infinite number of agents sending at an arbitrary fine resolution 15:51:54 <mroderus> (theoretically) 15:51:58 <bklei_> custom metrics i'd assume, ignoring libvirt? 15:52:28 <bklei_> we already have quota mgmt for # of instances 15:52:36 <mroderus> ok 15:52:50 <mroderus> is that already in Monasca? 15:52:56 <bklei_> it's in nova 15:53:04 <bklei_> nova quota-show 15:53:10 <bklei_> or something like that 15:53:58 <bklei_> i'm just saying, since openstack already has a mechanism for capping # of instances, we shouldn't cap the default libvirt metrics 15:54:06 <mroderus> ah, ok.. so that quota is for the provisioned VMs. But apart from this, a user can additionally install agents and post metrics to the API. Is that considered as well? 15:54:36 <bklei_> exactly, if we add quotas for # of metrics, should likely be 'custom' metrics they POST, not the default metrics 15:54:59 <mroderus> right, makes sense 15:55:22 <bklei_> thx for working on this mroderus 15:55:38 <mroderus> bklei_: thanks back to you 15:55:57 <rhochmuth> i just wanted to point out that we have a blueprint 15:55:59 <rhochmuth> https://blueprints.launchpad.net/monasca/+spec/alarm-count-resource 15:56:06 <rhochmuth> https://wiki.openstack.org/wiki/Monasca/UI_UX_Support#Alarm_Counts_Resource 15:56:16 <mroderus> cool 15:56:18 <rhochmuth> we had a number of requests from our UI team 15:56:35 <bklei_> cool 15:56:41 <rhochmuth> to to server side filtering, sorting/ordering, and return summaries for alarms 15:56:54 <rhochmuth> this blueprint is from the summary of counts of alarms 15:56:56 <bklei_> nice, would like to see that ui 15:57:11 <rhochmuth> the ui is in helion 15:57:17 <rhochmuth> called opsconsole 15:57:20 <bklei_> i know :) 15:57:42 <bklei_> rbak is our UI team :) 15:57:56 <rbak> thanks 15:58:16 <rhochmuth> the general idea for alarms counts resource to ti return the total alarms, and alarms in various states of ALARM, ACKNOWLEDGED, … 15:58:26 <rhochmuth> so, it would be good to take a look at that 15:58:41 <rhochmuth> we're also going to have blueprints for ordering/storing better 15:58:58 <bklei_> gonna be a busy 2016 15:59:07 <rhochmuth> i believe fujitsu had a bluepring for ordering/sotring too, so we might end-up adding to yours 15:59:26 <rhochmuth> anyway, just wanted to point out that we've started on this 15:59:41 <mroderus> uh.. honestly speaking I'm not aware of anything. But that doesn't mean much :) 15:59:42 <rhochmuth> rbrandt is the engineeer working on that 15:59:57 <rhochmuth> ok, looks like we are done 16:00:04 <tomasztrebski> yeah, that blueprint you're talking about was done some time ago 16:00:05 <tomasztrebski> ;) 16:00:26 <rhochmuth> need to end the meeting folks 16:00:29 <rhochmuth> see you next week 16:00:32 <mroderus> ok.. bye! 16:00:35 <bklei_> bye 16:00:42 <witek> thanx, bye 16:00:43 <tomasztrebski> bye 16:00:50 <rhochmuth> #endmeeting