15:00:50 #startmeeting openstack search 15:00:51 Meeting started Thu Mar 3 15:00:50 2016 UTC and is due to finish in 60 minutes. The chair is TravT_. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:55 The meeting name has been set to 'openstack_search' 15:01:25 o/ 15:01:36 o/ 15:01:42 o/ 15:01:53 o/ 15:02:18 sjmc7: are you there? 15:02:35 hi lakshmiS 15:02:54 hi 15:02:57 how is everybody today? 15:04:02 sleepy 15:04:11 hi travis. more or less same 15:04:17 o/ 15:04:25 late 15:04:34 yeah, i'm a bit sleepy as well... couldn't help getting up at 1 am and working a bit 15:04:49 anyway, i know it is late ofr lei-zh and yingjun 15:04:55 so, agenda is here https://etherpad.openstack.org/p/search-team-meeting-agenda 15:05:06 add anything you see fit 15:05:24 #topic mitaka 3 15:05:54 The searchlight client has a release! 15:06:03 https://pypi.python.org/pypi/python-searchlightclient/0.2.0 15:06:35 on the downside, I followed old instructions to do it 15:06:43 and bypassed the new route 15:07:04 any port in a storm 15:07:09 but chatted with dhellmann 15:07:15 and he said it was okay 15:07:24 and to go ahead and put up the normal review 15:07:54 So I put that up: Release management: https://review.openstack.org/#/c/287439/ 15:08:11 I also updated the patch adding SL client to global requirements 15:08:25 https://review.openstack.org/#/c/268394/ 15:08:50 once that lands, we can fix our devstack script. 15:08:54 yay 15:09:04 but whatever the case. great work to all in getting that out! 15:09:26 cool 15:09:59 so, we also need to tag mitaka 3 for the service 15:10:46 i believe we should see if we can land the neutron plugin and swift plugin today 15:10:54 i've looked through both 15:11:18 but reviews on those two will be especially appreciated 15:11:28 and i uploaded a new patch to fix the README as Travis found: https://review.openstack.org/#/c/287555/ 15:11:39 yingjun: thanks! 15:12:18 the swift plugin is functionally complete with some patches for review comments coming up today 15:12:34 yeah, let's talk swift for a minute. 15:12:38 #topic swift 15:12:55 the swift team is having a hackathon this week 15:13:12 sjmc7 sent a request to get our need for notifications onto their agenda 15:13:23 turns out a number of people wanted that topic 15:13:42 * notmyname lurks 15:13:49 so yesterday sjmc7 and i dialed in and had a lively discussion with the team. 15:13:53 notmyname: hello 15:14:15 notmyname: i'll give my impression and then you can correct me 15:14:29 I'm listening to one person while reviewing code for another and also in here. yes, please carry on with your summary :-) 15:14:51 search is very interesting to many people involved with swift 15:15:10 and the need to index data is pretty well agreed on 15:15:17 but, doing notifications via traditional middleware and rabbitmq was worrisome to the team. 15:15:36 so a lot of discussion went around about how to best accomplish this 15:16:27 and the agreement seemed to be that we'd like to try an approach that allows swift to call some searchlight library code where they essentially directly send updates through to searchlight / elasticsearch 15:16:56 and the swift team would look at various options to integrate it at the most appropriate layer in swift 15:17:35 yes, that sounds all correct to me 15:17:51 cool 15:18:17 does that make sense to everyone else? I can answer any questions you have about it 15:18:43 i am in favor of removing moving parts, but i’d like to speak to our ceilometer team about issues they had with rabbit 15:18:54 and we (swift) have one request of you (searchlight): some example code on how to add something to the index 15:18:55 i guess the question would be - is that the only option? 15:19:04 that == no rabbit? 15:19:10 yes 15:19:54 we've had at least 2 medium to large production clusters that have specifically rejected using rabbit to transport notifications from swift. seems the problems are mostly with the receivers keeping up 15:20:00 notmyname: we can (will) point you at the current code, though it’d obviously need some refactoring to be plugged into other projects 15:20:34 ah, yes, rmq doesn’t deal well with that 15:20:38 and other deployers who are exploring search integration as well and are looking for more efficient ways to do index updates 15:21:08 yeah, doing it directly is certainly more efficient 15:21:28 yeah in that case direct updates to searchlight will more or less resemble the plugin code in searchlight 15:21:29 handling errors (which we spoke about) is potentially complicated 15:21:33 but we can deal with that 15:22:07 yeah, and the thought is basically "we're just dumping stuff on a queue so that it can go to an indexer and put it on its own work queue. can we just skip that first part?" 15:22:25 notmyname: we were thinking we could get a bit of that code refactored to support this usage concept as well before sending it to you. 15:22:39 cool 15:22:44 right. although the argument in favor of queues is that in theory they can handle burst high loads 15:22:45 notmyname: question for you 15:23:02 if SL or ES is down, does swift have built in mechanisms for retry 15:23:15 or would any client code of SL need to handle that? 15:23:20 softlayer or espana? 15:23:36 I don't know what SL or ES is 15:23:52 SL = searchlight. ES = elasticsearch 15:24:30 but yeah. if you heard on the phone, our conversation was that *anything* we do has to be best-effort. swift will need to retry if it doesn't get a success from the other side 15:24:34 ok :) 15:24:56 notmyname 15:25:02 yeah, that's what we were wondering 15:25:35 and i was thinking we could potentially use messaging as backup 15:25:44 retrying and algorithms that still make progress is a common pattern in swift. although this code isn't yet written (so technically, no, we don't yest have built in retries for it), I wouldn't expect it to land without that functionality. it's the only way to scale 15:26:07 ok. 15:26:22 well, i think this is great progress 15:26:34 and we're very interested in trying out this direct pattern 15:26:45 no, I don't think we'd want to see messaging as a backup. messaging (even if it scaled) is viewed as the optimization that can fail and itself needs a backup. message queues arent' reliable 15:26:59 :) 15:28:01 btw, for everybody here. Monday night i put together a brief demo of POC swift object search in the new horizon searchlight panel https://youtu.be/-Io8uaNLrVc?vq=hd720 15:28:09 cool 15:28:38 that's awesome! 15:29:29 ok, so anything else to talk about re: swift for today? 15:29:36 so for mitaka, SL swift plugin will be tagged as Experimental until notification middlware lands(direct call from swift in future) 15:29:59 right. we did the same last release for glance metadefs. 15:30:05 very clearly documented. 15:30:11 disabled by default 15:30:28 yes in devstack and docs 15:31:03 will pull sjmc code and push it to SL repo today 15:31:27 which is a swift patch currently 15:33:37 ok, on to next 15:34:15 #topic feature freeze exceptions 15:34:45 it looks like zero downtime reindexing will need it. as well as cinder plugin 15:34:56 both have had several rounds of patches 15:35:06 and are close 15:35:49 i’m working on cinder today 15:36:08 lei-zh what is the status on the zaqar forwarder? 15:37:15 I'll rebase it and some feedback is welcome 15:37:27 any link for the cinder one? 15:37:49 should I extract the data enhancement from the es indexing plugins 15:38:00 yingjun: https://review.openstack.org/#/c/280273/ 15:38:02 yingjun: 280273 15:38:20 ok, thanks 15:40:25 ok 15:40:41 so, let's all attack reviews. 15:40:55 is there ability / interest in a live review day next Tuesday? 15:41:01 sure 15:41:31 what time? 15:41:48 I can do pretty much all morning 15:42:02 so what time works for you? 15:42:10 i know this is late for yingjun 15:42:13 TravT_: global openstack hackdays are 7-9 15:42:19 ah, right 15:42:25 is that pst? 15:42:32 march 7 - 9 15:42:36 oh 15:43:00 #topic hackdays 15:43:14 rosmaita: nikhil: how are these different than just doing my every day job? 15:43:40 not much, for most active folks 15:43:56 it will be a lot of active folks all over the world 15:44:01 big difference for me 15:44:03 you may see a surge of bugs taken 15:44:27 possibly and hopefully a ton for you to review 15:44:55 foundation and team wants it to help make a stable and successful release 15:45:06 so the side-effects are accordingly 15:45:20 * nikhil done 15:45:36 ok. well, it sounds very interesting. 15:45:43 last week you had a link 15:45:46 can you share again? 15:46:15 https://twitter.com/nikhilskomawar/status/704518613026230273 15:46:27 TravT_: oh, which link? 15:46:41 I got that one for lakshmiS (scrolling back logs) 15:47:27 oh looks like we'd want to add candidate bugs to here: https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka-Bugs 15:47:27 I got that twitter as I am hoping there was be some conversations around it 15:47:36 cool 15:47:38 some folks said they had some .. 15:47:47 meh :| 15:47:56 TravT_: correct 15:48:10 so we can put up new bugs for fixing and bug reviews 15:48:12 ? 15:48:34 TravT_: yes please 15:49:02 well, maybe we should just do that right now 15:49:17 s/was/will/ 15:49:27 https://bugs.launchpad.net/searchlight 15:49:50 any on there we would like to see if we can get attention on from bug day? 15:50:26 1538349 has a patch up but is tricky to test 15:51:13 it’s sort of tough figuring out how much effort it would be for someone to come in cold and be able to work on things 15:51:18 yeah, i know 15:51:26 oh! 15:51:34 I've seen that in glance before 15:51:38 yeah :) 15:51:43 we’rte using the same code :) 15:51:48 but if somebody has interest, would love to enable them. 15:51:56 haha 15:52:01 ++ 15:52:20 I think it will help 15:52:24 maybe some of the e-s 2.0 compatibility stuff 15:52:32 we can give prize in the NYC center who solves it!!! :D 15:52:41 that’s not urgent for this release but we will need in N 15:52:47 muhaha 15:52:55 i think we’ll find more bugs next week as we start testing more 15:52:59 And the "Solved ALL THE THINGS" award goes to.... 15:53:09 last release you found a bunch from working on the horizon panel as we got up to the summit 15:53:24 maybe we should have a bug for each of the sets of missing functional tests. 15:53:32 yeah.. 15:53:40 TravT_: https://bugs.launchpad.net/searchlight/+bug/1526856 15:53:41 Launchpad bug 1526856 in OpenStack Search (Searchlight) "Refactor plugin unit test code" [Medium,New] 15:53:54 I think someone would def like that one 15:54:50 sjmc7 you okay with that? 15:54:58 let's open a bug for each group of functional tests 15:55:09 sure 15:55:13 maybe we should open a bug for functional tests needing to run on zuul 15:55:21 that'd be a great one to get solved 15:55:25 yeah. 15:55:30 it is currently a BP 15:55:37 but i'd be happy to switch it to a bug 15:55:49 getting e-s installed on the test nodes is i think the main blocker 15:55:56 you can link bugs to BP 15:56:07 ok, I'll open that one and add to the etherpad 15:56:15 that way all of the tests are congregated 15:57:10 lakshmiS sjmc7 any chance you could open a bug for each set of functional tests missing? 15:57:18 then add to the bug smash etherpad? 15:57:22 sure 15:57:58 cool, thanks 15:59:46 ok will add more later, but i opened the zull one 15:59:47 https://bugs.launchpad.net/searchlight/+bug/1552767 15:59:48 Launchpad bug 1552767 in OpenStack Search (Searchlight) "Enable running of functional tests in zuul" [Undecided,New] 16:00:01 it looks like we are out of time for today 16:00:07 thanks everybody 16:00:09 #endmeeting