02:30:40 <ekcs> #startmeeting congressteammeeting
02:30:41 <openstack> Meeting started Fri Apr  6 02:30:40 2018 UTC and is due to finish in 60 minutes.  The chair is ekcs. Information about MeetBot at http://wiki.debian.org/MeetBot.
02:30:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
02:30:43 <ekcs> hi all!
02:30:45 <openstack> The meeting name has been set to 'congressteammeeting'
02:30:57 <ekcs> back for another meeting =)
02:31:03 <ekcs> topics are here as usual: https://etherpad.openstack.org/p/congress-meeting-topics
02:31:10 <ekcs> please read/comment/add
02:31:14 <masahito> hi
02:32:24 <ramineni_> ekcs: hi
02:32:31 <ramineni_> masahito: hi
02:32:38 <masahito> ramineni_: hi
02:33:40 <ekcs> hi masahito =)
02:33:42 <ekcs> hi ramineni_ =)
02:33:57 <ekcs> how are things?
02:36:31 <ekcs> well hope everone’s doing well. let’s dive in then.
02:36:33 <ekcs> #topic gate
02:36:39 <ekcs> gate is failing since oslo.config upper constraint got bumped to 6.0.1 and changed something that the cfgvalidator depends on.
02:36:44 <ekcs> I took a stab at it, but so far haven't fixed it.
02:36:45 <ekcs> https://review.openstack.org/#/c/559206/
02:37:19 <ekcs> anything to talk about there?
02:37:58 <ramineni_> ekcs: oh , may be you could add peirre to the patch, he might be able to help
02:38:24 <ekcs> yea I’ll add/ping him at some point. Thanks
02:38:33 <ramineni_> ekcs: cfgvalidator seems to break very frequently , tightly coupled with oslo.config
02:39:08 <ekcs> yea that’s unfortunate. I may ask pierre if there are ways to improve that aspect of things.
02:40:05 <ramineni_> ekcs: ya , ok
02:40:12 <ekcs> anything else?
02:40:44 <ekcs> ok moving on then.
02:40:46 <ekcs> #topic monasca push
02:41:16 <ekcs> ramineni_: I have a couple discussion points on monasca push. is this a good time to talk about it? or maybe wait till it’s made open?
02:41:53 <ramineni_> ekcs: ok, we can discuss
02:42:32 <ekcs> ok then. the main question is how the alarms get deleted.
02:42:45 <ekcs> does monasca send a notification for alarm deactivate?
02:42:55 <ekcs> or does congress side auto delete things?
02:43:31 <ramineni_> ekcs: its a notification genrally , they wont get stored , they just send the notification to who all activated it , monasca doesnt do any store anything related to that
02:43:42 <ramineni_> ekcs: thats the case with all notifications right
02:44:04 <ekcs> right.
02:44:08 <ramineni_> ekcs: IMO , notifications wont get stored at source , its up to the receiver what to do with them , ignore or take action
02:44:22 <ramineni_> ekcs: so once evaluated , it wont be of use
02:44:42 <ekcs> Right so that’s what I’m trying to understand.
02:44:50 <ekcs> 1. does monasca send notification on deactivate?
02:44:54 <ramineni_> no
02:45:02 <ekcs> got it.
02:45:04 <ekcs> 2. what does congress do with the notifications?
02:45:13 <ramineni_> execute actions ,
02:45:27 <ramineni_> invoking nova /.. api
02:45:35 <ramineni_> depending on policy
02:46:01 <ekcs> right. but there’s a step before that. policy trigger execute actions based on the rows in tables.
02:46:15 <ekcs> so congress must create rows based on notifications right?
02:46:15 <ramineni_> ekcs: yes
02:46:58 <ekcs> so it’s: when a notification is received, delete all pre-existing rows and create new rows based on only the latest notification?
02:46:59 <ramineni_> so im thinking of PUT , single row or set of rows , they get evaluated , and respective actions would take place, after that there is no use of that data
02:47:32 <ramineni_> ekcs: right , i could think of only that usecase
02:48:20 <ekcs> hmm I see.
02:48:40 <ekcs> do you know how that mechanism interacts with the existing polling mechanism in monasca driver?
02:48:53 <ramineni_> ekcs: means
02:49:18 <ekcs> from what I understand we already have polled data on the alarms table.
02:49:28 <ekcs> do both mechanisms go to the same table?
02:50:12 <ramineni_> ekcs: no, we havent added any interaction bw poll , and webook nitification , policies were based on notification data alone
02:50:34 <ramineni_> ekcs: may be i can check that and get back
02:50:36 <ekcs> i see. so the webhook notifications go to a new table.
02:50:38 <ekcs> ok.
02:50:56 <ramineni_> yes, ill check if there is any overlap
02:51:12 <ekcs> ok. well one last question i think.
02:51:36 <ekcs> monasca webhook does a POST right? how do you guys plan to handle it?
02:51:49 <ekcs> 1. add POST api to congress side for receiving the push?
02:51:56 <ekcs> 2. change what monasca does into PUT or something else?
02:51:59 <ramineni_> ekcs: we changed to PUT at monasca end
02:52:07 <ramineni_> downstream
02:52:58 <ekcs> I see…. at PTG it sounded like gmann is interested in upstreaming. is he the point person on that effort or someone else?
02:53:19 <ekcs> seems like changing from POST to PUT isn’t what monasca side would want in their upstream code.
02:53:32 <ramineni_> but for monasca push to work , there are couple of changes to be done at monasca level too , but for this it can be done , using POST at congress end also , because its a new resource everytime , so post makes sense
02:53:52 <ekcs> yea I think POST makes sense.
02:54:08 <ramineni_> ekcs: right
02:54:28 <ekcs> ok well. thanks this is helpful.
02:54:33 <ekcs> I’d like to help if possible.
02:54:42 <ramineni_> ekcs: sure, thanks
02:54:49 <ramineni_> ekcs: regarding generic push
02:54:58 <ekcs> ok
02:55:01 <ekcs> #topic generic push
02:55:24 <gmann> ekcs:  yea we have plan of that and ramineni_ will be doing it along with some other members.
02:56:06 <ekcs> gmann: awesome thanks for chiming in! I’d love to stay in the loop.
02:56:16 <gmann> sure
02:56:31 <ekcs> thanks gmann
02:57:06 <ekcs> ramineni_: you were saying about generic push?
02:57:06 <ramineni_> ekcs: regarding PATCH operation , i read your comment
02:57:28 <ekcs> btw masahito you might have helpful expertise here given your push driver experience. we’re making generic push driver.
02:57:35 <ramineni_> ekcs: you are right about my concern , that if we use patch , how do we handle the stale data
02:58:11 <ekcs> ramineni_: ok
02:58:35 <ramineni_> ekcs: right, masahito : your comments would be helpful on the spec, we are debating on that for long time :)
02:58:43 <masahito> got it.
02:59:23 <ramineni_> ekcs: so you meant , if ppl use geenric push , its the source resposiblity to delete the data again?
02:59:45 <masahito> From my experience, PATCH looks useful but is also painful solution :-)
03:00:39 <ekcs> ramineni_: yes that’s what I intended. It seemed like the only sensible way to be generic.
03:00:51 <ekcs> some data needs to be deleted. some don’t. depending on the data and the situation.
03:01:18 <ekcs> a generic driver can’t make that decision. but it should give tools to make it easy for source/deployer to control behavior.
03:01:26 <ramineni_> ekcs: but in most cases, will it be possible at source end to maintain all the data pushed to congress, and delete the same everytime, push generally used for immediate evaluation , so i doubt source end have that data stored
03:03:24 <ramineni_> masahito: could you add more, evalautaing whole data again in case of patch , would cause erroneous behaviour?
03:03:59 <ekcs> ramineni_: then in that case I guess something else/extra is needed. PUT can be used if they never want previous data to persist.
03:04:21 <ekcs> if they want some previous data to persist and be used but not past a certain time, then timestampting works.
03:04:54 <ekcs> vitrage works this way though: it sends notifications on all CHANGE. both alarm activate and alarm deactivate.
03:05:10 <ekcs> so until we receive alarm deactivate, a previous alarm activate is still good.
03:05:28 <ekcs> if I remember correctly from masahito zabbix works similarly.
03:05:30 <masahito> As we discussed, someone needs to take care of deleting the row in case of patch.
03:06:21 <masahito> If no one take care it, there're lots of "noise" rows in the table.
03:06:41 <ekcs> masahito: right makes sense.
03:07:06 <masahito> On the other hands, PUT also has Pros/Cons
03:07:43 <ramineni_> ekcs: masahito: ok, may be we should clearly document that , when to use PATCH and PUT nd their use cases, so that end users will gain from both
03:08:16 <ramineni_> and clear that when to use what operation
03:08:31 <masahito> sorry, less activities in gerrit. I'll write the details in the patch.
03:08:53 <masahito> ah. patch means a patch on gerrit :-)
03:09:07 <ekcs> hahaha.
03:09:12 <ramineni_> masahito: thanks, that would be helpful :)
03:09:22 <ekcs> thanks masahito
03:09:31 <ramineni_> more opinions , make the solution better :)
03:09:56 <ekcs> I’ve been thinking about the whole generic issue on a broader level.
03:10:20 <ekcs> congress is based on tables and rows.
03:10:44 <ekcs> some sources can be configured to send what congress needs.
03:10:54 <ekcs> but many sources are fixed and send what they send.
03:12:35 <ekcs> it’s difficult to have a one solution for everyhing because the translation from the notifications into ultimately the rows congress needs is different in each case.
03:12:53 <ekcs> not just schema different, but fundamentally different.
03:12:58 <ekcs> some sources send only add.
03:13:09 <ekcs> some sources send all changes.
03:13:29 <ekcs> some sources send notifications that don’t correspond to add and deletes at all.
03:14:27 <ekcs> the desired translation from notification into congress state is different in each case.
03:15:07 <ramineni_> ekcs: right
03:15:48 <ekcs> maybe the best way to handle it is for congress to represent exactly what is sent, not try to translate into state.
03:16:07 <ekcs> so instead of an alarms table.
03:16:19 <ekcs> we have instead a notifications table.
03:16:43 <ekcs> and then it’s up to the policy writer to do useful things with the notifications table, including writing the policy needed to translate to state.
03:17:50 <ramineni_> ekcs: means , im not sure i got what you meant
03:17:54 <ekcs> basically instead of trying to put the customization in the driver, put the customization in the policy.
03:18:15 <ekcs> ok yea it’s a bit vague now. i’ll need to make it more concrete. i’ll share later.
03:18:45 <ramineni_> ekcs: ok
03:19:01 <ekcs> ok well any other topics for now? =p
03:19:49 <ramineni_> ekcs: reviews on driver loading part would be help, almost completed
03:20:58 <ekcs> ok great.
03:21:06 <ekcs> I’ve reviewed the main patch.
03:21:16 <ekcs> but you’re talking about this one? https://review.openstack.org/#/c/546496/
03:21:25 <ekcs> and thin one? https://review.openstack.org/#/c/558780/
03:21:50 <ramineni_> ekcs: ya, added soltion for custom ones also, it works fine , WIP because need to add unit tests
03:22:01 <ramineni_> ekcs: yes
03:22:01 <ekcs> great I’ll take a look.
03:22:02 <ekcs> thanks!
03:22:27 <ramineni_> ekcs: thanks
03:22:33 <ramineni_> ekcs: thats it from my side
03:22:44 <ekcs> ok then.
03:22:53 <ekcs> I don’t have anything else either.
03:22:59 <ekcs> oh.
03:23:50 <ekcs> I can’t figure out why importing from mistral_tempest_plugin fails here: https://review.openstack.org/#/c/538336/
03:24:01 <ekcs> I think I did al lthe proper setup.
03:24:17 <ekcs> if anyone has hints it’d be great =)
03:24:28 <ramineni_> ekcs: sure, will have a look at it today
03:24:39 <ekcs> thanks!
03:24:50 <ekcs> ok well let’s end then if nothing else.
03:25:23 <ekcs> thanks everyone!
03:25:41 <ramineni_> Thanks All, Bye
03:25:46 <ekcs> thanks ramineni_
03:25:54 <ekcs> bye all.
03:25:57 <ekcs> #endmeeting