| *** TravT has quit IRC | 00:13 | |
| *** TravT has joined #openstack-searchlight | 00:14 | |
| *** yingjun has joined #openstack-searchlight | 00:25 | |
| *** david-lyle has joined #openstack-searchlight | 00:42 | |
| *** bpokorny has quit IRC | 01:38 | |
| *** yingjun has quit IRC | 01:47 | |
| *** david-lyle has quit IRC | 02:05 | |
| *** yingjun has joined #openstack-searchlight | 02:41 | |
| *** lakshmiS has quit IRC | 02:43 | |
| *** david-lyle has joined #openstack-searchlight | 03:25 | |
| *** GB21 has joined #openstack-searchlight | 07:05 | |
| *** GB21 has quit IRC | 07:59 | |
| *** GB21 has joined #openstack-searchlight | 08:27 | |
| *** yingjun has quit IRC | 10:11 | |
| *** yingjun has joined #openstack-searchlight | 11:00 | |
| *** yingjun has quit IRC | 11:12 | |
| *** yingjun has joined #openstack-searchlight | 11:13 | |
| *** yingjun has quit IRC | 11:17 | |
| *** yingjun has joined #openstack-searchlight | 11:42 | |
| *** yingjun has quit IRC | 12:43 | |
| *** yingjun has joined #openstack-searchlight | 12:50 | |
| *** yingjun has quit IRC | 13:29 | |
| *** yingjun has joined #openstack-searchlight | 13:30 | |
| *** yingjun_ has joined #openstack-searchlight | 13:34 | |
| *** yingjun has quit IRC | 13:34 | |
| *** yingjun has joined #openstack-searchlight | 13:37 | |
| *** yingjun_ has quit IRC | 13:38 | |
| *** yingjun has quit IRC | 14:01 | |
| *** yingjun has joined #openstack-searchlight | 14:10 | |
| *** yingjun has quit IRC | 14:26 | |
| *** yingjun has joined #openstack-searchlight | 14:32 | |
| *** yingjun has quit IRC | 14:45 | |
| *** RickA-HP has joined #openstack-searchlight | 14:58 | |
| *** yingjun has joined #openstack-searchlight | 14:59 | |
| TravT | hello | 15:00 |
|---|---|---|
| yingjun | hi | 15:01 |
| sjmc7 | morning | 15:01 |
| rosmaita | RickA-HP: will you be insulted if i begin referring to you as "mr. erudite" ? | 15:01 |
| rosmaita | o/ | 15:01 |
| RickA-HP | Good morning/evening | 15:01 |
| sjmc7 | :D | 15:01 |
| RickA-HP | :) | 15:01 |
| TravT | how is everybody doing today | 15:01 |
| TravT | ? | 15:01 |
| RickA-HP | Not too bad for 8:00am! | 15:02 |
| rosmaita | another snow day here, so wfh | 15:02 |
| TravT | i wasn't sure if lakshmiS would make it... | 15:02 |
| TravT | still a bit early in California and I think he has to get his kids to school | 15:03 |
| TravT | nikhil: david-lyle: FYI we're gonna be talking specs right now | 15:03 |
| TravT | Allright, let's start with what I hope is an easier one. | 15:04 |
| RickA-HP | :) | 15:05 |
| TravT | The notification forwarding one. It already has 3 +2's and a +1 from Fei Long who is the zaqar PTL. | 15:05 |
| TravT | https://review.openstack.org/#/c/246220/ | 15:05 |
| TravT | unless there are any objections, i was going to go ahead an +A it. | 15:05 |
| rosmaita | looks like work is already underway on it | 15:06 |
| RickA-HP | It looked good to me | 15:07 |
| TravT | Yes there is an initial patch up | 15:07 |
| TravT | https://review.openstack.org/#/c/271958/ | 15:07 |
| TravT | which is very early | 15:07 |
| TravT | but it is good to see progress | 15:07 |
| TravT | Okay, going once | 15:08 |
| rosmaita | i don't see any reason not to approve, unless there's a question of reviewer bandwith or something | 15:08 |
| TravT | well, there's always some question of reviewer bandwidth, but I'd rather get this in prior to going to 1.0 with searchlight. | 15:09 |
| TravT | before we have to take deprecation more seriously | 15:09 |
| rosmaita | good point | 15:09 |
| TravT | ok going twice | 15:09 |
| rosmaita | let's do it | 15:09 |
| TravT | Sold to the man from Pennsylvania | 15:09 |
| TravT | ok, +A applied | 15:10 |
| *** sigmavirus24_awa is now known as sigmavirus24 | 15:11 | |
| TravT | ok, so now on to the zero downtime: | 15:12 |
| TravT | https://review.openstack.org/#/c/245222/ | 15:12 |
| openstackgerrit | Merged openstack/searchlight-specs: This BP is implementing a notification-forwarding for SearchLight index https://review.openstack.org/246220 | 15:13 |
| TravT | RickA-HP: I added some comments, but they are mostly just minor cleanup items. | 15:14 |
| sjmc7 | i need to go through the current patchset | 15:14 |
| rosmaita | me too | 15:14 |
| TravT | so, want to take 10 - 15 minutes now and we'll pick chat up? | 15:15 |
| RickA-HP | TravT: I saw your comments. I was waiting for more before cleaning up and submitting a new patchset. | 15:15 |
| rosmaita | TravT: +1 | 15:16 |
| *** yingjun has quit IRC | 15:22 | |
| *** david-lyle_ has joined #openstack-searchlight | 15:27 | |
| sjmc7 | TravT, RickA-HP : https://www.elastic.co/guide/en/elasticsearch/reference/1.7/indices-aliases.html#filtered (the line before that section header) throws a wrench in the works | 15:34 |
| TravT | reading | 15:34 |
| RickA-HP | Hmmmm.... | 15:35 |
| TravT | ok, this is the filtered aliases we discussed before possibly as part of role based filtering (but you didn't use) | 15:35 |
| sjmc7 | above that | 15:35 |
| *** yingjun has joined #openstack-searchlight | 15:35 | |
| sjmc7 | the sentence before the section header | 15:35 |
| sjmc7 | “It is an error to index to an alias which points to more than one index." | 15:35 |
| TravT | ooh | 15:35 |
| sjmc7 | gonna do a quick test | 15:36 |
| RickA-HP | Is this referring to the glob pattern for specifying multiple indexes? | 15:37 |
| sjmc7 | don’t think so, checking | 15:37 |
| TravT | that seems extraordinarily odd | 15:37 |
| TravT | given that above that it explicitly talk about adding multiple indexes to an alias | 15:37 |
| sjmc7 | the common use for aliases is for logstash type applications | 15:38 |
| RickA-HP | It seems that they are implying that multiple indexes in an alias is to be use only for querying. | 15:38 |
| sjmc7 | where you’re using them to search | 15:38 |
| sjmc7 | they’re not implying it :) | 15:38 |
| TravT | would this just mean that the listeners and sync job would just retrieve the indexes in an alias and then push to both indexes directly | 15:38 |
| sjmc7 | could do. that introduces a race condition | 15:39 |
| TravT | anything we can do to avoid all the overhead i originally put in the spec (now in the alternatives sections) | 15:39 |
| sjmc7 | curl localhost:9200/test-alias/test-type/1 -XPUT '{"a": "b"}' | 15:40 |
| sjmc7 | {"error":"ElasticsearchIllegalArgumentException[Alias [test-alias] has more than one indices associated with it [[test-2, test-1]], can't execute a single index op]","status":400} | 15:40 |
| TravT | allright, back to the drawing board! | 15:40 |
| sjmc7 | yeah, sorry :( i should’ve thought to check earlier | 15:41 |
| RickA-HP | Steve, good catch! | 15:41 |
| sjmc7 | better late than later | 15:41 |
| * TravT seems to remember discussion between us of running this test a month ago | 15:41 | |
| rosmaita | that is a ... bummer | 15:41 |
| TravT | so, alias switching is still required | 15:42 |
| sjmc7 | it is a bit. the good news is it’d raise an error :) | 15:42 |
| TravT | we just can't publish to the alias | 15:42 |
| sjmc7 | the brute-force method would be to pull the index names out of the error and retry... | 15:42 |
| TravT | yes, the could serve as the communication mechanism I suppose. | 15:43 |
| sjmc7 | might be safer than a half-assed home-grown solution for a case tht’s in use for a tiny percentage of time | 15:43 |
| TravT | sync job adds the multiple indexes | 15:43 |
| TravT | error trapped | 15:43 |
| RickA-HP | Or the listener would have two aliases, one corresponding to the old index and one to the new index. | 15:43 |
| TravT | publishes to all indexes | 15:43 |
| sjmc7 | though you know me, i LOVE half-assed homegrown solutions | 15:43 |
| RickA-HP | Once again, Searchlight would manage the aliases. | 15:43 |
| TravT | RickA-HP, that gets back to the alternative section | 15:44 |
| sjmc7 | and it’d publish to both aliases? | 15:44 |
| sjmc7 | i think actually the error trapping is simplest/safest, if not terribly elegant | 15:44 |
| RickA-HP | Travis, maybe it's time we rename the "alternative" section! | 15:44 |
| TravT | we have to either put APIs and a bunch of management communication on talking to them | 15:45 |
| TravT | or try to do something like error trapping | 15:45 |
| rosmaita | i'm with sjmc7 on the error trapping approach | 15:45 |
| sjmc7 | it’s times like this i really miss Visual Basic’s On Error Resume Next | 15:45 |
| TravT | which I don't think is that bad | 15:45 |
| sjmc7 | everything was so much simpler | 15:45 |
| sjmc7 | yeah, ruminate on it | 15:45 |
| sjmc7 | other than that i have a few minor nits, but mostly looks good | 15:46 |
| sjmc7 | and kind of agree it looks like a patent application :) | 15:46 |
| TravT | sjmc7: except Exception: pass | 15:46 |
| rosmaita | RickA-HP: did you do the diagrams? nice work | 15:47 |
| sjmc7 | OERN was like a global version of that. it was glorious | 15:47 |
| sjmc7 | try: <do everything> except: pass | 15:47 |
| sjmc7 | yeah, the diagrams are nice | 15:47 |
| TravT | sjmc7: ES docs say it is atomic | 15:48 |
| TravT | Renaming an alias is a simple remove then add operation within the same API. This operation is atomic, no need to worry about a short period of time where the alias does not point to an index: | 15:48 |
| sjmc7 | ah, my mistake - i thought it was like bulk indexing | 15:49 |
| sjmc7 | man, i’m off form today | 15:49 |
| TravT | i'd say you are quite on form, finding that little tidbit in the docs about aliases | 15:49 |
| sjmc7 | think i’m batting about 0.100 for the morning! | 15:50 |
| TravT | okay, my vote is for switching this up a bit to use error trapping... would be nice to optimize it somehow, but that's something Rick can explore in code | 15:52 |
| TravT | not sure you'd have anything faster than ES giving an instant response of more than one index in an alais | 15:52 |
| sjmc7 | nope | 15:53 |
| TravT | the error includes the indexes | 15:53 |
| sjmc7 | right. i don’t think it’s that ugly | 15:53 |
| TravT | so no additional query needed | 15:53 |
| rosmaita | just need to hope no one "optimizes" the error message upstream | 15:53 |
| sjmc7 | :D that’d be unfortunate | 15:54 |
| *** GB21 has quit IRC | 15:54 | |
| RickA-HP | Or changes the format of the error messages. | 15:54 |
| TravT | what are you talking about? error messages and APIs never change | 15:54 |
| TravT | ;) | 15:54 |
| rosmaita | anyway, i like the plan | 15:54 |
| * TravT glares at rosmaita for trying to throw more monkey wrenches into our hacking | 15:54 | |
| * rosmaita is glare-proof | 15:55 | |
| TravT | time for a beer, gentleman | 15:55 |
| rosmaita | besides, we don't index Glare yet, do we? | 15:55 |
| TravT | no, what is the status on that anyway? | 15:55 |
| TravT | glare, that is | 15:55 |
| sjmc7 | and puns | 15:55 |
| rosmaita | it's going to be its own endpoint, i think | 15:56 |
| RickA-HP | Maybe there is another apporach. What if the search alias had multiple indexes and the listener alias only has the "new" index. | 15:56 |
| TravT | RickA-HP: please expand? | 15:56 |
| RickA-HP | Let me get it straight in my mind first :) | 15:57 |
| RickA-HP | The Glance listener starts indexing into indexA. The Glance search is querying indexA. | 15:58 |
| RickA-HP | When we get a reindex request for Glance, the GLance listener switches to a new index indexB. | 15:58 |
| RickA-HP | The Glance search will now query on IndexA and IndexB. | 15:59 |
| sjmc7 | then you’ll get two results for everything? | 15:59 |
| TravT | you'd have duplicate results | 15:59 |
| RickA-HP | Is there a way to filter out dups? | 15:59 |
| TravT | and if we are re-indexing because A contains things that should have been deleted | 15:59 |
| TravT | you'll still get the things in A that should not be returned | 16:00 |
| *** yingjun has quit IRC | 16:00 | |
| TravT | as a note the docs should have the same ID | 16:00 |
| TravT | so maybe they'd filter out | 16:00 |
| sjmc7 | nope, it’d give you both | 16:00 |
| TravT | because diff index? | 16:00 |
| sjmc7 | yep | 16:00 |
| RickA-HP | We would still get the deleted docs in indexA with our current solution. | 16:00 |
| TravT | true | 16:01 |
| *** GB21 has joined #openstack-searchlight | 16:01 | |
| TravT | we'd have to filter all results for dupes | 16:01 |
| TravT | and prefer results from new index | 16:01 |
| TravT | rick that isn't quite true if listener is going to both on deletions | 16:02 |
| TravT | if listener is still going to both, then deletes would be removed in A | 16:03 |
| TravT | unless your deletion journal concept goes in | 16:03 |
| TravT | and the filtering includes handling that filtering as well | 16:03 |
| TravT | (deleted doc in index B means filter out of results from index A) | 16:04 |
| TravT | this seems a little fragile. | 16:04 |
| RickA-HP | Yes, it seems overly complicated. | 16:04 |
| TravT | i think it is good idea to put some into the alternative section at least | 16:04 |
| RickA-HP | It feels like defects are just waiting to be written with this approach. | 16:04 |
| TravT | by the way, i like that you brought up an inverse idea | 16:05 |
| TravT | for consideration | 16:05 |
| TravT | ok, so I guess Rick will publish updates to the spec today. if any other grand idea comes up, we'll go over it. | 16:06 |
| *** yingjun has joined #openstack-searchlight | 16:06 | |
| rosmaita | sounds good! | 16:06 |
| TravT | will look for that, but let's also talk about deletion journal | 16:06 |
| RickA-HP | We're over time for the meeting. Should we still continue or schedule another meeting to discuss deletions. | 16:06 |
| TravT | do you all still have a little time? | 16:07 |
| rosmaita | yes, let's keep going | 16:07 |
| sjmc7 | let’s do the deletions one since there was some confusion | 16:07 |
| TravT | yingjun: sorry it is late for you | 16:07 |
| RickA-HP | I have time to continue the discussion. | 16:07 |
| TravT | if you need to drop, we understand | 16:07 |
| TravT | the irc room is logged so you can catch up if needed | 16:07 |
| TravT | https://review.openstack.org/#/c/269783/ | 16:07 |
| rosmaita | +1 for deletions spec | 16:08 |
| rosmaita | and sorry for the confusion | 16:08 |
| TravT | rosmaita: no need to be sorry at all. very much appreciate calling out questions. | 16:09 |
| sjmc7 | itwas good to clarify it | 16:09 |
| RickA-HP | Yes, if it was confusing it could have meant that it was incomplete. | 16:09 |
| TravT | i actually found myself confused yesterday trying to remember why it was needed | 16:10 |
| TravT | as evidenced by my current comments on it | 16:10 |
| RickA-HP | We also uncovered some subtleties in the design that need careful thought when implementing. | 16:11 |
| rosmaita | so what's really weird is that a PUT to a deleted doc can re-create it? | 16:11 |
| rosmaita | or am i completely misunderstanding? | 16:11 |
| sjmc7 | rosmaita: yeah, because we use the openstack id for documents | 16:11 |
| rosmaita | gotcha | 16:11 |
| sjmc7 | to avoid having to remove old copies on updates/deletes | 16:12 |
| sjmc7 | it’s always a problem in eventually-consistent systems | 16:13 |
| sjmc7 | or rather, it’s always a problem with asynchronous operations | 16:14 |
| sjmc7 | i think even if we were using SQL we’d have to do this because we’ll never guarantee we process everything every event order, even if we receive them in order | 16:14 |
| RickA-HP | Are there any unresolved issues with this spec (as opposed to some more clean up)? | 16:15 |
| TravT | Well, i think my comment on line 54 is a case that SQL, nosql, anything can't handle on its own | 16:15 |
| rosmaita | i'm a bit vague on how the TTL will be coordinated with the reindexing | 16:15 |
| TravT | the fact you have multiple processes using different routes (one via API callbacks and one via notifications) to get data | 16:16 |
| *** yingjun has quit IRC | 16:16 | |
| TravT | Rick, re-reading | 16:17 |
| TravT | but where does it catch the fact that we actually STORE deleted documents | 16:17 |
| TravT | e.g. we get a deleted document and we actually need to store it and set it to deleted | 16:18 |
| TravT | with TTL | 16:18 |
| TravT | without that, I don't see how it handles the race condition. | 16:18 |
| *** david-lyle_ has quit IRC | 16:18 | |
| rosmaita | i wonder whether instead of deleted: true it would be worth having deleted: version-num-of-doc-when-deleted | 16:19 |
| sjmc7 | the deleted doc’s version will still get updated. but yeah, we could do that. i don’t think it’d make querying much more expensive (test for the presence/absence of the field) | 16:20 |
| sjmc7 | what would we gain, rosmaita ? | 16:20 |
| rosmaita | sjmc7: not sure | 16:20 |
| sjmc7 | actually, that is a point; on a deletion, we’ll no longer be able to generate a version (timestamp) | 16:21 |
| TravT | can i -1 RickA-HP for using funny and appropriate phrases that I have to google? | 16:21 |
| rosmaita | i think nova uses the epoch time for the 'deleted' column in the databases | 16:21 |
| rosmaita | TravT: no, but you can call him "mr. erudite" | 16:22 |
| TravT | ok, maybe we can vote that he has to change his irc nick to that | 16:22 |
| sjmc7 | i’m not sure how much information we get in notifications. maybe i’m misremembering; it’d make sense if we got a notification that included the time | 16:22 |
| *** GB21 has quit IRC | 16:23 | |
| TravT | i'm not opposed to the deleted field having more info if we have it | 16:25 |
| sjmc7 | we have to have the info; we need to supply a version number | 16:25 |
| TravT | maybe filtering is faster if it is only a boolean? | 16:26 |
| * TravT just trying to think of pros / cons | 16:26 | |
| rosmaita | yeah, i'm a "just in case" kind of guy, but there's no sense having extra overhead if we don't really need it | 16:26 |
| sjmc7 | can use an existence check. i dont’ think that’d be a significant concern. i’m more worried we don’t have enough information to put the right version on ‘deleted’ docs. i’d need to look at the notificaitons | 16:27 |
| RickA-HP | I was starting to look at notifications, but it will take longer than this meeting. | 16:27 |
| RickA-HP | It sounds like there is still some investigation needed for the delete field. | 16:28 |
| TravT | existence check would work no matter what is stored. | 16:29 |
| rosmaita | i have to drop for next 1/2 hour | 16:29 |
| TravT | RickA-HP: i don't feel like what is actually stored in the field is worth holding up the BP over... more concerned on just a bit more clarity, on the use case.. | 16:29 |
| RickA-HP | Ok | 16:30 |
| sjmc7 | right, i think that’s an implementation thing | 16:30 |
| sjmc7 | i do think it’s worth making sure we can correctly assigna version to ‘deleted’ docs, since it doesn’t work if we can't | 16:31 |
| TravT | ideally, it would be best to use explain it in the first paragraph or so in the least amount of words as possible. | 16:31 |
| sjmc7 | starting to wonder if there’s a timestamp rabbitmq assigns we can use instead of anything specific to the resource | 16:32 |
| TravT | which I think might be done in the problem description section | 16:32 |
| sjmc7 | anywho | 16:32 |
| TravT | sjmc7: i think we had those questions on the review from lei | 16:32 |
| TravT | need to check that | 16:32 |
| TravT | oslo timestamp | 16:32 |
| TravT | https://review.openstack.org/#/c/255751/ | 16:33 |
| TravT | ok, so, it seems like just a few minor updates to the deletion spec and it should be good to g | 16:33 |
| RickA-HP | TravT: I'll update the problem description to be more focused on zero downtime. | 16:34 |
| TravT | no more nitpicks after next update. only "THIS CAN'T BE DONE" kind of comments. Everybody agree to that? | 16:34 |
| RickA-HP | I do :) | 16:34 |
| sjmc7 | yeahyep | 16:34 |
| rosmaita | ok | 16:34 |
| RickA-HP | I'll update both the zero downtime and deletion specs today and push them out this afternoon. | 16:34 |
| TravT | cool, thanks guys. Great focus. | 16:34 |
| TravT | sjmc7: I'll try to dig more into the role based patch today | 16:35 |
| TravT | started yesterday | 16:35 |
| TravT | lots of files | 16:35 |
| sjmc7 | so many files | 16:35 |
| RickA-HP | What other reviews do need more attention? | 16:35 |
| TravT | https://review.openstack.org/#/c/257516/ | 16:35 |
| TravT | rosmaita: sjmc7: we should probably just push the global requirements patches through. | 16:36 |
| sjmc7 | yeah | 16:37 |
| TravT | I'll also test out this one: https://review.openstack.org/#/c/267881/ | 16:37 |
| rosmaita | TravT: ok | 16:38 |
| TravT | RickA-HP: this URL should help you | 16:38 |
| TravT | https://review.openstack.org/#/q/project:%255E.*searchlight.*+status:open,n,z | 16:38 |
| TravT | All right guys, thanks for the time this morning. | 16:38 |
| RickA-HP | TravT: Travis, yeah I know the open reviews, I was just wondering if there were some higher priority than others. | 16:39 |
| TravT | Steve' role based one is highest priority | 16:40 |
| sjmc7 | ALL my patches are the highest priority! | 16:48 |
| TravT | sjmc7: actually at least 3 of them are... | 16:49 |
| sjmc7 | but yes, that one has ramifications in other places | 16:49 |
| TravT | three cheers to lakshmi, made progress on the glance notifications | 16:49 |
| TravT | https://review.openstack.org/#/c/221307/ | 16:49 |
| sjmc7 | https://review.openstack.org/#/c/267864/ is a little simpler but is sort of a dependency for other plugins | 16:49 |
| sjmc7 | ah, nice | 16:49 |
| TravT | he's not here to receive the cheers | 16:49 |
| TravT | :( | 16:49 |
| *** RickA-HP has quit IRC | 16:50 | |
| sjmc7 | he snoozed and losed | 16:50 |
| sjmc7 | or did real life things, like taking children to school | 16:50 |
| *** lakshmiS has joined #openstack-searchlight | 16:59 | |
| *** RickA-HP has joined #openstack-searchlight | 17:01 | |
| *** bpokorny has joined #openstack-searchlight | 17:06 | |
| *** openstackgerrit has quit IRC | 17:17 | |
| *** openstackgerrit has joined #openstack-searchlight | 17:18 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 17:59 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 18:03 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 18:04 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/searchlight: Updated from global requirements https://review.openstack.org/271652 | 18:14 |
| openstackgerrit | Lakshmi N Sampath proposed openstack/searchlight: WIP - Swift plugin Pending RBAC and Code tuning. https://review.openstack.org/271622 | 18:33 |
| sjmc7 | lakshmiS: middleware’s going to be problematic for swift notifications. if you POST metadata, any existing metadata won’t be visible short of loading the objects from the metadata store. i’ll see how difficult it would be to inject notifications into the swift code itself | 18:50 |
| lakshmiS | hmm | 18:55 |
| lakshmiS | in the worst case i can do incremental metadata update by lookup from es first | 18:56 |
| *** sigmavirus24_awa is now known as sigmavirus24 | 18:57 | |
| sjmc7 | i’ll see how tough it would be to do the notifications inside swift, like other services do | 19:03 |
| lakshmiS | i find it easier to create notifications from inside a service; atleast in the case of glance | 19:14 |
| sjmc7 | the plumbing was mostly there in glance | 19:25 |
| sjmc7 | and also middleware’s easily installable if it’s not in-tree | 19:25 |
| *** bpokorny_ has joined #openstack-searchlight | 19:30 | |
| *** bpokorny_ has quit IRC | 19:31 | |
| *** RickA-HP has quit IRC | 19:31 | |
| *** bpokorny_ has joined #openstack-searchlight | 19:31 | |
| sjmc7 | yeah, maybe stick with updating metadata | 19:33 |
| *** bpokorny has quit IRC | 19:34 | |
| lakshmiS | ok | 19:36 |
| TravT | lakshmiS: great job on the metadef notifications | 20:10 |
| TravT | 12:33 openstackgerrit: Merged openstack/glance: Fix for Image members not generating notifications https://review.openstack.org/221307 | 20:10 |
| TravT | 12:36 flaper87: lakshmiS: TravT ^ | 20:10 |
| TravT | 12:36 flaper87: sorry it took so long | 20:10 |
| *** nikhil has quit IRC | 20:27 | |
| *** nikhil has joined #openstack-searchlight | 20:28 | |
| lakshmiS | yeah finally. thanks to glance team | 20:41 |
| openstackgerrit | Travis Tripp proposed openstack/searchlight: Added Keystone and RequestID headers to CORS middleware https://review.openstack.org/265396 | 20:50 |
| TravT | krotscheck: I'll probably regret asking you this because I have to join a meeting in 2 minutes and won't be around, but maybe you can help me out here. | 20:58 |
| TravT | getting a CORS error when going against searchlight on local host | 20:59 |
| TravT | http://paste.openstack.org/show/485077/ | 20:59 |
| TravT | (POSTMAN) -> Searchlight (localhost) -> ElasticSearch on VM @ 192.168.200.200 | 21:00 |
| TravT | That fials | 21:00 |
| TravT | fails | 21:00 |
| TravT | with the error I pasted | 21:00 |
| TravT | Any ideas? | 21:00 |
| sjmc7 | lakshmiS: stuffed the swift middleware up at https://github.com/sjmc7/swift-messaging-middleware | 21:03 |
| lakshmiS | ok thanks | 21:04 |
| *** RickA-HP has joined #openstack-searchlight | 21:09 | |
| sjmc7 | also lakshmiS , i’ve changed my mind - i’d be ok merging the swift indexing patch before notifications if it makes it easier to test/review | 21:24 |
| sjmc7 | as long as we get the notifications in by mitaka | 21:24 |
| *** bpokorny_ has quit IRC | 21:26 | |
| *** bpokorny has joined #openstack-searchlight | 21:27 | |
| *** bpokorny has quit IRC | 21:28 | |
| *** bpokorny has joined #openstack-searchlight | 21:29 | |
| lakshmiS | good to see searchlight is python3 compatible at https://wiki.openstack.org/wiki/Python3#Other_OpenStack_Applications_and_Projects | 21:35 |
| sjmc7 | :) | 21:35 |
| sjmc7 | yep, test run in 3.4 | 21:35 |
| *** lakshmiS has quit IRC | 22:19 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 23:28 | |
| *** lakshmiS has joined #openstack-searchlight | 23:30 | |
| openstackgerrit | Rick Aulino proposed openstack/searchlight-specs: Zero Downtime Reindexing Proposal https://review.openstack.org/245222 | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!