Friday, 2015-03-20

torgomaticnotmyname: fragment size is how big a fragment is (yes, I know)... e.g. if 10+4 coding, and 1MB segments, then fragment_size is roughly 100000 bytes plus ~32 header bytes so 10003200:01
torgomaticseg_size / ec_ndata + fragment headers00:01
notmynameah good. thanks00:01
notmynameso, importantly, segment_size is bigger than fragment_size00:02
notmynamebut they don't have any particular integer multiple relationship00:03
*** ho has quit IRC00:04
*** ho has joined #openstack-swift00:06
notmynametorgomatic: this doesn't look right to me. https://gist.github.com/notmyname/ed7c81e6290fcc337d7900:08
notmynamefragment_size = 200, segment_size = 100000:08
torgomaticnotmyname: so, what looks wrong about it?00:08
notmynameI think it's my understanding :-)00:09
notmynameto the fragment start/end is what's then passed down as the translated range request00:09
torgomaticI mean, the fact that segment size is a multiple of fragment size is sort of surprising; are you making those numbers up, or do they come from pyeclib?00:09
notmynameso how does 0, 199 have anything to do with 790,81000:09
notmynametotally making them up00:09
torgomaticoh, ok00:09
notmynameI'm trying to understand the math in a REPL with numbers smaller than MB00:10
torgomaticdo you see how they turn into a segment start/end?00:10
torgomaticthat is, does client -> segment make sense?00:10
notmynameyes I think so. so that's the start and end ranges for the segment that the range is in00:11
notmynameright?00:11
torgomaticyup00:11
torgomaticand then a segment is bigger than a fragment, so we scale those ends down by the ratio segsize/fragsize, and there you go00:11
notmynamebut how do the 0,199 have to do with the 20 bytes requested?00:12
notmyname(21)00:12
torgomaticwe have to decode entire fragments and get entire segments00:13
torgomaticer, "to get"00:13
torgomaticand then trim the resulting segments to fit what the client asked for00:13
torgomaticif we try to go grabbing partial fragments, pyeclib complains mightily00:14
notmynameok00:14
notmynameI get that00:14
notmynameand since the fragment size is 200, that makes sense that it's 200 bytes00:14
notmynamebut that's not translated to an offset of which fragment00:15
torgomaticI don't understand that last statement00:15
notmynamelike, I'd expect it to be the range of bytes in the segment to fetch.00:15
notmynamebasically, I have zero clue how setting req.range to the fragment start/end has anything to do with the bytes the client requested00:16
notmynameI mean, yes I see the math. I just don't know why00:16
notmynamewhy that math00:16
torgomaticso we start with the client start/end00:17
torgomaticand then we subtract some from client-start, and add some to client-end, so that they encompass only whole segments00:17
torgomaticthose things are now called segment-start and segment-end00:17
notmynameok, I've got that. the range is adjusted to be the whole segments00:18
torgomaticand then we scale those by fragsize/segsize to turn them into ranges encompassing whole fragments00:18
notmynamethat's the part I don't get. or I don't understand the scaling00:18
* notmyname wishes for a whiteboard00:18
notmynameso here's what I'm expecting00:19
notmynameclient range -> whole segments. eg if a boundary is crossed, the range will be for the whole segments that are spanned00:19
torgomaticyup00:19
notmynamethen fragment range-> offset in the segment range of the fragments that have the client-requested ranges00:20
notmynamewhich is not at all what I'm seeing00:20
torgomaticso let's say you've got 5+0 coding, so just a 5-way stripe00:20
notmynameoh, and fragment range anchored (ie 0) at the segment start00:20
notmynameok00:20
torgomaticyou take your 3000-byte object and turn it into 1000, 1000, 1000 segments00:20
notmynameok00:20
torgomaticthen you take your 1000-byte segment and turn it into 200, 200, 200, 200, 200 fragments00:21
torgomaticthen do it twice more00:21
notmynameok00:21
torgomaticso 5 object servers have 600 bytes apiece00:21
torgomaticfor a total of 300000:21
torgomaticso if someone wants bytes 1500-1600, you have to go get the middle segment00:21
torgomaticso that's bytes 1000-199900:21
notmynameright00:22
torgomaticand that's the middle third of each segment, so bytes 200-39900:22
torgomaticand that's what goes to each object server00:22
notmynameok. I think I get it now00:23
notmynameto quote myself, "so there's this thing called erasure coding. it's complicated"00:23
torgomaticyep, it is00:25
torgomaticanyhow, did you get a repeatable failure for a ranged GET? If you did, tell me and I'll see about making a unit test out of it00:26
notmynameso much in EC, including this, only makes sense when I'm visualizing it as a 2-dimensional array across the drives00:26
notmynamenah, I got the hangs on the functional tests and then went to the range code to figure that out. and here we are :-)00:26
torgomaticit's basically https://www.youtube.com/watch?v=qHQZcRPqUkY00:27
notmynameI was thinking more of https://www.youtube.com/watch?v=lVZ8Ko-nss400:28
notmynamegotta run. kid duty time00:29
notmynametorgomatic: thanks for the help00:30
torgomaticnp00:30
notmynameI might tackle it again tonight. or more likely, tomorrow am in the office00:30
claygwhoa00:47
claygshri: what version of swift?  are they all from that same account hash?  are the other primary nodes for that account having lock timeouts?00:49
*** shri has quit IRC00:50
*** kota_ has joined #openstack-swift01:01
*** zhill has quit IRC01:26
*** dmorita has quit IRC01:26
*** jrichli has joined #openstack-swift01:32
*** zhill has joined #openstack-swift01:42
*** tsg has quit IRC01:50
*** kota_ has quit IRC02:21
*** zhill has quit IRC02:23
*** jamielennox is now known as jamielennox|lunc02:32
*** jamielennox|lunc is now known as jamielennox|food02:32
*** haomaiwang has joined #openstack-swift02:35
*** tsg has joined #openstack-swift02:55
*** greghaynes has quit IRC02:58
*** jamielennox|food is now known as jamielennox03:01
*** greghaynes has joined #openstack-swift03:06
*** jbonjean has quit IRC03:20
*** gyee has quit IRC03:41
*** jrichli has quit IRC03:43
*** jrichli has joined #openstack-swift03:45
claygwe have some stupid crazy slow proxy.test_server.TestObjectController test methods04:03
*** kbee has joined #openstack-swift04:04
*** ho has quit IRC04:08
clayghell yeah --with-timer!04:10
claygwtf are you doing test.unit.proxy.test_mem_server.TestObjectController.test_version_manifest_utf8: 1.2433s !?04:10
*** ppai has joined #openstack-swift04:25
mattoliverauobviously utf8's fault :P04:37
openstackgerritJanie Richling proposed openstack/swift: WIP - non-in-process functest mods to support different policies  https://review.openstack.org/16609704:38
claygi think i've tried to make this test used pipelined requests before - i'm getting strange de-ja-vu04:40
mattoliverauclayg: or your just psycic :P04:41
mattoliverau*psychic04:43
*** jrichli has quit IRC04:44
*** kota_ has joined #openstack-swift04:44
claygbah, stupid ... like who thought it was a good idea to write a bunch of HTTP by hand?04:49
claygis it any surprise we got it wrong?04:49
*** nonix4 has quit IRC04:50
*** chlong has quit IRC05:02
claygsome of a -test.unit.proxy.test_mem_server.TestObjectController.test_version_manifest_utf8: 1.1549s05:02
claygso all the tcp_connect's are not the problem - sign05:03
claygsigh05:03
claygfuck these tests!?  test.unit.proxy.test_mem_server.TestObjectController.test_version_manifest_utf8: 1.1443s05:18
claygi would have swore the read(1) in readuntil2crlfs was the problem!05:18
*** chlong has joined #openstack-swift05:19
claygwell, if it's not makefile i don't know what it is - test.unit.proxy.test_mem_server.TestObjectController.test_version_manifest_utf8: 1.1466s05:28
*** tsg has quit IRC05:35
openstackgerritClay Gerrard proposed openstack/swift: Try to make real socket version tests run faster  https://review.openstack.org/16610405:38
claygit helps - but not enough - i respectively bow out05:39
mattoliverauclayg: baby steps are better then backwards ones05:46
*** reed has quit IRC05:55
*** echevemaster has joined #openstack-swift05:57
*** echevemaster has joined #openstack-swift05:57
*** chlong has quit IRC06:01
*** chlong has joined #openstack-swift06:13
*** fifieldt has joined #openstack-swift06:32
*** jamielennox is now known as jamielennox|away06:35
*** Bsony has quit IRC07:01
*** echevemaster has quit IRC07:03
*** fandi has joined #openstack-swift07:05
*** fandi has quit IRC07:06
*** fandi has joined #openstack-swift07:07
*** fandi has quit IRC07:10
*** fandi has joined #openstack-swift07:10
*** fandi has quit IRC07:13
*** fandi has joined #openstack-swift07:14
*** fandi has quit IRC07:17
*** fandi has joined #openstack-swift07:17
*** fandi has quit IRC07:21
*** fandi has joined #openstack-swift07:22
*** ppai has quit IRC07:24
*** fandi has quit IRC07:25
*** fandi has joined #openstack-swift07:26
*** fandi has quit IRC07:29
*** fandi has joined #openstack-swift07:30
*** silor has joined #openstack-swift07:30
*** echevemaster has joined #openstack-swift07:32
*** fandi has quit IRC07:33
*** fandi has joined #openstack-swift07:33
*** ppai has joined #openstack-swift07:35
*** fandi has quit IRC07:37
*** fandi has joined #openstack-swift07:37
*** fandi has quit IRC07:39
*** Bsony has joined #openstack-swift07:43
*** chlong has quit IRC07:45
*** jistr has joined #openstack-swift07:58
*** Trixboxer has joined #openstack-swift07:59
openstackgerritKota Tsuyuzaki proposed openstack/swift: Fix a lack of method arguments at tempauth  https://review.openstack.org/16612908:07
*** geaaru has joined #openstack-swift08:18
*** openstackgerrit has quit IRC08:22
*** acoles_away is now known as acoles08:22
*** openstackgerrit has joined #openstack-swift08:22
*** mmcardle has joined #openstack-swift08:38
*** Bsony_ has joined #openstack-swift08:39
*** Bsony has quit IRC08:40
*** echevemaster has quit IRC08:51
*** mmcardle1 has joined #openstack-swift08:51
*** mmcardle has quit IRC08:52
*** joeljwright has joined #openstack-swift08:53
*** jordanP has joined #openstack-swift09:02
*** classics1 is now known as classicsnail09:10
*** jamielennox|away is now known as jamielennox09:14
*** ppai has quit IRC09:20
openstackgerritKota Tsuyuzaki proposed openstack/swift: Fix a lack of method arguments at tempauth  https://review.openstack.org/16612909:21
*** ppai has joined #openstack-swift09:30
acoleskota_: ^^ thanks!09:30
*** mtreinish has quit IRC09:35
*** mtreinish has joined #openstack-swift09:36
kota_acoles: yeah, you are welcome :)09:52
*** sileht has quit IRC10:07
openstackgerritClay Gerrard proposed openstack/swift: wip: ec reconstructor probe test  https://review.openstack.org/16429110:13
openstackgerritClay Gerrard proposed openstack/swift: Erasure Code Reconstructor  https://review.openstack.org/13187210:13
openstackgerritClay Gerrard proposed openstack/swift: Multiple Fragment Archive support for suffix hashes  https://review.openstack.org/15963710:13
claygalright we'll see what gerrit thinks of this mess10:14
claygpeluse: I think I've either broken some of the probetests - are they weren't quite working right to begin with :\10:14
*** joeljwright has left #openstack-swift10:14
claygpeluse: we should skype about suffix hashes later10:14
*** joeljwright has joined #openstack-swift10:19
*** sileht has joined #openstack-swift10:22
*** sluo_laptop has quit IRC10:26
*** kbee has quit IRC10:26
acolesclayg! what you doing here at this time?10:34
*** erlon has joined #openstack-swift10:42
*** silor has quit IRC10:44
*** ppai has quit IRC10:47
claygacoles: you're an ssync expert - have you given any thought to how we could ship just a .durable marker to a node that just failed right before the commit message?10:51
acolesclayG; you mean it has the .data but just missing .durable?10:51
claygacoles: yes10:52
acolesclayg ^^10:52
acolesclayg: not yet but i will give it some thought10:52
claygthanks10:52
*** ppai has joined #openstack-swift10:53
acolesclayg: ugh. so ssync_receiver tries to open its diskfile to compare timestamp, that open will fail if there is no durable. sounds like another case where we need to be able to say 'no, please construct this diskfile, even if you don't have a durable'10:54
claygah... curious10:55
acolesclayg: ok i'm going to have to ponder that some more, cos we'll either need a way for the receiver to say 'i want something, but it ain't the whole data file', or for the receiver to 'infer' that it can unilaterally add a durable file10:57
claygacoles: it should look a lot like what you did to teach ssync how to POST right?10:57
acolesclayg: yeah, i was just tapping that into keyboard ;)10:58
acolesclayg: well similar10:58
claygbbiab10:58
acolesclayg: for fast-post work i modified the receiver return to be a tuple of hash and encoding of all the timestamps - .data, .meta etc - so adding explicit .durable timestamp in there somehow might work10:59
acolesclayg: i'd need to be able to encode a 'None' when durable is missing11:00
acolesclayg: then sender sends a new verb ('RUGGEDIZE' makes a comeback?) or a POST with .durable timestamp and some special header X-Make-Me-Durable??11:05
*** ppai has quit IRC11:19
*** kota_ has quit IRC11:28
*** ppai has joined #openstack-swift11:32
*** dencaval has joined #openstack-swift11:43
*** haomaiwang has quit IRC11:45
openstackgerritMerged openstack/swift: Fix a lack of method arguments at tempauth  https://review.openstack.org/16612911:48
*** fifieldt has quit IRC11:54
*** fifieldt_ has joined #openstack-swift11:54
*** fifieldt__ has joined #openstack-swift11:58
*** fifieldt_ has quit IRC12:00
*** stockpirate has quit IRC12:05
*** ppai has quit IRC12:15
*** ppai has joined #openstack-swift12:25
*** ppai has quit IRC12:38
*** ppai has joined #openstack-swift12:52
*** panbalag has joined #openstack-swift13:01
*** jrichli has joined #openstack-swift13:31
openstackgerritPrashanth Pai proposed openstack/swift: Refactor server side copy as middleware  https://review.openstack.org/15692313:36
*** jamielennox is now known as jamielennox|away13:36
openstackgerritPrashanth Pai proposed openstack/swift: Refactor server side copy as middleware  https://review.openstack.org/15692313:39
*** acoles has left #openstack-swift13:51
*** acoles has joined #openstack-swift13:51
*** ChanServ sets mode: +v acoles13:51
*** mariusv has quit IRC13:51
*** mariusv has joined #openstack-swift13:53
*** mariusv has quit IRC13:53
*** mariusv has joined #openstack-swift13:53
*** raginbajin has joined #openstack-swift13:55
openstackgerritJanie Richling proposed openstack/swift: WIP - non-in-process functest mods to support different policies  https://review.openstack.org/16609714:01
*** thumpba has joined #openstack-swift14:06
*** thumpba_ has joined #openstack-swift14:07
*** Gu_______ has joined #openstack-swift14:07
*** thumpba has quit IRC14:11
*** Gu_______ has quit IRC14:15
*** ppai has quit IRC14:15
*** vinsh has joined #openstack-swift14:22
*** vinsh has quit IRC14:23
*** ppai has joined #openstack-swift14:28
*** tsg_ has joined #openstack-swift14:28
*** ppai has quit IRC14:34
*** dencaval has quit IRC14:39
*** vinsh has joined #openstack-swift14:44
*** mahatic has joined #openstack-swift14:47
*** os1 has joined #openstack-swift14:48
*** vinsh has quit IRC14:48
acolespeluse: hi, i'm adding cards to trello for future 'todo's', is that the right thing? is there a way to mark them as low priority?14:51
*** a1|away is now known as AbyssOne14:53
notmynameacoles: sounds good, thanks. tag them with some color. I don't think there's any color used yet except red for the gotta-be-in-beta items14:56
*** dencaval has joined #openstack-swift14:59
pelusecorrect, I will add a yellow color today for those things that are 'stretch goals' but not requirements so feel free to use that color if something is obviously in that category (or bring it up here if its not clear)15:01
peluseand no color, of course, means "future sometime" :)15:01
acolespeluse: notmyname ok15:02
acolespeluse: i prefer stuff on trello, comments in gerrit get easily lost15:03
peluseditto15:03
acolesin other news, we had a partial solar eclipse this morning15:03
acolesbut it was cloudy :(15:04
*** reed has joined #openstack-swift15:06
*** openstackgerrit has quit IRC15:21
*** openstackgerrit has joined #openstack-swift15:22
openstackgerritAlistair Coles proposed openstack/swift: Add fragment index support to obj server and ssync  https://review.openstack.org/16518815:33
openstackgerritAlistair Coles proposed openstack/swift: Per-policy DiskFile classes  https://review.openstack.org/16512515:33
openstackgerritAlistair Coles proposed openstack/swift: Multiple Fragment Archive support for suffix hashes  https://review.openstack.org/15963715:33
openstackgerritAlistair Coles proposed openstack/swift: Diskfile decides if durable is written based on policy  https://review.openstack.org/16520815:33
*** nellysmitt has joined #openstack-swift15:35
acolesmattoliverau: ^^ hopefully addressed your comments on 165125, thanks for reviewing!15:40
*** Nadeem has joined #openstack-swift15:48
*** welldannit has joined #openstack-swift15:55
*** GlennS has joined #openstack-swift15:59
GlennSHi, I'm wondering what would be the quickest way in Swift to delete a folder and all its sub-folders? I haven't found any documentation for this. (I appreciate folders are somehow not real in swift.)16:04
*** mahatic has quit IRC16:05
*** silor has joined #openstack-swift16:11
openstackgerritAlistair Coles proposed openstack/swift: Enable in-process functional test policy to be configured  https://review.openstack.org/15920516:14
clayghyeoh!16:17
acolesclayg: morning!16:18
acolesclayg: if you can put your +2 back on patch  165125 maybe we can get it landed (if you're happy with it still)16:19
claygGlennS: scrool down the "Bulk Delete" -> http://docs.openstack.org/developer/swift/middleware.html?highlight=bulk#module-swift.common.middleware.bulk16:19
acolescome on patchbot ... patch 16512516:20
patchbotacoles: https://review.openstack.org/#/c/165125/16:20
claygacoles: NO!  you've *ruined* it!16:20
acolesclayg: i aim to please ;)16:20
*** mahatic has joined #openstack-swift16:20
claygacoles: hey you didn't by chance fix my suptid missing @patch_policies rebase screw up on patch 159637 did you?16:20
patchbotclayg: https://review.openstack.org/#/c/159637/16:20
acolesi did16:20
acolesmore ruination16:21
acolesclayg: i'm going to put some thoughts about ssync & missing durable on a trello card in a while16:22
acolespeluse: ping16:23
claygacoles: sweet!16:23
claygacoles: i don't think i quite followed your explination of fname_to_ts on the replicated diskfile16:24
claygacoles: like you said reconstructor - but I guess you meant ssync?16:24
acolesclayg: see my follow on comment16:25
claygi thougth i did :\16:25
acolesbut yeah it would be ssync16:25
acolesok hang on, lets reload that context16:25
pelusepong16:26
claygso it's *yield_hashes* acctually it's used as part of the trailing filter impl16:26
peluseyes16:26
claygbut that's a manager method - soo......16:26
GlennSthanks clayg, I'll tkae a look16:26
pelusetox16:28
acolesclayg: if i ripped it out of 165125 the the dependent patch would have a problem16:28
claygERROR:   py27: commands failed16:28
claygoh damn, too slow ^ peluse that was for you16:28
claygscrew that patch!  we'll fix it then16:28
acolespeluse: hi, got a question for you, can i just finish with clay on fname_to_ts?16:29
pelusesure16:30
acolesclayg: yeah, so it needs fixing to be diskfile manager impl specific yield hashes (and i'm buzzing about that taking advantage of gather_ondisk_files)16:30
peluseheh, nice clayg.  you responded faster than my VM :)16:30
GlennSclayg: I take it middleware is something that my CDN needs to have installed on their end for me to be able to use?16:30
acolesclayg: but i'm all frazzled by the patch dependencies ?!?16:30
peluseI'm bedazzled16:30
acolespeluse: ok, i'm looking at trello https://trello.com/c/W4TkwVDS/144-cleanup-also-what-s-the-difference-between-x-backend-node-index-and-x-object-sysmeta-ec-archive-index16:32
acolespeluse: and i can't see where these headers are set, like in the proxy i presume but i couldn't find it - am i beng stupid or is it in a patch that hasn't yet landed?16:32
peluseOK, give me a min16:33
acolessure16:34
claygGlennS: which provider?  try to call /info on it.16:35
claygGlennS: http://docs.openstack.org/developer/swift/api/discoverability.html?highlight=discover#discoverability16:36
claygGlennS: mine says it has Additional middleware: bulk_delete16:36
claygacoles: I've given them more useful names like 'git checkout -b rebase-here'16:37
openstackgerritpaul luse proposed openstack/swift: Make get_dev_path() treat moun_check literally...  https://review.openstack.org/16630716:37
claygthe literal *moun*_check sounds tricky :\16:38
peluseclayg, so this was a bit more of a PITA than I thought it would be ^^^ but I do need it for ECrecon.  Stupid commit msg!16:38
peluseacoles, OK wil go look at your question now16:38
acolesdid he mean moon_check?16:38
claygecRec ?16:38
peluseha!16:38
acolesdid he mean ecWreck :)16:39
peluseholy cow it must be Friday!16:39
claygyeah thats how to say it - the eck-rec16:39
clayg- the frag-fixer?16:40
peluseacoles, so the second one is in the footer on an EC put and defined in the policy.  Will check on the first right onw16:40
*** EmilienM is now known as EmilienM|afk16:41
peluseacoles, and the 2nd is on the reconstructor patch16:42
claygacoles: idk if self._diskfile.manager is so much better than self._diskfile._mgr?16:43
acolespeluse: ok i see the second now, thx16:43
peluseI think I can probably just use the first in the reconstructor.  It didn't exist when I started16:44
*** tsg_ has quit IRC16:44
peluseso if you want to ignore that trello card, that's fine, I'll throw it in my name as part of the reconstructor16:44
claygwhat was getting me is that I'm never sure if I should call ._mgr or ._diskfile._mgr - adding the alias just means we'll also have instances where the code will say ._diskfile.manager and .manager - but instead of only one way working we'll have two16:45
claygif the @properties somehow made it so you could always say self.manager and get the thing you wanted - then I'd be down, because people would probably just do that than try to remeber which under attr has the damn thing16:46
GlennSclayg: it's Memset16:46
clayg*and* i want to get rid of some of those other changes to the replicated diskfile16:46
clayghey that's cool -> https://github.com/Memset/sftpcloudfs16:48
claygdidn't chmouel and redbo both write one of those two?  maybe it's like the thing to do.16:48
claygchmouel: what the heck is this -> https://github.com/cloudfs/ftp-cloudfs16:50
acolesclayg: hmm. so DiskFile has a manger property, it constructs a DiskFileWriter and DiskFileWriter either creates its own manager property so it can use self.manager or it just holds a ref to its DiskFile parent and calls self.diskfile.manager? Are you saying you prefer the first? Either works, I tend to prefer the second because if you take the first approach for every property that DiskFileWriter might want to inherit fro16:55
acolesm DiskFile you end up with more lines of code in DiskFileWriter where one line (self.diskfile = diskfile) would do.16:55
claygman, i can never seem to find storage urls from public providers - like the auth endpoint is always published - but without the catalog you never know what's the real swift endpoint16:56
claygi wonder if you could crowd source it16:56
acolesclayg: Arguably for manager it makes sense to do first because its like a 'hub' for all those helper methods16:56
claygacoles: i don't much care for def some_useful_thing(self): return self._mgr.some_useful_thing()16:57
claygi'd much rather see the place calling self.some_useful_thing() just flipping tell me it's defined on the manager with self.manager.some_useful_thing()16:58
claygin the weird case of the writer where it has to proxy through the diskfile to get to a manager I think i could stand a @property so the writer can still call self.manager.some_useful_thing() (which the property translates to self._diskfile.manager or something16:59
acolesclayg: ok which specific example are we looking at, i thought i'd reverted the place i did that with get_ondisk_files?16:59
claygor ._mgr or ._manager - i don't really care what it's called16:59
clayginvalidate_hash I think?16:59
acolesright, but there's a reason for that, iirc, let me check16:59
*** zhill has joined #openstack-swift17:00
claygacoles: nah, i had originally splew'd the module functions all over the classes that were using them - but that turned out to be wrong - i eventually realized we should just do it all on the manager17:04
acolesclayg: oh boy you know i actually reverted invalidate_hash back to a self_strip or whatever today, and then convinced myself that i would break a dependent patch :(17:05
claygbecause while the writer is the *primary* call site for invalidate_hash and it would make sense to override implementation specific behavior there - the manager's got a bunch of quarantine functionality that eventually call into invalidate_hash17:06
acolesi'm going to work on crypto...17:06
claygi'm *pretty* sure I implemented it on the manager17:06
claygacoles: wfm - I'm going to go on a rebase cleanup tear17:06
claygacoles: anyway - are you buying into diskfile.manager = manager and DiskFileWriter.manager = @property self._diskfile.manager ?17:08
acolesclayg: let me go look at inavlidate_hash, cos unless i ahd a reason then you are right17:08
claygacoles: if you had a reason I'll find it when I get there17:08
acolesk that works too17:08
claygacoles: but I'll also add it then - so we can both see why it has to work that way17:09
acolessorry, i thought i'd moved things the way you were asking but misunderstood you17:09
claygacoles: i wasn't complaing - i thogutht they were find - two obvious ways to do it but only one way works17:09
claygmattoliverau was complaining about accessing a under atter - but the alias ended up making it worse for me17:10
claygman i misspell fine as find *a lot*17:10
claygthere was something I couldn't type yesterday...17:11
claygstupid muscles17:11
acolesi ahd no porbelm undrestadning :)17:11
clayglol17:11
claygacoles: have you looked at https://review.openstack.org/#/c/156825/817:12
claygit's the proxy method extraction refactor on master17:12
acolesno not yet17:13
claygacoles: i was to head over there I think i'd be looking at re-organizing and auditing some of the test coverage - i mean the code is sorta obviously better chunked up - so the only real question is if we missed something trying to copy and paste that stuff into new methods17:14
acolesk17:15
acolestbh i don't think i'll get there today17:16
*** jordanP has quit IRC17:16
*** zaitcev has joined #openstack-swift17:17
*** ChanServ sets mode: +v zaitcev17:17
*** jistr has quit IRC17:19
*** openstackgerrit has quit IRC17:21
*** openstackgerrit has joined #openstack-swift17:22
*** dmorita has joined #openstack-swift17:22
*** Bsony_ has quit IRC17:25
acolespeluse: just ome more thought on those node index headers - if the node index does not need to be persisted in object metadata then X-Backend-Node-Index is a lot more succinct than X-Object-Sysmeta-Ec-Archive-Index :)17:27
*** gyee has joined #openstack-swift17:27
*** jkugel has joined #openstack-swift17:28
acolesclayg: so is this what you mean re invalidate_hash http://paste.openstack.org/show/193983/ ?17:31
acolesclayg: give or take the "_diskfile."17:31
acolesclayg: i think i got it in my head that we'd be passing frag_index to invalidate_hash, but yeah, that was wrong17:32
*** tsg has joined #openstack-swift17:33
claygacoles: yeah i've got that17:34
claygand I'm trying to decide what to do with quarantine_renamer17:34
claygbecause *honestly* - while a diskfile *should* be able to override that stuff we don't need it17:34
claygit calls invalidate_hash - but at the end of the day the ecdsikfilemanager's invalidate_hash is *exactly* the module method17:35
claygand not plubming quarantine_renamer (so it can be "fixed" to call the the right invalidate_hash) means the reader doesn't need a diskfile reference17:35
claygso I think i'm going to rip it out - and invalidate_hash too17:36
claygbah, crap i have a bunch of tests that expect invalidate_hash to be on a amanger17:37
*** nellysmitt has quit IRC17:37
acolesclayg: its always the tests that make small change into a big one !17:37
clayglol17:38
acolesclayg: ok i am leaving invalidate_hash fixing and/or ripping out to you man ;) i'm going to write my ssync thoughts down before i disappear17:39
*** jbonjean has joined #openstack-swift17:42
*** mmcardle1 has quit IRC17:47
*** dmorita has quit IRC17:47
*** fandi has joined #openstack-swift17:47
*** fandi has quit IRC17:47
*** dmorita has joined #openstack-swift17:48
claygdoes anyone else thing we can't have X-Backend-Node-Index, X-Backend-Ssync-Frag-Index, and X-Object-Sysmeta-Ec-Archive-Index that all mean the same thing?17:51
acoles+117:52
*** dmorita has quit IRC17:54
claygacoles: ok - you get to pick then!17:55
acolesclayg: i think peluse is on it. I like the shortest one.17:55
acolesclayg: of course, another answer is to have them all mean *different* things ;)17:56
*** dmorita has joined #openstack-swift17:57
*** Bsony has joined #openstack-swift17:58
claygi love it when I find some wft code - then go look at the review where I approved it - with a comment like "i'm not sure about this bit buth looks ok otherwise"18:12
acolesclayg: https://trello.com/c/UjVTwXj7/154-optimize-ssync-to-not-replicate-data-file-when-only-durable-is-missing18:13
*** Nadeem has quit IRC18:15
*** rdaly2 has joined #openstack-swift18:16
*** acoles is now known as acoles_away18:17
*** geaaru has quit IRC18:18
peluseclayg, acoles_away:  yeah I'll cleanup the dup headers and pick the shortest name :)18:20
claygtorgomatic: do you think it'd be really hard on PUT to know what node-index gaps you're filling in for as you're connecting?18:33
claygtorgomatic: like what if Putter was more like GETorHEADHandler - and took a node_iter18:34
claygoh well, i'm not going to do it until after patch 164950 anyways...18:37
patchbotclayg: https://review.openstack.org/#/c/164950/18:37
*** jdaggett has quit IRC18:39
*** dmorita has quit IRC18:46
*** tdasilva has quit IRC18:47
*** Fin1te has joined #openstack-swift18:53
*** tdasilva has joined #openstack-swift18:54
*** tdasilva has quit IRC19:04
*** EmilienM|afk is now known as EmilienM19:10
*** silor has quit IRC19:13
*** h_m has quit IRC19:14
*** tdasilva has joined #openstack-swift19:17
*** tdasilva is now known as tdasilva_19:18
*** tdasilva has joined #openstack-swift19:20
tdasilva_acoles_away: panicbnc is a little shaky today19:24
*** h_m has joined #openstack-swift19:26
openstackgerritJanie Richling proposed openstack/swift: WIP - non-in-process functest mods to support different policies  https://review.openstack.org/16609719:32
*** mahatic has quit IRC19:47
pelusenice Janie!19:57
*** tdasilva_ has quit IRC20:03
jrichlipeluse: thanks!20:06
*** jdaggett has joined #openstack-swift20:08
*** Bsony has quit IRC20:10
*** Bsony has joined #openstack-swift20:11
*** erlon is now known as erlon_away20:21
*** tellesnobrega has quit IRC20:34
claygpeluse: so i've managed to tease out why get's from handoffs isn't working20:35
claygi think we need to merge some of the out standing per-policy-diskfile -> ec-probe-test chain so we can start fixing stuff20:36
*** tsg_ has joined #openstack-swift20:40
*** tsg has quit IRC20:41
*** tellesnobrega has joined #openstack-swift20:44
notmynamelooks like the OpenStack summit presentation accept/reject emails are getting delivered now20:46
jrichlinotmyname: good results so far?20:53
notmynamehttps://www.openstack.org/summit/vancouver-2015/schedule/20:54
notmynamehttp://sched.co/2qcL is going to be the best evar!20:55
notmynameand http://sched.co/2qbz will be good too :-)20:57
*** Guest__ has joined #openstack-swift21:00
*** tab____ has joined #openstack-swift21:01
*** silor has joined #openstack-swift21:03
*** dmorita has joined #openstack-swift21:05
*** Fin1te has quit IRC21:05
*** Guest__ has quit IRC21:07
*** Guest__ has joined #openstack-swift21:09
*** GearboxL_ has joined #openstack-swift21:13
GearboxL_Question about the object ring... Is it possible to change the zone of a given entry ?  Say I've accidentally ended up with ~20 zones, of which 19 have ~12 entries, and 1 has ~100 entries, thusly giving me very unbalanced zones.21:14
GearboxL_(And leading to those 19 smaller zones being really / completely full, and that 1 zone substantially less full)21:15
*** silor has quit IRC21:15
claygGearboxL_: you must be pre swift 2.0 maybe?21:29
GearboxL_Yeah21:29
GearboxL_Havana21:29
GearboxL_1.1021:29
*** jrichli has quit IRC21:31
clayganyway - no you can't really change the zone21:32
GearboxL_Ok, thanks21:33
claygbut if you remove a device and add a device (with different zone) in the same rebalance you have some control over how many parts move - but some shuffling will occur21:33
GearboxL_*nod*21:33
GearboxL_Is upgrading to 2.2 or later a viable approach here?21:33
claygbasically equal to the amount that you'd get if you just "changed" a zone on a device21:34
claygmaybe - if you wanna make your builders available I could look at the balance/dispersion with the new ring-builder code and see what I would recommend21:34
claygyou could also just go clone it somewhere (or use a vagrant-swift-all-in-one) and then get a copy of your builders and play around with it21:35
*** Guest__ has quit IRC21:35
GearboxL_basically it's this:  We have 21 zones.  20 of them have 12 device nodes in them.  1 has 95.  There are 376 total nodes.  Each node is 4 TB. :/21:35
claygultimately the on-disk ring.gz file has been stable even with all the balance changes - i wouldn't *recommend* it - but you could balance rings with swift master and then distribute them to your older cluster if you like the partition placement better until you can figure out how to do an upgrade21:36
claygGearboxL_: sounds like a great deployment!  with all those zones I'm not really sure why even back in swift 1.10 you're not getting a decent balance21:37
notmynamebalance is good. just that the smaller ones are filling up. makes sense for swift 1.1021:37
*** zhill has quit IRC21:37
claygnotmyname: but all the *disks* are the same size - they should have equal parts - if balance is good I think that means by definition the devices are assigned a number of parts == parts wanted21:39
GearboxL_And this is all in a single cluster.21:39
claygGearboxL_: can you paste your swift-ring-builder blah.builder list output so we can make sure we're on the same page?21:40
GearboxL_yes21:40
claygGearboxL_: are you having problems issues with some of the 4TB drives being more *full* (like acctual df GB on disk) that others?21:40
GearboxL_https://gist.github.com/gabriel-seomoz/1009f08f750a3babe8d321:41
notmynameclayg: but with as-unique-as-possible, it put partitions into a different zone and will not place replicas in the same one. which means that small zones fill up. especially since num_zones >> num_replicas21:41
GearboxL_yup!21:41
GearboxL_lots of drives in the small zones are full21:41
*** Guest__ has joined #openstack-swift21:41
*** tdasilva has quit IRC21:42
GearboxL_this is absolutely our fault for badly managing the zone placement, and I recognize going forward what to change... but recovering from the issue is where I'm at now ;)21:42
claygoic - right - *that* problem - the total weight of the 1 zone with 95 devices is more than one-replicanth - bah21:42
GearboxL_yup21:43
claygso for balance you'd need to assign multiple copies of some parts to the huge zone, and unique-as-possible won't do it - unique-as-balanceable ftw!21:43
*** EmilienM is now known as EmilienM|PTO21:44
GearboxL_so upgrade required to make that happen?21:44
GearboxL_we've been meaning to do the upgrade for ... too long ... but today might be when we have to21:45
GearboxL_Fridays, right? :P21:45
claygheck yeah!21:45
*** rdaly2 has quit IRC21:45
claygGearboxL_: I mean you don't *have* to upgrade - you can do the remove/add devices trick - and just split up the larger zone into smaller ones21:46
GearboxL_Ok21:46
GearboxL_We've got a couple extra boxes that we've been meaning to add as well21:46
GearboxL_so I'm hearing that we should add new capacity in different zones and that it'll pull out of *all* the other zones, inclusively our giant one, reducing the overall problem space && we should also pull nodes out of our giant zone && reallocate it21:46
claygit's always better to have roughly evenly sized zones - but yeah newer swift was will let you trade dispersion (multiple replicas in a failure domain) for balance (making disks not have more parts assigned than wanted)21:47
claygswift *loves* when you add capacity - adding more capacity is *always* an option ;)21:47
GearboxL_Yeah, we goofed by ending up with this disparity of zone size21:47
GearboxL_;)21:47
claygGearboxL_: no worries - we've seen it happen before21:48
GearboxL_thanks for your help21:48
GearboxL_I think I have a sense of how to proceed.21:48
*** jamielennox|away is now known as jamielennox21:49
*** rdaly2_ has joined #openstack-swift21:50
claygGearboxL_: remeber you can do all of this swith swift-ring-builder offline - just makes copies of your rings - play around and see what you like21:50
*** rdaly2_ has quit IRC21:50
claygGearboxL_: I'd try removing devices (maybe a lot) from the too big zone - and adding them back in under a different zone name - rebalance and see what your balance looks like21:51
GearboxL_Are there risks to the actual data in doing that?21:51
GearboxL_Like, could I bisect the too-big-zone safely?21:52
claygheh - it *should* work - you've got three copies ;)21:52
os1Is anyone aware of why /usr/bin/swift-recon-cron places the following lock file/directory: /var/lock/swift-recon-object-cron21:52
os1Also, doesn't Swift need to be deployed such that the swift user is included in the 'lock' group, then?21:53
os1Because otherwise, it will fail whenever trying to write the file.21:53
GearboxL_Since we've filled up a number of the disks on the small zones (to 100%, ugh) is it the case that the data really is in 3 different zones?21:54
claygyeah being full sucks - if only z95 has room that's where they're at21:54
claygrebalancing can't really account for partitions out of place because of handoffs21:55
GearboxL_*nod*21:55
GearboxL_so we gotta get space utilization down by deleting old stuff before we can realistically safely rebalance, huh?21:56
claygyou may be in for some availability woes - but you might already be returning 507's and 404's depending on how many disks are full and what your request node count is21:56
claygGearboxL_: a delete is just another write21:56
GearboxL_Yeah, my users detected this problem. :-(21:57
GearboxL_so I'm clearly suffering an availability problem right now :D21:57
claygand if the nodes with the data you want to delete is on full devices the tombstones just go elsewhere and can't replicte back to cleanup the data files21:57
*** Guest__ has quit IRC21:57
claygwell then screw it - just split the big zone21:57
*** thumpba_ has quit IRC21:58
*** jkugel has left #openstack-swift22:00
claygGearboxL_: this is what I was looking for - > https://bugs.launchpad.net/swift/+bug/135916022:03
openstackLaunchpad bug 1359160 in OpenStack Object Storage (swift) "Problem with disk overflowing" [Undecided,Expired]22:03
GearboxL_easy for you to say... ;)   I have a few hundred TB of user data online that I can't lose.  Not being available is ok, but losing the data wouldn't be.22:03
GearboxL_*looks*22:03
claygoh no - it's ok - you're not going to *loose* anything - it's not a *durablity* issue - just *availability*22:04
claygif you're already getting complaints you're better off just getting the cluster on the path to rightness as quickly as possible22:04
*** jamielennox is now known as jamielennox|away22:05
claygif you had noticed last week that things were starting to look hairy you could have come up with a plan to move more slowly and maybe avoid anyone noticing22:05
GearboxL_Much joy in hindsight. ;)  Strong is the bias there. :D22:05
GearboxL_But I do appreciate what you're saying22:05
GearboxL_thanks for the link.22:07
claygif you don't have some new disks you can add asap getting that one big zone cut down into less than one-replicanth of your weight is the next best thing22:09
claygaside from the rebalance asap - setting handoffs first on the fullest nodes would be the next biggest help22:10
claygif your metadata servers (containers & accounts) are also full - there's some risk of inconsistencies (deleted objects stuck in the listings) the longer that goes on22:11
*** tdasilva has joined #openstack-swift22:12
GearboxL_fortunately, we've done a less terrible job with metadata22:15
GearboxL_we actually do have a bunch of disk that we can bring online22:15
*** erlon_away has quit IRC22:41
peluseclayg, you still hanging around?22:50
openstackgerritpaul luse proposed openstack/swift: wip: ec reconstructor probe test  https://review.openstack.org/16429122:59
*** tsg_ has quit IRC23:00
*** welldannit has quit IRC23:03
*** welldannit has joined #openstack-swift23:10
*** GearboxL_ has quit IRC23:11
*** welldannit has quit IRC23:14
*** os1 has left #openstack-swift23:14
*** Bsony has quit IRC23:18
*** joeljwright has quit IRC23:23
*** tsg has joined #openstack-swift23:34
openstackgerritSHIGEMATSU Mitsuhiro proposed openstack/swift: Fix typo in swift/test/unit/account/test_backend.py  https://review.openstack.org/16642123:43
notmynametorgomatic: if you have a WIP for the range stuff by the time you finish up today, put it on gerrit and I'll take a look23:49
torgomaticnotmyname: sure23:49
*** gyee has quit IRC23:59

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