17:01:13 <gibi> #startmeeting nova notification
17:01:14 <openstack> Meeting started Tue Jun  6 17:01:13 2017 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:18 <openstack> The meeting name has been set to 'nova_notification'
17:01:21 <gibi> almost missed the start time :)
17:01:58 <mriedem> o/
17:03:36 <gibi> soo I'm back
17:03:51 <gibi> piles of mails to reade
17:03:53 <gibi> read
17:04:05 <gibi> reviews to go through
17:04:36 <gibi> actually we have a lot of transformation pathes that looks complete and ready
17:04:50 <gibi> mriedem: what is the deadline for such commits to be merged?
17:05:04 <mriedem> FF
17:05:07 <mriedem> which is...
17:05:13 <gibi> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/versioned-notification-transformation-pike+label:Code-Review%253E%253D%252B1+label:Verified%253E%253D1+AND+NOT+label:Code-Review%253C0
17:05:21 <mriedem> july 27
17:05:33 <gibi> mriedem: thanks, that still plenty of time
17:06:25 <gibi> I will rebase the searchlight additions this week as it is now in conflict
17:06:45 <gibi> I also saw you comment about binary=nova-api
17:06:50 <gibi> so I opened a bug report
17:07:15 <mriedem> i've forgotten what that comment was - that nova-api isn't a binary?
17:07:19 <mriedem> it's nova-osapi_compute
17:07:20 <mriedem> right?
17:07:21 <gibi> #link https://bugs.launchpad.net/nova/+bug/1696152
17:07:22 <openstack> Launchpad bug 1696152 in OpenStack Compute (nova) "nova notifications use nova-api as binary name instead of nova-osapi_compute" [Undecided,New]
17:07:28 <gibi> mriedem: right
17:08:01 <gibi> seems easy to fix
17:08:12 <gibi> so I marked as low hanging
17:08:13 <mriedem> but, is it worth fixing at this point
17:08:19 <mriedem> it would be a version bump wouldn't it?
17:08:59 <gibi> good question. I thought that this is a bugfix so no bump
17:09:08 <mriedem> it's a change in the payload
17:09:11 <mriedem> the value i mean
17:09:11 <gibi> also this is part of the envelope not the payload
17:09:24 <gibi> as binary ends up as publisher_id
17:09:26 <mriedem> hmm, well, still seems like a change
17:09:36 <mriedem> i don't know if/how anyone is consuming this
17:09:47 <gibi> aaand there is no version on the envelope as that is created by oslo
17:09:47 <mriedem> and if they use that binary to correlate anything
17:10:27 <gibi> https://github.com/openstack/nova/blob/master/doc/notification_samples/aggregate-create-end.json#L18
17:10:38 <gibi> so we have basically no number to bump
17:10:55 <gibi> only the suff under the payload key is versioned by nova
17:11:49 <mriedem> sure, but
17:12:01 <mriedem> any client side tooling that was expecting nova-api before and using that for something,
17:12:04 <mriedem> would now be broken
17:12:09 <gibi> true
17:12:37 <mriedem> http://git.openstack.org/cgit/openstack/monasca-agent/tree/monasca_setup/detection/plugins/nova.py#n22
17:12:47 <gibi> can we somehow singal deprecation? maybe with a release notes?
17:12:59 <mriedem> i doubt people would notice
17:13:30 <mriedem> i think i would just mark the bug as won't fix and consider it an alias
17:13:42 <mriedem> we could put a note in the code if we cared enough,
17:13:53 <mriedem> and/or make the binary kwarg for the notifications an enum
17:14:02 <gibi> the monasca agent talks about the name of the process wich is nova-api in ubunut distro at least
17:14:04 <mriedem> so we don't end up with nova-api and nova-osapi_compute both happening
17:14:59 <mriedem> i left some comments in the bug report
17:15:09 <mriedem> but i'd just do an enum validation for now and stick with the existing binary
17:15:11 <gibi> yeah, I think this nova-osapi_compute is an edge case
17:15:12 <gibi> https://github.com/openstack/nova/blob/master/setup.cfg#L48
17:15:27 <gibi> here ^^ we also create nova-api as a script
17:15:33 <mriedem> yes honestly nova-osapi_compute as the name as messed us up many times even within nova
17:15:36 <mriedem> checking for service versions
17:15:43 <mriedem> *has messed
17:16:18 <gibi> OK, lets keep nova-api, and add an enum to make clear this is intentional
17:18:48 <gibi> beside this you mentioned that on the summit an issue was raised regarding the frequency of instance.exists
17:18:57 <gibi> but I haven't seen a bug report jyet
17:19:12 <mriedem> me neither
17:19:21 <gibi> OK then I will wait patiently
17:19:21 <gibi> :)
17:19:22 <mriedem> i think that was klindgren from godaddy that said it
17:19:27 <mriedem> we could ask them or harlowja
17:19:36 * gibi making notes
17:19:46 <mriedem> i remember the issue, let me check the code quick
17:20:09 <mriedem> so it's sent from here right? https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L6157
17:20:45 <mriedem> and every time that periodic task runs (default once per minute), we get the instances for that host within some audit period window https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L6130
17:20:56 <gibi> yes, this is the periodic source of this notificaition, and there are some other places we send this
17:21:27 <mriedem> i think the complaint was that we get all of those instances for each periodic, so once per minute, rather than like the heal_instance_info task that pulls the instances and puts them in a queue and processes 1 instance per minute
17:21:43 <mriedem> https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5891
17:22:18 <mriedem> would need to investigate last_completed_audit_period
17:22:52 <mriedem> oh dtp might also be able to help here, he works on notifications stuff at godaddy too
17:22:59 <gibi> the default of CONF.instance_usage_audit is a month
17:23:36 <mriedem> https://github.com/openstack/nova/blob/master/nova/utils.py#L325
17:24:14 <mriedem> ok, so i think what it's doing is getting all instances on that host within the last month
17:26:04 <mriedem> anyway, dtp is going to ask about it
17:26:08 <mriedem> i asked him in -nova
17:26:15 <gibi> OK
17:26:37 <gibi> It seems pretty complicated to me so I need to read the code a bit deeper
17:27:04 <gibi> at least there seems to be return statement here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L6126
17:27:08 <gibi> could be a sortcut
17:27:55 <mriedem> i'm not totally sure how that works either
17:27:56 <gibi> anyhow if dtp give us some hints then I can try to reproduce the provelm
17:28:25 <gibi> problem
17:29:49 <gibi> I think that was all I have in mind for today
17:29:54 <mriedem> ok
17:30:08 <gibi> do you have anything else to discuss?
17:31:09 <mriedem> nope
17:31:37 <harlowja> mriedem whatss up
17:31:43 <mriedem> harlowja: see dtp in -nvoa
17:31:45 <mriedem> *nova
17:31:50 * mriedem needs to each lunch
17:31:53 <harlowja> k
17:34:25 <mriedem> gibi: are you going to end the meeting
17:34:27 <mriedem> ?
17:34:37 <gibi> ohh yeah :D
17:34:55 <gibi> have  nice lunch :)
17:34:58 <gibi> #endmeeting