15:01:10 <TravT> #startmeeting openstack search
15:01:10 <openstack> Meeting started Thu Feb 18 15:01:10 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:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:14 <openstack> The meeting name has been set to 'openstack_search'
15:01:21 <nikhil> o/
15:01:23 <TravT> Hello!
15:01:24 <yingjun> o/
15:01:31 <lei-zh> o/
15:01:33 <sjmc7> hey
15:01:41 <RickA-HP_> o/
15:01:49 <TravT> FYI rosmaita just said he'll be 10 - 15 mins late (depending on icy road conditions)
15:02:06 <TravT> Agenda is here, feel free to add to it: https://etherpad.openstack.org/p/search-team-meeting-agenda
15:02:39 <TravT> #topic general updates
15:02:46 <TravT> Time is getting tight.
15:02:49 <TravT> http://releases.openstack.org/mitaka/schedule.html
15:03:16 <TravT> I think we'll need to be considering a few feature freeze exceptions
15:03:34 <TravT> we can evaluate that in a week or so
15:03:56 <TravT> #topic client release schedule
15:04:08 <TravT> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086362.html
15:04:55 <TravT> Of note in that email: Final release for client libraries: Mar 2
15:05:28 <yingjun> There is only one patch under review for client: https://review.openstack.org/#/c/275046/
15:05:50 <TravT> yingjun: thanks for updating it today
15:05:55 <TravT> i'll definitely review it later
15:06:12 <sjmc7> yep, me too. i think that gets us to the minimal set of stuff we wanted to do
15:06:46 <TravT> i think so too, but i'm wondering about versioning, backwards compatibility, and deprecation.
15:07:14 <TravT> we haven't yet decided if searchlight itself will stay 0.2 as it has been tagged thus far or will go to 1.0.
15:08:13 <TravT> so, i'm not sure we should tag client as anything more than 0.1 or 0.2, both due to the service and due to us wanting one more release for wiggle room on the CLI
15:08:48 <sjmc7> i’d be fine with that
15:09:10 <TravT> we should look back at this again
15:09:12 <TravT> #link https://review.openstack.org/#/c/226157/
15:09:47 * TravT briefly reading
15:10:52 <sjmc7> so we have to make sure we don’t break stuff? we can do that
15:11:29 <TravT> i think that's the gist of it...
15:11:52 <TravT> but my other concern is that we have no external feedback on the CLI itself
15:12:27 <sjmc7> it’s the first version
15:12:41 <sjmc7> if we have to make changes, we’ll make them
15:12:54 <TravT> so, maybe planning to tag it at 0.2 will make sense
15:12:59 <TravT> yingjun: any thoughts here?
15:13:18 <yingjun> no, 0.2 is ok for me
15:13:42 <TravT> So also as FYI
15:13:51 <TravT> there is a standard deprecation policy tag
15:13:59 <TravT> we haven't asserted it for searchlight yet
15:14:00 <TravT> https://openstack.nimeyo.com/60351/openstack-asserting-projects-follow-least-deprecation-policy
15:14:15 <TravT> but it is something that deployers will likely consider
15:16:10 <TravT> so, the versions we use (pre-1.0) aren't quite as important as understanding whether or not we follow deprecation and using semver
15:16:27 <TravT> so major bump 0.1 to 1.0 signifies non-compatible changes
15:16:57 <TravT> http://semver.org/
15:17:13 <sjmc7> i think more it signifies that from that point on we’re following deprecation and semver
15:17:22 <RickA-HP_> TravT: Does a major bump in the version always imply a non-compatible change?
15:17:40 <TravT> RickA-HP_: i don't think strictly
15:17:52 <TravT> because many project increment the full version with each openstack release
15:18:17 <TravT> they used to follow kind of a versioning that tracked the release year and milestone
15:18:29 <TravT> e.g. 2012.1.x for first release in 2012
15:18:35 <TravT> 2012.2.x for second
15:19:06 <TravT> but i think with liberty most projects switched to semver notation and just automatically jumped to a release number that equated to the number of release cycles they'd been a part of
15:19:20 <TravT> so things like nova went to 12.x.x and horizon went to 8.x.x
15:20:18 <TravT> http://releases.openstack.org/
15:20:44 <TravT> see here are kilo numbers: http://releases.openstack.org/kilo/index.html
15:20:58 <TravT> Here are liberty numbers: http://releases.openstack.org/liberty/index.html
15:21:15 <TravT> and here are current mitaka numbers: http://releases.openstack.org/mitaka/index.html
15:21:55 <rosmaita> the client versions are all over the place
15:22:59 <TravT> rosmaita: yeah, there doesn't seem to be any correlation
15:23:06 <rosmaita> which is a true observation, but not very helpful
15:23:31 <TravT> i see the project senlin went straight to a 1.0.
15:23:36 <TravT> in liberty
15:23:58 <TravT> from mailing list, it looks like dev started pre-liberty though
15:24:35 <TravT> i think at this point, i'm inclined to bump the searchlight service to 1.0
15:24:48 <TravT> and just start incrementing major every single release like other projects
15:25:02 <TravT> but hold off on deprecation policy tag for another release
15:25:39 <TravT> we have about two weeks to finalize on that decision
15:25:57 <TravT> but how does that "feel" to everybody?
15:26:20 <nikhil> If we use Semver then it should
15:26:36 <RickA-HP_> I like the bump to 1.0 for the version. Is there a reason to not apply the deprecation tag?
15:26:51 <nikhil> be straightforward, no?
15:26:58 <sjmc7> i’m pretty ambivalent about versioning, i can go either way. i kind of feel like until we’ve got more real world usage a 1.0 tag is premature but i don’t feel that strongly about it
15:27:14 <TravT> well, if you think about semver
15:27:29 <TravT> we have already made some major changes since liberty.
15:27:31 <rosmaita> sjmc7: you have expressed my feelings exactly
15:27:39 <TravT> so major version increment seems to apply
15:28:14 <nikhil> the thing is incr major would result into more scrutiny in community
15:28:51 <sjmc7> which is good and bad :)
15:28:51 <rosmaita> nikhil: ++
15:28:55 <TravT> nikhil: and that could be a good thing or a bad thing depending on how you look at it.
15:29:00 <rosmaita> yep
15:29:01 <TravT> sjmc7: :)
15:29:01 <nikhil> :)
15:29:25 <rosmaita> we seem to have a consensus here! it's good or bad!
15:29:35 <TravT> well at least we have that figured out
15:29:35 <sjmc7> :)
15:29:37 <TravT> :D
15:30:03 <rosmaita> i don't seem to be bringing a lot of value to this discussion
15:30:12 * TravT disagrees
15:30:42 <nikhil> me too
15:30:46 <TravT> ok well at least is seems we can agree that client will be 0.2?
15:30:51 <nikhil> don't bring value
15:31:16 <sjmc7> agreeing with me is always valuable! yeah, i can go with 0.2
15:31:21 <TravT> okay.
15:31:23 <nikhil> sjmc7: ++
15:31:41 <TravT> well, we'll review that last patch from yingjun
15:31:57 <TravT> i have not explicitly tested the client with just v2 and just v3 keystone
15:32:01 <rosmaita> 0.2 lgtm, too
15:32:02 <TravT> have you done that yingjun?
15:32:25 <TravT> #agreed (initial python-searchlightclient will be version 0.2)
15:33:09 <yingjun> yes, all tested, didn’t find any issue yet
15:33:41 <TravT> okay, great!
15:33:57 <TravT> allright, next topic
15:34:15 <TravT> #topic searchlight panel
15:34:28 <TravT> i haven't set up a repo for it separate from horizon yet
15:34:40 <TravT> it is still two patches deep in the patch chain on horizon
15:34:54 <TravT> the other patches being ones that definitely need to be in core horizon
15:35:09 <TravT> but the horizon mid cycle is next week
15:35:25 <TravT> so will be lobbying hard to get those two parent patches in
15:35:43 <TravT> making it more reasonable to separate out
15:36:06 <TravT> i'll go ahead and put in the governance request change for the repo though
15:36:24 <TravT> we have a really nice demo we'll be doing of it at the horizon midcycle
15:36:39 <TravT> i will see about making a youtube version of it as well to share with everybody
15:36:49 <TravT> (after next week)
15:37:08 <TravT> that's all for that
15:37:16 <TravT> #topic blueprints and reviews
15:37:34 <TravT> https://review.openstack.org/#/q/project:%255E.*searchlight.*+status:open,n,z
15:37:56 <TravT> So top priorities in reviews IMO:
15:38:06 <TravT> Support DSL query for the query CLI
15:38:18 <TravT> Fix role based indexing for designate
15:38:33 <TravT> Use external version to ensure index updates
15:38:42 <TravT> Zero Downtime Re-indexing changes
15:38:57 <sjmc7> external versioning is the one that most worries me on that list
15:39:17 <TravT> lei-zh: are you here?
15:39:24 <lei-zh> yes
15:39:29 <TravT> https://review.openstack.org/#/c/255751/
15:39:29 <sjmc7> there’ve been some roadbumps along the way
15:39:57 <sjmc7> it feels like it’s close but i don’t know how we get it done - lei-zh, would it help to discuss anything here?
15:40:31 <sjmc7> or perhaps if i come online later tonight (my time, your morning)?
15:40:53 <lei-zh> most things happen in glance plugins
15:40:58 <sjmc7> yep :)
15:42:10 <lei-zh> the doc consists of different resources, which sometimes we cannot get a acurrate version when updating
15:42:30 <sjmc7> specifically image members?
15:43:01 <lei-zh> also metadef things I think
15:43:05 <lei-zh> like properties
15:43:30 <TravT> so images first
15:43:46 <TravT> are you thinking members should be child plugin to images?
15:44:27 <lei-zh> I think they should be separated
15:44:30 <sjmc7> the alternative to that would be forcing an update from the glance API?
15:44:43 <sjmc7> so on an image member change, reindex the image entirely
15:45:03 <sjmc7> i dislike having image member be its own entity
15:45:14 <TravT> this would then make the rbac query filter for images be something like (total pseudo of course) or has_child match project id
15:45:15 <sjmc7> it seems like an implementation detail leaking into the model
15:45:30 <TravT> that would slow it down a little because child queries are a little slower according to ES docs
15:46:41 <sjmc7> it’s not speed that concerns me particularly, more complexity
15:47:31 <sjmc7> the problem is that the image updated_at timestamp doesn’t change when image members are added or deleted
15:47:36 <lei-zh> the problem is if we try to use external version, we should keep using it all the time
15:48:33 <lei-zh> if a member changes, we still don't have a new image version, because nothing changes in image
15:48:53 <TravT> so sjmc7 this seems to lead towards separating them, but i'm not sure based on your comments whether you are advocating for parent child or for keeping them together
15:49:06 <sjmc7> i would prefer to keep them together, trying to think of how
15:49:28 <rosmaita> would it help if glance updated the image updated_at on a member change?
15:49:31 <sjmc7> yes
15:49:34 <sjmc7> that would solve all
15:49:40 <sjmc7> great rejoicing etc
15:49:49 <TravT> less gnashing of the teeth
15:50:04 <rosmaita> i will file a bug and see what happens
15:50:29 <rosmaita> too bad the glance meeting already happened this morning
15:50:49 <sjmc7> ok. in the meantime, one thing we could do is a scripted update without a version, which will increment by one
15:51:08 <TravT> that would be good... because then at least the glance team can debate on whether or not this is intended functionality for glance
15:51:19 <sjmc7> yeah.. but we need an interim solution
15:51:35 <sjmc7> first off, am i incorrect to want to keep them together?
15:52:15 <nikhil> a version/increment update on the value would need a test and set
15:52:34 <nikhil> and that would require a temp column in the table
15:52:52 <nikhil> so, I doubt if this is small change
15:53:25 <TravT> well, this meets the criteria of a parent child relationship... but what I really don't like about it is that it becomes a new resource type that will now show up in search results potentially unless we exclude them by default
15:53:32 <sjmc7> is keeping them separate going to be better? image members don’t need to be their own plugin
15:53:46 <sjmc7> just because they’re child documents for update purposes doesn’t mean making them a whole plugin
15:54:16 <TravT> sjmc7: that's true
15:54:17 <sjmc7> they are useless on their own, ergo i don’t think they should be a full plugin
15:54:40 <lei-zh> I think current datastructure makes sense, the only reason to seperate is the external version thing
15:55:07 <sjmc7> me too, but i can’t think of a good solution other than allowing the version increment behavior
15:55:10 <sjmc7> which maybe that’s ok?
15:55:15 <TravT> for visibility testing in the UI (I just wrote the new angular filter for standard glance in horizon) we have to have image members in the result
15:55:31 <TravT> well i take that back
15:55:35 <TravT> we derive it
15:55:53 <sjmc7> lei-zh: how about this - for now, we making updating image members a special case where we do an update without specifying the version (which will increment by one)
15:56:12 <sjmc7> since we’re only removing or adding the individual id it should be ok
15:57:28 <sjmc7> if we REALLY need to do so we can store the timestamps with each member
15:57:39 <sjmc7> and only update when appropriate, although for deletes that will be difficult
15:58:06 <lei-zh> it may have a rare chance that it will conflict with other image updates?
15:58:12 <sjmc7> not really
15:58:23 <TravT> sjmc7: so basically this takes the chance of other image update conflict down to 1 millisecond
15:58:28 <sjmc7> incrementing by 1 is equal to a nanosecond after the previous update
15:58:38 <sjmc7> or.. yeah, millisecond i guess. but after the last notification
15:58:40 <lei-zh> yes, very rare
15:58:44 <sjmc7> so any REAL image update will overwrite it
15:58:49 <sjmc7> becaues the image timestamp will be older
15:59:07 <sjmc7> errr.. younger, sorry
15:59:22 <TravT> this seems reasonable to me.
15:59:25 <sjmc7> i would like to get the patch in and fix specific edge cases separately
15:59:32 <TravT> as long as there aren't 400000 member updates
15:59:35 <sjmc7> this seems like a reasonable compromise
16:00:03 <sjmc7> time’s up
16:00:07 <TravT> out of time here, can we jump over to #openstack-searchlight to finish?
16:00:16 <sjmc7> lei-zh: can you stick around for a few more minutes to talk about metadefs?
16:00:17 <lei-zh> ok, I think it's the quickest way to solve it.
16:00:29 <TravT> #endmeeting