15:00:41 <TravT> #startmeeting openstack search
15:00:41 <openstack> Meeting started Thu Jun 30 15:00:41 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:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:44 <openstack> The meeting name has been set to 'openstack_search'
15:01:01 <TravT> o/
15:01:03 <yingjun> o/
15:01:08 <GB21> 0/
15:01:09 <david-lyle> o/
15:01:11 <matt-borland> o/
15:01:11 <GB21> o/
15:01:23 <RickA-HP> o/
15:01:24 <lei-zh> o/
15:01:53 <TravT> okay, with sjmc7 joining i think we have a quorum
15:01:58 <sjmc7> hello
15:01:59 <TravT> rosmaita will be right back
15:02:07 <GB21> hi sjmc7
15:02:12 <Kevin_Zheng> o/
15:02:18 <TravT> i say lei-zh join as well
15:02:25 <TravT> say --> saw
15:02:28 <itisha> o/
15:02:33 <TravT> o/ itisha
15:02:43 <TravT> todays agenda is here
15:02:43 <TravT> https://etherpad.openstack.org/p/search-team-meeting-agenda
15:02:49 <TravT> please add anything you see missing
15:03:20 <TravT> as a reminder, we are about two weeks from the end of newton 2
15:03:24 <TravT> http://releases.openstack.org/newton/schedule.html
15:03:34 <rosmaita> back
15:04:01 <TravT> did you get your coffee emergency solved? ;)
15:04:14 <GB21> hi rosmaita
15:04:27 <TravT> first up
15:04:34 <TravT> #topic searchlight ui updates
15:04:44 <matt-borland> Yeah, a couple of updates
15:04:56 <matt-borland> first, the npm jobs in Jenkins were all passing all the time
15:05:07 <rosmaita> TravT: yes, it was both and input and output problem if you know what i mean
15:05:13 <TravT> rofl
15:05:18 <matt-borland> and we introduced lint/test errors on master searchlight-ui
15:05:39 <matt-borland> so if you have patches and rebase you'll see those errors in your patch
15:05:49 <matt-borland> that's fixed in a patch I have up
15:06:01 <matt-borland> otherwise, what we're doing in feature development is:
15:06:13 <TravT> matt-borland's patch: https://review.openstack.org/#/c/335041/
15:06:38 <matt-borland> Adding the 'registered' details views to the results...so you link off to client-side views when they available
15:06:48 <matt-borland> that patch is nearly landed ^^
15:06:52 <matt-borland> but can use some more eyes
15:07:13 <matt-borland> We also have a patch to make the result list respond appropriately when you complete an action, like Editing an item
15:07:28 <matt-borland> it will cause the item to 'light up' if it's in a transitional state
15:07:38 <rosmaita> fancy
15:07:47 <matt-borland> :) it's good ux
15:07:56 <matt-borland> lets people know that 'hey, this thing might be changing status soon'
15:08:12 <matt-borland> so they don't feel they edited something and the screen seems out of sync
15:08:27 <TravT> the ui is affected by a bug on horizon master right now
15:08:28 <TravT> FYI
15:08:38 <matt-borland> that patch is waiting on some work from tyr who is on paternity leave
15:08:47 <TravT> links off to django based detail pages fail.
15:08:50 <matt-borland> so TravT I'm a little blocked on that
15:09:15 <TravT> https://bugs.launchpad.net/horizon/+bug/1597528
15:09:15 <openstack> Launchpad bug 1597528 in OpenStack Dashboard (Horizon) "Containers/Swift URL Redirection Loop" [High,Confirmed]
15:09:29 <matt-borland> That loop is a specific-to swift problem
15:09:36 <matt-borland> they registered their urls badly
15:09:44 <TravT> it behaves the same as the network pages, though
15:09:47 <matt-borland> true
15:10:06 <matt-borland> TravT, I can look at that upstream today
15:10:18 <matt-borland> is this only when within webroot?
15:10:19 <TravT> cool we can work through that offline. just wanted to FYI people here
15:10:23 <matt-borland> (again, not the same as swift problem)
15:10:27 <matt-borland> thanks!
15:10:31 <TravT> let's jump to the next topic
15:10:38 <TravT> #topic nova notification status
15:10:55 <TravT> yingjun, how is your work going for hypervisors and flavor notifications?
15:11:59 <yingjun> The hypervisor one is waiting for Balazs’s patch: https://review.openstack.org/#/c/313654/
15:12:36 <yingjun> it’s almost done
15:12:48 <TravT> looks like you are getting good attention on it from nova cores
15:13:03 <TravT> :)
15:13:26 <yingjun> Yeah,)
15:13:32 <TravT> do we have any hope for flavor notifications in newton?
15:13:57 <yingjun> Not sure for the Flavor one
15:14:14 <yingjun> The spec: https://review.openstack.org/#/c/321336/ is not approved yet :(
15:14:36 <TravT> rosmaita and chance you can nudge any of your friends to look at that one?
15:14:42 <yingjun> I think i can get the hypervisor one done in newton.
15:14:44 <TravT> and -> any
15:14:55 <Kevin_Zheng> nova will not review spec after n-1
15:15:05 <rosmaita> what Kevin_Zheng said
15:15:07 <TravT> okay. so then that one is out
15:15:14 <TravT> which brings me to my next topic
15:15:26 <TravT> #topic Disable plugins by default that don't have notifications
15:15:38 <TravT> there may be an even bigger question here
15:15:51 <TravT> but basically, right now we have enabled most plugins by default
15:15:55 <TravT> swift being the exception
15:16:19 <TravT> we didn't enable swift by default because there aren't supported notifications yet.
15:17:15 <TravT> so, i was thinking that perhaps we should make it a policy that if a resource type has to be re-indexed periodically (via cron or some other scheduler), that we should disable them by default
15:17:36 <sjmc7> TravT: do you mean by default the example devstack conf? or in code?
15:17:40 <TravT> in code
15:18:02 <TravT> on devstack, enable by default in sample local.conf
15:18:43 <yingjun> It’s ok for me, just make sure document that..
15:19:25 <sjmc7> to go one step further, we could disable everything by default and make things opt-in
15:19:32 <TravT> yes, that is the next consideration
15:19:43 <rosmaita> i understand the motivation, but do you really think it's necessary?
15:19:59 <RickA-HP> Is there any way to make the connection of enabling a plugin and periodically re-indexing more explicit?
15:20:10 <sjmc7> i think delpoyers are probably going to write their own config file anyway, so the defaults don’t matter too much
15:20:17 <rosmaita> for a young project, probably don't want the devstack and shipping config to differ
15:20:23 <rosmaita> sjmc7: ++
15:20:39 <TravT> so, you can see my long winded comments on https://review.openstack.org/#/c/332242/
15:20:42 <TravT> patch set 4
15:21:11 <TravT> The last line kind of summarizes it
15:21:14 <TravT> All of the above has led me to also realize that upgrade scenarios may be problematic for deployers, particularly because we seem to just enable plugins by default or not.  If you enable them by default, a deployer who had a config file per service will suddenly have to update every single config file to disable the new plugin (At least according to documentation:
15:21:14 <TravT> http://docs.openstack.org/developer/searchlight/plugins.html#non-inheritable-common-configuration-options)
15:22:05 <sjmc7> from my experience we don’t typically blindly re-use config files from release to release
15:22:27 <sjmc7> since so much changes with the various oslo libraries and in services themselves
15:24:07 <TravT> okay, so, sjmc7 rosmaita are you voting to leave all plugins enabled by default?
15:24:25 <TravT> or disable all or disable the ones without notifications by default?
15:24:26 * rosmaita is still reading that monster comment
15:24:41 <sjmc7> i think considering some as ‘experimental’ and disabling them by default is ok
15:24:58 <sjmc7> fully functional ones i’m ok leaving enabled
15:25:52 <TravT> yeah, my only reasoning on disable by default those which don't have notifications is that i wouldn't want a deployer to falsely think that they can expect the data to stay up to date in the index
15:26:28 <TravT> at least without them doing an external sync process
15:26:36 <david-lyle> perhaps a different section in the config file to point out the need for the cron job on those
15:26:50 <david-lyle> separate plugins that have notifications and those that don't
15:27:49 * TravT would have to think about that a bit...
15:28:12 <TravT> maybe if nothing else we could output a warning message in searchlight-manage index sync
15:28:21 <TravT> for any plugins that don't have notification listeneres?
15:28:33 <TravT> but are enabled
15:30:05 <TravT> okay, i think at least i've introduced the topic
15:30:05 <lei-zh> in index sync or searchlight-listener
15:30:28 <david-lyle> combination of warnings and clear documentation
15:30:37 <rosmaita> david-lyle: ++
15:30:44 <TravT> that sounds like a winner
15:31:18 <TravT> Okay, we'll go that direction
15:31:19 <TravT> thanks
15:31:29 <TravT> #topic pipeline architecture status
15:31:52 <lei-zh> I write some demo code about the pipeline, using nova instance as an example
15:32:03 <lei-zh> it's on https://github.com/liverbirdkte/searchlight-1/
15:33:10 * david-lyle ponders liverbird
15:33:15 <Kevin_Zheng> cool
15:33:45 <lei-zh> it's not a complete one, but if it's on the right road, I can work on  actual patches
15:34:13 <sjmc7> i’ll try and take a look today, been caught up in some internal work for a couple of days
15:34:32 <TravT> on this topic
15:34:57 <TravT> RickA-HP had mentioned to sjmc7 and I that perhaps we could schedule a hangout or something if needed to talk through parts of it
15:35:28 <TravT> since many projects have a mid-cycle meetup and we don't, it could help to facilitate faster discussion
15:35:45 <lei-zh> yeah, that's welcome
15:36:03 <TravT> i will be at the horizon mid-cycle the week of July 11th
15:36:12 <TravT> so, next week would be good or the week after that.
15:36:39 <david-lyle> July 11 is the week after that
15:36:47 <TravT> yeah, unclear statement by me
15:36:52 <TravT> i mean the week after the week of the 11th
15:37:03 <david-lyle> aha
15:37:06 <TravT> lei-zh would you want to meet next week?
15:37:21 <RickA-HP> And we can pick a time more convenient for you :)
15:37:56 <lei-zh> we'll have a bug smash next week, but I think it won't be conflicted because I can meet at evening
15:39:12 <lei-zh> so next week is ok
15:39:21 <TravT> well i can do Tuesday, Wednesday, Thursday, or Friday morning next week
15:40:15 <TravT> i'll send a doodle poll after this meeting to the ML
15:40:24 <TravT> and coordinate a time
15:40:33 <lei-zh> sure, thanks
15:40:46 <TravT> Next up.
15:40:50 <TravT> #topic community images
15:41:01 <TravT> rosmaita: i haven't been able to go through this in depth or keep up
15:41:10 <TravT> how's it looking for newton?
15:41:18 <TravT> for glance
15:41:33 <rosmaita> it is going to happen
15:41:46 <rosmaita> but, there will be no bookmarking of images
15:42:03 <rosmaita> so should be a pretty simple change from searchlight POV
15:42:03 <TravT> https://review.openstack.org/271019
15:42:33 <rosmaita> biggest change will be 'visibility' will be public, private, shared, community
15:42:43 <sjmc7> shared == the current ‘members’ thing?
15:42:51 <rosmaita> sjmc7: correct
15:43:11 <rosmaita> there will still be members, but the image won't be considered shared unless it has visiblity == shared
15:43:47 <TravT> rosmaita are we going to need to do some conditional configuration in searchlight to index pre / post this spec?  i mean is this being done in a backwards compatible way?
15:44:24 <rosmaita> TravT: probably
15:44:44 <TravT> probably conditional configuration for indexing? kind of like nova api versioning?
15:44:46 <rosmaita> maybe we can discuss at the midcycle meet you are settin gup
15:44:51 <TravT> ok
15:45:02 <sjmc7> it sounds like our current membes check will still do the job
15:45:10 <sjmc7> the ‘shared’ thing is more an indicator that there ARE memebers i guess?
15:45:24 <sjmc7> so we can probably do an optimization to avoid asking for members all the time for private images
15:45:33 <rosmaita> well, the problem is the member list will persist across visibility transistions
15:45:40 <rosmaita> so yes, what you just said
15:45:43 <sjmc7> ah, ok
15:46:05 <sjmc7> so we should make the change but things’ll work in the interim
15:46:20 <rosmaita> more or less
15:46:47 <rosmaita> 'private' images will show up as shared in searchlight results without the change, i think
15:46:54 <TravT> horizon as well
15:46:57 <sjmc7> but in the new world you mgit have an image with ‘private’ but members that should now no longer show up
15:47:05 <sjmc7> yeah, this will likely affect all consumers of images
15:47:09 <TravT> this glance change breaks backwards compatibility
15:47:16 <rosmaita> not really
15:47:25 <TravT> i think it does
15:47:33 <sjmc7> whether it does or doesn’t, we’ll have to make a change :)
15:47:52 <rosmaita> sjmc7: right
15:47:57 <TravT> yeah...
15:48:16 <david-lyle> if it causes consumers to change behavior to support existing features, it breaks backward compatibility
15:48:25 <david-lyle> period
15:48:43 <rosmaita> well, normal people don't have access to the member list
15:48:55 <rosmaita> the plugin knows more that you'd know from pure api access
15:49:03 <TravT> i'm just trying to think of some of the display filters in horizon
15:49:03 <rosmaita> because it sees member_status, etc
15:49:08 <TravT> they look at visibility
15:49:15 <TravT> and do some derivation today
15:49:29 <TravT> maybe won't be a problem
15:49:32 <TravT> but will have to look at it
15:49:38 <david-lyle> yup
15:50:13 <TravT> okay, will look at spec before the meetup
15:50:25 * TravT looks like there will be lots of homework before meetup
15:50:37 <TravT> I'm going to skip a bit
15:50:43 <TravT> RickA-HP add the next topic
15:50:49 <TravT> #topic Updating ES python client library to match ES 2.X.
15:51:14 <RickA-HP> Some background. Elasticsearch recommends having the python client's version major number match the version number of Elasticsearch. Since we are moving to ES 2.X for Newton, the python client should also be 2.X.
15:51:33 <RickA-HP> But the README for the requirements project claims that we should bump the client library version only if it is "impossible" to stay at the current level. Do we know how strict "impossible" is?
15:52:03 <RickA-HP> The current 1.X version of the client library works with ES2.X.
15:52:09 <sjmc7> that’s not entirely true
15:52:14 <sjmc7> it works for everything we do
15:52:49 <sjmc7> there are some API calls where parameters were removed, or payload requirements changed
15:53:15 <TravT> did any of the query string syntax get affected?
15:53:32 <sjmc7> not sure but that’s not related to the client version
15:53:36 <TravT> shouldn't be
15:53:37 <sjmc7> https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking_20_query_dsl_changes.html
15:54:33 <RickA-HP> I think we should bump the ES client version to 2.X.
15:55:06 <sjmc7> yes. especially as ES 5.0 will be released before newton
15:55:31 <RickA-HP> OK. I'll submit the change and see what push back we get.
15:55:45 <RickA-HP> In global-requirement.txt change it to elasticsearch<3.0,>=2.0 (currently elasticsearch<2.0,>=1.3.0)
15:55:56 <RickA-HP> And in upper-constraints.txt change it to elasticsearch==2.9.0 (currently elasticsearch==1.9.0)
15:56:05 <sjmc7> there is no 2.9.0
15:56:40 <lei-zh> seem max is 2.3.0
15:56:49 <sjmc7> there’s a procedure on https://github.com/openstack/requirements for altering upper-constraints
15:57:31 <RickA-HP> Maybe I'll let the CI bot handle it then.
15:57:55 <sjmc7> there is a manual procedure on that README
15:58:43 <TravT> okay, sounds good.
15:58:49 <RickA-HP> Thanks.
15:58:51 <TravT> you might want to also send out a message to the ML
15:58:58 <TravT> responding to an earlier message steve had sent
15:58:59 <RickA-HP> Ok.
15:59:44 <TravT> http://lists.openstack.org/pipermail/openstack-dev/2016-April/092583.html
15:59:46 <TravT> for reference
15:59:51 <TravT> just tell people that we'
15:59:55 <TravT> are making the move
16:00:03 <TravT> and need to up the client version
16:00:03 <odyssey4me> o/ please wrap up - we have this meeting room booked for this time :/
16:00:12 <TravT> odyssey4me: sorry!
16:00:14 <TravT> okay all
16:00:17 <odyssey4me> :) no worries
16:00:17 <TravT> thanks!
16:00:23 <TravT> #endmeeting