Thursday, 2019-07-18

*** gyee has quit IRC00:46
openstackgerritTim Burke proposed openstack/swift master: Give ECAppIter greenthreads a chance to wrap up  https://review.opendev.org/66577300:58
*** baojg has joined #openstack-swift01:13
openstackgerritTim Burke proposed openstack/swift master: Give ECAppIter greenthreads a chance to wrap up  https://review.opendev.org/66577301:48
*** threestrands has joined #openstack-swift02:43
*** redrobot has quit IRC03:32
*** psachin has joined #openstack-swift03:36
*** Guest99405 has joined #openstack-swift03:39
*** ccamacho has quit IRC05:33
*** pcaruana has joined #openstack-swift05:44
*** rcernin has quit IRC06:44
*** threestrands has quit IRC07:24
*** ccamacho has joined #openstack-swift07:36
*** early has quit IRC08:26
*** early has joined #openstack-swift08:29
*** new_student1411 has joined #openstack-swift08:37
*** tkajinam has quit IRC08:40
*** zaitcev__ has joined #openstack-swift09:25
*** ChanServ sets mode: +v zaitcev__09:25
*** tdasilva_ has quit IRC09:25
*** tdasilva_ has joined #openstack-swift09:26
*** ChanServ sets mode: +v tdasilva_09:26
*** zaitcev_ has quit IRC09:28
*** tdasilva_ has quit IRC09:47
*** tdasilva_ has joined #openstack-swift09:47
*** ChanServ sets mode: +v tdasilva_09:47
*** thiago__ has joined #openstack-swift10:15
*** ChanServ sets mode: +v thiago__10:15
*** tdasilva_ has quit IRC10:17
*** new_student1411 has quit IRC10:23
*** new_student1411 has joined #openstack-swift10:23
*** takamatsu has joined #openstack-swift10:37
*** tesseract has joined #openstack-swift11:38
*** new_student1411 has quit IRC11:49
*** thiago__ has quit IRC12:26
*** thiago__ has joined #openstack-swift12:27
*** ChanServ sets mode: +v thiago__12:27
*** zaitcev__ has quit IRC12:27
*** thiago__ has quit IRC12:33
*** thiago__ has joined #openstack-swift12:33
*** ChanServ sets mode: +v thiago__12:33
*** tdasilva_ has joined #openstack-swift12:35
*** ChanServ sets mode: +v tdasilva_12:35
*** thiago__ has quit IRC12:38
*** zaitcev__ has joined #openstack-swift12:39
*** ChanServ sets mode: +v zaitcev__12:39
*** new_student1411 has joined #openstack-swift12:47
*** mvkr_ has quit IRC12:56
*** Guest99405 is now known as redrobot13:13
*** hoonetorg has quit IRC13:28
*** tdasilva_ has quit IRC13:41
*** tdasilva_ has joined #openstack-swift13:42
*** ChanServ sets mode: +v tdasilva_13:42
*** tomha has joined #openstack-swift14:00
*** tomha has quit IRC14:01
*** tdasilva_ has quit IRC14:09
*** tdasilva_ has joined #openstack-swift14:09
*** ChanServ sets mode: +v tdasilva_14:09
*** tdasilva_ is now known as tdasilva14:15
*** ccamacho has quit IRC14:15
*** ccamacho has joined #openstack-swift14:20
*** tdasilva has quit IRC15:05
*** tdasilva has joined #openstack-swift15:05
*** ChanServ sets mode: +v tdasilva15:05
*** hoonetorg has joined #openstack-swift15:26
*** tdasilva_ has joined #openstack-swift15:26
*** ChanServ sets mode: +v tdasilva_15:26
*** tdasilva has quit IRC15:28
*** zaitcev__ is now known as zaitcev15:41
*** gyee has joined #openstack-swift16:27
*** zaitcev has quit IRC16:36
*** ccamacho has quit IRC16:37
*** zaitcev has joined #openstack-swift16:53
*** ChanServ sets mode: +v zaitcev16:53
claygtdasilva_: yeah I think the fact that you can update the content-type of a hardlink-target but the hardlink (and container listing) don't get updated isn't great17:29
tdasilva_clayg: yeah, but if we want to provide the functionality, i'm not sure how to get around it...fwiw, it's only the container listing that doesn't get updated17:30
claygtdasilva_: give that the client probably just wants to change the content-type it might be useful to know that you can post to a symlink/hardlink to change it's content-type and update the container listing (even thought we return 307)17:30
claygtdasilva_: well symlink=get will still show the old content-type too17:30
clayggiven that the lifecycle of the link's content-type is compleatly decoupled from the target maybe there's a better affordance in the API - it's difficult to make it transparent because the lifecycle of the targets ctype is decouopled from the etag17:32
tdasilva_right!17:35
claygI think the truth is just that hardlinks are tied to the .data (etag & size) and the content-type stuff is just convience17:37
tdasilva_yeah, so might be worth getting rid of content-type??17:39
clayga few ideas might make that more clear 1) only set content-type on the hardlink if the client doesn't explicitly set it  2) simiarlly set application/symlink on soft links if the client doesn't set it 3) try to document that you can update content-type of symlinks in the container listing using a POST despite the 307 response (!?)17:39
claygi'm not really sure any of those are good ideas mind you 😁17:40
tdasilva_i'm not sure they help solve the issue...for the content-type of the symlink itself, why not enforce that it must always be application/symlink17:45
tdasilva_?17:45
*** tdasilva_ is now known as tdasilva17:45
*** hogepodge has quit IRC17:45
*** clayg has quit IRC17:45
*** hogepodge has joined #openstack-swift17:47
*** clayg has joined #openstack-swift17:48
*** ChanServ sets mode: +v clayg17:48
timburkeclayg, i think i like all of those ideas -- seems to put more power in the client's hands, which is generally a good thing17:53
timburketdasilva, we *could* enforce a content-type for symlinks at PUT time... but we we'd have to write down whatever the client sent us at POST. in light of that, idk that there's good reason to impose requirements at PUT time17:55
clayghow on earth does the object server understand how to 412 an if-match correctly on SLOs and respect multipart-manifest=get17:55
timburkeslo ignores the 412 ;-) https://github.com/openstack/swift/blob/2.21.0/swift/common/middleware/slo.py#L704-L71117:56
timburkeof, but there's more to it than that! i'd kinda forgotten about https://github.com/openstack/swift/commit/2d25fe6 ...17:59
tdasilvatimburke: good poing on not being able to enforce on POST :/18:01
claygtimburke: yeah so but that change didn't add any new code to the object-server - the existing `resolve_etag_is_at_header` machineary must have somehow been sufficient18:03
timburkeyup; that all came in with encryption18:03
claygdoes SLO somehow add some x-backend header to ... every GET/HEAD like "just in case"18:03
timburkeyup18:03
*** psachin has quit IRC18:04
timburkeit's the call to update_etag_is_at_header18:04
timburke...which we skip on ?multipart-manifest=get18:04
claygright, right, ok... ok... so 🤔18:05
timburkeactually... i wonder if that machinery first came in with EC...18:05
*** irclogbot_3 has quit IRC18:07
*** altlogbot_1 has quit IRC18:07
timburkelooks like x-backend-etag-is-at came in with https://github.com/openstack/swift/commit/b1eda4a18:08
timburkeand it was refactored to take a list of headers in https://github.com/openstack/swift/commit/03b762e18:08
*** irclogbot_0 has joined #openstack-swift18:09
*** altlogbot_1 has joined #openstack-swift18:09
* clayg timburke: so, this works:18:25
clayg            final_etag = resolve_etag_is_at_header(18:25
clayg                req, HeaderKeyDict(self._response_headers))18:25
claygbut i still to have to figureout how to normalize the quoting :\18:26
claygalso, i guess SLO doesn't set the x-backend header on PUT18:30
timburkeno -- since the only if-match-y semantic PUT supports is `If-None-Match: *`18:33
openstackgerritThiago da Silva proposed openstack/swift master: Add rolling upgrade tests  https://review.opendev.org/62666318:35
*** dsariel has joined #openstack-swift18:41
*** dsariel has quit IRC18:43
claygtimburke: so is the coupling less bad if slo sets it on PUT so that symlinks can validate the client provided etag?18:43
claygthere's a similar problem in versoined writes where it has to notice the object in the listing it's creating a hardlink too (like on a stack DELETE) has a slo_etag and it uses that instead18:44
claygwe could side step most of this by requiring hardlink clients to use the etag of the manifest 🤷‍♂️18:44
timburkeclayg, yeah, i'm kinda coming around to that... largely because we want symlink so far to the right in the pipeline18:46
timburkeit's kinda annoying from a client perspective... but at the same time, it's not like it's *that* hard to get the value you need18:47
clayga hardlink *is* pretty low-level - i just hate that SLO's manifest etag is really hard to predict - you kinda just have to look it up!18:47
timburkeyup :-(18:48
*** dsariel__ has joined #openstack-swift18:48
timburketwo proxy servers may well write down different bytes-on-disk for the same SLO18:48
timburkeit's not like we include sort_keys or anything in slo...18:49
*** new_student1411 has quit IRC19:05
openstackgerritGhanshyam Mann proposed openstack/swift master: Add integrated gate tempest and grenade job  https://review.opendev.org/67155419:16
openstackgerritGhanshyam Mann proposed openstack/swift master: Add integrated gate tempest and grenade job  https://review.opendev.org/67155419:17
timburkeoh, cool: swiftclient isn't *completely* useless in trying to make symlinks: swift upload c - < /dev/null --object-name link -H 'x-symlink-target: c/o'19:23
timburkenot exactly pretty, but it seems to work19:24
*** e0ne has joined #openstack-swift19:38
*** pcaruana has quit IRC20:01
*** tesseract has quit IRC20:05
*** mvkr_ has joined #openstack-swift20:05
*** tomha has joined #openstack-swift20:08
*** tomha has quit IRC20:09
*** dsariel__ has quit IRC20:10
claygthat's awesome that you can stuff the `- < /dev/null` in the middle of the command option slike that 🤯20:11
openstackgerritTim Burke proposed openstack/swift master: py3: Bring functional/test_object.py under test; add func-ec-py37 job  https://review.opendev.org/64589521:05
clayganyone know anything about dsvm-functional and account.name vs AUTH_swiftprojecttest1?21:05
timburkeclayg, i know a bit about that sort of thing...21:05
timburkewhat are you seeing?21:05
claygAUTH_59b53071a4fd469cb3e4586bb1303a2c != AUTH_swiftprojecttest1 in places where the func tests are building the path from self.account.name21:06
clayghttp://logs.openstack.org/57/633857/4/check/swift-dsvm-functional/50c6b7e/job-output.txt.gz21:06
claygall three dsvm func jobs on the change failed21:06
clayginiset /etc/swift/test.conf func_test account swiftprojecttest121:10
clayg seems legit21:10
timburkethose new tests seem to be the only ones that ever look at self.account.name... i think it's going to be the project name rather than the project id, which is what keystone's going to be shoving into the storage url21:12
claygoh bummer21:12
claygsymlink tests doing tf.parsed[0].path.split('/', 2)[2]21:14
timburkehttps://github.com/openstack/swift/blob/master/test/functional/test_container.py#L1633-L1638 might be useful?21:15
timburkeoh, yeah -- you already found parsed.path21:15
*** e0ne has quit IRC21:17
openstackgerritClay Gerrard proposed openstack/swift master: symlink-backed versioned_writes  https://review.opendev.org/63385721:37
*** tkajinam has joined #openstack-swift22:58
*** rcernin has joined #openstack-swift23:15
*** tdasilva has quit IRC23:19
zigotimburke: Did you try with a very recent kernel, maybe?23:30
zigo(re: the ERANGE thing...)23:31
openstackgerritThomas Goirand proposed openstack/swift master: Fix test_parse_get_node_args  https://review.opendev.org/67089423:33
zigoThis one should pass the pep8 tests.23:33
* zigo waves from Debconf in Curitiba, Brazil. :)23:33
mattoliveraumorning23:50

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