15:01:31 <TravT> #startmeeting openstack search
15:01:31 <openstack> Meeting started Thu May  5 15:01:31 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:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:35 <openstack> The meeting name has been set to 'openstack_search'
15:01:51 <TravT> o/
15:02:13 <lei-zh> o/
15:02:28 <rosmaita> o/
15:02:33 <sjmc7> morning
15:02:48 <TravT> light crowd today
15:02:59 <rosmaita> but high-quality
15:03:17 <yingjun> Hi
15:03:17 <TravT> yes
15:03:39 <TravT> agenda: https://etherpad.openstack.org/p/search-team-meeting-agenda
15:03:40 <lakshmiS_> o/
15:03:52 <TravT> #topic summit notes
15:04:04 <TravT> in case you didn't see
15:04:07 <TravT> i sent out notes to the ml
15:04:11 <TravT> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/093861.html
15:04:28 <TravT> I forgot to mention the most critical part... rosmaita brought pie
15:05:13 <sjmc7> :)
15:05:33 <TravT> It was really great to meet you in person yingjun
15:05:46 <yingjun> me too
15:06:09 <TravT> i feel quite honored to have bought you your first american beer
15:06:11 <yingjun> :)
15:06:42 <yingjun> nice beer, thank you
15:06:59 <TravT> okay, so, out of those notes, there are a couple things to talk about, i think.
15:07:13 <TravT> #topic Nova Cells v2 List API Proposed to be backed by Searchlight
15:07:27 <TravT> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/093716.html
15:07:32 <TravT> jump to the section on pagination
15:08:36 <TravT> item 4 under the pagination section
15:08:40 <TravT> i'll paste here
15:08:51 <TravT> 4. Use the OpenStack Searchlight project for doing massive queries like
15:08:52 <TravT> this. This would be optional for a cell of one but recommended/required
15:08:52 <TravT> for anyone running multiple cells. The downside to this is it's a new
15:08:53 <TravT> dependency, and requires Elasticsearch (but many deployments are
15:08:55 <TravT> probably already running an ELK stack for monitoring their logs). It's
15:08:57 <TravT> also unclear at an early stage how easy this would be to integrate into
15:08:59 <TravT> Nova. Plus deployers would need to setup Searchlight to listen to
15:09:01 <TravT> notifications emitted from Nova so the indexes are updated in ES. It is,
15:09:03 <TravT> however, arguably a better tool for the job than Nova trying to deal
15:09:05 <TravT> with filtering and sorting with python. There is general agreement
15:09:07 <TravT> within the core team that this is the path forward, but it's going to
15:09:09 <TravT> require investigation and testing before we get a better idea of how
15:09:11 <TravT> feasible this is.
15:10:45 <TravT> i think this is really important for us to support this effort
15:11:42 <sjmc7> yep
15:12:19 <TravT> and a big part / perhaps the main thing is for us to work on the versioned notifications
15:12:34 <yingjun> great, but not sure how will cell v2 integration with searchlight
15:13:00 <TravT> well, that's essentially the task in front of us
15:13:07 <TravT> to help figure that out
15:13:12 <TravT> i sent a response to the ML
15:13:21 <rosmaita> i am kind of concerned about the mix of internal and user-facing data here
15:14:00 <rosmaita> but maybe i am missing hte point
15:14:05 <TravT> this is only meant for instances
15:14:06 * david-lyle shuffles in late
15:14:26 <sjmc7> take a seat, lyle. at the front.
15:14:41 <TravT> if you look at this message at the very bottom
15:14:41 <TravT> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093657.html
15:14:54 <TravT> 4) Have all instance listing operations in the Compute API proxy to a
15:14:54 <TravT> call to Project Searchlight and ElasticSearch to handle the cross-cell
15:14:54 <TravT> queries against the instance and instance update (task) information.
15:15:14 <rosmaita> i guess the idea is that the api db won't have a lot of hte data, and instead of calling out to hte cell dbs, just let searchlight listen to notifications, and then use the searchlight index
15:15:26 <rosmaita> (ok, you already answered while i was typing)
15:15:46 <sjmc7> i think yeah, there are now multiple DBs and they don’t want to have to aggregate them
15:15:48 <rosmaita> ok, concern withdrawn
15:16:19 <david-lyle> all list API calls or just cells?
15:16:34 <TravT> yes, they don't have a solution for querying across them that supports sorting, filtering, pagination
15:16:38 * david-lyle reads email
15:16:47 <sjmc7> it would be unnecessary for single cell, but depends how they want to do it i guess
15:17:15 <sjmc7> they will have to support *something* for both single and cross cell cases in the absence of SL, it just might not be as good
15:17:22 <TravT> david-lyle: this one is the better one to read
15:17:28 <TravT> 09:07 TravT: #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/093716.html
15:17:28 <TravT> 09:07 TravT: jump to the section on pagination
15:18:10 <TravT> this youtube video was helpful: https://www.youtube.com/watch?v=Sieza5iMBXY
15:18:25 <david-lyle> well that would help adoption :)
15:18:41 <TravT> david-lyle: yeah, i would think so
15:19:09 <TravT> but basically, the direction they are going is that they want cells to be THE way that nova is deployed
15:20:20 <TravT> got dropped
15:20:59 * TravT taps mic
15:21:02 <sjmc7> :)
15:21:07 <sjmc7> tough audience
15:21:17 <TravT> :)
15:22:06 <TravT> So, sjmc7 and I think that the most critical part of us supporting this is the versioned notifications
15:22:29 <TravT> there is an ML thread on that
15:22:36 <TravT> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093962.html
15:23:07 <sjmc7> more accurately, i think it’s really important we stop hitting the API every notification
15:23:29 <TravT> yes (our whole fishbowl session) :)
15:23:31 <sjmc7> and versioned notifications seem tio be the way we can get extra data into the notifications
15:23:56 <TravT> but as a part of that, we also need to make sure we have the ability to return the correct version of the data
15:24:00 <TravT> as nova has a versioned api
15:24:28 <david-lyle> so we'll have to map the object to the requested version?
15:24:40 <TravT> not entirely sure yet...
15:24:45 <sjmc7> *shudder*
15:24:48 <TravT> don't know if we'll just index 1 version
15:24:49 <david-lyle> and also support specifying a version filter per request
15:24:53 <TravT> or need to index more than one
15:25:09 <TravT> so, part of the versioned notification work is a schema that nova will provide
15:25:22 <TravT> that in theory will allow us to drive data mapping
15:25:35 <TravT> and can be used for creating the object version
15:25:56 <david-lyle> so nova does the object version munging ?
15:26:29 <TravT> so, i got slammed with a bunch of things early this week and haven't been able to go through all the related specs yet
15:26:48 <david-lyle> request -> nova -> searchlight -> nova -> object versioning -> reply
15:27:03 <TravT> yeah, that's the question to be answered.
15:27:07 <david-lyle> that would be best rather than duplicate logic
15:27:09 <TravT> if they expect all versions to be supported
15:27:23 <TravT> that's interesting david
15:28:03 <TravT> if multiple versions are to be supported, i like that concept
15:28:10 <sjmc7> yeah, that’s an interesting option. that might require us to index exactly as nova does in its DB
15:29:02 <lakshmiS_> Which will have security implications if user goes to SL for same data
15:29:07 <sjmc7> or at least exactly as a particular version (probably the latest one) looks. but that might be much better than us doing it
15:29:19 <sjmc7> i guess we need to talk to them more
15:29:25 <david-lyle> sjmc7: or just provide the relevant fields and nova translates
15:29:25 <sjmc7> but first thing is supporting the versioned stuff at all
15:29:28 <sjmc7> yeah
15:29:39 <TravT> yeah, i attended the nova cells meeting yesterday, but stayed invisible
15:29:46 <TravT> too many things going on
15:30:05 <TravT> but my impression was that everybody is catching up from the summit and discussions can begin in earnest next week
15:30:41 <TravT> I think there are several possibilities
15:30:46 <TravT> 1) david's idea
15:30:58 <TravT> 2) we configure to index a certain version
15:31:10 <TravT> 3) we index multiple versions and store the version as a field we filter on
15:32:35 <TravT> we have a blueprint now
15:32:36 <TravT> https://blueprints.launchpad.net/searchlight/+spec/nova-versioned-notifications
15:32:38 <TravT> from our side
15:32:47 <TravT> i think i'll turn that into a spec
15:32:51 <TravT> because this got complicated
15:34:03 <TravT> i'm also curious if we should make this higher priority (currently high)... maybe essential?
15:34:44 <sjmc7> it is dependent on nova actually implementing it
15:34:55 <TravT> yes, that is true
15:35:08 <TravT> but, we should do everything on our part to support it, i think
15:35:12 <yingjun> does sl support listening multiple notification topics at the same time? cause the versioned notification topic is hard coded
15:36:04 <sjmc7> it can do
15:36:18 <TravT> https://github.com/openstack/searchlight/blob/725862a637d4cdf09901a52929453bdde02e3558/searchlight/elasticsearch/plugins/base.py#L42
15:36:39 <TravT> each plugin can configure its own.
15:37:13 <sjmc7> we’d need to support pools i think
15:37:23 <yingjun> but for nova plugin, can i config both versioned_notification and searchlight_indexer?
15:37:40 <sjmc7> i haven’t tested it, but in theory yes. it might get a bit confusing
15:37:44 <TravT> maybe we'd actually have two plugins
15:37:51 <TravT> you can enable versioned or you can enable legacy
15:38:17 <sjmc7> urgh
15:39:17 <sjmc7> maybe in that case we should fix the issue we currently have (not slamming the API) with the existing notifications
15:39:27 <TravT> because I'm not sure versioned notifications are guaranteed to be enabled either.
15:39:39 <yingjun> actually when i was testing the hypervisor plugin, i have to make this to notifications_topic to versioned_notification, so it only listen the versioned one
15:40:30 <yingjun> so the instance notifications are not received at all
15:41:25 <TravT> sjmc7 i'm okay with that.
15:41:43 <TravT> you have a blueprint it seems and i also filed something.
15:41:44 <sjmc7> yeah, there’s no legacy notifications going forward
15:42:02 <sjmc7> we could just make the call that we only support versioned ones
15:42:11 <sjmc7> so deployers should set it to versioned or both
15:42:27 <sjmc7> little bit wary of us unnecessarily complicating testing
15:42:55 <TravT> sjmc7, i'd rather first consider marking it deprecated until we understand all the ramifications of dropping the old
15:43:05 <sjmc7> well right now we can’t drop it :)
15:43:05 <TravT> so, we don't have to "support" it
15:43:28 <TravT> but it is available for deployers who want to say upgrade horizon and use SL....
15:43:29 <TravT> i don't know
15:43:30 <sjmc7> if it’s in the 1.0 release it becomes a burden
15:43:45 <TravT> need to think about it as part of this work with versioned notifications
15:43:53 <TravT> see what comes of them
15:43:55 <sjmc7> the only reason i bring it up is that if we are gonna support it we need to decide how to cope with the missing data
15:44:15 <sjmc7> if we put oureggs in the versioned basket we maybe don't
15:44:30 <TravT> yeah, fair point
15:44:39 <sjmc7> dunno how we decide :)
15:44:53 <TravT> i think we need to dig into the versioned notifications more
15:44:56 <TravT> yingjun
15:45:05 <TravT> wasn't ignoring what you said above
15:45:14 <sjmc7> just to be clear right now they aren’t written for instances (nor is the spec approved yet)
15:45:15 <yingjun> yeah
15:45:44 <sjmc7> but yeah, we can gaze into the future a little
15:46:12 <TravT> i know... jay was insistent that it will get done this release.  which he can't guarantee, but i'd like to work optimistically towards that direction since it will happen at some point.
15:46:21 <sjmc7> yep
15:46:42 <TravT> yingjun: you have the most direct investigation at this point due to your hypervisor work
15:46:58 <sjmc7> so one conversation we can have is what we do to avoid hammering the API with the existing notifications, because there’s no guarantee we’ll get more fields in newton even with versioned notifications
15:47:21 <TravT> yingjun would you be able to also look at the
15:47:26 <TravT> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093962.html
15:47:48 <yingjun> sure
15:47:50 <TravT> and regarding the dual listener thing, if that is a bug or needs a blueprint, please file and let's figure it out
15:48:11 <sjmc7> i’ll need some convincing on that
15:49:17 <TravT> sjmc7: looks like i filed a twin bug to your bp
15:49:18 <TravT> https://bugs.launchpad.net/searchlight/+bug/1577947
15:49:20 <openstack> Launchpad bug 1577947 in OpenStack Search (Searchlight) "Disable intermediate instance action callbacks in Nova" [Undecided,New]
15:50:16 <sjmc7> the more the merrier
15:50:19 <TravT> rosmaita: lakshmiS_ yingjun david-lyle any thoughts on
15:50:58 <TravT> https://bugs.launchpad.net/searchlight/+bug/1577947 & https://blueprints.launchpad.net/searchlight/+spec/optionally-disable-some-events
15:50:59 <openstack> Launchpad bug 1577947 in OpenStack Search (Searchlight) "Disable intermediate instance action callbacks in Nova" [Undecided,New]
15:51:58 <TravT> sjmc7, i think what you suggest makes sense.  just a simple config for events to ignore.
15:52:08 <sjmc7> yeah, that only halfway solves it though
15:52:08 <TravT> then it can be tuned in the field.
15:52:08 <rosmaita> my feedback is that this can be independent of the versioned notification payloads
15:52:13 <david-lyle> so 1577947 you just ignore certain events?
15:52:26 <sjmc7> ultimately i still feel pretty strongly we need to not hit APIs at all
15:52:54 <TravT> i think that possibly would be another configurable option
15:53:01 <TravT> notification_data_only
15:53:06 <sjmc7> yeah, we’ve argued it forever :)
15:53:22 <david-lyle> seems reasonable as long as error states are caught and updated
15:53:47 <TravT> we could first implement as a nova only thing
15:53:51 <TravT> then generalize if needed
15:54:23 <rosmaita> makes sense, nova is the most chatty of the services
15:55:11 <TravT> alright should i delete the bug of the BP?
15:55:14 <TravT> any preference?
15:55:21 <yingjun> agree with the configurable option
15:55:24 <sjmc7> i would still like (we’re out of time now, but sometime) to see what it looks like if we cut out API calls entirely. the reason i’m so against it is that it makes deployment configuration much harder
15:55:34 <sjmc7> but i will say no more now
15:56:17 <TravT> okay, i'll prioritize one of the two up and delete the other.
15:57:00 <TravT> also, given this is all around pagination
15:57:57 <TravT> i was previously blocked on using server side pagination in the searchlight-ui due to the magic search widget's integration with smart table (horizon stuff).  I think that is out of the way now, so i'm going to look at making that change.
15:58:16 <sjmc7> that’ll be a good change
15:58:23 <TravT> https://blueprints.launchpad.net/searchlight/+spec/searchlight-ui-pagination-scrolling
15:58:55 <TravT> okay, we are out of time.
15:59:33 <TravT> please if you have time look into the versioned notifications to understand it better so we can work towards this effectively.
15:59:40 <TravT> i appreciate all your time today!
15:59:53 <rosmaita> go team!
15:59:55 <TravT> and comment on the specs already up if you can
15:59:57 <TravT> :)
16:00:10 <TravT> rosmaita might even bring more pie in the future
16:00:22 <TravT> okay, adios!
16:00:27 <TravT> #endvote
16:00:38 <TravT> or something like that
16:00:38 <TravT> #endmeeting