17:00:06 <gibi> #startmeeting nova notification
17:00:07 <openstack> Meeting started Tue May 16 17:00:06 2017 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:10 <openstack> The meeting name has been set to 'nova_notification'
17:00:18 <gibi> hi
17:00:48 <mriedem> hi
17:00:53 <gibi> mriedem: hi
17:01:15 <gibi> It seems it is again just two of us
17:01:17 <gibi> anyhow
17:01:26 <mriedem> and i've been gone for awhile
17:01:43 <gibi> last week I cancelled the meeting
17:02:01 <gibi> so you didn't miss anything :)
17:02:38 <gibi> I think I managed to summarize the notification tasks state in my weekly mail yesterday http://lists.openstack.org/pipermail/openstack-dev/2017-May/116662.html
17:03:14 <gibi> so I just want to highlight that both keypair and BDM in instance notification is ready to be reviewed
17:03:26 <mriedem> ok i think i was planning on getting back to the series where you split out the instance.create payload
17:03:28 <mriedem> for keypairs
17:03:39 <mriedem> just hadn't gotten back into the swing of reviews yet since the summit
17:03:42 <gibi> https://review.openstack.org/#/q/topic:bp/additional-notification-fields-for-searchlight+status:open
17:04:10 <gibi> instance.create is now split
17:04:17 <gibi> both for the keypair and for the tags
17:04:33 <gibi> but the tags patch needs more work
17:05:25 <gibi> besides that I managed to hand roll a minimal json ref implementation for
17:05:32 <gibi> https://review.openstack.org/#/q/topic:refactor-notification-samples
17:05:48 <gibi> it is less than 50 lines
17:06:40 <mriedem> ok
17:07:16 <mriedem> https://review.openstack.org/#/c/452820/6/doc/notification_samples/instance-pause-end.json ?
17:07:49 <gibi> that seems like a mistak :)
17:08:08 <gibi> we only need the second payload key
17:08:51 <gibi> it seems json parser allows duplicated keys
17:09:06 <gibi> this is why the test didn't failed
17:09:48 <mriedem> ok
17:10:11 <mriedem> i wonder if there is a way to use jsonschema validation to detect duplicate keys?
17:10:22 <gibi> I will look into that
17:10:35 <gibi> it all depends on the jsonschema and json libs
17:10:48 <gibi> maybe even the json lib can be configured for stricter check
17:11:01 <mriedem> http://deron.meranda.us/python/demjson/
17:11:05 <mriedem> jsonlint i guess
17:11:09 <mriedem> duplicate keys is valid json
17:11:19 <mriedem> so jsonschema validation doesn't fail on it
17:11:54 <mriedem> oo https://github.com/openstack/requirements/blob/master/global-requirements.txt#L361
17:11:57 <mriedem> already available in g-r
17:12:00 <mriedem> so we could use it
17:12:07 <gibi> cool
17:12:24 <gibi> I will spin up a separate patch to use that
17:12:47 <gibi> maybe a combination with https://review.openstack.org/#/c/443677/
17:13:33 <gibi> anyhow thanks for the tips
17:14:12 <gibi> these were the two highlight I wanted to mention
17:14:27 <gibi> the weekly mail has some additional goods top of this
17:14:47 <gibi> was there any notification related discussion in Boston I should know about?
17:15:41 <mriedem> no one is using versioned notifications yet
17:15:49 <mriedem> some people are running with notifications in general,
17:15:58 <mriedem> but have to turn them down because of how frequent they are
17:16:02 <mriedem> like the instance.exists ones
17:16:11 <mriedem> klindgren from godaddy commented on that
17:16:15 <mriedem> we told him to open a bug
17:16:45 <mriedem> the searchlight integration stuff is taking a bit of a turn, as in we might explore less invasive changes to the api before integrating with searchlight,
17:16:51 <mriedem> that was all very hand wavey though
17:17:47 <gibi> I saw a patch about this turn of direction. Searchlight could be a second step for big deployers
17:18:33 <gibi> I will keep an eye on the instance.exists bug, I guess we could add a config option to change the frequency
17:18:59 <mriedem> there is already a config for that i think
17:19:02 <mriedem> it's a periodic
17:19:13 <mriedem> what we talked about was doing a queue thing like the heal_instance_info periodic
17:19:27 <mriedem> where we get all of the instances, put them in a queue, but only process 1 per iteration (1 minute by default)
17:19:43 <mriedem> i think the issue was the size of the payload (with the frequency)
17:19:45 <mriedem> was killing rpc
17:19:58 <mriedem> nectar said they run notifications on a separate message bus
17:20:03 <mriedem> which is probably smart
17:20:47 <gibi> so we either decrease the frequence (can be with the queue) or we decrease the payload size. We can do the later with a really small payload like a singel instance.uuid
17:21:07 <mriedem> well, the payload would decrease if you only send 1 instance
17:21:09 <mriedem> instead of a list
17:21:12 <mriedem> but i haven't dug into it
17:21:14 <mriedem> or seen a bug yet
17:22:11 <gibi> OK, I will look into this with the bug
17:23:04 <gibi> if there is nothing else then I have one more thing
17:23:30 <mriedem> ok
17:23:33 <gibi> I will be on paid time off in the next two weeks
17:23:55 <gibi> so most I'm planning to cancel the next two meetings
17:23:59 <gibi> if that is OK
17:24:42 <gibi> so the next meeting I'm planning is on 6th of June
17:25:06 <mriedem> works for me
17:25:09 <mriedem> enjoy the time off
17:25:25 <gibi> thanks. I will have wedding to attend ;)
17:26:06 <gibi> this week I'm still fully here but then see you on 6th of June
17:26:15 <gibi> thanks for the meeting!
17:26:30 <mriedem> np, ttyl
17:26:36 <gibi> #endmeeting