15:01:39 <TravT> #startmeeting openstack search
15:01:40 <openstack> Meeting started Thu May 19 15:01:39 2016 UTC and is due to finish in 60 minutes.  The chair is TravT. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:44 <openstack> The meeting name has been set to 'openstack_search'
15:02:00 <TravT> rosmaita: thanks for looking at it with a close eye!
15:02:15 <rosmaita> np
15:02:36 <sjmc7> ello
15:02:38 <TravT> o/
15:02:53 <lei-zh> o/
15:03:17 <TravT> sjmc7 i think Rick-A was supposed to be back today
15:03:28 <TravT> but he's not showing online yet
15:04:00 <TravT> anyway, let's get going. maybe yingjun is sleeping tonight.... :)(
15:04:16 <TravT> https://etherpad.openstack.org/p/search-team-meeting-agenda
15:04:29 <TravT> #topic Lei Zhang core nomination
15:04:49 <TravT> FYI http://lists.openstack.org/pipermail/openstack-dev/2016-May/095270.html
15:05:05 <TravT> lei-zh has been doing a great job, i think.
15:05:33 <TravT> should be able to finalize by end of day tomorrow or Monday.
15:06:15 <TravT> #topic Backport 0.2.1
15:06:48 <TravT> we only have a couple more candidates for backport which are already landed on master
15:07:01 <TravT> sjmc7: can you propose this for backport?
15:07:09 <TravT> https://review.openstack.org/#/c/311834/
15:07:20 <sjmc7> yes indeedy
15:07:35 <TravT> and then i was wondering if we should go ahead and backport this one from lei-zh
15:07:36 <TravT> https://review.openstack.org/#/c/309290
15:07:45 <TravT> hi yingjun
15:07:47 <sjmc7> i don’t think we need to do that one
15:07:57 * yingjun late for meeting
15:07:58 <david-lyle> o/
15:08:04 <TravT> hi david-lyle
15:08:10 <sjmc7> it’s not clear when they’ll actually remove the ‘count’ search type
15:08:12 <jaimguer> o/
15:08:18 <TravT> hi jaimguer
15:08:45 <lei-zh> it's deprecated in 2.x, but don't know when it doesn't work
15:09:09 <sjmc7> i suspect it’ll be a long time; it would make sense that they could translate that into a size=0 search internally rather than cause client issues
15:09:25 <sjmc7> otoh it’s not a huge patch to backport
15:09:43 <TravT> it is rather small.
15:09:50 <sjmc7> i’m just wary of backporting too much because we start getting conflicts
15:10:11 <sjmc7> but i could go either way
15:10:22 <TravT> so, how about if it is a clean cherry pick we backport it?
15:10:27 <TravT> otherwise we don't?
15:10:35 <TravT> fyi yingjun talking about this one: https://review.openstack.org/#/c/309290
15:10:58 <yingjun> TravT, thanks
15:11:34 <sjmc7> it makes it more likely to get conflicts down the line too. i guess it’s ok to pick it
15:12:24 <TravT> okay, well, if we do backport it, i'll have to add to the release notes
15:12:49 <TravT> i went ahead and posted a release notes patch on master (which we'll backport) that has notes for all the fixes since mitaka released
15:12:50 <TravT> https://review.openstack.org/#/c/318365/
15:13:26 <TravT> so, let's try to get that done by end of day tomorrow.
15:13:33 <david-lyle> what's the max e-s supported in 0.2.1 ?
15:14:18 <TravT> well, originally we were thinking 1.x, but ES changed their support for 1.x
15:14:48 <david-lyle> but at release time, it was 1.x, correct?
15:14:55 <TravT> yes.
15:15:05 <TravT> by the time some deployers get to deploying mitaka, es 1.x will be problematic for some deployers
15:15:08 <david-lyle> just wondering why 2.0 support in a branch that won't upgrade E-S versions
15:15:09 <sjmc7> and this option is still supported, just deprecated
15:15:42 <david-lyle> seemingly searchlight and E-S will upgrade in tandem
15:15:43 <TravT> the changes for es 2.x were pretty minor for us
15:16:01 <david-lyle> right, but backporting them seems unnecessary
15:16:06 <TravT> well, for example david-lyle HP's deployment of mitaka will only include es 2.x
15:16:39 <david-lyle> just trying to apply stable policy
15:16:50 <david-lyle> or analyze based on that criteria
15:17:00 <TravT> well, i was looking at that
15:17:02 <TravT> http://docs.openstack.org/project-team-guide/stable-branches.html
15:17:04 <sjmc7> we won’t be using bleeding edge ES though
15:17:32 <TravT> i believe all these patches apply while in phase 1
15:17:37 <sjmc7> it seems you’re set on backporting it, and i’m ok with that, dunno if we need to argue it too much
15:17:58 <TravT> sjmc7: this particular patch i don't care too much
15:18:14 <TravT> it was the others which actually prevent usage of es 2.x
15:18:14 <sjmc7> e-s is a bit weird in that it’s not goign to be deployed via system packages like mysql would be
15:18:28 <sjmc7> yeah, those i am definitely onboard with
15:19:21 <TravT> david-lyle: hp had to make a decision to upgrade to es 2.x for mitaka late in the game because of es support contracts going away for 1.x
15:19:24 <david-lyle> I'm not trying to be difficult, but unless > 2.0 is supported in 0.2.1, I don't see the justification to backport
15:19:50 <sjmc7> it is supported in a sense that we decided not to exclude it
15:20:08 <sjmc7> since it had been released for over 6 months
15:20:21 <david-lyle> sjmc7: by >2.0 I guess I'm meaning >=3.0 when the deprecation is removed
15:20:31 <TravT> ahh, on this patch.
15:20:33 <sjmc7> that might be the case, yeah - they don’t specify
15:21:09 <david-lyle> I'll drop it, I know the stable team is trying to be more vigilant on what goes in to stable
15:21:18 <TravT> okay, well, my arm is twisted on this patch
15:21:18 <TravT> https://review.openstack.org/#/c/309290
15:21:30 <TravT> we don't need to backport that one specifically
15:21:38 <sjmc7> ok. other one’s got a backport review https://review.openstack.org/#/c/318729/
15:22:40 <TravT> so a few other items to discuss today
15:23:00 <TravT> upcoming changes to glance that will affect the searchlight plugin
15:23:08 <TravT> #topic upcoming changes to glance that will affect the searchlight plugin
15:23:14 <TravT> rosmaita put up a few BPs
15:23:26 <TravT> i just wanted to check with people on the priority we should put on them
15:23:37 <TravT> https://blueprints.launchpad.net/searchlight/+spec/glance-visibility-changes-shared-community
15:24:26 <TravT> this seems like we should approve it and should consider giving it a high
15:25:09 <TravT> thoughts?
15:25:20 <sjmc7> yeah, agree
15:25:40 <rosmaita> spec isn't approved yet, but there's a dev dedicated to it, so the implementation should land
15:26:21 <rosmaita> but you won't have aything to work with for a while
15:26:30 <TravT> yeah, we might need to mark it as blocked
15:26:40 <TravT> so approve, but blocked until glance further along
15:26:52 <sjmc7> ok. so keep an eye on it. if we don’t support it, worst case is some stuff is invisible when it shouldn’t be?
15:27:06 <TravT> seems that way
15:27:15 <rosmaita> my real motivation was to get y'all to look at the spec in case there's anything bad for searchlight in the design
15:27:37 <sjmc7> i don’t think so, long as we continue to get notifications on changes
15:27:49 <rosmaita> ok
15:27:58 <sjmc7> little bit curious how it’ll actually work :)
15:28:35 <TravT> okay, the other one is this one: https://blueprints.launchpad.net/searchlight/+spec/glance-visibility-changes-inherited
15:29:05 <rosmaita> that's fairly speculative at this point
15:29:21 <sjmc7> your favourite subject, david-lyle - hierarchial tenants!
15:29:29 <rosmaita> it's another heads-up to make sure what glance does is searchlight-friendly
15:29:48 <rosmaita> although, i don't think there's a detailed proposal yet
15:29:52 <TravT> david-lyle probably goes home and writes songs about it, he loves it so much
15:30:06 <sjmc7> i think the multitenant stuff may be a bit wait-and-see
15:30:07 <TravT> ;)
15:30:16 <TravT> yeah, we can leave it as is for now
15:30:18 <sjmc7> it’s definitely gonna cause us some problems
15:30:33 <sjmc7> though i am hoping the request context will have the parent tenant id as well
15:30:33 <david-lyle> TravT: :)
15:30:36 <TravT> i suppose we really should look over that spec
15:31:19 <sjmc7> which just leaves the problem of determining conceptually who should be able to see a resource (like extra ‘visibility’ flags)
15:31:21 <TravT> rosmaita can you let us know if it looks like it is going to make it into newton for glance?
15:31:48 <rosmaita> yes, i will keep you posted
15:32:01 <TravT> i'll add myself as reviewer on the spec, but i have so many review notifications come in that it is easy to miss some
15:32:32 <david-lyle> rosmaita: no assignee
15:32:40 <david-lyle> the odds seem long
15:32:55 <rosmaita> except the PTL is a fan
15:33:03 <david-lyle> is he doing it?
15:33:08 <rosmaita> not sure
15:33:14 <yingjun> We were very interested in the hierarchial tenants thing here in our company year ago.
15:33:18 <david-lyle> won't go far without an implementer
15:33:22 <rosmaita> but yeah, there is already a lot of stuff happening in newton for glance
15:33:53 <david-lyle> I think HMT is going to be a 30' onion
15:34:44 <rosmaita> i am not familiar with that expression
15:34:52 <david-lyle> heck we couldn't even successfully use domains, but now we're going to handle deeper hierarchy
15:34:57 <david-lyle> rosmaita: large onion
15:35:12 <david-lyle> so many layers to uncover
15:35:21 <TravT> well, i'll just mark it as drafting for now
15:35:29 <TravT> but not prioritize it
15:35:40 <TravT> let's move along a bit if we can
15:35:43 * david-lyle remains a sceptic
15:35:54 <TravT> #topic nova notifications updates
15:36:14 <TravT> FYI, went to the versioning meeting yesterday
15:36:26 <TravT> comments from meeting were reflected on bottom of spec
15:36:26 <TravT> https://review.openstack.org/#/c/286675/
15:36:32 <TravT> but basically
15:36:48 <TravT> with 1.0 of versioned notifications they are simply looking to get current notification data in
15:37:08 <TravT> so there is compatibility of payload from current notifications to versioned notifications on existing types
15:37:38 <TravT> from there, they'd like feedback on what additional data they should add after 1.0 for instances
15:37:40 <sjmc7> the comments from most people on there don’t leave me tremendously hopeful we’ll get what we want; consensus seems to be they want to reduce rather than add, and not much appetite for standardizing between notificaitons and the API
15:38:07 <TravT> yeah, they said this is for technical reasons
15:38:07 <sjmc7> i guess we’ll see. hopefully they can implement it reasonably quickly
15:38:18 <sjmc7> and then we’ll find out what direction they take it
15:38:27 <TravT> and to try to get 1.0 versioned notifications out in newton.
15:38:49 <TravT> for net new notifications, not so problematic
15:39:04 <TravT> so, we'll keep watching there...
15:39:23 <TravT> but versioned notifications won't be a panacea in newton
15:39:41 <TravT> which is why we all previously decided to try to reduce callbacks
15:39:48 <TravT> sjmc7 started on that
15:39:55 <sjmc7> yes. my patch is hideous!
15:39:58 <TravT> https://review.openstack.org/#/c/317100/
15:40:16 <sjmc7> i will tidy it up some, but the overall hideousness will remain
15:40:40 <sjmc7> the primary option to reduce hideousness is not trying to keep track of status changes
15:41:15 <TravT> sjmc7, i think your logic works
15:41:22 <TravT> it is just hard to follow...
15:41:34 <TravT> because nova notification flow is hard to follow
15:41:35 <sjmc7> it really is. i’ll tidy it up; it kind of evolved as i went though it
15:42:00 <sjmc7> the basic issue is that there can be conditions under which all the notifications arrive at once, which means requiring lots of special case conditions
15:42:24 <TravT> turning on the option to only have a single listener thread and using pycharm debugger really helped with that one.
15:42:48 <sjmc7> if we do that in production it becomes much simpler :)
15:42:56 <TravT> hahahaha
15:43:32 <TravT> anyway, anything else to say or any questions from anybody or can we move on. just wanted to give status update
15:44:47 <TravT> #topic use pools
15:44:55 <TravT> https://bugs.launchpad.net/searchlight/+bug/1583215
15:44:56 <openstack> Launchpad bug 1583215 in OpenStack Search (Searchlight) "Enable oslo.messaging pools support " [Medium,New] - Assigned to Steve McLellan (sjmc7)
15:45:27 <sjmc7> aside from the 2 hours i spent tracking down a configuration issue with cinder, it looks like pools work and make deployment much easier; no need for multiple messaging topics
15:45:46 <TravT> that would make deployment easier
15:46:18 <TravT> but, does this mean configuration changes still in cinder or other services?
15:46:24 <sjmc7> nope, nothing
15:46:32 <TravT> that's great
15:46:50 <TravT> so, i'd like to prioritize this high, then
15:47:07 <sjmc7> yeah, i’m gonna work on it this week
15:47:51 <TravT> so basically, as long as services are already emitting notifications, no additional changes to deploy searchlight.
15:48:09 <sjmc7> right
15:48:26 <TravT> very cool
15:48:35 <yingjun> so with this change, we will no need to add a specific topic for sl ?
15:48:40 <sjmc7> correct
15:48:56 <yingjun> awesome
15:49:01 <sjmc7> the ‘pool’ becomes a rabbitmq queue rather than the topic itself
15:49:39 <TravT> when we first tried this in liberty, oslo messaging pools had bugs
15:49:47 <TravT> but that got sorted out since then
15:50:00 <sjmc7> yeah. nobody seems to remember what the problem was :)
15:50:26 <TravT> okay, one last thing on agenda, then open discussion.
15:50:33 <TravT> #topic searchlight ui changes
15:51:13 <TravT> there has been a lot of work going on in horizon to enable registration of views / actions / etc for various resource types
15:51:18 <TravT> for the new angular work.
15:51:52 <TravT> tyr and matt-borland have been working together to do things that allow searchlight ui to best consume that work
15:52:00 <TravT> so tyr has a number of patches up on searchlight ui
15:52:42 <TravT> i'll try to get other horizon reviewers to look at them as well
15:52:56 <sjmc7> they’re all a bit over my head
15:53:29 <TravT> but one net affect is that you might have to go through a gyration or two to update horizon from master and update searchlight-ui with re-install a few times this cycle
15:53:33 <TravT> to keep them in sync
15:54:20 <TravT> okay... that's all on that.
15:54:30 <TravT> #topic open discussion
15:54:42 <TravT> FYI i will be out next week.
15:54:48 <TravT> any volunteers to run the meeting?
15:54:56 <sjmc7> yeah, i can do it
15:54:59 <TravT> thanks
15:55:10 <TravT> i'll be out thursday / friday
15:55:48 <TravT> okay, lei-zh yingjun anything you want to bring up?
15:56:24 <yingjun> https://review.openstack.org/318432, please review
15:56:43 <TravT> ok
15:56:53 <yingjun> simple fix
15:57:00 <lei-zh> nope, just want to say I'm honored to join the team:)
15:57:09 <sjmc7> :) welcome!
15:57:17 <TravT> lei-zh: we're honored to have you!
15:57:28 <rosmaita> +1
15:57:31 <david-lyle> welcome
15:57:48 <lei-zh> thanks : )
15:58:10 <TravT> okay, well thanks everybody!
15:58:21 <TravT> #endmeeting