Wednesday, 2016-02-10

openstackgerritRick Aulino proposed openstack/searchlight: Zero Downtime Re-indexing changes.  https://review.openstack.org/27786000:08
TravTsjmc7: for your keystone v3 patch00:08
sjmc7the whoosiwhat now?00:08
TravTwhat do i need to do to test it properly?00:09
sjmc7oh, the devstack one?00:09
sjmc7i think it’ll just use v3 now00:09
TravTso, if i just restack after pulling it and reclone = no?00:10
sjmc7yeah, that should do it. check the config file it generates (and that it works)00:10
sjmc7the devstack change that broke things was disabling the v2 endpoint00:10
sjmc7but it shouldn’t use it at all now00:11
*** RickA-HP has joined #openstack-searchlight00:26
*** sjmc7 has quit IRC00:49
*** lakshmiS_ has joined #openstack-searchlight01:06
*** lakshmiS has quit IRC01:09
*** lakshmiS_ has quit IRC01:23
*** itisha has quit IRC01:26
*** bpokorny has quit IRC02:10
*** RickA-HP has quit IRC02:50
*** sjmc7 has joined #openstack-searchlight04:02
*** sjmc7 has quit IRC04:16
*** openstackgerrit has quit IRC07:47
*** openstackgerrit has joined #openstack-searchlight07:47
*** itisha has joined #openstack-searchlight08:03
*** krotscheck_dcm is now known as krotscheck12:38
*** itisha has quit IRC13:16
krotscheckAny cores around to perhaps add another +2 to https://review.openstack.org/#/c/265396/ ?14:20
*** sjmc7 has joined #openstack-searchlight15:04
*** sigmavirus24_awa is now known as sigmavirus2415:19
TravTkrotscheck: I think sjmc7 was going to add his vote onto that one15:43
sjmc7yeah, will do15:43
TravTsjmc7, krotscheck was asking about https://review.openstack.org/#/c/265396/15:43
sjmc7approved15:43
sjmc7TravT: take a look at the bottom of https://www.elastic.co/blog/elasticsearch-versioning-support15:43
sjmc7i think i may have done some work for nothing :)15:43
TravTok15:43
TravTis this what rosmaita was asking about in the spec reviews?15:45
sjmc7i don’t think so15:46
TravTso....15:46
TravTwith the versioning spec15:46
sjmc7well, obviously i didn’t think so because i didn’t know about this, so maybe. ‘garbage collection’ means many things15:46
sjmc7i think we don’t need the deletion work15:46
TravTin theory, all we have to do is adjust the gc_deletes time15:46
sjmc7right15:46
sjmc7i’ll test that today15:46
sjmc7i seem to be awesome at finding information long after it’d be useful15:47
TravTwell, glad you caught that now.15:47
sjmc7i need a time machine15:47
TravTmakes our code simpler15:47
TravTbetter make sure that didn't get deprecated in 2.0 though15:47
TravTES seems to like to deprecate useful things15:47
sjmc7yeah, i am15:47
sjmc7haha, they usually have reasons for doign so15:48
TravTusually perf related i think15:48
TravTok, i'm going to go eat a bite of breakfast. be back shortly15:49
openstackgerritMerged openstack/searchlight: Added Keystone and RequestID headers to CORS middleware  https://review.openstack.org/26539615:55
sjmc7looks like it is supported in 2.0. it doesn’t appear to be documented anywhere. it is mentioned in the migration tool as being a field that needs to have time units16:14
openstackgerritRick Aulino proposed openstack/searchlight: Zero Downtime Re-indexing changes.  https://review.openstack.org/27786016:20
sjmc7TravT: i’m pretty sure that’s the way to go. i guess we need to modify the spec - is it ok to submit a patch to the existing spec document? i’ll move any existing implementation details into the alternatives section16:37
TravTYeah, it is perfectly reasonable to amend a spec to bring it up to date.16:38
sjmc7ok. i’ll do another patch based of the versioning one (which we also need to try to close on)16:39
sjmc7lei had another question about image members; i don’t think we have access to the new updated_at time for the image16:40
TravTi just asked back in that patch...16:40
TravTis the image update date actually updated with membership changes?16:40
TravTor does it only change with properties changes16:40
sjmc7i haven’t checked yet16:41
TravTin glance i mean.16:41
*** bpokorny has joined #openstack-searchlight16:41
TravTi had a script for adding members and seem to have lost it16:41
TravTit is a two step process16:42
TravTso there may be two opportunities for the time to change16:42
sjmc7lovely16:42
TravT1) when you add a member16:42
TravT2) when the member accepts it16:42
TravTnot too hard.16:42
TravTi guess i could test it right now16:42
sjmc7i’ll do it16:42
TravTokey-dokey16:43
sjmc7TravT: looks like the image’s updated_at doesn’t change16:50
sjmc7but the member notification comes with an updated_at16:50
sjmc7so i think we can use that16:50
sjmc7for the versioning, at least16:50
TravTfor the version16:50
TravTbut we don't want to update the glance image / snapshot version16:50
sjmc7we’ll have so many edge conditions we’ll be able to make nice geometric shapes16:50
TravTversion --> updated_at16:51
TravTurghh16:51
sjmc7right16:51
sjmc7the version’ll be slightly different from updated_at16:51
sjmc7and i think that’s ok16:51
TravTyeah, i think it is okay16:51
sjmc7although… if an image update comes out of sync with a member one it’ll cause trouble16:51
TravThmmm16:51
sjmc7i don’t see a good way around this short of requesting that image member updates also affect the image timestamps16:52
TravTso then the version should be based on the image updated_at16:52
sjmc7and even then i guess that doesn’t really help16:52
sjmc7yeah.. maybe we can script image member updates16:53
sjmc7i don’t *think* they work with versioning16:53
sjmc7also an image update refreshes the full member list16:53
TravTi'm almost inclined to think that member updates should just take whatever last version is and increment by 116:53
sjmc7could also keep the same timestamp16:54
TravTyeah, was just trying to think about that...16:54
*** sigmavirus24 is now known as sigmavirus24_awa16:55
*** sigmavirus24_awa is now known as sigmavirus2416:56
sjmc7i don’t think there’s a way to deal with this correctly in every condition. our model’s different from glance's16:56
TravTi'm wondering if we'll hit other cases like this16:56
sjmc7undoubtedly16:58
TravTif we normalized docs (flavors into servers) this could also present issues17:00
TravTde-17:00
sjmc7yep17:01
sjmc7maybe parent-child is better for all these kinds of things17:01
sjmc7i’m not sure what the best answer is for now. i’m inclined to alter the image member notifications to run a scripted update and use the existing image update time17:08
sjmc7as the version17:08
TravTi'm just running debugger on code and looking at the notification17:11
sjmc7it has updated_at and created_at but for the image17:11
sjmc7sorry, for the member17:11
TravTmaybe child for member would be better17:11
sjmc7urgh. yeah, maybe17:11
TravTit would actually be faster, i think.17:11
TravTwouldn't require a retrieval17:11
TravTslower search17:12
sjmc7probably not significantly17:12
sjmc7and speed is less important than correct for us17:12
TravTbut i'm trying to think about the rammifications on queries17:12
sjmc7https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-has-child-query.html17:13
TravToh yeah17:13
TravTi run that quite a bit17:13
sjmc7weirdo17:13
sjmc7ok. for now, what can we do to unblock lei’s patch?17:13
sjmc7and consider switching members to parent/child separately17:13
TravTwell, i have to do things like point out that grandchildren aren't handled in code17:13
TravT:P17:13
sjmc7weirdo!17:13
TravTwhen I say queries, I mean this17:14
sjmc7i’m inclined to go with ignoring versioning for image member updates17:14
TravTalready with designate17:14
TravTthere are two different resource types17:14
TravTand so in the search panel right now it isn't handling them nicely17:14
TravTpartially because the ui is generic and it has no way to know about relationships ahead of time...17:15
sjmc7yes. it complicates things a lot on that end17:15
TravTand i've been trying to figure out (haven't put much thought into it) how to handle that better17:15
TravTmaybe our plugins API endpoint should list parent / children17:15
TravTbut with things like member17:16
TravTwhat are the access rights to that?17:16
TravTor if i search on an image id, will i get membership records... maybe that's desired, maybe not... probably based on context.17:16
sjmc7maybe we don’t expose members as a thing17:16
sjmc7yeah, i don’t know. denormalizing is vastly preferable for querying17:17
TravThmm... another thing, who is allowed to see members?17:20
TravTjust the image owner?17:20
sjmc7currently?17:20
TravTyeah17:20
sjmc7anyone who can see the image i think17:20
TravTi just tried it locally and realized my local debugger sent stuff into local elastic search and my API on VM picked up requests...17:20
TravTgot a little lost17:20
TravTbut that might be another case for members to be their own thing17:21
sjmc7we maybe need to post-filter the member list. or not expose it at all17:21
sjmc7ok. for now, what do we suggest lei do?17:21
TravTonly owner and admins see them...17:21
TravTrun away screaming17:21
TravT:D17:21
sjmc7i’m starting to feel that way17:21
TravTi'm pretty sure parent child would solve these technical issues on server side.17:22
TravTbut not sure on API side17:23
TravTneed to look at code17:23
TravTAPI side should show image if owner, public, or if requester in member list / accepted17:23
sjmc7maybe we don’t expose that at all on the API side; it bcomes something you go to the glance api for17:24
*** lakshmiS has joined #openstack-searchlight17:24
sjmc7there may be some cases it doesn’t make sense for us to deal with17:24
sjmc7but again: what do we have lei do with the versioning patch?17:24
TravTmembers are already handled in rbac17:24
sjmc7if we wait until we solve this, it won’t merge17:24
sjmc7because i don’t want to rush a patch in the next day or two17:25
* TravT looking through code17:25
TravT_get_rbac_field_filters(self, request_context):17:25
sjmc7my suggestion is when a member update is received, we always make the change, since ordering is not important, with a scripted update17:25
TravThandles part of it...17:25
TravTso right now, image just has members field17:28
TravT               "members": [17:28
TravT                  "ed6eb9c5d34441c280fc11f7367d2227"17:28
TravT               ],17:28
sjmc7yes17:28
TravTwhat if members actually had list of them as nested object but also had updated17:29
sjmc7i don’t know17:29
sjmc7what would updated matter?17:29
TravTso are you saying with scripted update that we only update member list?17:31
sjmc7yeah17:31
TravTi was still thinking that you could still hit a timing issue with that.17:31
sjmc7you might if you were adding and removing a particular member quickly and happened to manage to get out of date notifications, i suppose17:32
TravTi agree that member syncs should just update member fields.17:33
sjmc7adding a date won’t really help though; deletions will be hard to track17:33
sjmc7we’d need to keep deleted members around. i think it really requires some more thought, and i don’t want to hold up the versioning stuff on this17:33
TravTok, i'd be okay with changing to scripted update and have a follow on to see if this needs more done just for image members17:34
sjmc7the versioning patch already needs a rebase; maybe i can get something out today that changes it so it’s a separate change17:35
TravTi'll BRB, have to go do something.17:37
*** itisha has joined #openstack-searchlight17:55
openstackgerritSteve McLellan proposed openstack/searchlight-specs: Update deletion spec to use elasticsearch GC  https://review.openstack.org/27855418:16
openstackgerritTravis Tripp proposed openstack/searchlight: Add sample devstack local.conf  https://review.openstack.org/27855818:32
openstackgerritTravis Tripp proposed openstack/searchlight: Add sample devstack local.conf  https://review.openstack.org/27855818:34
*** sjmc7 has quit IRC18:34
*** TravT_ has joined #openstack-searchlight18:58
*** bpokorny_ has joined #openstack-searchlight18:59
*** bpokorny_ has quit IRC18:59
*** bpokorny_ has joined #openstack-searchlight19:00
*** TravT has quit IRC19:00
*** bpokorny has quit IRC19:02
*** sjmc7 has joined #openstack-searchlight19:03
*** TravT_ is now known as TravT19:16
*** bpokorny_ has quit IRC19:17
*** bpokorny has joined #openstack-searchlight19:18
*** krotscheck is now known as krotscheck_dcm19:47
*** briancline has quit IRC21:48
*** dhellmann has quit IRC21:48
*** dhellmann has joined #openstack-searchlight21:49
*** bpokorny has quit IRC21:56
*** TravT has quit IRC22:10
*** lakshmiS_ has joined #openstack-searchlight22:15
*** dhellmann has quit IRC22:22
*** lakshmiS has quit IRC22:22
*** dhellmann has joined #openstack-searchlight22:23
*** TravT has joined #openstack-searchlight22:29
*** lakshmiS_ has quit IRC22:31
*** sigmavirus24 is now known as sigmavirus24_awa22:53
*** bpokorny has joined #openstack-searchlight23:55

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!