15:00:42 #startmeeting openstack search 15:00:43 Meeting started Thu Dec 10 15:00:42 2015 UTC and is due to finish in 60 minutes. The chair is TravT_. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:46 The meeting name has been set to 'openstack_search' 15:01:05 o/ 15:01:05 o/ 15:01:09 o/ 15:01:11 o/ 15:01:15 brb ... have to refill coffee 15:01:23 hi 15:01:24 same here 15:01:30 good call on coffee 15:02:22 as FYI, lakshmiS live in an area of India that has been hit hard by flooding and he's had only occassional power the last couple weeks. 15:02:28 back 15:02:50 how is everybody this lovely day? 15:02:59 sorry to hear about lakshimiS ... hope he & his family are OK 15:03:24 yeah. i think they are all ok 15:03:46 agenda is here: https://etherpad.openstack.org/p/search-team-meeting-agenda 15:04:27 #topic Mitaka m1 tagged 15:04:27 https://github.com/openstack/searchlight/releases/tag/0.2.0.0b1 15:04:38 not much to say about it 15:04:40 other than FYI 15:05:04 that’s a catchy tag 15:05:07 rolls off the tongue! 15:05:25 the new process on the surface seemed complicated from the email, but actually was easier than last time. 15:05:50 i think some of the projects that are used to just having release manager do everything may not have agreed 15:06:14 but for us, it was simpler 15:06:39 #topic cinder updates 15:06:50 this one isn't on the agenda, but thought I'd share some info 15:07:12 duncan (core on cinder team) tells me he's got it nearly ready 15:07:27 nice 15:07:51 he's been also working on improving notifications from cinder for searchlight purposes 15:08:07 awesome! 15:08:14 (o/ btw) 15:08:19 o/ 15:09:05 the plugin he's got, he says will work with new notifications and have a fallback to do API callbacks until the notifications are in cinder 15:09:14 (unless I mistook something) 15:09:26 so is it possible to get that Mitaka? 15:09:35 that is definitely the goal 15:10:05 i know he has a number of things he's juggling, but he says he'll try to have a patch up shortly 15:10:07 once lakshmi’s back online i’m hoping to put a swift demo together, although hte notifications are harder in that case 15:10:24 #topic swift updates 15:10:25 ^ 15:10:34 err, that 15:10:56 i’ve been able to consume notifications from swift, but need to find somewhere for the middleware to live 15:11:36 yeah, once lakshmi has that patch up, we'll be in a better place to talk to the swift team further 15:11:55 i've been scratching my head of whether or not we should put swift search into that horizon panel or not 15:12:16 i know there is effort being discussed to redesign the swift panel in horizon. 15:12:29 and i'd like to get them to consider search as part of that. 15:12:39 so i'll pursue that. 15:12:41 we’ll have to see how the timing works out 15:12:53 by "that horizon panel" i mean the one I created and showed at the summit 15:13:13 i've started working a bit on that code again. 15:13:58 anyway, next topic i believe, unless you have anything else here sjmc7. I don't see briancline 15:14:14 nope, thats it 15:14:32 #topic searchlight client cli 15:14:55 yingjun has been working on it. 15:15:21 i owe you a review on the base patch yingjun 15:15:22 https://review.openstack.org/#/c/249076/ 15:15:42 do you need anything more to do more work? probably some more thoughts on additional commands for it? 15:15:47 yeah, that’s going well. i’l ltry to review those patches as well today 15:16:00 i also uploaded a patch for facet list: https://review.openstack.org/#/c/249076/ 15:16:35 excellent! 15:17:16 As FYI, the group the sjmc7 and I work for is having a face to face meeting most of this week, which has been taking up a fair amount of overhead time 15:17:54 it ends tomorrow, so my plan is to catch up on reviews tomorrow. 15:18:21 #topic Add searchlight to requirements/projects.txt 15:18:22 That would be nice! 15:18:57 yingjun, this is your topic I believe? 15:19:14 yes, seems like searchlight is not added in requirements/projects.txt 15:20:33 that's interesting. what all is this used for? 15:20:35 is it missed to adding there or on purpose? 15:20:54 it wasn't on purpose. 15:21:19 http://docs.openstack.org/infra/manual/creators.html#add-project-to-the-requirements-list 15:21:41 ah, we were wondering about that the other day 15:21:48 the requirements checker 15:22:13 ahh, yes 15:22:20 looks like you put up a patch for this, yingjun? 15:22:25 this would make it so we get the auto proposal bots, right? 15:22:28 https://review.openstack.org/#/c/255031/ 15:22:31 right 15:22:39 yes 15:22:44 yingjun: thank you 15:23:05 there are so many places update that we just missed this one 15:23:14 I think we do want it 15:23:36 we don't have to accept the auto-proposal bots, but without them, we'll surely fall behind 15:23:44 yep 15:24:00 * david-lyle is late 15:24:15 p/ 15:24:17 o/ 15:24:35 o/ 15:24:41 i think we'll need to add the usual suspects as reviewers to that change 15:24:46 to get any action on it 15:25:08 i’ve still not been able to get the e-s requirements cap patch through 15:25:19 what's the patch #/ 15:25:20 ? 15:25:27 oo, wait, i think it did merge 15:25:30 i thought Doug +2'd 15:25:44 #topic es client version 15:25:50 the requirements patch did merged 15:25:53 yeah, looks like davanum approved it early this morning 15:26:05 oh, then we need to update our requirements 15:26:10 or yesterday? that’s what being in meetings all week does :) 15:26:24 (since we didn't have the autoproposal on) 15:26:29 yeah, i can do that 15:26:41 yeah 15:26:49 great 15:26:49 because we're no in projects.txt? 15:26:51 though i think once it does get turned on it’ll fix everything 15:26:53 *not 15:27:00 david-lyle: yingjun discovered that yesterday 15:27:14 interesting 15:27:17 yeah… SOMEONE (me) forgot to add the repo to projects.txt 15:27:20 he put up a patch 15:27:21 https://review.openstack.org/#/c/255031/ 15:27:59 let's blame kragniz 15:28:18 ;) 15:28:21 :) once that gets approved we should get caught up on anything that’s changed 15:28:36 but i’ll update our local one for the es version 15:28:49 will we get caught up? or do we need to manually get it up to date? 15:28:51 so were our requirements out of sync for Liberty? 15:29:02 might need a backport too 15:29:07 david-lyle: hmm... good point 15:29:13 well, I guess it wouldn't be a backport 15:29:15 urgh, maybe. i’ll take a look at that too 15:29:46 but next thing that changes on stable/liberty/requirements might trigger a larger req proposal 15:30:07 might be better to do preemptively and test it out 15:30:26 ok. i’ll file a bug and take a look 15:31:02 thx sjmc7 and thx yingjun for catching that and thx david-lyle for thinking about stable/liberty 15:31:43 #topic bug review 15:32:18 I just added a couple reviews up there related to a bug we opened quite awhile back. 15:32:40 https://bugs.launchpad.net/searchlight/+bug/1493975 15:32:40 Launchpad bug 1493975 in OpenStack Search (Searchlight) "Need separate config sections for api and listener" [Medium,In progress] - Assigned to Itisha Dewan (ishadewan07) 15:33:07 looks like we'll finally get that with the work yingjun is doing. 15:33:17 reaasign the bug then? 15:33:23 yeah i think so 15:34:10 i have little ctx 15:34:10 so, if anybody can take a look at reviewing them today, would be nice 15:34:15 so these patches need your reviews: https://review.openstack.org/#/c/253973/, https://review.openstack.org/#/c/253981/, https://review.openstack.org/#/c/255650/ 15:34:18 :) 15:34:27 may be person working can add review to the bug 15:34:40 yingjun, can you copy paste that into comments on bug? 15:34:57 yingjun: ah, pls feel free to add to that bug and assign it to yourself 15:35:10 ok, i’ll do that 15:35:21 the context is basically that searchlight.conf had several options in the [default] group and it wasn't clear if they were used for listener or api 15:35:25 or both 15:35:50 so we wanted a [listener] and [api] group to clarify that 15:36:01 TravT_: np, i was looking for newer reviews and ctx for the latest work 15:36:13 thanks for the info though 15:36:29 np 15:37:22 #topic blueprint review 15:37:57 FYI that Steve and I think we have come up with a good solution for limiting the ability to search admin fields. 15:38:21 https://review.openstack.org/#/c/245357/ 15:38:47 I think it is good enough to approve at this point and can be updated later if needed 15:39:02 remember, our specs aren't intended to be 100% detailed design docs 15:39:17 so if others can look at it, would be appreciated 15:40:30 sjmc7 and i also spent time yesterday whiteboarding on zero downtime indexing (since he's here this week due to other "overhead" meetings) 15:40:48 david-lyle: we'll be doing some more today probably if you'd be up for driving across town 15:41:52 i'll update that spec though. 15:42:03 I will likely be down there later in the afternoon 15:42:15 ok, i'll ping you on irc later 15:42:26 TravT_: sure 15:43:07 we didn't know if we'd get any time to do actual work while he was here, and just lucked out and manage a little yesterday 15:43:29 next up, there is a spec on notification forwarding to zaqar 15:43:35 that has quite a bit of dialog 15:43:42 https://review.openstack.org/#/c/246220/ 15:43:55 i need to read latest 15:44:10 i think we'll also want flwang (zaqar PTL) to comment again 15:45:14 #topic open discussion 15:45:23 Anything else to talk about? 15:45:50 don’t think i had anything else 15:46:46 thanks kragniz, david-lyle, yingjun, rosmaita, nikhil, sjmc7! 15:47:13 reading through the admin search spec now 15:47:25 rosmaita: ok, cool should we wait around 15:47:33 no from me 15:47:39 if you have a minute 15:47:42 sure 15:47:50 looks like my questions are being answered at the bottom of the doc, though 15:48:25 the current proposed change was an alternative brought up in patch set 2 15:48:39 so, the original proposed change is now an alternative 15:49:12 * TravT_ will be quiet and let rosmaita think 15:49:23 ty! 15:49:49 i remember the prior discussion about the 2 indices (indexes?) 15:50:13 yeah - i was persuaded that was a bad idea from a maintenance perspective 15:50:30 i think the 2 doc solution is pretty clever 15:50:37 it’s quite similar this way 15:50:40 def better than trying to modify the queries, i think 15:50:58 except that instead of an index seperation it’s a filter applied to queries (or aliases) 15:51:42 yeah it is based on this: 15:51:43 https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-aliases.html#filtered 15:52:00 i’ve tested a prototype, and it works fine 15:52:11 it has the advantage of allowing more than one role, potentially 15:52:17 to api users of ES, it looks like they are talking to a regular index 15:52:17 sorry,more than two roles 15:53:06 but really they are talking to an alias in ES that automatically applies a filter 15:53:07 sjmc7: i was thinking that, too (about the multiple roles) 15:53:17 it's extensible! 15:53:47 yeah.. not that i necessarily forsee that happening, but it’s there. it’s also much easier from an operator perspective 15:57:53 ok, just a couple minutes left 15:58:59 rosmaita: i'll be in the room shortly 15:59:10 TravT_: i'm done 15:59:10 i have to transfer to the office 15:59:16 ok. 15:59:22 thanks for looking through it 15:59:24 i +2 but didn't +A 15:59:33 thanks rosmaita 15:59:49 np, nice spec sjmc7 15:59:50 ok, will give others a bit more to look through 15:59:59 thanks everybody 16:00:08 yeah, just in case, but i think it's a good proposal 16:00:23 have a good rest of your day / night 16:00:26 #endmeeting