*** mvalsecc has joined #openstack-swift | 01:15 | |
seongsoocho | clayg: rledisez thanks for your reply . ( I'm using SATA 7k disk and I will retest with fio ) :-) | 01:30 |
---|---|---|
*** rcernin has quit IRC | 01:37 | |
*** rcernin has joined #openstack-swift | 01:39 | |
*** rcernin has quit IRC | 02:36 | |
*** rcernin has joined #openstack-swift | 03:06 | |
*** evrardjp has quit IRC | 05:33 | |
*** evrardjp has joined #openstack-swift | 05:33 | |
*** rcernin has quit IRC | 05:43 | |
*** rcernin has joined #openstack-swift | 05:55 | |
*** gyee has quit IRC | 06:30 | |
*** m75abrams has joined #openstack-swift | 07:19 | |
*** rcernin has quit IRC | 07:38 | |
*** rcernin has joined #openstack-swift | 07:44 | |
*** rcernin has quit IRC | 07:48 | |
*** rcernin has joined #openstack-swift | 08:01 | |
*** rcernin has quit IRC | 08:16 | |
*** rpittau|afk is now known as rpittau | 08:28 | |
*** rcernin has joined #openstack-swift | 08:32 | |
*** rcernin has quit IRC | 08:46 | |
*** tkajinam has quit IRC | 08:49 | |
*** m75abrams has quit IRC | 09:06 | |
*** mvalsecc has quit IRC | 09:32 | |
*** rcernin has joined #openstack-swift | 09:42 | |
*** rcernin has quit IRC | 09:42 | |
*** LarsErikP has left #openstack-swift | 09:54 | |
acoles | Diplomat: changing hash_path_suffix is documented here https://docs.openstack.org/swift/victoria/install/finalize-installation-ubuntu-debian.html but maybe you are using some installer tool that wrote %SWIFT_HASH_PATH_SUFFIX% in your swift.conf? anyway, sounds like you got it fixed :) | 09:57 |
*** dsariel has quit IRC | 10:42 | |
*** dsariel has joined #openstack-swift | 10:42 | |
*** dsariel has quit IRC | 11:03 | |
*** dsariel has joined #openstack-swift | 11:04 | |
*** m75abrams has joined #openstack-swift | 11:51 | |
*** klamath_atx has quit IRC | 14:44 | |
*** dsariel has quit IRC | 14:46 | |
*** dsariel has joined #openstack-swift | 14:47 | |
*** klamath_atx has joined #openstack-swift | 15:03 | |
klamath_atx | @timburke_ I think you replied to me yesterday about tempauth + keystone, i had a chance to skim over it yesterday but my laptop crashed out and i lost the details, I think it was around making sure pipeline is correct and delayed_auth? | 15:18 |
timburke_ | klamath_atx, yup! i was going to just copy/paste what i'd sent yesterday, but in case you hadn't seen the channel logging, that can be handy in the general case: http://eavesdrop.openstack.org/irclogs/%23openstack-swift/%23openstack-swift.2020-12-01.log.html#t2020-12-01T22:20:28 | 16:18 |
klamath_atx | perfect, thank you! I will give that a try today | 16:20 |
*** gyee has joined #openstack-swift | 16:58 | |
*** rpittau is now known as rpittau|afk | 17:04 | |
*** m75abrams has quit IRC | 17:09 | |
*** camelCaser has joined #openstack-swift | 17:48 | |
*** dsariel has quit IRC | 18:14 | |
openstackgerrit | Tim Burke proposed openstack/swift master: py3: Fix non-ASCII multipart uploads https://review.opendev.org/c/openstack/swift/+/765204 | 20:45 |
timburke_ | i might be a few minutes late for the meeting; got a plumber coming | 20:55 |
*** timburke_ is now known as timburke | 20:56 | |
kota_ | morning | 20:58 |
seongsoocho | morning | 20:59 |
kota_ | seongsoocho: o/ | 21:00 |
mattoliverau | Morning | 21:01 |
timburke | clayg, acoles meeting ping | 21:03 |
*** gregwork has joined #openstack-swift | 21:09 | |
rledisez | timburke: clayg: the "doc" we followed (it's very manual) and the script that put things in a cgroup. You will at least need to update the pattern /srv/node/disk-??-???, it's OVH specific. I think the rest should be fine. | 21:43 |
rledisez | http://paste.openstack.org/show/800670/ | 21:43 |
rledisez | http://paste.openstack.org/show/800671/ | 21:43 |
rledisez | (don't know how long it will stay online on paste) | 21:43 |
clayg | rledisez: thanks so much! i'll pull those down and save that off somewhere | 21:43 |
mattoliverau | just pondering part-power increase, I wonder if we managed to implement the old primary ring stuff that we talked about at the PTG, I wonder if that would mean we could re-vamp part-power increase and still have the consistency engine running? I mean we push a new ring with the new part power, but still know where the "old" primaries were. Would we need to relink at all? | 21:44 |
mattoliverau | I think I need to re load part-power increase in my head, it's been a few years. | 21:44 |
mattoliverau | ..and drink some coffee :P | 21:44 |
acoles | IIRC an early version of the part-power increase (spec not code) has the new partitions' hard links created in a different dir so the replication wasn't impeded, then the dir's got flipped. But I think that wasn't pursued because it messed with the path-to-data-file. | 21:52 |
mattoliverau | Yeah, and I guess it's the splitting of partitions that the relinker does too. | 21:53 |
acoles | relinker, and for duration of relinking diskfile creates an extra hardlink in the new partition for new PUTs | 21:56 |
*** dsariel has joined #openstack-swift | 21:57 | |
mattoliverau | Yeah, was just trying to think how we _could_ get automated part power increase without consistency engine down time. Just spitballing. Maybe the proxy can have both a copy of the old and new partpower ring, so it know where things are located (in both partions (old and new ring)), though we know we're in a part power adjustment from ring meta data, so actually we maybe already able to do this with the 1 ring, | 22:14 |
mattoliverau | programatically. Then we'd need some smarter in-line replication that could know what obj it's going to push and redirect to new part power location to do the split. But that means storing more then 1 ring and tsync (or ssync extensions). Probably a better way with existing pp increase mechanisms. | 22:14 |
*** rcernin has joined #openstack-swift | 22:34 | |
*** tkajinam has joined #openstack-swift | 23:00 | |
*** zaitcev has quit IRC | 23:05 | |
*** mvalsecc has joined #openstack-swift | 23:06 | |
timburke | :-/ this seems wrong: https://github.com/openstack/swift/blob/2.26.0/swift/common/ring/builder.py#L198-L209 | 23:10 |
timburke | shouldn't weight_of_one_part look more like sum(weight)/parts, not the inverse? | 23:11 |
mattoliverau | if we're looking at the avg weight (mean) per part then yeah it seems to be the wrong way round. the way it currently is seems to be the avg unit of weight in parts. | 23:54 |
mattoliverau | So the latter would be: how many parts is a single weight unit. ie 1 weight unit is x. When I look at weight_of_one_part (at least the name) I'd suspect it to be the opposite, 1 part is y weight. | 23:57 |
mattoliverau | But I guess we need to look at whats using this code to determine, maybe it's just a badly named method. | 23:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!