17:00:48 <gibi> #startmeeting nova notification
17:00:48 <openstack> Meeting started Tue Feb  2 17:00:48 2016 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:52 <openstack> The meeting name has been set to 'nova_notification'
17:01:02 <gibi> hi everyone!
17:01:10 <rlrossit_> hi gibi!
17:01:56 <gibi> rlrossit_: hi! I'm happy that you found the new place and time as I screwed up the mail on the ML twice. :)
17:03:04 <gibi> it seems just two of us today
17:03:19 <gibi> #topic open reviews
17:03:34 <gibi> actually we have merged everything that was open!
17:03:39 <rlrossit_> woo
17:03:41 <gibi> :)
17:03:49 <speller> hi there :)
17:03:52 <gibi> speller: hi!
17:04:15 <gibi> #topic midcycle summary
17:04:33 <gibi> so last week we had a fruitfull midcycle in the sunny Bristol
17:04:59 <gibi> most of the info are collected on https://etherpad.openstack.org/p/mitaka-nova-midcycle
17:05:14 <gibi> the notification part is starts at L43
17:05:47 <gibi> I did updated the our todo list etherpad with the outcome https://etherpad.openstack.org/p/nova-versioned-notifications
17:06:13 <gibi> I think the biggest result was that we agreed that no new legacy notification is allowed in nova any more
17:06:43 <rlrossit_> +1
17:07:02 <gibi> which is now documented in the code-review.rst
17:07:20 <gibi> one of our task for Mitaka-3 is related to this
17:07:42 <gibi> we have to find a way to automatically detect if somebody proposing a patch with a new legacy notification
17:08:15 <rlrossit_> hacking maybe?
17:08:18 <rlrossit_> but that seems hard
17:09:13 <gibi> hacking and grep is hard as the notifier coming from rpc.get_notifier is passed along in multiple calls and also somethime the get_notifier is wrapped in a partial
17:09:39 <gibi> another possibility is monkey patching get_notifier in the base test case
17:09:50 <gibi> but some test mocks get_notifier itself
17:10:07 <gibi> and it could only catch new notifications if there is a test for it as well
17:10:39 <gibi> another way is configure tempest to use the Log driver for notifications and post process logs after tempest
17:10:51 <gibi> but that is also problematic
17:11:12 <gibi> https://etherpad.openstack.org/p/nova-versioned-notifications L51 contains my understanding
17:11:12 <rlrossit_> I would like this to get caught in UT, not tempest
17:11:18 <gibi> rlrossit_: agree
17:12:02 <gibi> if we mix the mockey patch and the hecking rule solution then we might catch most of the new notifications
17:12:53 <gibi> some would be catched by the hacking rule some by the mockey patc
17:12:53 <gibi> h
17:13:17 <gibi> and I think we cannot aim for catching everything
17:13:25 <rlrossit_> yeah like if they patch get_notifier, use hacking, otherwise trust monkey patch?
17:13:42 <rlrossit_> +1. we can't catch everything, or else we would put cores out of their job :)
17:13:44 <gibi> rlrossit_: something like that, yes
17:13:56 <gibi> ahh we need cores for +2 :)
17:15:13 <gibi> I think I will looking into this hacking rule + mockey patch tomorrow and put up a patch for it
17:15:51 <rlrossit_> you may want to separate them as 2 patches, though not sure how dependent they'll be
17:16:05 <rlrossit_> wait... won't you need to blacklist existing legacy notifications until we get them changed over?
17:17:02 <gibi> rlrossit_: I can split it to two patches sure. I think they are not dependent on each other
17:17:23 <gibi> rlrossit_: if you have free time we can even split the work :)
17:17:40 <rlrossit_> I probably am too busy for the next week or so :(
17:17:54 <rlrossit_> IBM internal whatnot
17:17:55 <gibi> rlrossit_: no worries I will dig in :)
17:19:11 <gibi> rlrossit_: regarding the blacklist, yes we need one until we transform the existing legacy notifications. This list will serve us as a guide what we need to do
17:19:50 <gibi> rlrossit_: I might be generate that list into the notification devref as a 'list of legacy notifications'
17:22:27 <gibi> anyhow I see the way forward with this which is good :)
17:23:20 <gibi> another task possible for Mitaka-3 is moving the notification_format config option from nova.rpc into the config subtree
17:23:42 <gibi> but that is an easy piece
17:24:54 <gibi> for Newton I will put up a new spec to transform instance.update and api_
17:25:01 <gibi> ... and api_fault
17:25:45 <gibi> we agreed that no spec is needed for the transformation of the other legacy notifications so that will be an ongoing work after these two
17:26:17 <rlrossit_> So it will be like mitaka-objects, where it's just a big umbrella of changing?
17:26:38 <gibi> rlrossit_: yes, I imagine so
17:28:20 <gibi> we also agreed that we will provide a jsonschema for the notification payload, that will be a separate spec for Newton
17:28:35 <gibi> I mean schema per payload type
17:30:37 <gibi> I think that was all from the midcycle
17:31:54 <gibi> #topic open discussion
17:32:09 <gibi> anything else to discuss?
17:32:33 <rlrossit_> nope
17:33:58 <gibi> thank thanks for joining. next meeting will be held two weeks from now according to the new schedule
17:34:31 <gibi> #endmeeting