15:01:41 #startmeeting openstack search 15:01:41 Meeting started Thu Sep 3 15:01:41 2015 UTC and is due to finish in 60 minutes. The chair is TravT_. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:45 The meeting name has been set to 'openstack_search' 15:02:12 o/ 15:02:21 o/ 15:02:26 o/ 15:02:31 o/ 15:02:40 morning 15:02:52 sigmavirus24: are you around today? 15:03:06 Yeah 15:03:08 Sitting in a meeting 15:03:18 livin the dream! 15:03:32 as usual, eh 15:04:09 #link https://etherpad.openstack.org/p/search-team-meeting-agenda 15:04:09 I think we have quite a few items today 15:04:11 #topic General Status Update 15:04:46 so, big news is that nova patch is in 15:05:06 thanks for the continued effort on that sjmc7 15:05:17 sure 15:05:31 #topic release stuff 15:05:49 So, we all know the date, I think. 15:06:05 https://wiki.openstack.org/wiki/Liberty_Release_Schedule 15:06:05 Liberty 3 done feature freeze today 15:06:05 RCs Start: September 21st 15:06:07 Final RC October 9th 15:06:50 Last wee we talked about some release planning and release tags. 15:07:02 i want to review that again. i have a proposal on that 15:07:15 but first, i think we should review the current status on blueprints for liberty 15:07:26 #link https://blueprints.launchpad.net/searchlight/liberty 15:07:53 All but one of the essential BPs is implemented. 15:08:03 * david-lyle slinks in late 15:08:12 hi david-lyle 15:08:18 o/ 15:08:28 Our high's also look to be in good shape 15:08:36 last night i bumped the designate to rc1 15:08:53 we'll get it in! 15:08:57 yep 15:09:25 only thing higher priority is functional tests 15:09:46 lakshmiS: looks like you have really good progress based on your patch sets? 15:09:52 for functional tests? 15:10:11 yeah. 6 more tests needs to be added. will be there by tomorrow morning 15:10:24 looks like you found a bug in metadefs in the process? 15:10:41 yes thats more critical bug 15:11:02 ok, we'll look at bugs in just a moment... 15:11:19 but on metadefs, we have the BP as Beta Available because we thought it needed more code review 15:11:38 i guess you are getting to do some of that now with the functional testing? 15:12:12 which bp you are referring to? 15:12:21 https://blueprints.launchpad.net/searchlight/+spec/glance-metadef-plugin 15:12:31 oh ok 15:12:45 it was ported from glance, but didn't get much review 15:12:51 so we marked it as beta 15:12:54 yeah. i'll take blame for that 15:13:05 i can help fix issues 15:13:09 yeah the tests should cover most of it 15:13:19 ok. well, i still will look as well. 15:13:43 so then if we look at the medium and lows, on that list above 15:14:05 query-perf-tests, i think nikhil said he was still doing work? 15:14:09 nikhil_k? 15:15:12 or not... 15:15:14 :) 15:15:24 on the horizon integration for images. 15:15:29 he's in rel-mgr-office now 15:16:05 i think we'll be looking at horizon integration for presentation at the Tokyo summit 15:16:14 last time we have very POC'ish 15:16:29 i'm hoping this time it will be actual patches up for review. 15:17:19 there are a few other medium / low 15:17:32 but we don't have to go over now 15:17:42 we should talk about the release tags. 15:17:59 My proposal is that we target these two: 15:18:09 #link https://github.com/openstack/governance/blob/master/reference/tags/release_cycle-with-intermediary.rst 15:18:40 ^ for now, meaning we do a liberty release. 15:18:52 but we don't necessarily have to do milestone releases. 15:19:07 TravT: sorry trying to be in 3 places, isn't working 15:19:12 l3 would mean doing today, right? 15:19:18 l3 is milestone 15:19:28 that would mean we were following this one: 15:19:33 https://github.com/openstack/governance/blob/master/reference/tags/release_cycle-with-milestones.rst 15:19:35 sjmc7: yes, generally 15:19:50 so let's not do that :) 15:20:04 well it's a tag 15:20:17 its only feature freeze anyway 15:20:18 then you have most of Sept to pull together an RC-1 15:20:29 L-3 is not intended to ship 15:20:41 it should be working, but is not final 15:21:06 There is the "independent" one. 15:21:13 meaning release whenever. 15:21:20 https://github.com/openstack/governance/blob/master/reference/tags/release_independent.rst 15:22:02 At least for now, i think there is value in targetting a release to happen that lines up with the larger release cycle 15:22:16 yes 15:22:44 * david-lyle taking his turn in relmgr-office back soon 15:23:28 So, that means our goal for the next few weeks is fleshing out the couple of BPs and big bugs 15:23:50 that would be nice 15:24:01 we can decide our actual version in a week or two based on how things look. 15:25:04 david-lyle had the idea of doing a release version of 0.8.0, to signify this is an initial release 15:25:37 the .8 correlating to the bigger OS release number of 8.0 15:25:43 something to chew on 15:26:20 On to some specific reviews 15:26:30 #topic reviews 15:26:51 i'd like to call attention to this one: 15:26:52 Index CLI improvements: https://review.openstack.org/#/c/210759/ 15:27:05 this changes our command line interface 15:27:09 for the better 15:27:28 but we might get stuck with the options it proposes for some time 15:27:34 so i think input would be good. 15:28:05 input away! 15:28:05 sigmavirus24: nikhil_k: rosmaita: david-lyle: lakshmiS: ^ https://review.openstack.org/#/c/210759/ 15:28:49 * rosmaita looking 15:30:05 what is the value of allow stale? 15:30:19 s/value/reasoning for/ 15:30:21 A little problem statement: right now if you do an index sync command, it will go through ALL the plugins and sync ALL the data. In addition, it currently does not clear out non-current data. 15:31:04 so, if notifications get messed up, and say some instances were deleted, calling index sync now would not clear them out. 15:31:32 sjmc7 put in an option to clear all data, and my feedback was that clearing all data should be the default. 15:31:59 possibly leaving stale data being the option... 15:32:01 I agree with the second part :) 15:32:14 what's the benefit of stale data? 15:32:26 that's a good question... 15:32:27 if I just went and made the API call to index 15:32:30 it is! 15:33:00 unless you're trying to build a history up, but I think it would just cloud the results with non-existent items 15:33:01 if we're ok breaking back compatability, i'm more than happy to remove it 15:33:16 clear also recreates the mappings 15:33:29 backward compatibility with kilo glance? 15:33:30 so there are some other side effects... 15:33:42 or Liberty Searchlight 15:33:56 :) well, in the sense it was already that way. if there was no reason for it, i'll take it out 15:34:12 speak now, or forever hold your piece! 15:34:47 if just Liberty the API isn't really made official yet by a release 15:35:05 this isn't even the API, it's the management command 15:35:08 TravT: such as? 15:35:14 sjmc7, any other negative rammifications to just always clearing? 15:35:23 sjmc7: even better 15:35:42 nope. do you want me to drop the confirm: y/n prompt? 15:35:44 david-lyle: i was just meaning that clearing clears data and the data mappings for the data. 15:35:48 go all wild west? 15:36:16 so the only downside is an API call in the middle of a sync may get partial data? 15:36:19 adding options later (like to not clear mappings) is possible if we find a use case 15:36:27 david-lyle - yep 15:36:50 I think that's better than non-existent items 15:36:50 maybe this is stupid, but maybe don't have a default? 15:36:51 if someone's doing this often, there are ways to do it to avoid that (index into a different index and switch them over) 15:36:57 force user to specify which one? 15:37:16 then there's no change of behavior for scripts calling the manage command 15:37:45 sjmc7: i still think we should talk about the alias idea, to better faccilitate that 15:37:50 but another topic 15:37:53 for another time 15:38:08 the question is whether there's any reason to ever leave old data 15:38:23 in effect, whether that is essentially a bug in the implementation 15:38:24 i can't think of any. 15:38:51 and i don't see how anybody would have reason to know they should leave something old in 15:39:18 that would be quite the arduous task to figure out, i'd think 15:39:27 i can't think of any reason to do it, either 15:39:34 ok. decision made! 15:39:43 and as sjmc7 says, you could keep a copy if yo ureally want to 15:39:46 i'll leave the prompt in, since it is a destructive operation 15:39:48 now, re: the prompt 15:40:10 \o/ 15:40:25 :) 15:40:26 i like the prompt, especially because if you don't specify a specific type, you'll re-index everything which could be quite the expensive operation 15:40:34 and i should note, i took horizon as my inspiration for that 15:41:05 i wonder whether the override should be --force instead of --no-input 15:41:06 however, I was thinking the prompt could include a list of what will be re-indexed. 15:41:08 sounds scarier 15:41:19 :D 15:41:39 --force is more unix-y 15:41:51 TravT - yeah, that's easy to do 15:42:25 so, it would be searchlight-manage index sync --type OS::Nova::Server 15:42:41 Are you sure, you don't look like you know what you are doing (y/n)? 15:42:55 :) 15:43:01 or searchlight-manage index sync --type OS::Nova::Server --force 15:43:06 that sounds good to me. 15:43:21 yep. and i can add a list of resources that'll be re-indexed before the prompt 15:43:27 yeah 15:43:36 that would be really useful 15:43:37 "You're about to delete all your data, you fool" 15:43:51 i'd be okay with a small bit of humor in the prompt... 15:43:58 kidding :) 15:44:23 i'll get another patch back up after this. any other issues with it briefly? or submit reviews 15:44:35 ok, cool, thanks for letting me publicly harass you this time sjmc7 15:44:44 :) 15:44:47 i just saw this as an important change 15:44:50 worthy of discussion 15:45:32 ok, so let's quickly look at other bugs 15:45:45 #link https://bugs.launchpad.net/searchlight 15:46:18 The sort parameter is critical and could use another set of eyes on it 15:46:29 https://review.openstack.org/#/c/206268/ 15:46:31 yeah. it's also reasonably simple 15:46:40 yep 15:46:59 good catch, that's a key feature request 15:47:48 There is another big one we found 15:48:02 https://bugs.launchpad.net/searchlight/+bug/1491085 15:48:03 Launchpad bug 1491085 in OpenStack Search (Searchlight) "Searchlight not updating on member change" [High,New] 15:48:26 so, we don't get notified when glance members change 15:48:53 lakshmiS: did you find any old code ready to submit on that to glance? 15:49:22 yes, i will put a initial patch. will need some input from glance team though(may be nikhil?) 15:49:26 i agree with sjmc7 that glance should consider this 15:49:33 i did take a look at glance yesterday. it doesn't seem like a really simple fix; adding another layer to CRUD pipeline isn't as simple as i'd hoped 15:50:43 lakshmiS: when you get something up, can you notify rosmaita: and nikhil_k: 15:50:56 so we can get some attention to it 15:50:56 hope glance treats this as a bug for liberty 15:50:59 sure 15:51:16 it was a bug for kilo :) 15:51:23 kind of funny, we were discussing feature requests disguised as bugs in the glance meeting earlier 15:52:11 yesterday we debated on bug vs bp a bit. 15:52:15 decided to start with bug 15:52:26 talking of glance, https://bugs.launchpad.net/searchlight/+bug/1490697 is related to the glanceclient 1.0 release 15:52:27 Launchpad bug 1490697 in OpenStack Search (Searchlight) "python glance-client for image-members has upgraded" [High,In progress] - Assigned to Lakshmi N Sampath (lakshmi-sampath) 15:52:27 but if we need ffe on it, then we need to know asap 15:52:37 it's a bug that searchlight doesn't index neutron, go 15:52:43 :D 15:54:22 Do we need another dedicated review hour? 15:54:26 like we did last week? 15:55:09 guess not? 15:55:27 i'm happy to do it 15:55:42 since i have a few changes still need reviewing 15:55:44 guess everyone busy with releases... 15:55:50 Yeah, today is rough. 15:56:09 let's plan on having one next Tuesday again. 15:56:16 just an hour to be online 15:56:20 and get through open questions 15:56:26 ok 15:56:27 sounds good 15:56:49 ok, i'll send out a courtesy meeting request 15:57:05 That's it for today, unless there are other items 15:57:16 thanks for baring with me. 15:57:20 :) 15:57:59 3 minutes early. signing out! 15:58:01 #endmeeting 15:58:31 #endmeeting