15:01:02 #startmeeting openstack search 15:01:03 Meeting started Thu Apr 7 15:01:02 2016 UTC and is due to finish in 60 minutes. The chair is TravT. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:06 The meeting name has been set to 'openstack_search' 15:01:53 o/ 15:02:00 o/ 15:02:01 o/ 15:02:09 o/ 15:03:41 okay 15:03:48 hey, sorry, connection issue 15:03:51 so. https://etherpad.openstack.org/p/search-team-meeting-agenda 15:04:08 #topic Mitaka release 15:04:19 Mitaka is officially released 15:04:28 just chatted with thierry about it 15:04:31 no more RCs 15:04:36 woo! 15:04:42 \o/ 15:04:49 Great job everybody 15:04:50 ! 15:05:13 which brings us to: 15:05:22 #topic Candidates for backports (potential 0.2.1) 15:05:34 we don't have any more rcs 15:05:45 but we can request a point release at any time 15:05:48 so 0.2.1 15:06:01 and sjmc7 found a couple candidates there 15:06:14 found/caused 15:06:34 Fix for updating nova server on volume attach/detach (sjmc7): https://review.openstack.org/#/c/301943/ 15:06:39 that's merged 15:06:48 i already put up a backport review for that one 15:06:57 link? 15:07:09 https://review.openstack.org/302814 15:07:12 is anybody opposed to me approving that for stable/mitaka? 15:08:07 nope 15:08:14 seems kind of important 15:08:47 okay, then i'm going to do that. 15:09:22 o/ 15:09:29 sjmc7 want to talk about: Discussion on https://bugs.launchpad.net/searchlight/+bug/1565028; any fix is going to be a bit unpleasant, not sure about the payoff 15:09:30 Launchpad bug 1565028 in OpenStack Search (Searchlight) "Neutron port detach isn't detected by nova event handler" [Critical,New] 15:09:36 this is a similar issue; detecting port attach/detach events for servers 15:10:09 the solution’s much less straightforward, but i will have another think about it 15:10:45 i think this is a much less common occurrence (it only affects explicitly attaching a neutron port to an instance, not automatic port creation) 15:11:07 i guess this is compounded by the nova-networks vs neutron situation (which i know nothing about other than that it used to be a "thing") 15:11:11 and we do currently deal with port attach, just not detach, which is troublesome 15:11:22 yeah, nova networks is another kettle of fish 15:11:35 nova abstracts some parts of that but not all 15:11:43 this is one of them 15:11:50 i actually think it’s kind of a bug on nova’s side in a way 15:11:57 I added nova to the bug, not sure if what’s the nova guys think 15:12:04 it should send interface-attach/detach events 15:12:18 i agree 15:12:27 (though that doesn't help much) 15:12:45 right. so i don’t know if it’s worth a hacky fix for this 15:13:00 how bad would it be to have not port info indexed? 15:13:05 *no 15:13:18 that’s the other option. it’s nice being able to get servers by IP address 15:13:26 just wondering if inaccurate data is worse than no data at all 15:13:29 yeah 15:13:36 no, you answered the question 15:13:44 people like to get servers by ip address 15:13:46 the denormalized fields the nova API gives us cause trouble in this respect, but they are quite useful 15:14:08 i would like ot persuade nova to have the server notifications match the API output but that seems like a long shot 15:14:23 i just wonder how often this happens in the real world? 15:14:50 well, probably a lot if you have your own subnet 15:14:52 floating IPs i suspect would be one example 15:14:57 and yeah, that too 15:15:02 they are kind of small, may have to add/subtract servers 15:15:17 maybe a hacky solution is better than none 15:15:29 sjmc7, the other events will cause us to update the port details as well, correct? 15:15:36 eg. restart 15:15:40 yes 15:15:42 TravT: that's a good point 15:15:58 yeah, anything where we have to reindex servers for another reason will pick up any changes 15:16:07 maybe we should just leave the bug open until nova fixes it 15:16:15 so yeah, all these reasons leave me on the fence 15:16:24 what is your hacky fix? 15:16:35 the only solution i’ve got is not very reliable - it’d mean searching for instances matching the port id 15:17:08 and we’ve stayed away from searching the e-s data during updates because of potential races with updating the search index 15:17:31 it’d work most of the time 15:18:33 i guess i can put up a fix and see what it looks like? 15:19:35 we do need, again, to come up with a general answer for when notifications don’t match API output; we keep running into these kinds of problems 15:19:51 I'm probably suffering from amnesia, but i feel like i missed a part of your proposal. are you saying on a *neutron* port event, we'd do this search and update instances appropriately? 15:19:57 yep 15:21:33 okay here's my .02 15:21:57 so the neutron info is up to date, but the nova is not? 15:22:02 yep 15:22:24 thanks yingjun for adding nova... i think it would be good if sjmc7 cleaned up the description a bit for nova patch team ease of consumption 15:22:54 i think the idea you have sjmc7 is interesting, but i'm slightly hesitant to immediately backport to stable 15:23:05 so maybe could go on master first for a bit? 15:23:08 ok 15:23:38 looking at the code there is actually a pretty serious bug we may have to backport :( i’ll file it separately 15:23:45 i don't like this proposal, because the ip search is rough on the nova api 15:24:02 rosmaita? 15:24:06 rosmaita: i wouldn’t search nova’s api, just the SL data 15:24:27 ok, i misunderstood 15:24:39 yeah, that’d be a no-no 15:25:12 here's a crazy idea. Make just port as parent of nova and let neutron port updates go there. 15:25:29 ? 15:25:42 ports can belong to routers or subnets 15:25:48 or rather, be attached to 15:26:06 hmm... that's be network --> port --> server 15:26:17 wait, wait 15:26:29 servers are not logically descendents of ports 15:26:31 that seems a bit wrong 15:27:20 hmm let me think through if there is a way to normalize for updates 15:27:39 the problem is that a port detach contains no information indicating what it was attached from 15:27:49 err, detached from 15:27:51 hmm 15:27:59 that seems like it could be a bug / bp on neutron 15:28:10 spread the wealth :) 15:28:11 TravT: +1 15:28:38 in the meantime, what’s the consensus 15:29:18 i think do nothing, figure eventully server updates will make the data consistent 15:29:25 leave the bug open 15:29:36 see if more people complain 15:29:56 ok. we can maybe bring it to neutron’s attention too 15:30:03 because i think TravT has a good point that we may not see this very much 15:30:23 sjmc7: +! 15:30:29 +1, even 15:30:42 is +! the same as a -1? 15:30:55 (plus not) 15:31:01 ;) 15:31:19 *tumbleweed* 15:31:24 tough crowd 15:31:36 okey 15:31:39 dokey 15:31:47 so, back to 0.2.1 15:32:06 i think the volume attach bug alone is worth a point release 15:32:39 TravT: point release of which? 15:32:40 ok. i’m filing another related server notification bug that i’ll fix today, so can we hold off until then? 15:32:42 is there anything else critical that could be solved in a few days that also should go in point release 15:32:49 searchlight 15:32:57 it is too late for rc3 (mitaka out) 15:33:01 we're not release independent 15:33:06 but thierry said we can do a 0.2.1 at any time 15:33:14 oh O_o 15:33:40 I thought that was owned by stable 15:33:47 probably shifted again 15:33:52 ttx would know 15:33:59 we own stable for searchlight, but that's what i was told this morning 15:34:09 interesting 15:35:03 go back to ignoring me 15:35:05 :) 15:35:35 i think for things that aren't patch releases (e.g. 0.2.x) it would be diff 15:36:18 * david-lyle is tempted to start with "back in my day" 15:36:25 lol 15:36:47 so, anybody against me putting up a point release once https://review.openstack.org/#/c/302814/ lands? 15:36:54 or is there anything else to consider? 15:37:01 yes :) 15:37:19 i’ve got another similar change i’d like to get in 15:37:25 okay, do share 15:37:32 i’m filing the bug 15:37:37 related to the port stuff 15:37:38 i really need some time for summit planning as well 15:37:54 go for it 15:38:06 #topic summit planning 15:38:21 i need to get things uploaded into eventbrite asap 15:38:32 #link https://etherpad.openstack.org/p/searchlight-newton-summit 15:39:21 first thing to notice is that we will have some discussion on search in a horizon session. and looks like a good chance there will be a swift session 15:39:44 i put links for that at the top 15:39:49 next, we have 3 sessions 15:39:54 1 fishbowl 15:39:56 2 working 15:40:15 currently 5 ideas listed 15:40:56 i'll pause for a minute to let people look at what is there now. 15:41:02 i’ve got one i haven’t put on there about weaning ourselves off API calls 15:41:06 and to add ideas 15:41:36 sjmc7: d'oh! can't believe i don't have that one on after rambling about maybe doing a fishbowl on it 15:41:45 adding it now 15:42:10 i think that would be a good fishbowl and we could also tag neutron, nova, cinder on it. 15:42:26 ironic as well 15:42:46 maybe, but i also mean from our perspective, what our general approach should be 15:46:56 lei-zh1: are you there? 15:47:50 The pipeline topic surely would benefit from some face to face time, but need to know if anybody from your team will be there to talk about it 15:48:17 yes, yuntong will be there 15:48:42 will malini be there as well? 15:48:43 although he carries some other tasks, but he can have a discussion on that 15:48:45 does she care about this? 15:49:45 I'll confirm with her about it 15:49:57 ok. 15:49:58 not sure about her schedule 15:50:44 so, i think the cross project aspect of notifications makes that one the most likely candidate for fishbowl out of what we have right now 15:50:57 that one meaning the notification topic 15:51:05 shall we submit a spec of pipeline, it will be helpful for the discussion 15:51:39 so different than the one you already have? 15:52:15 I think it's more with pipeline architecture 15:52:37 we didn't define that too much on the zaqar plugin 15:52:41 ok, if you think it would be helpful to all of us, then please do 15:52:54 ok 15:53:40 yingjun: any topics you propose or would like to vote for? also do you know if you will be able to come or not? 15:54:16 i guess we still need to add david-lyle 's beer bash as an idea 15:54:30 ;) 15:54:58 i’ll come to the summit 15:55:04 \o/ 15:55:13 that's great! 15:56:20 okay, well please add votes / ideas to the etherpad 15:56:42 i'll arrange and upload to eventbrite on monday-ish 15:57:01 #topic open discussion 15:57:33 does anybody have any other topics? 15:57:44 sjmc7, have that bug ready for us to discuss? 15:58:09 https://bugs.launchpad.net/searchlight/+bug/1567525 15:58:10 Launchpad bug 1567525 in OpenStack Search (Searchlight) "port.create.end events are handled incorrectly by nova" [Critical,New] 15:58:31 in short - novca currently listens to port.create.end for reasons only i could have answered, 7 months ago 15:59:02 which a) doesn’t make much sense and b) doesn’t handle them correctly. in light of the conversation we had i’m gonna remove the handler for backporting 15:59:25 and then see if we can handle port updates consistently for Newton until we can get the notifications fixed 15:59:47 okay, i'll look at it in detail. 16:00:06 time is up for us 16:00:10 thanks everybody 16:00:16 #endmeeting