20:00:30 <gibi_> #startmeeting nova notification
20:00:34 <openstack> Meeting started Tue Nov 17 20:00:30 2015 UTC and is due to finish in 60 minutes.  The chair is gibi_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:37 <openstack> The meeting name has been set to 'nova_notification'
20:00:42 <rlrossit> o/
20:00:52 <gibi_> hi rlrossit
20:01:00 <rlrossit> hi gibi_!
20:01:25 <mriedem> HI!
20:01:31 <mriedem> <3 notifications
20:01:42 <gibi_> hi mriedem!
20:01:43 <gibi_> :)
20:01:52 <mriedem> rlrossit said you guys were lonely
20:02:17 <gibi_> yes, it was a quite place last time :)
20:02:41 <gibi_> anyhow, let's get started
20:02:47 <gibi_> #topic specs
20:02:57 * bauzas lurks
20:03:06 <gibi_> both notification specs has been approved
20:03:11 <rlrossit> woo
20:03:19 <gibi_> thanks for all the comments and help with that
20:04:14 <gibi_> at the moment I don't know about any other specs targeting notifications directly, if there any please tell
20:05:15 <gibi_> I guess it is a no
20:05:26 <gibi_> anything else regarding specs?
20:05:26 <mriedem> i haven't seen any
20:05:49 <mriedem> if i see things about notification impacts in specs i say they are dependent on the versioned notifications overhaul
20:06:07 <gibi_> that sounds reasonable
20:06:19 <bauzas> I guess all the specs are in the specs etherpad ?
20:06:44 <gibi_> bauzas: the two notification related from me are in the etherpad
20:06:51 <bauzas> coolness then
20:06:56 <bauzas> #link https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking
20:07:13 <gibi_> thanks for the link :)
20:07:36 <mriedem> https://blueprints.launchpad.net/nova/+spec/add-swap-volume-notifications
20:07:36 <gibi_> anything else regarding specs?
20:07:42 <gibi_> ohh
20:07:47 <mriedem> looks like that is dependent on the versioned notifications bp, but not marked in lp, i can do that
20:08:08 <mriedem> which is https://blueprints.launchpad.net/nova/+spec/versioned-notification-api right?
20:08:25 <gibi_> mriedem: yes. thanks!
20:09:11 <mriedem> done
20:09:30 <gibi_> great
20:10:33 <gibi_> if nothing else on specs then lets move forward
20:10:55 <gibi_> #topic patches
20:11:22 <gibi_> I published a work in progress patch adding the service status notification
20:11:35 <gibi_> #link https://review.openstack.org/#/c/245678/
20:11:48 <gibi_> rlrossit made some fine points there already
20:12:08 <gibi_> but more eyes are welcome
20:12:21 <mriedem> i'm confused
20:12:30 <mriedem> bp service-status-notification is the bottom bp
20:12:38 <mriedem> and versioned-notification-api is dependent on that
20:12:43 <gibi_> mriedem: no, it is the first one in the line
20:12:53 <gibi_> mriedem: on the summit we agreed that this will be the carrot
20:13:06 <mriedem> so the dep tree here is correct? https://blueprints.launchpad.net/nova/+spec/versioned-notification-api
20:13:06 <gibi_> mriedem: for the operators to move to consuming versioned notifications
20:13:27 <mriedem> those first 2 look backward
20:13:36 <gibi_> mriedem: yes it is correct
20:14:14 <gibi_> I also feel that it is confusing but that was the agreement
20:14:45 <gibi_> so I started with that
20:15:15 <rlrossit> gibi_: first we're doing the notification base, and then we'll base the service-status-notification on that base, and then we'll finish the rest of the versioned notifications after that right?
20:15:39 <gibi_> rlrossit: yes, this is my plan
20:15:46 <mriedem> yeah, so i'm wondering what the code changes are for https://blueprints.launchpad.net/nova/+spec/versioned-notification-api
20:15:57 <mriedem> since it looks like some of that infrastructure is in https://review.openstack.org/#/c/245678/
20:16:50 <mriedem> these should be split up
20:17:07 <bauzas> +1
20:17:08 <mriedem> the versioned-notification-api bits should be in change 1, then the service status stuff should build on that with change 2
20:17:30 <gibi_> mriedem: yes this is the confusing part, that some of the infra we need already for the service status notification. The versioned-notification-api will add documentation, sample generation, and it will transform three notifications instance.update keypair.* and api_fault notification
20:17:33 <mriedem> i understand the carrot part, and we can approve them in order when we're happy with the service status change
20:17:35 <bauzas> that should be at least 2 changes
20:18:03 <gibi_> Ok, I will split up the current so that the infra is in a separate patch
20:18:12 <mriedem> just make sure they are in a dependent series
20:18:14 <gibi_> s/current/current patch/
20:18:29 <rlrossit> gibi_: just create NotificationBase stuff in this change, and have that paritally implementing bp versioned-notification. Then do the service notifications stuff in a dependent patch, with that one on bp-service-status-notification
20:18:31 <mriedem> "and it will transform three notifications instance.update keypair.* and api_fault notification"
20:18:35 <mriedem> those conversions should all be separate changes
20:18:47 <mriedem> well, handle keypair and faults separately
20:18:51 <rlrossit> which is part of the notifications bp right?
20:18:57 <gibi_> mriedem: of course they will be separate dependent patches
20:18:57 <rlrossit> not service-status-notification?
20:19:09 <gibi_> rlrossit: looks like a good plan
20:19:17 <mriedem> ok, sounds like this is sorted out
20:19:26 <mriedem> mega patches are not fun to review
20:19:39 <rlrossit> I'll note this on the review too gibi_
20:19:45 <gibi_> rlrossit: thanks
20:19:48 <gibi_> mriedem: I agree
20:20:37 <gibi_> I feel we have one thing that we shall discuss regarding the current published implementation proposal
20:21:00 <gibi_> currently the notification payload object has an object field pointing to a Service object
20:21:19 <gibi_> this makes the version of the payload dependent on the version of the Service object
20:21:26 <gibi_> there are pros and cons
20:21:49 <gibi_> #link https://review.openstack.org/#/c/245678/2/nova/objects/service.py,cm
20:22:29 <gibi_> cons: 1) the payload version needs to be bumped if the Service object is updated
20:23:00 <rlrossit> gibi_: it actually doesn't
20:23:19 <gibi_> rlrossit: doesn't it enforced by some test?
20:23:23 <rlrossit> now that we do manifest-related backports we don't need to bump that every time
20:23:39 <rlrossit> they're only enforced if you add a new field or remotable method
20:23:49 <rlrossit> underlying object changes don't affect it anymore
20:24:04 <gibi_> rlrossit: do you have some reference regarding manifest-related backports. I have to check this out :)
20:24:21 <rlrossit> granted, with that, we can still have the carpet pulled out from underneath us
20:24:39 <bauzas> gibi_: I don't get a problem with that?
20:25:38 <gibi_> bauzas: the payload is yet another object in the dependency chain that needs to be bumped, somebody refered to this as an update hell in the spec review
20:25:50 <gibi_> but honestly I'm also hesitant droping the dependency
20:26:00 <rlrossit> gibi_: that was me, but now we don't need to worry :)
20:26:02 <gibi_> it feels more future proof to keep it
20:26:34 <rlrossit> gibi_: here's the dependency removal change
20:26:36 <rlrossit> #link https://review.openstack.org/#/c/231271/
20:26:42 <gibi_> rlrossit: thanks, I wil check
20:26:49 <bauzas> gibi_: using version manifests solves the problem, right?
20:27:06 <rlrossit> bauzas: I have a long-winded explanation of my concern with this
20:28:08 <gibi_> bauzas: it feels like it is less of a problem but I will read that change to understand it better
20:28:15 <rlrossit> If Service updates to v2.0 and removes some fields, the notification receiver won't be able to know what fields are deleted, because it has no concept of the versioned objects, just the dicts it receives. Because manifest backports only occur within nova, they're dangerous for the listeners outside of nova
20:29:06 <gibi_> rlrossit: Does it mean that only major version update can cause problems?
20:29:36 <rlrossit> gibi_: well, major version updates are the only cases in which we delete fields, so it was the easiest counterexample to come up with :)
20:29:47 <gibi_> rlrossit: right
20:29:48 <rlrossit> but in reality, I think that is our only problem
20:29:55 <rlrossit> because listeners don't care about remotable methods
20:30:14 <rlrossit> nor do they care about changes of fields from string to *Enum because the serialized format is the same
20:30:32 <rlrossit> the last thing would be is if fields are added, they just may not be able to access them because they aren't aware of them
20:31:05 <rlrossit> but then again if a field is added in like 1.5, the listener may start to expect it. Then if a compute spits out 1.4, the listener will explode again because it's expecting to get 1.5
20:31:23 <rlrossit> which would basically require a double implementation of compat code
20:31:24 <gibi_> this sounds good to me. If there will be major version change then we can even add some backporting code for a time period for the payload object
20:33:01 <gibi_> rlrossit: so consumers shall not be eager to consume 1.5 to early
20:33:08 <rlrossit> correct
20:33:21 <rlrossit> I may just be overthinking this too... I have no idea what consumers actually do
20:33:32 <rlrossit> those are just all of the scenarios I have thought of
20:34:58 <gibi_> I think if we go out with the versioned implementation and the consumers has problems with the compat code then we can add backporting to nova
20:35:34 <gibi_> but it was intentionally left out from the current scope as there might be no need for it
20:36:11 <rlrossit> part of the serialization sends the version with it too, so while it will require paying attention by the consumer, it is possible for them to do their own compat
20:36:33 <gibi_> rlrossit: yes, they can do it
20:38:14 <gibi_> rlrossit: I think there are multiple way to handle this so we just need some feedback from the consumer which I guess they will give use as soon as they start consuming versioned notifications
20:39:12 <gibi_> rlrossit: does it sounds good for you?
20:39:46 <rlrossit> yep sounds good to me
20:40:00 <mriedem> if you're looking for consumers, ping gordc
20:40:26 <gibi_> mriedem: I did some advertising of the spec in ceilometer but I will do it with the patch as well
20:40:38 <gibi_> rlrossit: great
20:41:16 <gibi_> anything else regarding the current patch?
20:41:30 <rlrossit> I'm done
20:42:03 <gibi_> then lets move forward
20:42:07 <gibi_> #topic Open Discussion
20:43:00 <gibi_> I have nothing for this topic, do you have anything?
20:43:27 <rlrossit> nothing other than let me know if you have work you want me to work on
20:43:44 <rlrossit> I'm guessing most of the work will come when we start converting all of the payloads
20:44:29 <gibi_> rlrossit: good point. I think as soon as the infra pieces are done we can split up the conversion work
20:45:06 <gibi_> both instance.update and api_fault are a big piece of work
20:45:38 <gibi_> so if you can take one of those then I will take the other
20:46:53 <rlrossit> I have no idea what either of those involve, but I'll decide later :)
20:47:05 <rlrossit> because we need the foundation down first
20:47:11 <gibi_> rlrossit: no pressure. :)
20:47:19 <gibi_> rlrossit: I agree, fundation first.
20:47:52 <gibi_> OK. anyithing else?
20:47:58 <rlrossit> I'm done
20:48:05 <rlrossit> mriedem disappeared
20:48:38 <gibi_> I guess he can catch us on openstack-nova or in the review
20:48:48 <rlrossit> sounds good
20:48:52 <gibi_> It feels we are done for today.
20:49:00 <gibi_> thank you all
20:49:03 <rlrossit> thanks!
20:49:11 <gibi_> #endmeeting