17:00:01 <gibi> #startmeeting nova notification
17:00:04 <openstack> Meeting started Tue May 17 17:00:01 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:08 <openstack> The meeting name has been set to 'nova_notification'
17:00:23 <gibi> hello everyone!
17:00:30 <rlrossit> o/
17:00:30 <syjulian> hi gibi
17:00:46 * rlrossit feels good for remembering the meeting today
17:00:50 <gibi> rlrossit: have you managed to eat lunch?
17:01:00 <rlrossit> just finished the last bite
17:01:17 <gibi> good, then everything is well set for the meeting :)
17:01:21 <gibi> syjulian: hi!
17:01:29 <TravT> o/
17:01:37 <gibi> TravT: hi!
17:01:46 <sjmc7> hey
17:02:40 <gibi> OK, lets get started
17:02:50 <gibi> #topic outstanding reviews
17:02:59 <gibi> start with the good news
17:03:15 <gibi> the json schema generation spec got accepted in ovo
17:03:27 <gibi> it went easier than I expected
17:03:35 <gibi> s/than/then/
17:03:44 <rlrossit> woo
17:04:16 <gibi> rlrossit: you mentioned earlier that you might be interested to implement / help implementing it. if you have time just go ahead
17:04:54 <rlrossit> unfortunately, I'm getting caught up in more and more internal things, so I don't think I'll be able to be of much help implementing things :(
17:05:22 <gibi> rlrossit: no worries. I hope you can still do some reviews as one of the main ovo guy
17:05:40 <rlrossit> I hope so as well
17:06:26 <gibi> if others are interested to help implementing the schema generation then just catch me or rlrossit for the details
17:06:50 <gibi> it won't be the easiest patch
17:07:05 <gibi> I feel
17:07:23 <rlrossit> yeah that one's going to be kinda interesting
17:07:37 <rlrossit> s/interesting/complex
17:08:32 <gibi> OK lets move to the transformation spec
17:08:37 <gibi> that is still open
17:09:00 <gibi> we resolved the instance vs. server naming issue today on IRC so that settled
17:09:22 <gibi> I left answers to TravT comments as well during the day
17:09:35 <TravT> hi gibi, yep
17:09:39 <gibi> but we can open those question up here if neede
17:09:40 <gibi> d
17:09:42 <TravT> i saw those and put in another comment.
17:09:55 <gibi> OK, I haven't read those yet
17:10:14 <gibi> do you want to discuss them here or keep the discussion in the review?
17:10:26 <TravT> either way is fine for me
17:10:37 <TravT> basically, i understand that versioned notifications seems to primarily be about giving a way to communicate change and structure of the notification
17:11:08 <TravT> we, of course, are also just hoping to get enough data that we don't have to or can severely limit having to call back to the API for more data.
17:11:51 <TravT> which i realize are different goals.
17:12:20 <gibi> one side of the problem is purely technical
17:12:50 <TravT> since an instance create can emit 7 notifications, doing an API call back is tricky.
17:12:51 <gibi> when we emitt the notifications we don't have the API structure available but we have an internal object model available
17:13:12 <gibi> replicating the API structure is possible but it would be quite heavy work as is
17:13:51 <gibi> and yes the other part of the problem is more fundamental, notification as the name suggest is different from an REST API response
17:14:38 <gibi> can we have a compromise on that we first transform what we have from legacy to the new framework and after that we are adding the bits and pieces searchlight really need
17:14:58 <TravT> sure, that probably makes sense as 1.0 version.
17:15:19 <TravT> but if the data is even available, we could consider transforming it on consumer side.
17:15:23 <gibi> this would be a bit different from the process of making everything the same in the notification as in the API and also it would allow a more stepwise process
17:16:21 <gibi> TravT: let's do it in a way as you proposed in the keypair notification
17:16:38 <gibi> TravT: there it seems quite OK to add that couple of extra fields
17:17:10 <gibi> TravT: however I have bad feeling about pushing the whole instance object out on the wire as is, as a first step
17:17:30 <TravT> hehe, yeah, i figured that'd be one concern
17:17:59 <gibi> if you can propose a set of fields you searchlight need then we can add those as a next step in the instance case as well
17:18:18 <TravT> okay, sjmc7 and i can look at that.
17:18:23 <gibi> great
17:18:48 <gibi> I really don't want to be the bad guy here, I just want to limit the scope as much as I can :)
17:19:14 <TravT> so what you are saying is that you want to have some hope that you get things done? ;)
17:19:23 <gibi> exatly!
17:19:34 <gibi> this is nova, it is alway just a hope :)
17:19:39 <TravT> hahaha
17:20:17 <gibi> good, that was the two spec I have
17:20:25 <gibi> does anybody has any spec we need to talk about?
17:21:24 <TravT> well, if we can just keep in mind for notifications (new and those to be transformed) that we want to make it possible to avoid API callbacks, then perhaps we can reach that goal someday.
17:21:43 <TravT> and iterate there as best we can.
17:22:15 <gibi> sure
17:23:05 <gibi> does searchlight want to index everything that is on the API or is there some rules what searchligth keeps and what not?
17:23:40 <TravT> we index most things. and then we provide quite a few ways in which we control the access to the things
17:24:18 * gibi has to read up on searchlight
17:24:41 <TravT> sure, you can also do a devstack deploy of it to try it out.
17:25:23 <TravT> just ping me when you find the time and i can help.
17:25:24 <gibi> I will check on one of the lazy Friday afternoons
17:25:34 <gibi> TravT: thanks
17:25:50 <gibi> anybody want to discuss a spec?
17:27:25 <gibi> OK
17:27:33 <gibi> then lets move forward
17:27:54 <gibi> before I left for vacation I pushed up some PoC code for the transformation of instance.delete
17:28:04 <gibi> https://review.openstack.org/#/q/topic:bp/versioned-notification-transformation-newton
17:28:22 <gibi> there is lot of raw edges there
17:28:38 <gibi> rlrossit already pointed out some in the series, thanks for it
17:28:49 <rlrossit> lotsa merge conflict there :)
17:29:00 <gibi> yeah, I'm working on it. :)
17:29:32 <gibi> rlrossit: regarding the auto discovery of the notification objects
17:30:09 <gibi> rlrossit: can we reuse the register_if(False) calls to get some sort of registry about the notification objects?
17:30:33 <rlrossit> I just saw your comment on that patch regarding that
17:30:38 <rlrossit> hmmmm
17:31:18 <rlrossit> ovo has a registration hook mechanism I think that maybe we can piggyback on
17:31:47 <rlrossit> it appears that's part of the object registry
17:31:58 <rlrossit> https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L112
17:32:41 <rlrossit> gibi: yeah, maybe we'll have to make a register_notification() decorator that makes things a little easier on us
17:33:12 <rlrossit> I already discussed with dansmith that register_if(False) can get kind of confusing (because from an initial readability standpoint, it's kind of lacking)
17:33:16 <gibi> rlrossit: good idea, it can call the register_if(False) and also create a list of notification objects for testing
17:33:26 <rlrossit> yup
17:33:42 <gibi> and it would be a lot more readably / logical for the reader
17:34:18 <rlrossit> gibi: plus that way for things like PayloadBase, you won't do register_notification on that, because we don't want to actually version the base classes
17:34:34 <gibi> rlrossit: right
17:35:17 <gibi> I think I will do this
17:35:25 <gibi> let's see how it looks in action
17:36:09 <gibi> thanks
17:36:54 <gibi> does anybody has any non spec patch to talk about?
17:38:29 <gibi> seem like we can move forward to the last topic
17:38:34 <gibi> #topic open discussion
17:38:50 <gibi> I have nothing extra to add
17:38:52 <gibi> anybody?
17:39:13 * rlrossit sits quietly
17:39:48 <gibi> rlrossit: sleepy from the food? :)
17:40:12 <rlrossit> gibi: no, sleepy from getting back from a short vacation yesterday :)
17:40:42 <gibi> rlrossit: I had a whole week of vacation, getting back was really a shock today
17:41:07 <gibi> vacation is good :) we need more :)
17:41:36 <gibi> anyhow It seems we are out of notification stuff so let's go back to work / sleep :)
17:42:01 <gibi> thanks for the valuable meeting
17:42:29 <gibi> #endmeeting