15:00:39 #startmeeting openstack search 15:00:41 Meeting started Thu Dec 3 15:00:39 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:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:45 The meeting name has been set to 'openstack_search' 15:01:42 o/ 15:01:42 o/ 15:01:47 ello 15:01:51 hi 15:02:24 maybe a smaller crowd here today. 15:02:57 Here's the agenda: https://etherpad.openstack.org/p/search-team-meeting-agenda 15:03:02 what has happened to the world!? 15:03:12 o/ 15:03:35 nikhil: don't ask! bad shit is going on everywhere 15:03:44 yeah, seriously 15:03:47 how are things in chicago and fort collins? 15:03:54 cold 15:04:00 can't complain too much... just a bit cold 15:04:08 nikhil, are you still in blacksburg? 15:04:13 rosmaita: oh man! every-time I read news my faint in humanity sinks :( 15:04:20 faith* 15:04:29 TravT: yeah 15:04:39 yingjun: where do you live? 15:04:40 sjmc7: hope the snow situation is better 15:04:46 hope lakshmi is doing fine (with flood situation) 15:05:02 China, Changsha 15:05:29 hi yingjun, we've never met (even virtually) 15:05:43 cool, we're really happy to have you join in the fun here! 15:05:45 HI, nikhil 15:05:54 fun indeed 15:06:11 :), nice to join 15:06:22 TravT: glad to hear, things are better there. 15:06:33 * nikhil shuts up 15:07:00 allright, let's get on with some topics. we seem to be missing a couple faces, but that happens. 15:07:12 #topic m1 is today 15:07:27 So, there's this: https://openstack.nimeyo.com/66888/openstack-dev-release-preparing-your-mitaka-milestone-tag 15:08:05 hola 15:08:09 i'm lurking :P 15:08:11 howdy ekarlso! 15:08:47 i'll look at taking care of submitting a few things up 15:08:58 but did have a couple questions 15:09:10 are we aware of any release notes that we missed before landing reno? 15:09:30 no, don’t think so 15:10:13 possibly we should have had one for this patch 15:10:17 https://review.openstack.org/#/c/245981/ 15:10:37 but i'm not thinking we need to stress over it. 15:10:49 +1 for no stress 15:10:51 :) 15:11:01 :) 15:11:35 so then the next question is version... 15:11:55 we had previously discussed whether to go to 1.0 with mitaka 15:11:59 i think that is the desired goal 15:12:05 but right now setup.cfg os 0.2 15:12:51 i suppose that depends what we want to call 1.0 15:12:55 in reading that email, it seems like we should propose 0.2b1 because that is in setup.cfg 15:13:10 but that might mess things up if we jump to 1.0 at the end of mitaka 15:13:45 TravT: i am glad you are PTL, i am having a hard time understanding the process 15:14:08 process is very dynamic 15:14:17 lol, yeah, there have been quite a few changes this last bit in how the release team wants to do things 15:14:28 not sure if we need to invent a new word for openstack process 15:14:47 i think i used a good word earlier 15:14:53 :D 15:14:58 I may decide to use urban dictionary finally again after 3 years 15:15:11 rosmaita: you go for it then 15:15:26 \o? 15:15:29 TravT: I think it should be fine with the .2b1 15:15:33 that's my head scratching emoticon 15:15:46 nice! 15:15:56 nikhil: yeah, i think so too. we'll sort out 1.0 decision at the end of this release. 15:16:07 cool 15:16:13 works for me 15:16:17 (was just about to enter) TravT: why do you anticipate it to be an issue? 15:16:29 but cool now 15:16:29 for me, 1.0 is a signal that we'll start formally handling deprecations and adhere to stability of plugin interfaces 15:16:53 gotcha 15:16:59 nikhil: because this process is new that doug put out (including reno) and nobody has experience with it. 15:17:25 makes sense 15:17:47 ok, well, i'll work on the tag etc today and ping in room if needed later. 15:18:19 so along these lines 15:18:32 #topic searchlight client launchpad project 15:18:49 yingjun: has been working on the client 15:18:55 \o/ 15:18:55 i vote strongly not to have another launchpad project 15:19:01 and thanks yingjun for all the hard work 15:19:04 +1 15:19:08 i sent out an email http://lists.openstack.org/pipermail/openstack-dev/2015-November/080525.html 15:19:09 yingjun: ++ 15:19:25 yingjun: +++ 15:19:30 sjmc7: haha, nice. I think that's fine to have everything consolidated 15:19:44 so, +1 from me too 15:20:25 i can’t see us ever having a huge number of client-specific issues open 15:20:34 btw 15:20:43 TravT: do we plan to release client in M? 15:20:47 i'm happy to not use it for now. my only question was if this would cause us issues with release managment since the client doesn't have to follow the same release schedule. 15:21:14 nikhil: that would be the goal 15:21:18 ah. that, i don’t know 15:21:37 i added release onto that email, but only got crickets from them. 15:21:39 TravT: I think you can rely on reno for rel mgmt but for milestone tracking no 15:21:47 i think they are dealing with changing the processes for every project right ow 15:22:09 TravT: you prolly want to be aware about https://review.openstack.org/#/c/226157 15:22:17 I brought that up in glance mtg 15:22:32 and it adds a new clause for client back compat 15:22:54 can you summarize for us? 15:23:01 so, the client release timing would be essential 15:23:05 sure 15:23:19 it's mostly saying that all clients and libraries need to support back compat 15:23:29 well it mentions that you can deprecate it 15:23:34 but need to give that some time 15:23:42 the example suggests 4 cycles 15:23:54 but I don't anticipate if that would ever be true 15:24:04 so, when we release something 15:24:16 we want to ensure that we absolutely want that API to exist for a long time 15:24:36 if we need to have breaking changes the `process` will be quite painful 15:24:42 so, for SL client 15:24:48 if we need to have it in M 15:25:16 we prolly should test a beta and commit to client API (CLI stuff) in M official release 15:25:21 * nikhil done 15:25:49 sorry I missed an imp point -- that sort of ties in with the LP project 15:26:15 to determine the commitment that the project is giving to the API in a official project page (wherever that might be) 15:26:28 * nikhil done for reals 15:27:04 thx nikhil 15:27:14 did doug add reno to the python glanceclient? 15:27:39 no 15:27:47 and I don't think they expect 15:27:56 but some folks from IBM are requesting 15:28:20 and that is a discussion item for me with mr. flavio 15:28:55 that I haven't gotten to yet (with backlog list growing) 15:29:11 ok, so nikhil, does everything you just said and your experience with glance client keep your vote at a +1 to not have a separate launchpad project for searchlight client? 15:29:29 TravT: nah, that bring me to 0 15:29:34 +1 for consolidation 15:29:35 i’m tremendously confused :) 15:29:47 -1 for explicit communication 15:30:15 sjmc7: sorry, I realized a bit before that, I did that 15:30:26 we might need the project just for somewhere to upload the releases of it 15:30:31 TravT: well, what I meant to say is 15:30:54 I think it should be separate, to be contrarian 15:31:03 o/ david-lyle 15:31:06 I gave some tradeoffs to you all and we can choose to prefer one way over other based on what we want to deal with later 15:31:50 david-lyle: are you being contrarian for fun or is that your real opinion? 15:31:55 the issues and releases are unique 15:32:18 once people start piling on bugs and bps, it will get noisy 15:32:24 and harder to track 15:32:54 the separate releases is the thing that makes me lean towards having its own project 15:32:55 for consumers and devs 15:33:32 i think we need to record a vote here... but before doing, any more points to consider? 15:33:54 yeah, i’m leaning that way as well now 15:34:02 I was told in a x-prj metg 15:34:10 that we are going to have some other tool for bugs 15:34:12 not LP 15:34:23 not sure how much has that been moved fwd 15:34:33 nikhil: they've said that for 5 releases now 15:34:39 I'll believe it... 15:34:45 :) 15:34:53 i'm wondering how that'll help things at this point 15:35:05 change for the sake of change 15:35:16 the opinion they had was projects can have LP for their own tracking purposes 15:35:38 but some for bugs, spec for BPs, and reno for rel 15:35:42 that was my impression 15:35:56 but as a prj we can choose to have LP 15:36:08 and like I said, there are tradeoffs to either 15:36:14 with my +0 15:36:31 until the replacement is more than handwaving, launchpad is what we have 15:36:55 i fail to see how specs (gerrit) on its own actually is good enough for BPs. (no assignees, priority, etc) 15:37:28 * TravT worries that the wheels are coming off the bus for process management tools 15:37:48 we're on 3/4 now 15:38:07 nothing mass confusion and chaos won't fix 15:38:09 :( 15:38:16 okay, to stay on track with current topic, i'm going to put out a irc vote. 15:38:38 :D 15:38:51 #startvote (Should we use a separate LP project for python-searchlightclient)? yes, no 15:38:52 Begin voting on: (Should we use a separate LP project for python-searchlightclient)? Valid vote options are yes, no. 15:38:53 Vote using '#vote OPTION'. Only your last vote counts. 15:39:10 #vote yes 15:39:30 #vote yes 15:39:33 I am fine w/ either 15:39:36 #vote yes 15:39:40 #vote yes 15:39:47 yingjun? 15:40:12 fine for either too 15:40:30 ekarlso: you still lurking and care at all? 15:41:06 #endvote 15:41:06 Voted on "(Should we use a separate LP project for python-searchlightclient)?" Results are 15:41:07 yes (4): TravT, david-lyle, rosmaita, sjmc7 15:41:31 okay, so we'll keep it... 15:42:16 I’ll update the doc.. 15:42:23 thank you! 15:42:36 #topic client command brainstorming 15:42:54 yingjun: has a patch up with the first command on it 15:42:56 https://review.openstack.org/#/c/249076/ 15:43:36 i added a comment about starting to sketch out the full suite of commands (so we have a basic roadmap of where we are going even if the first patch is only the first command) 15:43:55 but i think we should spend some time brainstorming that out 15:44:42 so, we don't have to do it here 15:44:45 but here is an etherpad 15:44:46 https://etherpad.openstack.org/p/searchlight-cli-brainstorming 15:45:46 so, please take a look and add thoughts 15:45:47 tarya :p 15:45:49 TravT: .. 15:46:12 TravT: just busy busy -,,- 15:46:18 no worries 15:46:29 #topic specs 15:46:31 anyone started the cli yet that I can take a look at ? 15:46:53 ekarlso: yingjun has started it 15:47:05 https://review.openstack.org/#/c/247565/ ekarlso 15:47:17 and https://review.openstack.org/#/c/249076/ 15:47:33 ok, i'll go look alter :) 15:47:47 thank you! 15:47:52 re: specs 15:48:06 sjmc7 and I have been having some fun with two that are "essential" for mitaka 15:48:32 they are admittedly kind of heavy to read 15:48:56 but we do need to work through them and come to some conclusion so we can work them out 15:49:06 and get implemented this release 15:49:42 if you can take a look please do. sjmc7 is actually going to be in fort collins next week, so we'll talk through them more in person next week 15:50:06 Admin search fields unless already addresed above 15:50:06 https://review.openstack.org/#/c/245357/ 15:50:06 Zero downtime re-indexing 15:50:08 https://review.openstack.org/#/c/245222/ 15:50:45 sjmc7: anything specific to bring up today? 15:51:11 about those? not really, except if anyone’s interested to look them over 15:51:34 though i did also want to briefly mention the elasticsearch client version palava 15:51:58 #topic elasticsearch client versioning 15:52:09 that’s the one! 15:52:33 mention away sjmc7 15:52:41 apologies yingjun, i should’ve mentioned i’d already proposed a patch to openstack/requirements at https://review.openstack.org/#/c/252075/ 15:52:59 capping the client version at 1.9.0 15:53:21 sjmc7, no worries 15:53:25 gordon chung seems ok with it 15:53:31 says they’ve only tested with 1.7 15:53:48 and i don’t think anyone else uses it 15:54:07 i’ll pick some random infra people today to add as reviewers 15:54:18 yeah, we need to get this through 15:54:44 we’ll need to do a small amount of work to be 2.0-compatbile 15:54:59 i’ll file a ticket 15:55:10 because searchlight doesn't work in out of the box devstack at the moment because of the 2.0 client release. 15:55:28 is the query syntax different between versions? 15:55:44 david-lyle - there’s one thing that isn’t supported in 2.0, which is deleting by document type 15:55:56 that’s the only thing i’ve found we do that doesn’t work as expected 15:56:18 ok, that's not too bad 15:56:36 and actually, a fresh devstack install should be ok unless i’ve missed something 15:56:45 unless the data already exists 15:56:54 but yes, needs fixing 15:57:32 https://bugs.launchpad.net/searchlight/+bug/1515412 15:57:32 Launchpad bug 1515412 in OpenStack Search (Searchlight) "python elasticsearch must match server version" [High,Triaged] - Assigned to Liyingjun (liyingjun) 15:57:58 ok, well, let's get the version capped for now, unless yingjun / sjmc7 come up with a searchlight fix first. 15:58:13 i think the version cap’s sensible anyway 15:58:21 while devstack and most people will be using 1.x 15:58:27 i think for now... 15:58:39 but it can't stay that way. 15:58:58 ok, thanks yingjun and sjmc7 15:59:04 out of time. 15:59:13 #topic parting words 15:59:17 any last words? 15:59:42 thanks everybody! 16:00:08 #endmeeting