15:01:02 #startmeeting openstack search 15:01:02 Meeting started Thu Aug 27 15:01:02 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:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:05 The meeting name has been set to 'openstack_search' 15:01:39 we'll wait a minute or two. 15:01:44 o/ 15:01:55 o/ 15:02:17 o/ 15:02:25 nikhil_k is sigmavirus24 around today? 15:02:34 didn't see his name in latter part of glance meeting 15:02:35 yes sorry 15:02:42 oh good 15:02:46 $work is keeping me distracted 15:02:56 $ugh 15:03:08 ok agenda here: 15:03:16 #link https://etherpad.openstack.org/p/search-team-meeting-agenda 15:03:34 #Mitaka Summit Sessions 15:03:40 #topic Mitaka Summit Sessions 15:04:02 so, first of all, we did get a main conference session accepted 15:04:03 https://mitakadesignsummit.sched.org/event/51d3ca10844052e650c130eebe7264f9#.Vd8ji9NVhBd 15:04:37 If others are interested in being a part of that, let's talk later. 15:04:49 o/ 15:04:56 hi rosmaita 15:05:29 so, thierry sent out a meeting saying we have to put in a requests for session by August 31st 15:05:58 Requests for fishbowls vs workrooms vs contributors meetups. 15:06:18 there are less sessions overall available for vancouver 15:06:18 we should prob ask for 1 of each? 15:06:23 and less fishbowls. 15:06:55 yesterday in the horizon meeting, i put up a topic to have a joint horizon / searchlight session 15:07:09 contributor meetup we can organize elsewhere if we have to. fishbowl would be good in case other people are interested in getting involved 15:07:17 david-lyle supported it. thanks david-lyle 15:07:25 other horizoner's seemed good with it. 15:07:30 sjmc7: +1 15:08:11 the fishbowls are advertised. 15:08:14 right 15:08:26 so, it might bring in cores from other projects 15:08:43 we'd want them to help review plugins, even if we develop them. 15:09:15 TravT: +1 15:09:48 it also might be 3 of us staring at each other in a big room. 15:09:56 :P 15:10:01 we're not so bad on the eyes 15:10:04 lol 15:10:09 yeah.... i suspect there'll be less people there than vancouver 15:10:12 Searchlight: the best-looking project 15:10:18 sweet! 15:10:47 we need to invite one core from each project to write a plugin for us :) 15:10:50 if we have a fishbowl, it would need to have a good topic... not just a presentation. that's what our main session presentation will be about. 15:10:57 oii guys 15:11:03 o/ ekarlso 15:11:15 hmm, I can maybe do a plugin for Cue also 15:11:23 seeing that i've worked on that 15:11:25 i like lakshmiS idea: deep dive into Searchlight plugins? 15:11:41 that would make sense. 15:11:54 at the least be a SME for that project and talk to us 15:12:14 and we could send an invite to each project team seeing if 1 person could attend. 15:12:29 yeah, that's a good idea 15:12:42 ok, so here's what I think is current summary: 15:12:46 Request: 15:13:02 1 fishbowl: Topic to deep dive into plugins and invite SME from each project 15:13:27 1 Working session for us: (possible ideal topic is multi-region searching) 15:13:39 1 Shared session with horizon 15:14:33 works for me 15:14:40 should we request the contributors meetup slot as well? 15:14:58 depends how many of us there'll be there 15:15:03 yeah. 15:15:08 if it's 3 of us staring at each other, i at least want to be in a pub 15:15:09 and how if overlaps with the other projects 15:15:59 i think we'll need more time to talk than one working session, but we can try to meet informally as well. 15:16:13 i want to be respectful of the many projects needing slots 15:17:15 +1 to pub, +1 to multiregion searching session 15:17:52 maybe i'll add in a request for one more working session but not a request for contributors meetup. we'll do that after hours. 15:18:05 1 fishbowl, 2 working sessions, 1 joint session with horizon. 15:18:10 I would expect most of us have conflicts for contributors meetup, so that makes sense 15:18:21 That may be more than we can get. 15:18:49 okay, going once 15:18:58 twice 15:19:04 sold 15:19:23 #action TravT send session summit request to ttx 15:19:44 #topic Liberty 3 Deadlines 15:20:05 As usual, end of cycle is upon us, which means at least two things. 15:20:16 People are getting frantic 15:20:22 Zuul jobs are taking a long time 15:20:56 Feature Freeze: September 3rd 15:20:57 RCs Start: September 21st 15:20:57 Final RC September 9th 15:21:13 I sent an email to thierry seeking advice on how we should handle things 15:21:46 Here are some snippets: 15:21:52 Given how new Searchlight is at this point, I'd say you don't really 15:21:53 need to enforce a strict feature freeze. If you do, it's a tool to 15:21:53 reduce the risk of introducing regressions by selecting which commits are acceptable as you get closer to the end of the dev cycle. 15:22:16 that seems sensible 15:22:50 I also asked about numbering scheme. As you all probably know, OpenStack is moving to new scheme 15:22:52 x.x.x 15:23:11 many will be at 8.0.0 15:23:13 in liberty 15:23:22 but thierry said: 15:23:27 I'd say the first release should be 1.0.0. If it's barely functional, 15:23:27 you could even number it 0.1.0. Your choice really. 15:23:58 I'm not sure of all the ramifications of choosing one vs the other. 15:24:05 0.1.0 seems like beta 15:24:13 0.1.0 15:24:21 seems better 15:24:29 would horizon use it if its 0.1.0 15:24:47 but then the rel versioning is being matched with cycle afaik 15:24:56 the version # doesn't change the level of functionality 15:25:07 like first cycle of incubation was 1.0.0 but not sure if true for all prj 15:25:30 lakshmiS: I would prefer it to come in as a plugin until more mature, honestly 15:25:32 rel-mgrs can better suggest the versioning coherent with os projs 15:25:56 but horizon is trying to reduce scope 15:26:40 david-lyle plugin external to horizon repo or not? i think we always talked about it being a plugin, but you initially suggested still being in horizon repo. 15:26:56 TravT: I'd be ok with it in /contrib 15:27:00 a plugin panel is easy. 15:27:24 but plugin search provider for APIs for various tables and global top nav, is a bit diff 15:28:07 TravT: I agree, there are some extensibility hooks needed 15:28:16 we can take this offline 15:28:27 okay. 15:28:34 but my argument is to horizon the version # is not important 15:28:58 better to set valid expectations, IMO 15:29:08 the point of this topic is actually for us to set a release cadence 15:29:45 so let's pop two levels :) 15:29:50 There are various tags for this in OpenStack governance 15:29:51 https://github.com/openstack/governance/blob/master/reference/tags/release_independent.rst 15:30:03 https://github.com/openstack/governance/blob/master/reference/tags/release_cycle-with-milestones.rst 15:30:20 https://github.com/openstack/governance/blob/master/reference/tags/release_cycle-with-intermediary.rst 15:30:41 https://github.com/openstack/governance/blob/master/reference/tags/release_managed.rst 15:31:12 A lot to read through there 15:31:12 https://github.com/openstack/governance/blob/master/reference/tags/release_has-stable-branches.rst 15:32:01 i will admit i have only read the first one, but release:independent sounds good to me, at least to start with 15:32:19 for where the project is, I think independent makes sense 15:32:42 then move to align with release cycle with milestones as it matures 15:32:43 are there any bad implications of that? we can always change later, right? 15:32:59 rosmaita: the only one I can think of is packaging 15:33:16 most distros would likely not include searchlight with 8.0.0 15:33:35 gotcha 15:33:41 but that may be ok for 0.1.0 ?? 15:34:15 a certain company i'm affiliated with is wanting to include it in a release sooner than later 15:34:49 that's a knife that cuts both ways 15:34:54 what would our plan be, then ... 0.1.0, 0.2.0, 0.3.0 and then immediately 9.0.0 ? to make the packaging work, i mean 15:36:06 that's a better transition than 1.0.0 2.0.0 9.0.0 15:36:19 I think we should target releases for the end of cycles. but, i like the idea of releasing intermediate releases at our own cadence. 15:36:57 Ironic and Swift are the only two mainstream projects that have independent release cycle 15:37:04 this initial release perhaps should be sub-1.0 though 15:37:04 but they are standalone as well 15:37:27 agree 15:37:36 i would not want to have to be held to a perfect API until we've actually integrated several searches from horizon 15:37:46 but a lot of early project start with independent 15:38:10 it gives us more flexibility 15:38:23 just suggestions 15:39:19 but we need a release to even let packagers start looking at the project, i believe 15:39:57 let's revisit this in next weeks meeting, but please look through those release tags 15:40:31 right now, the summary of this discussion seems to be people leaning toward 0.1.0 for first release, timed with liberty. 15:41:00 so what we're looking for is a tag that indicates not-yet-ready-for-prime-time but nonetheless worthy of being included in a distro 15:41:10 I think that;s the right message 15:41:45 but I think there;s value to double check if we are communicating when our project got incubated with a number of particular style 15:42:01 although 15:42:18 if I read ttx's language again 15:42:26 I'd say the first release should be 1.0.0. If it's barely functional, 15:42:26 you could even number it 0.1.0. Your choice really. 15:42:34 yeah 15:42:43 i don't like the implication that 0.1.0 is barely functional 15:42:52 but, that said it has not been tested at scale. 15:43:04 what would 0.9.9 mean? 15:43:08 ha 15:43:23 based on glanceClient discussions, it would mean 5 years in and still not releasable to 1.0? 15:43:25 :P 15:43:26 means, we had some alpha rel that never released 15:44:10 TravT: I doubt it. py-client consumers run legacy code 15:44:26 that's why slowness in upgrade to rel numbers 15:44:35 nikhil_k: just a joke :) 15:44:41 we should ensure our plugin adopters stick to upstream 15:44:50 TravT: heh 15:45:00 after watching some of last meeting 15:45:30 (continuing TravT )... feels like there are sad stories to tell 15:45:51 #action All to read release tags. We'll revisit this next week 15:46:03 #topic review process 15:46:14 Thank you everybody for the time on Tuesday 15:46:23 I thought that went really well and we made good progress 15:46:57 yeah, it was good to have everyone together 15:47:03 would anybody be available for another hour next Tuesday or Wednesday for similar activities. 15:47:08 ++ 15:47:12 same bat cave same bat time 15:47:23 ? 15:47:25 this tuesday starts liberty-3 rel (fyi) 15:47:52 fyi -- madness begins, bugs fixes, tagging, gate etc 15:48:13 so, are you suggesting a different day? 15:48:25 earlier or later might help more 15:48:33 gate would be more reliable and faster 15:49:30 lakshmiS, you have one of the tougher schedules being in India. 15:49:40 do you have any suggestions? 15:50:06 around this time any day is fine with me 15:50:23 that was just some information, being independent of the gate also works :) 15:51:47 #vote (what day next week works best for another hour review session) ? mon, tue, wed, thur, fri 15:51:56 guess that didn't work. 15:52:03 startvote 15:52:11 while y'all are discussing times, what is the general feeling about stable branches? or do we think people should always use the most recent? i am inclined to the latter, since we're heavily tied to an external project 15:52:19 sorry, didn't mean to interrupt the vote 15:52:50 rosmaita: since this will be our first rel 15:52:51 #startvote (what day next week works best for another hour review session) ? mon, tue, wed, thur, fri 15:52:52 Begin voting on: (what day next week works best for another hour review session) ? Valid vote options are mon, tue, wed, thur, fri. 15:52:53 Vote using '#vote OPTION'. Only your last vote counts. 15:52:59 we won't need a stable branch at this point 15:53:36 nikhil_k: right, but i mean for "the future" 15:53:40 nikhil_k +1 i would vote against stable vote until M 15:53:42 #vote fri 15:53:45 #vote any 15:53:46 david-lyle: any is not a valid option. Valid options are mon, tue, wed, thur, fri. 15:53:52 #vote thu 15:53:53 lakshmiS: thu is not a valid option. Valid options are mon, tue, wed, thur, fri. 15:54:00 #vote thur 15:54:01 no but my point was made openstack 15:54:06 lol 15:54:22 what time are we thinking? 15:54:48 :) any day is ok for me 15:55:05 7 PT, 8PT, 9PT i'd think would be some options 15:55:18 yeah, actually except tue and thur, others work for me 15:55:49 #endvote 15:55:49 Voted on "(what day next week works best for another hour review session) ?" Results are 15:55:51 fri (1): nikhil_k 15:55:52 thur (1): lakshmiS 15:55:59 #vote wed 15:56:06 I'll send something out. 15:56:21 running out of time. 15:56:30 So, I listed several items in the agenda 15:56:39 so question, has anyone deployed searchlight on an environment for a period of time? 15:57:10 beta ran in HOS env for a number of weeks pre-liberty. 15:57:16 but none of the recent stuff 15:57:38 would be good validation before release 15:57:42 we just had a discussion with our mgmt who said they could have some people help with things like that. 15:58:01 no luck here yet 15:58:02 good idea david-lyle 15:58:13 #topic reviews 15:58:13 TravT: great 15:58:13 i agree 15:58:27 Several on agenda 15:58:29 will highlight one 15:58:38 Please, look at nova plugin 15:58:38 nova? 15:58:39 Nova instances plugin https://review.openstack.org/198852 15:58:57 I started it but couldn't finish review 15:58:57 i beat up steve quite a bit now 15:59:06 i feel bruised 15:59:43 There are others to review and some bugs to triage. will copy paste here 15:59:53 Bug review (Please add any bugs needing attention below) https://bugs.launchpad.net/searchlight 15:59:54 Critical & High 15:59:54 Sorting https://review.openstack.org/#/c/206268/ 15:59:55 Other 15:59:57 https://review.openstack.org/#/c/210759/ 15:59:59 Needs Triage 16:00:01 Glance images not searchable after update notification: https://bugs.launchpad.net/searchlight/+bug/1486781 16:00:02 Launchpad bug 1486781 in OpenStack Search (Searchlight) "Glance images not searchable after update notification" [Undecided,New] 16:00:03 Sorting name fields does not behave as expected: https://bugs.launchpad.net/searchlight/+bug/1488236 16:00:04 Launchpad bug 1488236 in OpenStack Search (Searchlight) "Sorting name fields does not behave as expected" [Undecided,New] 16:00:05 Blueprint review (Please add any blueprints needing attention below) https://blueprints.launchpad.net/searchlight 16:00:07 Essential & High 16:00:10 Nova instances plugin https://review.openstack.org/198852 16:00:11 Designate Plugin https://review.openstack.org/#/c/199099/ 16:00:18 Ok, thanks everybody! 16:00:22 thanks! 16:00:34 #endmeeting