15:01:26 #startmeeting telemetry 15:01:27 Meeting started Thu Mar 3 15:01:26 2016 UTC and is due to finish in 60 minutes. The chair is gordc. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:32 The meeting name has been set to 'telemetry' 15:01:54 o/ 15:02:06 <_nadya_> o/ 15:02:11 o/ 15:02:17 o/ 15:02:33 o/ 15:02:51 ok let's get this started. 15:02:55 0/ 15:03:04 #topic recurring: roadmap items (new/old/blockers) https://wiki.openstack.org/wiki/Telemetry/RoadMap 15:03:26 i just cut m-3 this morning against HEAD 15:03:42 first. thanks for all the work you folks have done this cycle 15:04:13 regarding FFE, right now i'm just tracking idegtiarov timedelta patch 15:04:24 and r-mibu's tempest work (if it finishes) 15:04:51 gordc: the tempest work in Aodh? 15:04:59 if someone has anything outstanding, please yell now (although it probably won't work) 15:05:10 ildikov: ceilometer and aodh 15:05:21 r-mibu: do you still think you'll have time? 15:05:37 yep, i'll finish in this cycle 15:05:59 gordc: ok, cool 15:06:06 r-mibu: ok. just so you know, it ends very soon :) 15:06:12 i'm planning to use different name in our plugins to avoid param conflict 15:06:24 I will try to help 15:06:25 so, it can be finish only in our repos, 15:06:29 gordc: I started to check the Aodh one, I just got confused by the WIP sign 15:06:43 liusheng, thanks! 15:06:55 r-mibu: cool, thanks for the clarifications 15:07:27 ok. so final cut is in ~1 week 15:07:31 i will upload patches tomorrow, i'm working in my lab machine now... 15:07:33 Mar 14-18 15:07:52 <_nadya_> gordc: bug fixes can still be merged, right? 15:07:57 r-mibu: ok. thanks. hopefully we can merge it in. 15:08:29 ok, apologies for the delay :-p 15:08:37 _nadya_: yes, for next few weeks please test like crazy. 15:08:46 r-mibu: not a problem. 15:08:50 gordc: final cut means FFE deadline, right? 15:08:52 <_nadya_> gordc: yep... 15:09:34 ildikov: yeah, rc1. i'm going to make executive decision and say if you can't get feature in for RC1, we'll push it to N* 15:09:47 ildikov: seems like the logical answer. 15:09:59 gordc: yeah, right, this is what I meant 15:10:03 gordc: tnx! 15:10:39 so yeah, everyone with +2/+A powers, please do not merge anything unless it's: https://review.openstack.org/#/c/286469 15:10:54 or https://review.openstack.org/#/q/owner:r-mibu%2540cq.jp.nec.com+status:open 15:11:25 or a bug 15:11:27 gordc: -2ing other feature patches until N? 15:12:07 ildikov: i've -2 a few. feel free to -2 if you like, but just remember you need to unblock it in a few weeks. 15:12:19 gordc: I mean like what other projects are doing that "block this until next release" or we don't have that many? 15:12:26 ildikov: i would say just leave it unless you feel like -2'ing stuff. :) 15:12:39 ildikov: i trust most of us to not merge stuff. 15:12:45 O/ 15:12:54 gordc: ok, works for me, I'm not that eager with -2ing 15:13:03 but i guess if you think it's a feature pretending to be a bug, -2 it 15:13:33 gordc: it just can make it easier to remember that we are still in frozen state :) 15:14:07 gordc: ok, cool, crystal clear, tnx :) 15:14:31 ildikov: cool cool. 15:14:39 <_nadya_> ok 15:15:11 let's do a quick run through of projects (i don't think we have much to discuss) 15:15:15 #topic aodh topics 15:15:27 just a heads up, i'm going to defer aodhclient in heat 15:15:38 i didn't get a response when i asked about FFE last week 15:15:49 and i also realised it's a crazy big change. 15:16:17 if someone wants to work on heat+aodhclient, here's the patch: https://review.openstack.org/#/c/284985/ 15:16:23 then it sounds reasonable to defer 15:16:33 feel free to take it over (i only got unit tests working) 15:17:07 gordc: really a big change! 15:17:33 liusheng: yeah, it was more work than i wanted 15:18:17 liusheng: do you want to talk about 'aodh search --query' vs 'aodh list --query'? 15:18:22 we can defer to ML as well 15:18:40 <_nadya_> gordc: this change goes to N? 15:18:53 gordc: yeah, we can have a shot discussion 15:19:00 _nadya_: aodhclient support in heat? 15:19:03 https://review.openstack.org/#/c/283958/ 15:19:06 <_nadya_> gordc: yes 15:19:30 yeah, i'm not working on it. and i don't think heat wants to do it (no one replied when i asked about it last week) 15:20:00 <_nadya_> gordc: I think I will be able to work on this soon 15:20:30 _nadya_: sure if you like. feel free to takeover my patch (or start from scratch) 15:20:42 <_nadya_> gordc: ok, cool 15:21:14 #topic aodh - list vs search 15:21:29 liusheng: go for it 15:22:13 gordc: ok, I have a change try to drop the mandatory of "--type" in alarm list command 15:22:27 do you have any thoughts about that ? 15:22:32 https://review.openstack.org/#/c/283958/ 15:23:14 i don't mind dropping mandatory type. i think my question is what we want to do with list vs search 15:23:32 want to see if anyone has an opinion on this. 15:24:08 <_nadya_> liusheng: what's the reason of dropping --type? 15:24:14 does list with query equal to search 15:24:19 ? 15:24:26 disclaimer: the format was taken from gnocchiclient 15:24:29 yes, support query filters in "aodh alarm list" or support complex query in alarm search 15:24:50 in ceilometercliet, we supportted both 15:25:46 _nadya_: I think it is not reasonable to force users specifying --type if they just want to list alarms 15:26:37 <_nadya_> liusheng: I see, agreed 15:26:42 _nadya_: and, may be users want to get all the alarms in "ALARM" state and regardless the type 15:27:30 <_nadya_> liusheng: so the question "what filters should be supported in alarm list and alarm search"? 15:28:58 _nadya_: no, we have support almost all the query filters by "alarm search" (complex query), so gordon think we don't need duplicated functionaities in "alarm list" 15:29:23 _nadya_: so in gnocchiclient, list doesn't really have any filters (just how much details are shown). search is what you use to filter 15:29:55 liusheng: i think it's confusing to have query in both list and search. we should unify them. 15:30:07 either a) move all filtering capability to search 15:30:11 but it has been already supportted in aodh-api :) 15:30:18 or b) drop search and move everythin to list 15:31:06 right so there will be --query and --complex-query options... but they should both be under same command. 15:31:23 it just seems confusing to have list --query and search --query 15:31:28 or maybe that's just me. 15:31:43 I tend to agree that it causes confusion 15:31:57 it looks momre reasonable under search 15:32:09 s/momre/more/ 15:32:09 gordc: I thinks it is better to support filters in alarm list, maybe we can support them both temporally ? 15:32:37 liusheng: drop alarm search command then? 15:32:37 what if we call query as filter for alarm list? 15:32:48 <_nadya_> got it. IIUC, "list" and "search" both return the list of results. Tend to agree that these commands look very similar 15:33:02 _nadya_: right 15:33:09 gordc: since we have plan to support pagination in the future, yes, I think pagination and filtering query is enough 15:33:13 and keep complex-query for search or pick one and stick with that 15:33:15 what do you think ? 15:34:15 are we dropping alarm search command? i don't mind this. 15:34:40 i think right now it's not obvious what diff between list --query|filter vs search --query is... 15:35:40 I would drop list, but I think it's just a matter of taste :) 15:36:00 gordc: I prefer that, but I respect all of your opinions 15:36:13 :) 15:36:39 we should drop one, or leave all filtering (complex and regular) capabilities in search 15:37:13 gnocchiclient uses second approach 15:37:31 i think most clients for other projects, use first approach. 15:37:41 do we have any intention to keep these clients similar? 15:37:51 agree, if we just support "alarm list" without any parameter, it is equal to "alarm search" with no parameter specified 15:37:59 I mean what is under Telemetry umbrella 15:38:14 <_nadya_> +1 to drop one. but the question is in backward-compatibility. Do we care about it? or aodhclient is a new one and we don't want to mantain ceilometer alarming there? 15:38:21 ildikov: no plans. i just happened to build aodhclient off gnocchiclient becuase it was using all the latest libs 15:39:01 _nadya_: i think we can ignore backward-compatbility (for now) :) 15:39:29 gordc: sure, I meant that you referred to it as it uses the second approach so we might keep aodhclient similar so that who uses both knows what to expect 15:39:58 for backward-compatibility, we need support both :) 15:40:29 ildikov: right. or if you use one, you get get confused.lol 15:40:53 hmm, maybe we can still do things now quickly and tell people that they don't remember correctly that aodhclient supported this or that... ;) 15:41:13 gordc: why would I use only one? ;) 15:42:44 liusheng: i don't have a recommendation, maybe defer to ML? 15:42:57 unless someone has a strong opinion righ tnow 15:43:04 right now* 15:43:21 gordc: OK, I will open a thread in ML 15:43:32 liusheng: thanks! 15:43:39 #topic ceilometer topics 15:43:42 <_nadya_> yep, it would be better to discuss it in ML 15:43:43 anything here? 15:43:56 hi 15:44:25 you switched to ceilometer topic, but can I take 2 min to talk about aodh-vitrage integration? or should I do it in ML? 15:44:32 sure. 15:44:43 we have nothing for ceilometer anyways 15:44:54 #topic aodh+vitrage integration 15:45:03 ifat_afek: go for it 15:45:03 so we started working on aodh-vitrage integration. basically, it has 3 parts: 15:45:11 1. vitrage should periodically query aodh alarms. this seems quite straight forward 15:45:19 2. vitrage should be notified whenever an aodh alarm state is changed. this is more complicated, and we decided to implement it at a later stage 15:45:24 3. vitrage should trigger deduced alarms (vitrage alarms) in aodh. this is also not trivial 15:45:35 I created two blueprints, for #1 and #3. I will be happy to get your feedback about them. 15:45:42 https://review.openstack.org/#/c/287686 15:45:49 https://review.openstack.org/#/c/287861 15:46:03 there is much more information in vitrage wiki page: https://wiki.openstack.org/wiki/Vitrage 15:47:15 ifat_afek: cool cool, we can comment on the specs 15:47:34 i think #2 is possible since we have zaqar notifier but i haven't really tried 15:47:35 gordc: that would be great, thanks 15:48:02 we do plan to implement #2, but for now we will focus on 1 and 3 15:49:07 cool cool, so i guess aodh devs can comment there. 15:49:08 ifat_afek: hi, thanks, what is main reason for periodically querying aodh alarms ? 15:49:21 <_nadya_> ifat_afek: will vitrage create it's own alarms in aodh? 15:49:55 liusheng: we would like to have all aodh alarms in vitrage for rca and deduced alarms calculations. and doing periodic query seems easier than getting notifications about changes... 15:50:17 _nadya_: we would like to do this. this is the purpose of the #3 15:51:50 ifat_afek: will look the specs, thanks :) 15:52:02 liusheng: great, thanks! 15:52:25 cool cool. open discussion? 15:52:30 #topic open discussion 15:52:57 just an fyi, ~1 week until PTL self-nominations if anyone is interested. 15:53:06 that's all i have 15:53:18 do you have any plan about the Bug smash ? :-) 15:53:47 https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka-Bugs 15:53:57 liusheng: not formally. we have a lot of bugs though in aodh/ceilometer/gnocchi :) 15:55:04 gordc: :) 15:55:43 sorry folks, i have to run to a meeting. we all good? 15:56:20 cool cool. 15:56:25 thanks everyone again 15:56:27 #endmeeting