Monday, 2017-01-23

*** jamielennox|away is now known as jamielennox00:05
*** klrmn has joined #openstack-swift00:11
*** dmorita has quit IRC01:00
*** vint_bra has quit IRC01:20
*** dmorita has joined #openstack-swift01:26
*** chsc has joined #openstack-swift01:29
*** dmorita has quit IRC01:30
*** chsc has quit IRC01:41
*** mingyu has joined #openstack-swift01:49
*** dmorita has joined #openstack-swift02:16
*** cebreidian has quit IRC02:21
*** dmorita has quit IRC02:21
*** dmorita has joined #openstack-swift02:27
*** cebreidian has joined #openstack-swift02:30
*** mingyu has quit IRC02:31
*** dmorita has quit IRC02:32
*** mingyu has joined #openstack-swift02:46
*** jerrygb has joined #openstack-swift02:55
*** dmorita has joined #openstack-swift03:29
*** dmorita has quit IRC03:33
*** early has joined #openstack-swift03:35
*** early` has quit IRC03:36
*** cebreidian has quit IRC03:42
*** csmart has quit IRC03:43
*** jerrygb has quit IRC04:03
*** csmart has joined #openstack-swift04:17
*** psachin has joined #openstack-swift04:24
*** mingyu has quit IRC04:43
*** cebreidian has joined #openstack-swift04:45
*** chsc has joined #openstack-swift04:49
*** chsc has quit IRC04:54
*** cebreidian has quit IRC05:00
*** cebreidian has joined #openstack-swift05:09
openstackgerritMatthew Oliver proposed openstack/swift: Add container sharding to Swift containers  https://review.openstack.org/42390605:09
mattoliverau^^ very rough WIP that may not actaully run ATM. It's a rebase of the HEAD of the current POC. Tests, documentation, debugging still required.. but thought it's time to put it somethere. Will go through and leave some comments in the code as required. but I'm thinking reviews should start once I've finished writing up the dev docs that will go with the patch... so everyone knows how it works.. otherwise it'll be a05:12
mattoliveraulittle daunting. And then.. please go fix my dodgy code that has 5 POCs cruft probably thoughout it.05:12
*** cebreidian has quit IRC05:14
jrichlimattoliverau: woohoo!  Sharding patch \o/  ... I need to watch your talk from lca.  I guess they are available now?  I didnt get to watch the live stream.05:19
mattoliveraujrichli: they are. They should be on youtube05:19
jrichligreat.  i loved the last sharding one - great explanations of the phases you had gone through05:20
mattoliveraujrichli: \o/.. still a quite aways to go.. but not sitting as POCs anymore, so finally in gerrit05:20
mattoliverauThis one went better, ie I spoke and the presentation was better (in my opinion) Tho the introduction (introducing me) was crap.. I was kind dumbfounding by that for the first minute or so.05:21
mattoliverauinstead of introducing the talk by reading the title, they said "some rackspace thing" which isn't totally what it isn't.05:22
jrichliwell i am excited to hear how things ended up being done - and then i can understand enough to look at the patch, i hope :-)05:23
mattoliveraujrichli: you mean fix my code to make it better right ;)05:23
mattoliverau?05:23
jrichliah ... yeah.  ;-)  I am just gonna focus on understanding right now!05:24
mattoliveraulol05:24
*** klrmn has quit IRC05:24
*** cebreidian has joined #openstack-swift05:31
openstackgerritTone Zhang proposed openstack/swift: IO Priority support on the aarch64 architecture  https://review.openstack.org/42378305:37
*** zaitcev has quit IRC05:37
*** ppai has joined #openstack-swift05:42
*** jerrygb has joined #openstack-swift06:04
*** jerrygb has quit IRC06:08
*** bkopilov has joined #openstack-swift06:23
*** hseipp has joined #openstack-swift07:07
*** hseipp has quit IRC07:16
*** ChubYann has quit IRC07:18
*** McMurlock1 has joined #openstack-swift07:19
*** McMurlock1 has quit IRC07:25
*** tesseract has joined #openstack-swift07:31
*** sams-gleb has joined #openstack-swift07:38
*** oshritf has joined #openstack-swift07:52
*** rledisez has joined #openstack-swift08:15
*** hseipp has joined #openstack-swift08:15
*** pcaruana has joined #openstack-swift08:17
*** ppai has quit IRC08:29
*** geaaru has joined #openstack-swift08:29
*** hseipp has quit IRC08:51
openstackgerritChristian Schwede proposed openstack/swift: Add support to increase object ring partition power  https://review.openstack.org/33729708:55
*** abhitechie has joined #openstack-swift09:10
*** abhinavtechie has joined #openstack-swift09:13
*** abhitechie has quit IRC09:13
*** abhinavtechie has quit IRC09:15
*** abhinavtechie has joined #openstack-swift09:15
*** hseipp has joined #openstack-swift09:16
*** cbartz has joined #openstack-swift09:19
*** yarkot has quit IRC09:29
*** mingyu has joined #openstack-swift09:37
*** abhinavtechie has quit IRC09:45
*** abhitechie has joined #openstack-swift09:46
*** abhitechie has quit IRC10:03
*** abhitechie has joined #openstack-swift10:03
*** acoles_ is now known as acoles10:07
*** mvk has quit IRC10:12
*** abhinavtechie has joined #openstack-swift10:17
*** abhitechie has quit IRC10:17
*** mariusv has quit IRC10:19
*** mariusv has joined #openstack-swift10:20
*** mariusv has quit IRC10:20
*** mariusv has joined #openstack-swift10:20
*** sams-gleb has quit IRC10:25
*** sams-gleb has joined #openstack-swift10:26
*** sams-gleb has quit IRC10:30
*** zhugaoxiao has quit IRC10:34
*** sams-gleb has joined #openstack-swift10:45
*** mvk has joined #openstack-swift10:46
*** vint_bra has joined #openstack-swift11:15
*** vint_bra has quit IRC11:16
*** dmorita has joined #openstack-swift11:18
*** ganders has joined #openstack-swift11:21
*** dmorita has quit IRC11:22
*** caiobrentano_ has joined #openstack-swift11:36
*** abhinavtechie has quit IRC11:38
*** vint_bra has joined #openstack-swift12:13
*** mingyu has quit IRC12:15
*** mingyu has joined #openstack-swift12:20
*** kei_yama has quit IRC12:33
*** mingyu has quit IRC12:39
*** vint_bra has quit IRC12:41
*** catintheroof has joined #openstack-swift12:45
*** vint_bra has joined #openstack-swift12:46
*** oshritf has quit IRC12:48
*** catintheroof has quit IRC12:50
*** psachin has quit IRC12:50
*** catintheroof has joined #openstack-swift12:58
*** hseipp has quit IRC13:05
*** vint_bra has quit IRC13:24
*** oshritf has joined #openstack-swift13:24
*** vint_bra has joined #openstack-swift13:24
*** oshritf has quit IRC13:34
*** caiobrentano_ has quit IRC13:34
*** caiobrentano_ has joined #openstack-swift13:35
*** jordanP has joined #openstack-swift13:38
*** mingyu has joined #openstack-swift13:39
*** oshritf has joined #openstack-swift13:39
*** mingyu has quit IRC13:44
*** yangzb09 has joined #openstack-swift13:55
tdasilvagood morning14:11
*** jerrygb has joined #openstack-swift14:14
*** jerrygb_ has joined #openstack-swift14:15
*** jerrygb__ has joined #openstack-swift14:18
*** jerrygb has quit IRC14:19
*** jerrygb_ has quit IRC14:20
*** catinthe_ has joined #openstack-swift14:29
*** catintheroof has quit IRC14:32
*** mingyu has joined #openstack-swift14:40
*** hseipp has joined #openstack-swift14:43
*** mingyu has quit IRC14:45
*** vinsh has quit IRC14:46
*** mingyu has joined #openstack-swift14:46
*** vinsh has joined #openstack-swift14:47
*** sams-gleb has quit IRC15:00
*** sams-gleb has joined #openstack-swift15:01
*** jordanP has quit IRC15:03
*** jordanP has joined #openstack-swift15:03
*** sams-gleb has quit IRC15:05
*** oshritf has quit IRC15:15
*** sams-gleb has joined #openstack-swift15:17
*** oshritf has joined #openstack-swift15:18
*** oshritf has quit IRC15:19
*** vinsh_ has joined #openstack-swift15:21
openstackgerritMerged openstack/swift: Simplify get_different_suffix_df args  https://review.openstack.org/42350115:21
*** vinsh has quit IRC15:24
*** oshritf has joined #openstack-swift15:26
*** mingyu has quit IRC15:29
*** mingyu has joined #openstack-swift15:29
*** _JZ_ has joined #openstack-swift15:32
*** oshritf_ has joined #openstack-swift15:35
*** oshritf has quit IRC15:37
*** jerrygb has joined #openstack-swift15:45
*** mingyu has quit IRC15:46
*** jerrygb__ has quit IRC15:47
*** oshritf_ has quit IRC15:49
acolestdasilva: I pushed a change over patch 423508, hope that's ok16:02
patchbothttps://review.openstack.org/#/c/423508/ - openstack-infra/project-config - Update swift functional job list16:02
tdasilvaacoles: thank you, i saw that earlier, great catch!16:02
*** Jeffrey4l_ has quit IRC16:06
*** Jeffrey4l_ has joined #openstack-swift16:06
*** sanchitmalhotra1 has joined #openstack-swift16:07
*** sanchitmalhotra has quit IRC16:08
*** sanchitmalhotra1 is now known as sanchitmalhotra16:08
openstackgerritAlistair Coles proposed openstack/swift: Fix race in new partitions detecting new/invalid suffixes.  https://review.openstack.org/41869016:09
acolesclayg: kota_ ^^ rebased, fixed merge conflicts, probably just needs clayg's blessing on the test changes16:10
*** pcaruana has quit IRC16:13
*** zaitcev has joined #openstack-swift16:15
*** ChanServ sets mode: +v zaitcev16:15
*** mvk has quit IRC16:18
*** klrmn has joined #openstack-swift16:20
*** hoonetorg has joined #openstack-swift16:42
notmynamegood morning16:44
*** hoonetorg has quit IRC16:45
tdasilvanotmyname: o/16:46
*** mingyu has joined #openstack-swift16:46
*** hoonetorg has joined #openstack-swift16:47
*** chsc has joined #openstack-swift16:50
*** chsc has joined #openstack-swift16:50
*** vint_bra has quit IRC16:51
*** caiobren_ has joined #openstack-swift16:51
*** mingyu has quit IRC16:52
*** caiobre__ has joined #openstack-swift16:54
*** caiobrentano_ has quit IRC16:54
*** caiobren_ has quit IRC16:55
*** david-lyle_ has joined #openstack-swift16:57
*** hseipp has quit IRC16:57
*** chsc has quit IRC16:57
*** cbartz has left #openstack-swift16:59
*** yangzb09 has quit IRC16:59
*** caiobre__ has quit IRC17:03
*** david-lyle_ has quit IRC17:03
*** vint_bra has joined #openstack-swift17:05
*** caiobrentano_ has joined #openstack-swift17:05
*** vint_bra has quit IRC17:10
*** vint_bra has joined #openstack-swift17:10
*** tesseract has quit IRC17:15
*** klrmn has quit IRC17:19
*** caiobrentano_ has quit IRC17:22
*** caiobrentano_ has joined #openstack-swift17:23
clayggood morning!17:24
claygacoles: oh, i was thinking I had a bunch of rebasing to do this am17:24
claygacoles: I looked at some of the test changes - it wasn't clear why all of them were needed (how they made the tests better) - but if you like them better; I'm sure it's fine!17:25
notmynamemattoliverau: thanks for pushing up https://review.openstack.org/#/c/423906/17:25
patchbotpatch 423906 - swift - Add container sharding to Swift containers17:25
claygacoles: you're always saying the mountains of tests are what makes it so easy to maintain swift and more benign implementation details they make assertions about the easier it is to refactor the code behind the interfaces!17:26
claygah... i *am* feeling better!17:26
*** mvk has joined #openstack-swift17:26
claygnotmyname: have you looked at it!?17:26
claygnotmyname: i'm sort of scared too :'(17:27
claygnotmyname: maybe global EC or symlinks first?17:27
claygnotmyname: or part power - but mattoliverau's been working on that too!17:27
notmynameclayg: I haven't looked at the patch yet (I just saw it), but I talked to mattoliverau about it last week. from what he's said, I think the idea's pretty good and I'm glad we can start looking at actual code17:29
claygnotmyname: yeah!  that's the spirit!17:29
notmynamehowever, I personally don't feel too much pressure to sit down with it in great detail before the PTG (although having a baseline for discussion at the PTG will be good)17:30
acolesclayg: the ones that I remember bothering me were like https://review.openstack.org/#/c/418690/5/test/unit/obj/test_auditor.py@85917:30
patchbotpatch 418690 - swift - Fix race in new partitions detecting new/invalid s...17:30
claygyeah, the auditor - that was the bulk of the change - what *was* going on there!?17:30
notmynamelike you said, some of the other stuff that's going on is much closer to being done and should take priority. global EC, part power increase, and maybe symlinks17:30
*** JimCheung has joined #openstack-swift17:31
acoleswas this the patch where I actually said "maybe clayg was deliberately avoiding digging around under the hood too much with assertions" ? or words to that effect :o17:31
claygwell, no i see your point - if the existing test was coupled with an assumption about the behavior of invalidate_hash (which I changed)17:32
claygit *is* sorta bs for the tests to keep living on like that - good catch17:32
claygso what did you come up with for the fix?  assertEqual(mock_invalidate_hash.call_arg_list, []) ????17:33
*** chsc has joined #openstack-swift17:33
*** chsc has joined #openstack-swift17:33
acolesTBH in the auditor tests they should probably have been mocking invalidate_hash on master since the goal is to verify that invalidate_hash is not called17:33
acolesum, no I think I stuck with the pattern of verifying that the state of hashes.invalid is how you'd expect it, which is of course as you say more brittle to implementation changes :/17:35
acolesbut no worse than what was on master (is that a valid defense? ;) )17:36
claygok, w/e - i'll do a follow up to change it to the mocks!17:36
claygnice work!17:36
acolesclayg: looks like bulk of the test changes I made was from patchset 5 to 617:39
claygcool - i'm just going to make sure the cleanup looks legit and then +A and move onto rebasing all the other stuff17:40
claygacoles: there was one patch I saw where you started to "standardize handling of invalid/non-existing hashes/pkl"17:41
claygacoles: i'm my fever induced visions I also came to that conclusion (assuming I was reading the patch correctly!)17:41
acolesclayg: this one maybe patch 42207617:42
patchbothttps://review.openstack.org/#/c/422076/ - swift - Handle unreadable hashes.pkl same way as non-exist...17:42
claygacoles: I'm also became quite bummed out about except Exception around consolidate_hashes (which I know now has strong tests :P)17:42
claygacoles: I don't think it was supposed to be there17:42
acolesyeah there is still some cruft in there17:42
claygacoles: I think the original pre consolidate hashes code had more reasonable exception handling17:42
claygparticuarlly - the lockdir call (which used to be around reading hashes, and is now around consoidate hashes) used to be able to raise the timeout all the way out to the REPLICATE call17:43
claygnow it carries on and does the rehash (making more io contention in the dir) - THEN it will raise the lockdir when it finally tries to writeback17:43
acolesclayg: so my patch 422076 does need a rebase but I didn't think any other of yours did, unless gerrit hasn't caught up with them yet17:44
patchbothttps://review.openstack.org/#/c/422076/ - swift - Handle unreadable hashes.pkl same way as non-exist...17:44
clayggetting git of that pokemon exception handling there will make it so we can safely put the getinode call under the lockdir!17:44
acolesyou weren't really sick were you, just plotting :)17:44
claygacoles: i think it's more like you said - the sickness came out of worry over get_hashes17:46
claygacoles: ok, well I don't even have all the patches up yet17:46
acoleslol, a bad case of hashitis17:46
claygacoles: i'm going to just work on merging patch 41869017:46
patchbothttps://review.openstack.org/#/c/418690/ - swift - Fix race in new partitions detecting new/invalid s...17:47
acolesclayg: +1 to that17:47
claygacoles: then i'm mostly thinking about patch 41978717:47
patchbothttps://review.openstack.org/#/c/419787/ - swift - Better optimistic lock in get_hashes17:47
claygwhich I think could also have some conflicts if it merges - so I may start thinking about what I have outstanding that can rebase *on top of* that one17:48
acolesI like that one17:49
claygacoles: oh there's a bunch of goodn's out there17:49
acolesclayg: the only one I didn't have +2 on was patch 418691, IIRC there was an issue over handling None from read_hashes17:51
patchbothttps://review.openstack.org/#/c/418691/ - swift - Fix performance regression with hash invalidations17:51
claygyeah patch 418691 is the one that will get messed up by patch 419787 for *sure*17:53
patchbothttps://review.openstack.org/#/c/418691/ - swift - Fix performance regression with hash invalidations17:53
patchbothttps://review.openstack.org/#/c/419787/ - swift - Better optimistic lock in get_hashes17:53
claygit's also the one that needs patch 422076 the most - and what I was talking about with letting the LockTimeout get out of consolidate_hashes17:54
patchbothttps://review.openstack.org/#/c/422076/ - swift - Handle unreadable hashes.pkl same way as non-exist...17:54
claygmainly I just want conslidate_hashes to either return with the "safe_inode" from hashes.pkl or raise an exeption that terminates get_hashes17:54
claygI don't want to have to handle "any" exception by calling safe_get_inode outside of lockdir because consolidate_hashes blew up17:55
*** david-lyle_ has joined #openstack-swift17:56
*** david-lyle_ has quit IRC17:56
*** Jeffrey4l__ has joined #openstack-swift17:57
*** david-lyle_ has joined #openstack-swift17:57
*** Jeffrey4l_ has quit IRC17:59
*** rledisez has quit IRC18:02
acolesclayg: yep think I was starting to think that way - have consolidate_hashes always result in a hashes.pkl existing and if it fails then bail out18:02
acolesrather than dealing with the new partition case outside of it18:02
claygacoles: I wasn't sure if I'd gotten as far as it should always create the hashes.pkl - but I like the implications18:03
acolesoic, yeah of course safe_get_inode can return None. well, IDK, I just started warning to the idea that consolidate_hashes would "just get me a consolidated hashes+hashes.pkl to work with"18:04
acoleswarming*18:04
acolesbut w/e, we're making progress!18:05
*** david-lyle_ is now known as david-lyle18:05
claygyeah - i'm remembering I had some weird edge case where the hashes.pkl was invalid (EOFError/zero-byte/etc) but there wasn't any suffixes that would trigger the rewrite18:07
claygand it would just stay there... invalid...18:07
acolesyes, if it exists but is unreadable for some reason18:08
claygthis was all in my mind tho - so I thought it may have just been a dream18:08
*** dmorita has joined #openstack-swift18:08
claygyeah, basically the reason force_rewrite came to exist in the first place18:08
acolesreadable but invalid returns None so we do a listdir etc, but exists and unreadable returns {}.18:08
claygI don't want conslidate_hashes to have to return some indication that it wasn't able to read18:08
acoleswait, that was what patch 422076 was about18:09
patchbothttps://review.openstack.org/#/c/422076/ - swift - Handle unreadable hashes.pkl same way as non-exist...18:09
acolesmaybe i am getting confused18:09
claygacoles: it still does "a dict or None"18:09
zaitcevI'm in your Swift cloning your MIMEputter18:09
zaitcever18:10
claygzaitcev: NOOOOooo - i thought you were going to fix the whole footer protocol thing!?18:10
zaitcevclayg: well yea, it's called DoublePutter now18:10
claygremember!?  the HTTP bug?  And the "golang will never let their httpserver be as broken as we made eventlet.wsgi"18:10
claygzaitcev: wahhhhhhaaaaaAAAAA?  nice!18:11
zaitcevyes, duh. You told me to do it18:11
claygto be 100% clear - I told you *not* to do the dumb thing - and when you asked "why didn't we do the smart thing" - I was like "yeah... because we're dumb"18:12
acolesclayg: yep, its the unreadable->empty dict that I was changing there18:12
claygacoles: ok, so yeah - then maybe you already have the situation where if the os.listdir doesn't find any suffixes to add to the empty dict - it won't be modified and need to rewrite so it will continue to be invalid on disk!?18:13
*** jordanP has quit IRC18:13
claygacoles: not saying it's bad - i just like the idea you may have independently come to the same conclusion as I did - makes it seem more "correct"18:13
acolesclayg: something like that, so if nothing changes you'll keep reporting hashes={} IIRC18:14
acoleswell, until the deterministic 10th cycle18:14
claygacoles: then what happens?  I think empty hashes will always do the listdir - the question is if the listdir finds any suffixes to mark None set's modified to True and tries to rewrite it?18:14
*** klrmn has joined #openstack-swift18:15
claygoic, do_listdir always set's modified to True18:15
claygi forgot about that - it always looked dedented to me18:15
claygoh, empty dict doesn't force listdir - that can't be correct for invalid - it needs to listdir18:16
acolesclayg: so, I wrote this test (patch 422076 depends on this patch 421385) https://review.openstack.org/#/c/421385/2/test/unit/obj/test_diskfile.py@738218:18
patchbothttps://review.openstack.org/#/c/422076/ - swift - Handle unreadable hashes.pkl same way as non-exist...18:18
patchbothttps://review.openstack.org/#/c/421385/ - swift - Add more tests for diskfile consolidate_hashes18:18
patchbotpatch 421385 - swift - Add more tests for diskfile consolidate_hashes18:18
acolesclayg: it is somewhat contrived18:19
acolesbut left me thinking why treat unreadable different from invalid or non-existent? we have to assume we have no idea what current hash state is in all cases18:20
acolesclayg: sorry, gotta dash. look forward to reviewing some updates :)18:20
claygacoles: k, thanks for the pointers!18:21
*** acoles is now known as acoles_18:21
*** ChubYann has joined #openstack-swift18:25
*** geaaru has quit IRC18:40
*** silor has joined #openstack-swift18:44
*** catintheroof has joined #openstack-swift18:45
*** catinthe_ has quit IRC18:47
*** mingyu has joined #openstack-swift18:49
*** mingyu has quit IRC18:53
notmynameI'm slightly worried about the openstack-wide discussions about how md5 can't be used (or must be wrapped)19:03
*** catinthe_ has joined #openstack-swift19:03
notmynameie http://lists.openstack.org/pipermail/openstack-dev/2017-January/110278.html19:04
*** catintheroof has quit IRC19:06
claygnotmyname: i'm just worried about the current social setup and prioritization19:08
timburkenotmyname: it put me in a mind to start thinking about how we could replace at least *some* of our use with other algorithms. say, create a new storage policy and have the ring inform hash_path to use sha256 or something19:08
notmynameyeah. like many people, I'd prefer to have not-md5. but I'm worried about API compatibility and code churn19:09
claygnotmyname: the idea that "someone" creates an abstraction around our use of md5 and eplicitly annoates useforsecurity=False is fine19:09
timburkeclayg: agreed that that's the much more frightening thing. but i can *do* something about the hashes we use19:09
claygthere's *some* hope that someday that abstraction could be leveraged to allow in some future-hand-wave where we get sha256 for get_hash_path and crc for ETags - but of course the migration and backwards compat is the hard part - not the global s/hashlib/oslo/19:10
notmynamehttps://blake2.net19:10
claygbut you know "every journey begins with a a step" is something people who like to do stuff say19:10
timburkenotmyname: py36 has it built in...19:10
notmynametimburke: well there's the reason to do py3 ;-)19:11
claygnotmyname: I think that may be more "fast" in terms of throughput - there's other algos that go for "wide-even-distribution-of-short-strings-fast"19:11
claygunless you want a cryptographically secure ETag (!?)19:12
claygdoesn't matter19:12
claygthat ML isn't about getting to *use* other hashes - it's about annotating the hashes we *are* using as useforsecurity=False19:12
claygtimburke: oh... or your saying we take the marching order for the audit as an oppertunity to shelve other stuff we're working on in favor of addressing this critical hash function question that's slowing swift adoption?19:14
timburkeclayg: i'm saying that the conversation put an idea into my head. didn't say i wrote (or will write) any code about it :-P19:15
claygnotmyname: my worry as it were is that "someone" will be either a) an openstack goal and we end up doing it before we really "need" to because OpenStack or b) someone tries to cross-project and ends up mad at Swift because... of me mostly I guess19:16
timburkeclayg: go back to *actually* addressing some critical hash-related bugs in swift ;-)19:16
claygtimburke: yessir!19:16
*** ganders has quit IRC19:27
dimstimburke : quick question, does /info work under py3 yet?19:38
dimsi've had to disable swift in many of the jobs for py3519:39
notmynamedims: he's standing at my desk right now. he'll answer soon19:42
dimshi notmyname thanks!19:42
*** vint_bra has quit IRC19:45
timburkedims: ...maybe? with your patch to actually get the proxy server to start, it was probably willing to send back *some* response, and since /info is served entirely from the proxy there's a decent chance it wasn't a 500. that said, there probably would be some... problems... with the response. i think i remember seeing things like `Content-Length: b'1146'` in the headers the last time i looked into it19:47
*** vint_bra has joined #openstack-swift19:47
*** McMurlock1 has joined #openstack-swift19:47
dimstimburke : swift generates the content-length info?19:48
timburkeand it goes in and out of a HeaderKeyDict a few times as it comes back through the pipeline, which may or may not be doing the right thing19:50
notmynamedims: yes, we do (since headers are sent first before the body, and stuff returned from swift can be very large, we can't simply pass the response body back up to the wsgi server to calculate)19:58
dimsgotcha19:59
timburkenotmyname: well, we *could* for /info, but (to my knowledge) we don't, because we're so in the habit of supplying it ourselves20:00
notmynamedims: well, that's the general case. seems like we don't for...yeah. what timburke said20:00
notmynamewell, we aren't explicitly providing it in the InfoController for /info responses, but we're passing it to swob (our webob replacement) and that's doing it20:01
notmynamehmm...or not. if we don't set it (we don't on /info responses) looks like we might just punt up to the wsgi server20:02
notmynamehowever, all that being said, timburke's comments about likely having to clean stuff up still stands20:04
notmyname#different_topic20:05
notmynameso we gotta do a swiftclient release this week20:06
dimsis the /info the easiest path to try to get to work? notmyname timburke20:06
timburkenotmyname: too bad! the info controller does it by way of swob.Response (because it set a body) https://github.com/openstack/swift/blob/master/swift/common/swob.py#L315-L32120:06
openstackgerritThiago da Silva proposed openstack/swift: remove reference to deprecated tool  https://review.openstack.org/42431220:06
timburkedims: yeah, that's where i'd start20:06
notmynamedims: it has the fewest requirements. so yes20:06
notmynametimburke: right. that's what I was getting down to in my code search.20:08
timburkethe next step would probably be something like making account requests work. the big pain is likely to be making https://github.com/openstack/swift/blob/master/swift/common/bufferedhttp.py work20:08
notmynamethat's the internal socket stuff, right?20:08
timburkeyeah, i still don't know how we're going to (properly) handle https://github.com/openstack/swift/blob/master/swift/common/bufferedhttp.py#L57 in py3 -- socket._socketobject flat out doesn't exist and i haven't had the time or inclination to try to find its replacement yet20:10
timburkeon the swiftclient release, https://review.openstack.org/#/c/413348/ might be good, particularly ahead of the stable branching20:17
patchbotpatch 413348 - python-swiftclient - Add Constraints support20:17
timburkehttps://review.openstack.org/#/c/359477/ is a nice developer-facing usability improvement20:18
patchbotpatch 359477 - python-swiftclient - Accept more types of input for headers/meta20:18
dimsand i have no clue about the code base :)20:18
timburkedims: you and me both. i at least have an idea of what it's trying to do, but i'm not sure how to validate that it still works, nor am i familiar enough with the stdlib to figure out what the modern equivalent is20:20
*** silor has quit IRC20:24
timburkehttps://review.openstack.org/#/c/310075/ would be nice, but i have to think more about how to do it -- currently, i think every POST will require a HEAD :-/20:25
patchbotpatch 310075 - python-swiftclient - Expire segments when expiring large objects20:25
dimsnotmyname : timburke : what's the simplest curl command that you use?20:25
timburkecurl -v http://swift-host:8080/info20:26
timburkethere's no auth required20:26
dimsack thanks20:27
timburkehttps://bugs.launchpad.net/python-swiftclient/+bug/1586690 and https://bugs.launchpad.net/python-swiftclient/+bug/1621581 are strange -- i'm not sure they're client bugs? seems like some problem with the server config20:27
openstackLaunchpad bug 1586690 in python-swiftclient "Uploading empty(0 B) file fails" [Undecided,Incomplete] - Assigned to Uday Swami (swamius)20:27
openstackLaunchpad bug 1621581 in python-swiftclient "swiftclient returns response headers without 'Content-Length' param, thus causing upload object to fail" [Undecided,In progress] - Assigned to Arun Mani (arun-mani)20:27
timburkehttps://review.openstack.org/#/c/297958/ is kinda interesting; i never got around to following up again...20:29
patchbotpatch 297958 - python-swiftclient - Check /info before send SLO segments20:29
timburkehttps://review.openstack.org/#/c/259410/ might be nice, but i think we need to think harder about how much we buffer and where we buffer it20:32
patchbotpatch 259410 - python-swiftclient - Support uploading to an object in swift from stdin20:32
timburkeand i still need to give a response to joel on https://review.openstack.org/#/c/399756/20:32
patchbotpatch 399756 - python-swiftclient - On auth failure, ignore passed-in tokens and retry20:32
timburkemay as well land https://review.openstack.org/#/c/360135/20:32
patchbotpatch 360135 - python-swiftclient - Make functests py3-compatible20:32
claygtimburke: we should just update bufferedhttp to keep a reference to "real_close" https://github.com/python/cpython/blob/master/Lib/socket.py#L40920:48
clayggetting ahold of something that will "screw your ref count and close this ^&*" is the only reason we ever wanted _real_socket in the first place20:49
*** mingyu has joined #openstack-swift20:50
timburkeclayg: either way, someone still needs to invest the time in finding the py3 equivalent and validating that it really does do the thing we need it to20:52
claygnot 100% clear to me if knowing what to do in that case acctually helps anything - it's not like I'm acctually going to take up the py3 cause anytime soon that I'm aware of20:52
claygtimburke: reading the close method just below it's pretty clear that *it* thinks _real_close does the "really acctually close the socket now" dance - which I can confirm is *why* we grew the reference to _real_sock and what we want it to do20:53
claygsomeone *could* change it "PY3: blah blah" and as long as py2 still calls _real_socket.close() i'm satisified we don't need to go out of our want to track down the reproduce case20:54
*** mingyu has quit IRC20:54
timburkebah, i'd glossed over the python source link -- yeah, *probably* does what it says on the tin?20:55
claygbut +1 to not signing up to do it!  But if someone *asks* - i'd point them that way.  And if they asked to review a patch that did that - I'd probably sanity the regression on py2 and be happy to merge20:56
claygtimburke: i mean... the next stop would be socket.c in modules or something i guess - see what close acctually does - but heavn help of if it's not a thin shim around man -s 2 close20:56
mattoliverauMorning20:57
clayganyway... if that *doesn't* work in py3 it's NBD - I mean so py3 grows a socket leak regression ... but only once someone gets py3 working and deployed in production (where'd you care)20:57
claygit doesn't risk eating your data - so at that point if someone files the bug "leaked socket in py3" we can kick ourselves for not doing it better20:58
claygdoesn't like... swift.conf not work in py3 or something too?20:58
claygmattoliverau: should I watch the container sharding talk from LCA!?20:58
mattoliverauclayg: if you need help falling to sleep then sure :p it's just a high level overview of the process of sharding, but could help if you can't remember some of the discussions21:02
timburkemattoliverau: linky?21:04
mattoliverauI plan to write up some decent documentation by the time the PTG at the latest. Whick will have details of all the design, include interesting internals.21:05
mattoliverauWhich will help y'all understand and then make my code better ;)21:06
claygI was just going to google "how to put a really big thing in your cluster by the man down under"21:06
mattoliverauLol21:08
mattoliverau youtu.be/g7tSqRNFaO021:08
claygyou sound like *extra* austrailian when you're in austraila I think21:10
clayg;)21:10
mattoliverauOh really, I always thought I was extra Australian when outside oz21:10
mattoliverauI didn't like the intro.. "this Rackspace thing".. when all she needed do was read the title :(21:11
claygmattoliverau: i'm probably jsut *missing* you21:11
*** jerrygb has quit IRC21:12
timburkeoooh and i see some new, pretty graphs on https://oliver.net.au/?p=28521:13
claygmattoliverau: it's all good - only way it woulda been better is if she'd have called you Swift PTL!21:13
*** JimCheung has quit IRC21:13
*** JimCheung has joined #openstack-swift21:14
mattoliverauLol yeah. Oh well, at least I got to speak about it :)21:15
mattoliverautimburke: yeah, need to change my blogs theme cause graphs images don't display quite right.21:16
mattoliverauIf you want to see more LCA videos: https://www.youtube.com/channel/UCDMo9DyACXG62ak5cVgs3TA21:19
*** jerrygb has joined #openstack-swift21:31
*** jerrygb_ has joined #openstack-swift21:32
openstackgerritDavanum Srinivas (dims) proposed openstack/swift: [WIP] Get swift process to come up under py35  https://review.openstack.org/41608421:33
*** Jeffrey4l_ has joined #openstack-swift21:34
*** Jeffrey4l__ has quit IRC21:35
*** jerrygb has quit IRC21:36
*** mingyu has joined #openstack-swift21:51
dimstimburke : so...got /info working http://paste.openstack.org/show/596153/21:53
timburkedims: sweet!21:55
*** mingyu has quit IRC21:56
notmynameI'm guessing there will be an openstack summit in Chicago https://twitter.com/OpenStack/status/82363040446890803221:56
notmynameoops. boston21:56
dimsguess this is as far i can get with the _socketobject stuff you mentioned...21:56
* notmyname might not keep up with baseball21:56
notmynameso maybe a thing at the boston summit21:56
timburkedims: clayg seemed to have some ideas involving socket._real_close ? if you're interested21:57
dimstimburke : i will check back in a few days :) hoping y'all get a little more further by then21:58
claygtimburke: don't put that on me!  I don't even know what we're trying to solve for!21:58
dimsupdated https://review.openstack.org/#/c/416084/21:58
patchbotpatch 416084 - swift - [WIP] Get swift process to come up under py3521:58
notmynamemattoliverau: it might be nice to share the "ugly" graphs you have. the ones where the VM noisy neighbor hosed you. wasnt' there some good info before that happened?21:58
dimsLOL clayg21:58
dimsclayg : simple, run everything under python3.5 :)21:58
timburkerun *correctly*. important distinction21:59
claygright ...21:59
claygtimburke: OMG!  you may have cracked it?  Is "correctly" part of the goal?21:59
dims:)21:59
timburkeif six.PY3: return HTTPNotImplemented()22:00
dimstimburke : so we have a CI job as of this morning in nova check queue that runs neutron/glance/cinder/nova everything under python3.5 and runs the tempest test suite :)22:00
dimsso yes, +1 to "correctly" :)22:00
*** vint_bra has quit IRC22:01
timburkedims: i'm still waiting on https://review.openstack.org/#/c/401397/ so... we'll see? i'm afraid we haven't had a great track record WRT to py3 review turn-around time22:01
patchbotpatch 401397 - swift - py3: port common/ring/, common/linkat.py, and comm...22:01
dimsack timburke22:01
timburkehopefully we'll be a bit further22:01
*** McMurlock1 has quit IRC22:01
mattoliveraunotmyname: sure, I can do that thing :)22:02
clayg"slicing"22:02
mattoliveraulol, yeah, this is why notmyname should come up with names.. and not me ;)22:02
timburkedims: i think the ability to actually *do something* with py3 is a step in the right direction, though. just porting unit tests isn't likely to motivate, in no small art because we have a hard time verifying that we're still actually testing the right things22:03
dimsright, so i first got the nova functional tests working, then rally test and then graduated to tempest22:04
*** sams-gleb has quit IRC22:05
timburkefwiw, it may be easier to start with a py3 proxy, py2 everything else22:06
notmynametimburke: dims: ...especially when considering project plans to delete the python object server. so not a lot of motivation to port that to py322:06
notmynameso I'd echo the "start with proxy server" part22:07
timburkemore than that; py3 proxy talking to py3 account server would be nice to have later, but a lot to try to debug right off the bat22:08
openstackgerritJim Cheung proposed openstack/liberasurecode: Add Phazr.IO libphazr backend to liberasurecode  https://review.openstack.org/42435322:13
clayg"bahrrhaahahhh crazy"22:19
notmynameJimCheung: cool. nice to see the patch up in gerrit :-)22:20
JimCheungThanks notmyname:  I did make a booboo and didn't include a brief description of the changes tho22:20
JimCheungAny easy way to mend it?22:21
notmynameJimCheung: well, yeah, I noticed that too :-)22:21
JimCheung:-)22:21
*** mmotiani has joined #openstack-swift22:22
notmynameJimCheung: there *used* to be an "edit commit message" button, but I don't see that now. you can also amend the commit locally and then `git review` again22:22
notmynameJimCheung: just keep the Change-Id the same, and you'll be good22:22
JimCheungOkay, thanks!22:23
openstackgerritJim Cheung proposed openstack/liberasurecode: Add Phazr.IO libphazr backend to liberasurecode  https://review.openstack.org/42435322:26
openstackgerritJim Cheung proposed openstack/liberasurecode: Add Phazr.IO libphazr backend to liberasurecode  https://review.openstack.org/42435322:28
JimCheungComments added.  Thanks!22:29
notmynamethanks22:29
claygwhat have we done :'(22:32
notmynameclayg: with what where?22:33
timburkeclayg: accidentally become C library maintainers?22:33
notmynametimburke: lol22:33
claygworse!  An opensource C library that's just a plugin wrapper to other interesting libraries and some of them may not even be FOSS!22:34
notmynametrue, phazr isn't FOSS. but the fact that we've got people who want to add support for more EC types is really great22:35
timburkeJimCheung: is there any way for us to run tests with libphazr enabled? we've already got an example of a backend where we can't do that, but it'll make the change easier to review i think22:36
timburkeoh, or i need to read the updated commit message, then contact support@ :-)22:37
JimCheungWe can submit a binary to help testing if needed22:38
JimCheung:-)22:38
notmynameJimCheung: yeah, it's going to be important to be able to test the code in order to accept it and maintain it22:38
JimCheungWe'll figure out something quick22:39
JimCheungHow did you test SHSS?22:40
notmynameyeah, I was about to type soemthing about that :-)22:41
JimCheungThe submitted changes are almost the same as SHSS.22:41
notmynamehonestly I wonder if it's just because kota_ is active with libec22:41
notmynamehowever, that's not a long-term good thing22:41
notmynameI'd definitely like to get his input, but it's still pretty early in tokyo22:42
JimCheungSounds good22:42
mattoliveraualso kota_ was sick yesterday (according to the twitter)22:43
notmynameyeah, I saw that too22:43
*** mingyu has joined #openstack-swift22:52
*** mingyu has quit IRC22:56
*** sams-gleb has joined #openstack-swift23:06
*** caiobrentano_ has quit IRC23:07
*** remix_tj has quit IRC23:07
*** remix_tj has joined #openstack-swift23:09
*** sams-gleb has quit IRC23:12
kota_Still a high fever, sorry23:16
notmynamekota_: hope you feel better soon23:17
notmynamekota_: please don't feel any pressure to do upstream stuff. spend time getting well23:17
kota_Thx, will take a look the log23:17
kota_Later23:18
*** catinthe_ has quit IRC23:23
*** chsc has quit IRC23:38
*** kei_yama has joined #openstack-swift23:46
*** caiobrentano_ has joined #openstack-swift23:52
openstackgerritOpenStack Proposal Bot proposed openstack/swift: Updated from global requirements  https://review.openstack.org/8873623:53

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