17:00:10 <gibi> #startmeeting nova notification
17:00:10 <openstack> Meeting started Tue Mar  7 17:00:10 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:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:14 <openstack> The meeting name has been set to 'nova_notification'
17:00:47 <mriedem> o/
17:00:57 <aunnam> o/
17:00:57 <gibi> hi
17:00:58 <sneti> o/
17:02:28 <gibi> let's get started
17:03:04 <gibi> I thought I will go throught the status mail I posted on the ML
17:03:29 <gibi> http://lists.openstack.org/pipermail/openstack-dev/2017-March/113358.html
17:03:43 <gibi> #topic bugs
17:04:06 <gibi> https://bugs.launchpad.net/nova/+bug/1665263
17:04:06 <openstack> Launchpad bug 1665263 in OpenStack Compute (nova) ocata "instance.delete notification is missing for unscheduled instance" [High,In progress] - Assigned to Balazs Gibizer (balazs-gibizer)
17:04:16 <gibi> this is the only hight prio bug I know of
17:04:28 <gibi> patch is ready for the cores
17:04:58 <gibi> I will re-do the ocata backport after the patch merges to the master
17:05:29 <gibi> https://bugs.launchpad.net/nova/+bug/1657428
17:05:29 <openstack> Launchpad bug 1657428 in OpenStack Compute (nova) "Nova sends notifications with different timestamp formats" [Medium,In progress] - Assigned to Timofey Durakov (tdurakov)
17:05:45 <gibi> patch seems OK, ready for the cores. really simple patch
17:05:58 <gibi> https://bugs.launchpad.net/nova/+bug/1653221
17:05:58 <openstack> Launchpad bug 1653221 in OpenStack Compute (nova) "availability_zone field is missing from the service.update notification payload" [Medium,In progress] - Assigned to Balazs Gibizer (balazs-gibizer)
17:06:12 <gibi> this is the last medium bug I know of
17:06:20 <gibi> but this needs review from the subteam
17:06:50 <gibi> any new bugs we need to track / discuss?
17:08:00 <gibi> I guess this means no :)
17:08:05 <mriedem> i need to go through the delete one
17:08:16 <mriedem> i was originally worried about lots of duplicate code
17:08:33 <gibi> yeah, I tried not to increase the duplications
17:08:50 <gibi> the whole delete code path is quite complex
17:10:24 <gibi> OK, let's move one
17:10:56 <gibi> #topic versioned notification transformation
17:11:17 <gibi> I proposed three patches to focus on this week
17:11:24 <gibi> * https://review.openstack.org/#/c/384922 Transform instance.rebuild
17:11:27 <gibi> notification
17:11:29 <gibi> * https://review.openstack.org/#/c/396621 Transform
17:11:32 <gibi> instance.rebuild.error notification
17:11:34 <gibi> * https://review.openstack.org/#/c/382959 Transform instance.reboot
17:11:37 <gibi> notification
17:11:41 <gibi> this mainly means inviting cores to look at those patches
17:11:48 <gibi> and answer/fix comments from them
17:12:27 <gibi> besides that we have couple commits that needs a re-spin to target the new Pike bp
17:12:49 <gibi> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/versioned-notification-transformation-ocata
17:13:08 <gibi> any issues / questions about the transformation work?
17:13:58 <mriedem> those 3 look pretty standard
17:14:02 <mriedem> i'll try to take a look
17:14:16 <gibi> mriedem: thanks.
17:15:31 <gibi> OK, lets go to the next topic
17:15:41 <gibi> #topic searchlight integration
17:16:02 <gibi> there is a spec up from mriedem
17:16:10 <gibi> https://review.openstack.org/#/c/441692/
17:16:28 <mriedem> wow a ton of comments since yesterday
17:16:32 <gibi> for me it seems we are on a right track with that
17:16:40 <mriedem> there are a lot of scary issues in that one
17:16:44 <mriedem> and hand waving
17:16:45 <mriedem> on my part
17:17:43 <gibi> the scariest thing to me is that we need to keep in sync the API response the InstancePayload and the SL schema
17:18:38 <gibi> anyhow I think we should start putting things together to see other issues we haven't discovered yet :)
17:19:18 <gibi> for the notification subteam the most important thing is to get bp additional-notification-fields-for-searchlight merged
17:19:32 <gibi> fortunetly the code is in good shape
17:19:38 <gibi> I mean the easy part
17:19:43 <gibi> excluding the BDM
17:20:18 <gibi> easy part is here https://review.openstack.org/#/q/label:Code-Review%253E%253D1+status:open+branch:master+topic:bp/additional-notification-fields-for-searchlight
17:20:52 <gibi> but I don't know how to get started modelling the BDM part of the bp
17:21:21 <mriedem> wouldn't the bdm payload just model the BlockDeviceMapping object?
17:21:50 <mriedem> it would be like network information in a notification
17:22:00 <gibi> yes, good point
17:22:10 <mriedem> would actually be a list, but same idea
17:22:15 <mriedem> list of dicts
17:22:56 <gibi> I will try to add something to the bp whiteboard this week
17:23:17 <gibi> and ping the SL guys to see if they have somebody who can help implementing it
17:23:24 <aunnam> gibi, that helps. So that I can start working on BDM part
17:23:32 <gibi> aunnam: thanks!
17:24:00 <mriedem> i think i saw Kevin_Zheng starting some patches for the SL integration
17:24:08 <mriedem> i need to call that searchlight because internally we call SL == softlayer :)
17:24:14 <mriedem> so i'm getting confused
17:24:56 <gibi> ohh, good to know that, then I will try not to push the SL abbrev too much :)
17:25:40 <gibi> I will definetly try to follow the searchlight integration patches to help with the notification part if and when needed
17:26:18 <gibi> I expect to see bugs appearing about the notification code as soon as we start using it seriously
17:26:53 <gibi> anything else about the searchlight integration?
17:28:02 <mriedem> well,
17:28:12 <mriedem> i'm also trying to get searchlight running in the nova-next ci job,
17:28:25 <mriedem> and testing some of that here https://review.openstack.org/#/c/441696/
17:28:40 <mriedem> the hard part is going to be the fact that the searchlight devstack plugin doesn't configure anything except searchlight
17:28:49 <mriedem> i.e. it doesn't configure nova for the things that it needs to consume notifications
17:29:06 <mriedem> i think we could add some of that to the searchlight devstack plugin hopefully
17:29:17 <mriedem> otherwise we have to do stuff like this https://review.openstack.org/#/c/441711/
17:29:30 <mriedem> summary is it's not looking as easy as i thought it would be
17:29:50 <mriedem> and i might need some help getting the pieces together to setup notifications going out of nova and being consumed by searchlight in the nova-next job
17:30:01 <mriedem> does searchlight even support/handle versioned notifications from nova>
17:30:01 <mriedem> ?
17:30:22 <gibi> as far as I understand searchlight builds on the versioned notifications
17:30:44 <gibi> but this understanding of mine is only based on bug reports and feature request
17:31:08 <gibi> I guess I cannot avoid to look at the searchlight code sooner or later
17:32:44 <mriedem> yeah. i don't have anything else. will go through the spec comments today.
17:32:49 <gibi> the event_types in https://github.com/openstack/searchlight/blob/2ff4edd1cb0f15742699ab153ed7b66d4fa45e75/searchlight/elasticsearch/plugins/nova/notification_handler.py seem to be legacy ones
17:32:50 <mriedem> and try to review some of the other changes.
17:32:57 <mriedem> right that's what i've noticed too
17:33:13 <mriedem> if searchlight doesn't support nova versioned notifications,
17:33:21 <mriedem> then we can't fulfill the rest api response for compute
17:33:24 <mriedem> and that's a pretty major blocker
17:34:22 <gibi> correct, I think we need to ask the searchlight cores to give a statement about it
17:34:58 <gibi> I will ask them tomorrow
17:35:14 <gibi> OK, let's move on
17:35:21 <gibi> #topic AOB
17:35:44 <gibi> there is couple of small things
17:35:57 <gibi> short circuit notification payload generation is the first
17:36:35 <gibi> We merged a change yesterday in oslo.messaging to move the generic part of the idea from nova/cinder to oslo
17:37:11 <gibi> so now we need to wait for an oslo.messaging release to bump the requirements and then adapt the nova patch
17:37:24 <mriedem> ok
17:37:36 <gibi> meanwhile I still have to add some test coverage to the nova patch https://review.openstack.org/#/c/428260/
17:37:41 <mriedem> you could request the o.m release yourself if you don't want to wait
17:37:52 <mriedem> just post a patch to the openstack/releases repo
17:37:55 <mriedem> and copy the oslo ptl
17:38:18 <gibi> mriedem: thanks for the info, I will try to do that
17:39:25 <gibi> the last thing from myself is asking for volunteers to pick up the implementation work for bp json-schema-for-versioned-notifications
17:39:42 <gibi> it seems syjulian is busy with something else
17:40:16 <gibi> for me this is low prio now considering all the other things we discussed already
17:40:23 <mriedem> not it
17:40:25 <mriedem> and i have to run
17:40:39 <gibi> mriedem: thanks for beeing here
17:41:13 <gibi> so that was the last thing from my side. Is there any other things that we need to discuss?
17:41:27 <gibi> aunnam, sneti : anyting on your side?
17:41:32 <sneti> gibi, nothing.
17:41:54 <aunnam> no from my side
17:41:59 <sneti> patches are ready for review for the first part of search light fields.
17:42:12 <sneti> gibi, so just waiting for reviews and comments.
17:42:47 <gibi> sneti: yes, those patches are OK for me too
17:43:26 <gibi> if nothing else then I think that was all for today
17:43:36 <gibi> thanks for dropping by :)
17:43:59 <gibi> #endmeeting