15:00:19 #startmeeting openstack search 15:00:24 Meeting started Thu Mar 24 15:00:19 2016 UTC and is due to finish in 60 minutes. The chair is TravT. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:28 The meeting name has been set to 'openstack_search' 15:00:39 o/ 15:00:42 morning 15:00:48 morning 15:00:56 o/ 15:01:20 Rick is out sick today, i think 15:01:23 morning/night 15:01:29 o/ 15:01:30 o/ yingjun 15:01:40 lakshmi should join shortly 15:01:56 agenda is here: https://etherpad.openstack.org/p/search-team-meeting-agenda 15:02:08 if there is anything you want to add, please go ahead! 15:02:21 o/ 15:02:24 #topic Mitaka RC1 done 15:02:48 We had quite a push to finish things out in RC1 15:02:51 TravT: good job! 15:03:11 Hey! 15:03:28 ohai itisha! 15:03:45 https://launchpad.net/searchlight/+milestone/mitaka-rc1 15:03:57 we have some cool stuff make it 15:04:19 but this coming release, we will need to avoid the FFE's 15:04:54 this does mean the repo is tagged and we have a stable/mitaka branch now 15:05:13 since we do have some bugs floating into RC2, we'll be following the backport process 15:05:31 basically, a fix has to be made to master and merged 15:05:41 then we cherry pick it to the stable/mitaka branch 15:06:15 #topic Mitaka RC2 15:06:27 https://launchpad.net/searchlight/+milestone/mitaka-rc2 15:07:14 The tough ones are already underway. 15:07:35 the medium and two undecided are just documentation fixes, I think. 15:08:15 i was looking at the generated release notes yesterday 15:08:22 and the format is a little weird 15:08:31 does anybody know where those actually get published to? 15:09:24 rosmaita any ideas? 15:09:57 not sure 15:10:09 nikhil? 15:10:27 hi 15:10:31 was distracted, sorry 15:10:46 oh the reno stuff 15:10:47 TravT is wondering where the released notes are published 15:11:18 I think here 15:11:20 #link http://releases.openstack.org/mitaka/index.html 15:11:58 or at least a page related to it 15:12:22 yeah, i can see the release but not the notes 15:12:24 http://releases.openstack.org/mitaka/index.html 15:12:28 sorry, got disconnected 15:12:37 no worries 15:12:48 well, anyway, i can see the release notes generated in a recent build 15:12:48 http://docs-draft.openstack.org/56/296356/3/check/gate-searchlight-releasenotes/940f3a1//releasenotes/build/html/mitaka.html 15:12:59 and saw we might have missed a few things 15:13:22 so, i'll try to put a patch up to correct that. 15:13:55 if there is anything missing from this list for bugs for rc2, please let me know or target the bug yourself: 15:13:55 https://launchpad.net/searchlight/+milestone/mitaka-rc2 15:14:39 there were a couple of patches i think we already moved to rc2 cos they weren;’t ready for 1 15:15:45 hmm, okay, well, re-target them if we didn't already. 15:15:56 #topic searchlight-ui 15:16:17 still waiting for infra to move the repo under openstack NS 15:16:29 thierry +1'd the governance change 15:16:53 and i addressed a review on the infra patch yesterday. 15:17:23 yesterday after server side stuff died down a bit, i started doing some little touchups to the plugin 15:17:33 instructions for it should actually work now.. 15:17:38 https://github.com/ttripp/searchlight-ui 15:17:57 have a couple other minor touch ups to do to it 15:18:00 for mitaka 15:18:24 i installed it yesterday, seemed to work fine 15:18:37 thanks... 15:18:42 david-lyle saw you dropped 15:18:58 so just FYI that i've been doing some minor fixes to the searchlight-ui repo 15:19:32 okay, that's all for that for now. 15:19:54 #topic newton 15:20:28 i've started "grooming" the blueprints a bit 15:20:31 https://blueprints.launchpad.net/searchlight 15:20:53 i think next week we should go through them together and start talking priorities 15:21:21 I've a question after the update is over 15:21:24 but if there is something that you'd like to have considered for newton that isn't on there, please add it 15:21:40 nikhil: re this or just in general? 15:21:55 regarding this and may be in general :) 15:22:06 go ahead! 15:22:33 We (artifacts team) had a chat with app-catalog folks yesterday 15:22:45 on their requirements for artifacts and how they should work 15:22:54 one things came up again and again 15:23:20 they want to scale the registry of artifacts across internet (www -- basically) 15:23:28 TravT: net split ended up on the wrong side 15:23:58 are folks around then? 15:24:14 roll call! 15:24:16 i'm here 15:24:18 still here 15:24:33 here 15:24:34 I will continue 15:24:46 they were hoping to see if they can use SL or if they should use elastic search for this 15:25:12 mostly they good information out to the users and that's real time-like update 15:25:19 if they have any RBAC concerns, then i think taking advantage of searchlight concepts would be very beneficial to them 15:25:20 what do you mean about ‘scale it across the internet'? 15:25:58 the way app-catalog is setup right now is a website apps.openstack.org and they are planning to run a Glare behind it 15:26:09 the end users can be anyone in the world 15:26:27 so, how do they deploy this today? 15:26:28 and they will have read access to listing, download etc 15:26:44 do they have multiple datacenters with replicated databases behind it? 15:27:03 it used to be hard coded and now they are using experimental API (not sure though at what capacity exactly) 15:27:12 TravT: nah! 15:27:40 I don't know what their plan is around geo-spatial HA 15:27:56 but they seemed to be on a plan to have a federated like setup 15:28:08 for scientific community for the most part 15:28:32 for eg. different National labs would want to share images, templates etc assets 15:28:41 and keep them versioned and tagged 15:28:50 all of it kept in app-catalog 15:29:11 but they may run a Glare on their end as well (or some other too) 15:29:26 that will get the latest of the assets from app-catalog into the local host 15:29:43 (cloning -- if you may) 15:30:24 so who all is on this team? 15:30:35 artifacts or app catalog? 15:30:55 (both are different teams) 15:31:11 so is Glare and "artifacts" team the same thing now? 15:31:12 (and app catalog is a consumer of artifacts) 15:31:20 TravT: correct 15:31:38 do you know their timeline? 15:31:45 GLARE == GLance Artifacts REpository 15:32:22 TravT: there wasn't a timeline posted. we're still working on the Glare API approval from defcore etc folks 15:32:31 may be this is newton may be ocata 15:32:49 (hence, regarding this and may be in general) 15:32:58 okay, it sounds interesting. 15:33:05 anyways, the specific reason I brought this up was -- would we consider adding artifacts support? 15:33:20 we already have a BP for artifact support, although it’s not very well fleshed out 15:33:26 ativelkov brought this up at the last summit 15:33:44 yeah, but the API and architecture is now completely changed (Again!) 15:33:45 so we entered a low BP 15:33:53 yeah, that's what he mentioned 15:34:01 that there needed to be some more work on glare first 15:34:23 it won't be very different from Glance 15:34:29 I mean Glare 15:34:35 (just more generic) 15:35:04 but Glance was a tough one with the prop protections and tags and notifications (Afair) 15:35:30 well, if their is a desire for any authentication / authorization / management tooling around ES, then SL has added benefit over starting from scratch with ES 15:35:38 their -> there 15:35:57 oh one more thing, they do not have/need keystone support 15:36:18 they use some other sort of authN 15:36:38 i think we maybe need to take this offline 15:36:47 but I thought the UI and may be horizon integration would be benefitial 15:36:50 sure 15:36:57 I wanted to know: what would be blockers? may be the lessons learnt will make things easier? 15:37:03 that we can discuss offline 15:37:16 auth would be one we’d need to discuss 15:37:49 yeah other auth provider is something we also need to look further into for swift, i think... 15:37:58 deployment would be another; if it’s not colocated with SL, there’s got to be a mechanism for getting information into SL 15:38:32 nikhil, would the timeline for discussing this call for something pre-summit or is this a potential summit session? 15:38:59 TravT: I was thinking at the summit should be good enough. May be even at the contributors meetup would work. 15:39:17 depending on the availability and priorities 15:39:39 nikhil: Glare doesn't use keystone? 15:39:57 david-lyle: oh sorry, it's app catalog that doesn't need it. 15:39:58 the app catalog presumably doesn’t 15:40:08 Glare will be exactly like Glance on the basics of openstack. 15:40:11 ok, less confused now 15:40:25 so no keystone at all, not just a federated provider? 15:40:47 I prolly shouldn 15:41:01 shouldn't have used the word federated 15:41:01 community app-catalog isn't running on top of openstack 15:41:02 yeah, we should maybe not make wild assertions here. we’ll track them down at the summit 15:41:07 IIUC 15:41:27 david-lyle: yes and now they want to use artifacts (glare) to store assets 15:41:43 sjmc7: correct 15:42:02 nikhil: where? 15:42:15 I brought this up to understand the project priorities and see if we can try to collaborate and get some momentum on this in newton even if it's just small things 15:42:48 ok. we’d need to understand the glare data model first off to be able to index anything 15:43:01 and then look at how they plan to deploy it in this instance 15:43:04 david-lyle: right now (afict) they hard code the links to assets 15:43:27 david-lyle: they will want to run a Glare backing the apps.openstack.org website 15:44:16 * david-lyle still confused, but willing to learn more later 15:44:34 sounds good. 15:44:39 i think i’ll have that inscribed on my gravestone, david-lyle 15:44:58 :) 15:45:13 that's one fun authorization model 15:45:43 sorry about the confusion folks.. 15:45:46 fun as in ¯\_(ツ)_/¯ 15:45:51 nikhil: thanks for bringing it up 15:45:58 :) 15:46:10 it does sound like a good summit conversation 15:46:31 looking forward to it 15:47:15 only one other thing i had to mention 15:47:24 #topic notification bugs 15:48:07 sjmc7 already started and we should continue to get notification bugs / bps filed against other projects. 15:48:48 getting as much data via notification as possible is critical to scalability 15:49:01 yeah. nova’s the big one 15:49:20 yeah, we need to figure out the versioned notifications with them. 15:49:29 i opened a bp on that 15:49:30 https://blueprints.launchpad.net/searchlight/+spec/nova-versioned-notifications 15:49:36 yes, that too 15:49:41 with us... 15:49:59 yingjun: have you made any progress on hypervisors? 15:50:33 not yet 15:50:33 * TravT he might be asleep by now 15:50:38 :) 15:51:20 yingjun okay, i think that one will be pretty important to us. 15:51:59 okay... 15:52:09 #topic open discussion 15:52:42 yes, i’ll put a initial patch recently without the notification 15:53:01 are there notificaitons at all for hypervisors? 15:53:19 no 15:54:00 https://blueprints.launchpad.net/nova/+spec/hypervisor-notification 15:54:14 ok 15:54:19 we'll need to flesh that out a bit... perhaps after yingjun does initial plugin 15:54:31 but soon enough to maybe get it noticed in nova land 15:55:38 i have a question about that 15:55:48 who is hypervisor info aimed at? 15:55:57 admins 15:56:02 i thought the whole point of hte cloud is users don't worry 15:56:24 hmmm ... you'd hope they'd have some kind of inventory system 15:57:09 this is for operators 15:57:17 ok 15:57:47 rosmaita do you still do any nova work? 15:58:04 sort of 15:58:35 still mostly glance, but some nova 15:59:13 it would be helpful if someone could move on the hypervisor thing in nova.. 15:59:14 okay. 15:59:28 anyone can submit a patch :) 15:59:51 maybe rosmaita knows the right person to bribe, though. 15:59:53 ;) 16:00:20 i'll ask johnthetubaguy what he thinks 16:00:27 cool, thanks! 16:00:28 though he'll be away until tuesday 16:00:33 np 16:00:35 guess we're out of time for today. 16:00:37 #endmeeting