15:01:32 #startmeeting openstack search 15:01:32 TravT: hi 15:01:34 Meeting started Thu Aug 13 15:01:32 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:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:35 o/ 15:01:38 The meeting name has been set to 'openstack_search' 15:01:39 hi! 15:01:42 o/ 15:01:45 o/ 15:01:47 o/ 15:02:07 How is everybody this fine day 15:02:08 ? 15:02:16 o/ 15:02:17 o/ 15:02:21 enjoying the airshow practice 15:02:38 Sounds interesting 15:02:52 Okay, here's the meeting agenda. Please add any topics that you see fit. 15:02:53 https://etherpad.openstack.org/p/search-team-meeting-agenda 15:03:10 I don't have any general status updates today. 15:03:24 #topic Testing - python 3 15:03:40 This patch merged: Patch Merged (Thanks Sergey!): https://review.openstack.org/#/c/209939/ 15:03:49 yeah, that's awesome 15:03:56 So, I went ahead and put up a patch for zuul gate jobs 15:04:09 to add py3 tests 15:04:09 Gate Jobs review up: https://review.openstack.org/#/c/212103/ 15:04:11 o/ 15:04:34 if there is any reason we shouldn't do that, speak now or forever hold your peace. 15:05:18 only reason we didnt do before was to keep it simple when we started searchlight code merge 15:05:27 +1 to that 15:05:31 that's what I remember as well. 15:05:36 yeah, go for it 15:05:48 and moving py 3.4 is a priority from the cross project meetings 15:06:20 TravT: umm, for may be 1 year more :) 15:06:37 but +1 to avoid regression! 15:06:50 that's like nothing in openstack time 15:06:54 :) 15:07:20 #topic Planning a liberty 3 prioritization discussion 15:07:45 ha :) 15:07:50 As you might have seen, I put up a doodle poll 15:07:51 http://doodle.com/99kzigdbmed57g7s 15:08:25 seems like there's only one option left :) 15:08:28 Current responses point to tomorrow at 8 AM pactific 15:08:40 hah 15:08:42 works for me 15:08:47 works for me 15:08:51 yep 15:09:28 So, next question is should we just do it in the IRC room or do it via a video call. 15:09:33 IRC 15:09:40 (is my vote) 15:09:48 I'll probably be on a separate video call all day tomorrow 15:10:00 either works for me 15:10:26 irc has the advantage of being logged automatically 15:10:46 sigmavirus24: all day video call sounds boring 15:10:58 lakshmiS: it is 15:12:27 irc+1 15:14:41 i guess TravT doesnt want IRC 15:14:47 well, that was fun 15:15:03 what'd i miss? 15:15:03 :D 15:15:05 :D 15:15:29 sorry, i got disconnected 15:15:30 fun was nothing happened 15:15:34 TravT: we talked about your leaving irc just when we voted for irc meeting :P 15:15:40 you* 15:15:55 Not sure if this sent or not. So re-pasting 15:16:02 either also works for me. i do like the rich-ness of verbal discussion, but i don't want to leave you out sigmavirus24, so let's go IRC 15:16:11 I don't think it'll take very long, TBH 15:16:14 TravT: you can leave me out 15:16:25 I leave myself out of things often 15:16:28 Sounds like everybody voted IRC 15:16:45 sigmavirus24: not going to let you off the hook that easy. 15:16:50 ;) 15:16:51 damnit 15:17:02 haha 15:17:22 okay, so tomorrow i'll put out a courtesy reminder 15:17:51 I'm adding a topic here 15:17:59 #topic discussing security bugs 15:18:20 i was watching some of the discussion in the glance meeting just now 15:18:42 sigmavirus24, you were talking about what we should and shouldn't discuss in meetings when it comes to vulnerabilities 15:19:10 would you or somebody else like to repeat that? 15:19:27 certainly 15:19:27 so 15:19:34 talking about open bugs in meetings is fine 15:19:41 if a bug has been privately reported though 15:19:46 then we shouldn't 15:19:48 A) Link to it 15:19:54 B) Discuss the bug number 15:19:57 C) Discuss the contents 15:20:00 D) Discuss the patch 15:20:08 E) Add random people to it unless they're vetted security cores 15:20:36 Basically when something is reported, the only people on the bug should be teh VMT, the security liaison, the PTL 15:20:43 F) Dates 15:20:47 Right 15:21:00 Patches are developed as attachments to the bug report 15:21:11 Once a patch seems to fix the issue, a core or two are added to review it on the bug report 15:21:29 Once they're satisfied, then a disclosure date is set, the stakeholders are emailed by a VMT member 15:21:46 And then on teh disclosure date, the patch is proposed to gerrit the cores that were added auto-approve it 15:21:53 And we have a successful security process 15:22:03 \o/ 15:22:10 great synopsis 15:22:19 There's a really good wiki page about all of this 15:22:26 So that makes me wonder, do we have a security liaison? 15:22:34 Or a security team? 15:22:34 now for reporting, there is a Information Type field. 15:22:38 TravT: and nikhil_k once we have a release, you will need a core-sec group 15:22:51 david-lyle: good point 15:22:59 as sigmavirus24 was pointing out 15:23:13 liaison(s) == core sec group 15:23:31 what if a security related bug is reported and is set as public? 15:23:39 then it stays open 15:23:45 fix it quick! 15:23:51 someone needs to take it up and fi it 15:23:57 it's already disclosed at that point 15:23:59 usually the responsibility of the core sec group 15:24:03 no, undisclosing 15:24:10 so they needs to be part of cores in general 15:24:29 need* 15:24:37 today is my un-grammar day 15:24:40 So the other thing is, NEVER add the security group 15:24:45 everyday is my un-grammar day 15:24:47 * david-lyle doesn't limit to one day 15:24:50 the VMT and the OpenStack Security Group on Launchpad are two very different teams 15:25:16 If you add the OSSG it's as good as publicly disclosing 15:25:38 sigmavirus24: can you point to the wiki link 15:25:44 lakshmiS: let me look 15:25:46 yes, when a bug is properly submitted the VMT is usually on it before the project tream 15:26:09 #linkhttps://wiki.openstack.org/wiki/Vulnerability_Management 15:26:15 #link https://wiki.openstack.org/wiki/Vulnerability_Management 15:26:22 david-lyle: right 15:26:29 That assumes the bug tracker is appropriately configured 15:26:35 basically, as a practice you can add Tristan Cacqueray, ttx and (or) Jeremy Stanley 15:26:38 looks like it is moved here 15:26:38 glance_store (was?) is not configured appropriately 15:26:41 #link https://security.openstack.org/vmt-process.html 15:26:53 TravT: yeah, 15:27:04 I think the links in the wiki (which comes up first on Google) are to that 15:27:48 Since we haven't done a release yet, I think we're okay. But we've already had a few security bugs reported as public. 15:28:07 But moving forward, we should follow that process. 15:28:32 I think we are okay for now, given people would be deploying with a risk anyways 15:28:37 yep, please reach out to one of the vmt when you have time and we can clear it up 15:28:48 I think the suggestion is configure launchpad properly and have a team/individuals properly assigned by release time 15:29:04 david-lyle: +1 15:29:13 david-lyle, sounds good 15:29:13 we should have this in place before searchlight 1.0.0 15:29:29 that way once we have 1.0.0, we don't need to scramble on the first report 15:29:43 so, i would nominate all cores on this meeting to be a part of sec-core group. 15:29:54 but how is that normally done? 15:30:07 fungi: ? 15:30:09 I think that's fair given the diverse set of focus/expertise 15:30:14 in Horizon it's a subset of core plus a non-core 15:30:30 i'm very trustworthy 15:30:48 basically if we see something in designate we need someone with domain k/w on that, if nova then so 15:30:48 * TravT never believes somebody who says that about themselves 15:30:58 TravT: generally it depends on the size of your core reviewer group 15:31:45 if it's just a handful of people and they're familiar enough with the embargoed security patch proposal/review process such that they can successfully avoid accidentally leaking information prematurely, then that's fine 15:32:23 one idea: to start with we should ask 2 volunteer security liaisons. they can do the needed delegation once an intial pass is completed 15:32:23 for projects the size of, say, nova it doesn't make sense to have two dozen people automatically subscribed to a vulnerability report. might as well just be public at that point 15:33:41 but yeah, by default for repos in a governance deliverable tagged vulnerability:managed there is a vmt liaison (by default the ptl) and then some subset of the project-team's core reviewers identified with a projectname-coresec group in lp 15:33:51 Also, I should point out that respected members of the larger sec community are turning against embargoed disclosures 15:34:08 sigmavirus24, what does that mean? 15:34:20 It doesn't affect us 15:34:25 for deliverables that are not officially vulnerability:managed you can mostly follow the same processes we publish, and we're happy to help you out in getting familiar with them 15:34:29 But, there would be no private disclosure of the bug in a private bug report 15:34:49 Just food for thought is all 15:35:29 right, for any of you who attended my talk at oscon, i tried to underscore that our vmt is taking a pretty hard line on only embargoing things that really benefit from it (where the embargo effort is eclipsed by the potential impact of having the bug public without available fixes) 15:35:35 ok, well, i have about 6 people (including me) that I think are candidates for seccore group. 15:36:13 yeah, so you'd create a searchlight-coresec group in launchpad and invite them 15:36:30 Ok, that sounds like a good way to go about it. 15:37:00 nikhil_k, sigmavirus24, can we have a side discussion on this later, before I do that? 15:38:18 fungi: thanks for the info. 15:38:42 now that we've had that topic, let's move on. 15:39:08 #topic Bug review 15:39:24 what helped prompt the above 15:39:34 is we have a security bug right now... 15:39:41 as it turns out, it is really just configuration. 15:39:54 i'll test this today 15:39:54 so, documentation + devstack settings. 15:39:57 yesterday exploded 15:39:57 Fix for Authentication not Happening: https://review.openstack.org/#/c/211047/ 15:40:14 thanks sjmc7 15:40:28 if other could also take a look that'd be great. 15:42:13 There is another related bug, which it appears sjmc7 has triaged 15:42:33 could use some reviews on his fix: 15:42:35 https://bugs.launchpad.net/searchlight/+bug/1484285 15:42:35 Launchpad bug 1484285 in OpenStack Search (Searchlight) "Elasticsearch unable to parse query when using non-admin user" [Critical,In progress] - Assigned to Steve McLellan (sjmc7) 15:42:41 TravT: no objection 15:42:58 lakshmiS: i had notified you of that one last night. 15:43:06 did you also look at it? 15:43:32 yes i did, also looling through sjmc7 fix 15:43:35 looking 15:43:45 ok, sounds good 15:44:08 i am still not sure how it worked before. I will be spending more time on it 15:44:39 Fix for API root returns HTML instead of a list of versions: https://review.openstack.org/#/c/207864/ 15:44:42 it worked as an admin user 15:45:14 the above ^ has several positive reviews. 15:45:24 yeah, that one's good to go. even graham approved! 15:45:41 just needs another +2'er with +A 15:46:46 any other bugs specifically needing attention today? 15:47:00 if not, would like to move to next topic 15:47:27 not from me, aside from the other reviews waiting 15:47:43 i had hoped to review more earlier this week, 15:47:55 but that authentication bug took most my attention 15:48:15 ok 15:48:29 #topic BP: Functional Tests https://blueprints.launchpad.net/searchlight/+spec/set-up-functional-tests 15:48:44 lakshmiS: that patch fixes more then just HTML right? 15:48:52 I mean, is intended to fix** 15:49:15 #undo 15:49:16 Removing item from minutes: 15:49:19 prevent HTML output and provide version info similar to glance 15:50:01 lakshmiS: and the correct version listing in the discovery api response 15:50:30 nikhil_k: yes and it only has one api version for searchlight which is v1 15:50:45 may be a updated commit message (using the webui) with APIImpact flag for historical purposed? 15:50:57 purposes* 15:51:19 nikhil_k: sure 15:51:21 I can comment that on the patch 15:51:26 thanks lakshmiS 15:51:32 https://review.openstack.org/#/c/207672/ should also have an APIImpact flag in that case 15:51:42 since it changes the /search/plugins response 15:52:05 umm, yeah.. 15:52:24 sure, go ahead and add it. 15:52:49 #topic https://blueprints.launchpad.net/searchlight/+spec/set-up-functional-tests 15:52:52 we can do a quick grep at the end of the cycle and say this is how the API has evolved 15:52:58 thanks TravT 15:53:12 so ceilometer assumes JDK and ES is already installed and there is no other known solution 15:53:21 https://github.com/openstack/ceilometer/blob/6f6f655766a1ab4a66e00ea7f95dabb56a654e8a/setup-test-env-es.sh 15:53:29 for functional tests 15:53:43 that's what i did too. because it's hard :) 15:53:56 thats the same approach i am following unless anybody has something to say! 15:53:58 i still think there's a lot of value in being able to run them locally even if integrating in CI is hard 15:54:21 I agree 15:54:37 I see, it might be the only good solution for a bit 15:55:02 i will put the patch up for review then! 15:55:04 I am not a fan of creating mock back-ends for integration tests 15:56:05 lakshmiS: I would like to work with you or on the review. there are a few things like avoiding sys variables that we should do. it broke glance many a times 15:56:22 nikhil_k: definetly 15:56:49 because above might be mis-interpretted by others following along at home, just want to be clear that i feel that testing elasticsearch integration should be against real elasticsearch. 15:57:07 yes 15:57:09 i agree 15:57:22 lakshmiS, that's great you have a patch ready 15:57:48 ok, we are almost out of time. 15:58:04 as usual, review what you can. 15:58:28 sjmc7: I think the nova plugin is failling silly 15:58:29 Tomorrow we'll have a BP prioritization review in the room 15:58:37 https://review.openstack.org/#/c/198852/ 15:58:42 which room? searchlight or meeting room? 15:58:47 sjmc7: may be a set() on the test should help 15:58:51 #openstack-searchlight 15:59:22 I'll send a courtesy reminder out 15:59:22 because, currently it's looking at the order of values in resp 16:00:00 TravT, lakshmiS - don't forget the i18n meeting. 16:00:13 thanks everybody 16:00:15 wokuma: thx for the reminder 16:00:18 #endmeeting