| *** lakshmiS_ has joined #openstack-searchlight | 00:02 | |
| *** lakshmiS has quit IRC | 00:04 | |
| *** bpokorny_ has quit IRC | 00:33 | |
| *** bpokorny has joined #openstack-searchlight | 00:33 | |
| *** lakshmiS_ has quit IRC | 01:23 | |
| *** bpokorny_ has joined #openstack-searchlight | 02:30 | |
| *** bpokorny_ has quit IRC | 02:31 | |
| *** bpokorny has quit IRC | 02:33 | |
| *** bpokorny has joined #openstack-searchlight | 04:09 | |
| *** GB21 has joined #openstack-searchlight | 05:19 | |
| *** GB21 has quit IRC | 05:25 | |
| *** GB21 has joined #openstack-searchlight | 05:38 | |
| *** bpokorny has quit IRC | 06:12 | |
| *** GB21 has quit IRC | 08:04 | |
| *** TravT has quit IRC | 08:07 | |
| *** TravT has joined #openstack-searchlight | 08:09 | |
| *** GB21 has joined #openstack-searchlight | 09:32 | |
| *** GB21 has quit IRC | 10:12 | |
| *** GB21 has joined #openstack-searchlight | 10:12 | |
| *** GB21 has quit IRC | 10:23 | |
| *** GB21 has joined #openstack-searchlight | 10:24 | |
| *** GB21 has quit IRC | 11:51 | |
| *** openstackgerrit_ has joined #openstack-searchlight | 12:39 | |
| *** openstackgerrit_ has quit IRC | 13:56 | |
| openstackgerrit | Rick Aulino proposed openstack/searchlight: Zero Downtime Re-indexing changes. https://review.openstack.org/277860 | 14:46 |
|---|---|---|
| *** sjmc7 has joined #openstack-searchlight | 15:02 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 15:07 | |
| *** nikhil_ has joined #openstack-searchlight | 15:55 | |
| *** nikhil_ is now known as Guest33449 | 15:56 | |
| *** nikhil is now known as nikhil_k | 15:56 | |
| *** Guest33449 is now known as nikhil | 15:56 | |
| sjmc7 | TravT: got a sec? it can wait if you’re in the middle of something | 16:17 |
| TravT | hey sjmc7 | 16:31 |
| sjmc7 | this will be quick but require brainpower so if you’re doing something else, finish it | 16:32 |
| TravT | ok, give me a few minutes then... i'm in the middle of a -1 on something with magic search | 16:33 |
| *** bpokorny has joined #openstack-searchlight | 16:42 | |
| *** bpokorny has quit IRC | 16:45 | |
| *** bpokorny has joined #openstack-searchlight | 16:45 | |
| TravT | hey sjmc7 | 16:49 |
| sjmc7 | hey | 16:53 |
| sjmc7 | sorry, got caught up in an email. on https://review.openstack.org/#/c/255751, was just going through the math again on the size of numbers we’ll use for verisoning | 16:57 |
| sjmc7 | did we agree we were ok going above the javascript max? | 16:57 |
| *** lakshmiS_ has joined #openstack-searchlight | 16:59 | |
| *** lakshmiS_ has quit IRC | 17:00 | |
| *** lakshmiS has joined #openstack-searchlight | 17:07 | |
| sjmc7 | and i’m not sure the arithmetic in your comment on dec 11th is right about the notification timestamps. if we use the right 9 digits, three of those are milliseconds and can be ignored; of the rest, we have 5 digits at second precision (the 6th we can’t rely on because we truncate the MSD) which gives us i think 27 hours of tiebreaker precision | 17:15 |
| sjmc7 | that’s probably fine, but i want to make sure it’s documented | 17:15 |
| TravT | sjmc7: sorry, didn't see this. | 17:19 |
| TravT | sjmc7, i wouldn't get rid of milliseconds | 17:21 |
| TravT | i'd get rid on the left | 17:22 |
| TravT | rather than right | 17:22 |
| sjmc7 | yes - we use the right 9 digits | 17:22 |
| sjmc7 | but you can’t treat those as seconds for the purposes of calculating time | 17:22 |
| TravT | i treated them as milliseconds i thought | 17:23 |
| TravT | https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&es_th=1&ie=UTF-8#q=854366000%20milliseconds%20in%20hours&es_th=1 | 17:23 |
| TravT | is the notification timestamp only in seconds? | 17:24 |
| TravT | at the time, we thought it might have milliseconds | 17:24 |
| sjmc7 | you can’t use all 9 digits either | 17:24 |
| sjmc7 | we’re discarding the most significant digit | 17:24 |
| sjmc7 | so it’ll roll over from <something>999999 to <something+1>000000 | 17:24 |
| -openstackstatus- NOTICE: Gerrit is restarting now, to alleviate current performance impact and WebUI errors. | 17:25 | |
| sjmc7 | it’s only correct to treat the 5 right-most digits as useful | 17:25 |
| sjmc7 | i think | 17:25 |
| TravT | i'm not sure i'm on the same page with you. | 17:25 |
| TravT | which digits are you talking about? | 17:25 |
| TravT | the notification timestamp? | 17:25 |
| sjmc7 | yes | 17:25 |
| TravT | what is its format? | 17:25 |
| sjmc7 | we take str(ts.seconds) + str(ts.millseconds) | 17:26 |
| sjmc7 | giving us a big number | 17:26 |
| sjmc7 | then we take the right-most 9 digits | 17:26 |
| sjmc7 | giving us 6 digits of seconds plus 3 of millis | 17:26 |
| TravT | just a sec, i'm looking at code in patch | 17:27 |
| sjmc7 | treating the whole thing as milliseconds, we have 9 digits of them (which is somewhere around 270 hours) | 17:29 |
| TravT | (update date) vs (timestamp) is critical information to | 17:29 |
| sjmc7 | yes, this is just the tiebreaker | 17:29 |
| sjmc7 | and i don’t think there’s a problem but i want the math in the comments, which is why i want to make sure it’s right | 17:29 |
| sjmc7 | the update time is all good, and that’ll be in seconds | 17:29 |
| TravT | lets see | 17:30 |
| sjmc7 | we strip off one digit, which still leaves a precision of many years | 17:30 |
| sjmc7 | for the tiebreaker though, i think of those 9 digits of milliseconds, only 8 of them are valid for comparison | 17:31 |
| sjmc7 | which gives around a day | 17:31 |
| sjmc7 | and that’s probably fine because it’s only meant for temporary race conditions | 17:31 |
| TravT | current epoch in seconds is 1455039132 and in milliseconds is 1455039132517 | 17:32 |
| sjmc7 | yep | 17:32 |
| TravT | 9 digits in seconds is: 455039132 which is 126399 hours | 17:33 |
| sjmc7 | yes, but we’re not using 9 digits | 17:34 |
| TravT | 9 digits in milliseconds is 039132517 which is 10 hours | 17:34 |
| sjmc7 | right | 17:34 |
| TravT | it seem like we should use less digits from the seconds (updated dt) and more from the milliseconds (timstamp) | 17:35 |
| sjmc7 | we’re currently using 9 digits from updated_at plus 9 from timestamp | 17:35 |
| sjmc7 | using less from updated_at will land us in trouble quickly i think | 17:36 |
| TravT | 10 digits from timestamp would give us 1,399 hours | 17:36 |
| TravT | 8 digits from seconds would give us 15288 hours | 17:37 |
| sjmc7 | i’m not sure that’s right | 17:38 |
| TravT | ok, well, i just used the google converter | 17:39 |
| sjmc7 | with 8 digits, we get up to 1499999999 before it ticks over and we get all 0s | 17:39 |
| TravT | maybe we should spreadsheet it | 17:39 |
| sjmc7 | to 1500000000 | 17:40 |
| TravT | that rolloer. | 17:40 |
| sjmc7 | that comes in 2017 | 17:40 |
| TravT | hadn't considered that | 17:40 |
| TravT | y2k17 bug? | 17:40 |
| sjmc7 | and it’s the same thing with the timestamp, hence my question :) | 17:40 |
| sjmc7 | yeah | 17:40 |
| sjmc7 | so we need 9 for the updated_at | 17:40 |
| sjmc7 | which gives us a Y2k33 bug and is probably fine | 17:41 |
| TravT | if we're still working on this in y2k33, we should be thankful to have that kind of job security | 17:41 |
| sjmc7 | and 9 digits from the TS gives 27 or so hours | 17:41 |
| sjmc7 | right | 17:41 |
| sjmc7 | so given that, are we ok with it? i’ll ask lei to put the numbers in the docs | 17:41 |
| sjmc7 | and given all THAT are we ok that our timestamps are above what javascript can use? | 17:42 |
| sjmc7 | i don’t know why we’d care but it did come up | 17:42 |
| TravT | so, this is still the 9 + 9 i put in original comment or did something change. | 17:44 |
| TravT | i think aliens just abducted my brain for 2 seconds | 17:44 |
| sjmc7 | it’s still 9+9 but the reasoning wasn’t right | 17:44 |
| sjmc7 | and while i think it’s still ok i’m asking lei to be explicit with the numbers | 17:44 |
| sjmc7 | so nobody else spends 30 minutes dividing things by 3600 :) | 17:44 |
| TravT | https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&es_th=1&ie=UTF-8#safe=active&q=999999999+milliseconds+in+hours | 17:45 |
| TravT | i'm not confusing myself on how much leeway that gives us | 17:45 |
| TravT | the "27 hours" is just some spot representation of time | 17:45 |
| sjmc7 | 1499999999 -> 1500000000 | 17:45 |
| TravT | right, that gives us quite awhile... | 17:46 |
| TravT | i'm talking about the timestamp (tiebreaker) | 17:46 |
| sjmc7 | yes. | 17:46 |
| TravT | i think it is still as best we can do... | 17:47 |
| TravT | re: javascript | 17:47 |
| sjmc7 | one update on may 17th 2017 at 21:39:59 will look like it came after one at 22:40:00 on the same day | 17:48 |
| sjmc7 | i think i’m confusing myself now though | 17:48 |
| sjmc7 | so i’m gonna stop | 17:48 |
| TravT | i don't know what to do about version in javascript or if we should care | 17:50 |
| sjmc7 | let’s not care | 17:50 |
| sjmc7 | job done! | 17:50 |
| TravT | what's this about may 17, 2017? | 17:51 |
| TravT | is that when we go back to the future? | 17:51 |
| sjmc7 | no.. i’m trying to say that the 277 hour number is not reliable. but i think we’ll have to agree to disagree | 17:51 |
| sjmc7 | and in any case i’m not sure it matters as long as it’s more than a few hours | 17:52 |
| TravT | i'm not disagreeing | 17:52 |
| TravT | this kind just needs to be written out clearly, like you said. | 17:52 |
| sjmc7 | my reasoning comes from: if you truncate to N digits | 17:52 |
| TravT | it would probably be best for you to write exactly what you think makes sense in a comment. | 17:52 |
| TravT | for him to add | 17:52 |
| sjmc7 | only N-1 digits are reliable | 17:52 |
| sjmc7 | as a relative measure | 17:52 |
| sjmc7 | yeah, i am | 17:53 |
| TravT | yeah, the rollover | 17:53 |
| sjmc7 | i wanted to try to argue the rollover first to avoid confusion | 17:53 |
| sjmc7 | in case i was insisting something that was wrong | 17:53 |
| TravT | it was something i hadn't thought about. | 17:53 |
| sjmc7 | it’s all i think about | 17:53 |
| sjmc7 | everything rolling over | 17:53 |
| TravT | i'm hoping my 401k can rollover if i get fired from this job for not creating the next y2k17 bug | 17:54 |
| TravT | (remove not) ^ | 17:54 |
| * TravT lame humor of the day | 17:54 | |
| sjmc7 | :) | 17:54 |
| TravT | ok, so, i have to go. I have to go stand in line to get an xray | 17:54 |
| sjmc7 | you are guaranteed of that, at least under this administration | 17:55 |
| sjmc7 | ok, good luck! don’t jiggle | 17:55 |
| TravT | hasta | 17:55 |
| lakshmiS | if you are going to stand in line, then your leg might be perfect :) | 17:55 |
| sjmc7 | :) | 17:56 |
| *** lakshmiS_ has joined #openstack-searchlight | 18:23 | |
| *** lakshmiS has quit IRC | 18:26 | |
| *** lakshmiS has joined #openstack-searchlight | 18:30 | |
| *** lakshmiS_ has quit IRC | 18:32 | |
| *** lakshmiS_ has joined #openstack-searchlight | 18:34 | |
| *** lakshmiS has quit IRC | 18:35 | |
| *** sjmc7 has quit IRC | 18:50 | |
| *** sjmc7 has joined #openstack-searchlight | 19:26 | |
| *** itisha has joined #openstack-searchlight | 20:21 | |
| *** sjmc7 has quit IRC | 20:33 | |
| *** sjmc7 has joined #openstack-searchlight | 20:41 | |
| *** nikhil_k is now known as nikhil_ | 21:01 | |
| *** nikhil_ is now known as nikhil_k | 21:02 | |
| *** krotscheck is now known as krotscheck_dcm | 21:03 | |
| *** nikhil has quit IRC | 21:44 | |
| *** nikhil_k is now known as nikhil | 21:45 | |
| sjmc7 | TravT: missed your comment on https://review.openstack.org/#/c/267864 yesterday; I am done working on it unless there are any issues. one thing that does need fixing is https://bugs.launchpad.net/searchlight/+bug/1543245 but i want to base that fix on top of the parent/child change | 22:10 |
| openstack | Launchpad bug 1543245 in OpenStack Search (Searchlight) "User Role: Designate domains need user roles" [High,Confirmed] - Assigned to Steve McLellan (sjmc7) | 22:10 |
| TravT | ok | 22:39 |
| TravT | i'll go through it again then | 22:39 |
| sjmc7 | ta | 22:39 |
| TravT | sjmc7: that patch looks all good. | 23:16 |
| sjmc7 | that’s a first | 23:16 |
| TravT | it probably should have release note | 23:16 |
| sjmc7 | ah, yeah. | 23:16 |
| sjmc7 | ok, let me add that before you review it | 23:16 |
| TravT | cool | 23:16 |
| sjmc7 | i don’t think i’ll ever remember to do them | 23:17 |
| TravT | it is a shitty process | 23:17 |
| TravT | i wish they could be generated from launchpad or something for bugs | 23:17 |
| sjmc7 | i should have a git review hook | 23:17 |
| sjmc7 | “have you done a release note?" | 23:17 |
| TravT | that's not a terrible idea | 23:18 |
| TravT | i think release notes will be hit or miss across projects | 23:18 |
| TravT | i shouldn't say it is shi*** | 23:18 |
| TravT | because it is better to have it automated and in git rather than the old wiki way, i suppose | 23:19 |
| TravT | kind like if I would deal with all the litter that the mailman leaves in my mailbox as it comes, then it wouldn't pile up | 23:19 |
| openstackgerrit | Steve McLellan proposed openstack/searchlight: Index child plugins as part of parent https://review.openstack.org/267864 | 23:25 |
| sjmc7 | ok, done | 23:25 |
| sjmc7 | yeah, i’ll get used to it | 23:25 |
| TravT | i just +2'd the CORS patch | 23:27 |
| TravT | but i don't have a great way to verify it really has all the headers we want | 23:27 |
| TravT | at least it has the minimum headers we think we need | 23:27 |
| sjmc7 | yeah. we can add more | 23:31 |
| sjmc7 | i’ll +A it in a bit | 23:31 |
| *** lakshmiS_ has quit IRC | 23:45 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 23:51 | |
| *** lakshmiS has joined #openstack-searchlight | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!