Tuesday, 2018-11-20

*** hoonetorg has quit IRC00:35
*** hoonetorg has joined #openstack-swift00:37
*** hoonetorg has quit IRC00:40
*** hoonetorg has joined #openstack-swift00:40
*** two_tired has joined #openstack-swift01:48
kota_good morning03:48
openstackgerritPete Zaitcev proposed openstack/swift master: py3: adapt the account server completely  https://review.openstack.org/61350504:39
*** two_tired has quit IRC04:47
*** ccamacho has quit IRC06:24
*** spsurya has joined #openstack-swift06:39
*** mahatic has quit IRC06:51
*** mahatic has joined #openstack-swift06:52
*** ChanServ sets mode: +v mahatic06:52
*** gkadam has joined #openstack-swift07:02
*** mahatic has quit IRC07:12
*** pcaruana has joined #openstack-swift07:20
openstackgerritPete Zaitcev proposed openstack/swift master: py3: port encryption  https://review.openstack.org/60145407:30
*** pcaruana has quit IRC07:34
*** psachin has joined #openstack-swift07:37
*** pcaruana has joined #openstack-swift07:40
openstackgerritPete Zaitcev proposed openstack/swift master: py3: adapt the account server completely  https://review.openstack.org/61350507:53
*** ccamacho has joined #openstack-swift07:54
*** zaitcev has quit IRC08:02
*** e0ne has joined #openstack-swift09:24
*** mahatic has joined #openstack-swift09:41
*** ChanServ sets mode: +v mahatic09:41
*** gkadam has quit IRC11:56
*** gkadam has joined #openstack-swift12:14
*** psachin has quit IRC12:41
*** zaitcev has joined #openstack-swift14:25
*** ChanServ sets mode: +v zaitcev14:25
rledisezhi15:53
rledisezsimple question: right now, the ring is limited to 2 ** 16 devices (65536). how hard would it be to increase this limit? (eg: 2 ** 32)15:55
rledisezit seems quite easy quickly reading the ring (serialize_v1 method and NONE_DEV), but I might be missing something15:55
*** itlinux has quit IRC15:57
*** ccamacho has quit IRC16:20
*** e0ne has quit IRC16:21
DHEI thought it was available to around 32 or so, but it's user configurable at ring creation time16:30
DHEor am I confusing partitions and devices16:30
rledisezDHE: are you talking about the part power? yes, it's a number of bits that define the number of partitions in a cluster16:42
*** itlinux has joined #openstack-swift16:43
rledisezI'm talking about https://github.com/openstack/swift/blob/master/swift/common/ring/builder.py#L43 and https://github.com/openstack/swift/blob/master/swift/common/ring/ring.py#L14816:43
DHEI see...16:44
DHEso device number 65535 can't exist because it would be confused for a gap in the ring profile...16:44
rledisezwell, forget about !I, it's not related, but NONE_DEV, yes, it's a limit16:45
rledisezDHE: exactly16:46
rledisezwe are not there yet, but we are starting to think of it. better be prepared ;)16:48
*** gkadam has quit IRC16:50
DHEI'm mildly jealous....17:08
tdasilvaheh17:26
*** e0ne has joined #openstack-swift17:31
*** e0ne has quit IRC17:44
*** e0ne has joined #openstack-swift17:57
timburkerledisez: i *think* it'd be as "simple" as adding a key to the JSON dict at the front, like device_bits or something, then over in deserialize_v1 we'd validate that it's either 16 or 32 and use that to switch between H and I when we load up the array.array18:03
timburkewe could get pretty far into that space before we'd need to start worrying about the 32-bit limit on the device dict, too -- but even then we could just shift the magic to something like R2NG and start using a 64-bit int for the json size18:05
timburkebiggest downside is that we'd be doubling our memory footprint, so maybe only switch to 32-bit if we *have to*? of course, as long as your part power's something sane, it still shouldn't be that bad (i think)...18:06
DHEwouldn't you need a part_power around 21 or so for such a cluster?18:14
timburkeDHE: yeah -- and that's not so bad. i'm more worried about something inching up towards 30 -- as we are now, you're over a gig just to load up one ring with a pp of 2918:19
timburkeexponents are rough18:19
zaitcevtimburke: did you see my changes to the "encryption" py3 patch?18:24
timburkeyeah -- hoping to look through it this morning18:24
timburkeshould i +A if i'm happy?18:25
zaitcevyes18:25
zaitcevIMHO18:25
zaitcevAlso, I found that my "finish the account" py3 thing didn't take advantage of json.loads monkey-patching for some reason, so I removed some code from there too. But that's less important.18:26
timburkefunny -- i coulda sworn i'd pulled that out on my second push -- w/e18:33
*** pcaruana has quit IRC18:47
*** e0ne has quit IRC19:22
*** itlinux has quit IRC20:39
*** AJaeger has joined #openstack-swift20:53
AJaegerswift team, could you import your rocky translations, please? https://review.openstack.org/61508120:54
patchbotpatch 615081 - swift (stable/rocky) - Imported Translations from Zanata - 1 patch set20:54
timburkenotmyname: ^^^21:10
*** itlinux has joined #openstack-swift21:13
timburkei... what? what is this testing?? https://github.com/openstack/swift/blob/2.19.0/test/unit/common/test_utils.py#L1284-L128921:38
*** rcernin has joined #openstack-swift21:38
tdasilvammm...21:40
tdasilvatimburke: more importantly (IMO) i was wondering how did it get past review, turns out it probably didn't as it was in the initial commit...21:41
tdasilvawas probably temp code never got finished...21:42
timburkeyup...21:42
timburke21:42
zaitcevsio is clearly unused, the rest makes sure that NullLogger has a method that doesn't crash.22:07
mattoliveraumorning22:18
mattoliverau@AJaeger because that's on the stable branch only notmyname has +2/+A writes there. on the swift team anyway.22:20
openstackgerritTim Burke proposed openstack/swift master: py3: encryption follow-up  https://review.openstack.org/61910922:27
timburkezaitcev: ^^^22:31
*** itlinux has quit IRC22:44
openstackgerritMerged openstack/swift master: py3: port encryption  https://review.openstack.org/60145422:45
*** zaitcev has quit IRC23:56

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