Friday, 2019-12-13

*** dosaboy has joined #openstack-swift00:23
*** rcernin has joined #openstack-swift00:48
*** gyee has quit IRC00:52
tdasilvain tempurl we strip lose any other query param besides sig and expires, is that a security mechanism: https://github.com/openstack/swift/blob/master/swift/common/middleware/tempurl.py#L599  ?02:06
tdasilvait prevents a GET with version-id02:06
tdasilvano range requests either, right?02:11
*** diablo_rojo has joined #openstack-swift03:30
*** psachin has joined #openstack-swift03:32
mattoliverauwell range is a header, so range requests probably work. But slo's also have problems, but that I think was by design.04:31
mattoliverauBut it was one thing to go back and revisit04:31
*** psachin has quit IRC04:48
timburkeso thinking about tempurl... i'm inclined to say that a today's notion of a tempurl for an object should only be useful for the *current* version -- i'm not entirely sure we should even include the version-id...04:54
timburkebuuut... it *would* be nice to be able to have a new style of tempurl *for a particular version* -- maybe not so dissimilar from what we did by adding prefixes...04:55
timburkeat least, that's my gut feeling. haven't actually tried to *implement it* yet, so take it with a grain of salt04:56
timburkeprobably OK to punt on tempurl-for-a-particular-version for now? i wonder what the s3api patch will let you do...04:57
timburke(since query params are included in canonical requests and all)04:57
tdasilvamattoliverau: yeah, got mixed up with range04:59
tdasilvatimburke: the issue i'm seeing with tempurl+version-id is that it currently just ignores the version-id and sends back the latest version05:00
timburke👍 i think i can live with that -- ?version-id is ignroed, just like all other query params05:01
mattoliverauyeah, I like it. if someone wants to give someone access to a version we could look at adding version to the HMAC somehow (like prefixes).05:04
timburke?tempurl_version=xxx05:04
tdasilvaok, sounds good05:12
mattoliverau+105:22
*** pcaruana has joined #openstack-swift06:02
*** pawan-gupta has joined #openstack-swift06:47
*** rcernin has quit IRC07:41
*** tesseract has joined #openstack-swift07:43
openstackgerritMerged openstack/swift master: py3: Make seamless reloads work  https://review.opendev.org/69834708:17
*** FlorianFa has quit IRC08:49
*** FlorianFa has joined #openstack-swift09:01
*** FlorianFa has quit IRC09:09
*** mikecmpbll has joined #openstack-swift09:09
*** rcernin has joined #openstack-swift09:14
*** tkajinam has quit IRC09:19
*** FlorianFa has joined #openstack-swift09:22
*** rcernin has quit IRC09:53
*** rdejoux has joined #openstack-swift09:56
pawan-guptaHello friends, I have setup a openstack swift cluster, what I have noticed, if I make a s3v4 request, it takes more time (between 1-2 seconds extra) as compared to swift request, any specific reason behind this? Any help would be appreciated. thanks in advance10:42
DHEthat's long enough that I would suspect something's failed and the proxy is trying to connect to it13:34
DHEaside: a machine with 30 hard drives and a single 1gig connection is disappointingly slow...14:28
*** mikecmpbll has quit IRC15:36
claygi'm trying to duplicate lp bug #1856303 on 2.18 (rocky) since i'm not seeing the transfer-encoding: chunked repsonse to 404 on master15:46
openstackLaunchpad bug 1856303 in OpenStack Object Storage (swift) "HEAD doesn't return Content-Length header due to catch_errors middleware" [Undecided,New] https://launchpad.net/bugs/185630315:46
clayg... but I'm getting a signature does not match error - didn't we change something with the default region or something like that?15:47
claygchanging signature_version from s3v4 to s3 in .aws/config didn't help15:50
*** baffle has quit IRC15:54
*** efried is now known as efried_afk16:12
clayglocation = us-east-1 in the filter:s3api config section 👍16:14
ormandjheya folks, quick question (or not): what are people using for info such as container size for accounting/billing nowadays? looks like gnocchi is dead entirely16:20
claygormandj: swiftstack has a home rolled solution based roughly on the same design as slogging - https://github.com/notmyname/slogging16:25
claygormandj: for db in (find /srv/node*/*/accounts -name \*.db); do swift-account-info $db; done16:26
*** gyee has joined #openstack-swift16:26
rledisezormandj: at OVH, we use a customer version of ceilometer that scan all sqlite db to extract info, then the ceilometer-collector push to mongodb through a custom driver implementation16:27
rledisez*custom version of ceilometer16:27
*** rdejoux has quit IRC16:32
ormandjcopy that, thanks you two16:36
*** tesseract has quit IRC16:53
claygrledisez: I think this one is going to bite whoever tries to deploy master -> 69856316:58
claygp 69856316:58
patchbothttps://review.opendev.org/#/c/698563/ - swift - WSGI server workers must drop_privledges - 2 patch sets16:58
claygat least it's blocking my deploy 😁16:58
claygtimburke: p 698799 seems like a good place to start - but I lost track of the gatekeeper quote_etags = false change?17:03
patchbothttps://review.opendev.org/#/c/698799/ - swift - Add normalize_etag() helper function - 1 patch set17:03
ormandjclayg: rledisez: thank you. do you know what the long-term plans are for this accounting? if ceilometer wasn't just ingestion/notification, and had a data reporting/analytics api, swapping out backends would be easy, but as it is now, it seems like there's not really a great solution17:04
ormandjbefore we go write our own metrics gathering/reporting/api/etc goodies, i thought i'd check if there was actually something in the cards17:04
rledisezormandj: you might be interested by this thread. it seems they will re-integrate mongodb17:05
rledisezhttp://lists.openstack.org/pipermail/openstack-discuss/2019-November/thread.html#1092217:05
ormandjso idea is still to have all reporting done directly via the underlying storage vs. abstracting it so backend changes aren't so painful?17:08
ormandjor when ceilometer API is mentioned, is that the data-access API layer ?17:08
ormandj(from that thread)17:08
ormandjsorry - just trying to make sure I'm not offbase in my understanding :)17:08
openstackgerritClay Gerrard proposed openstack/python-swiftclient master: object versioning features  https://review.opendev.org/69187717:19
clayg^ we'll see if that's any better on py317:19
*** openstackgerrit has quit IRC17:29
*** mvkr has quit IRC17:34
timburkegood morning17:44
*** openstackgerrit has joined #openstack-swift17:58
openstackgerritPete Zaitcev proposed openstack/swift master: Let developers/operators add watchers to object audit  https://review.opendev.org/21282417:58
ormandjtimburke: morning!18:47
openstackgerritPete Zaitcev proposed openstack/swift master: Let developers/operators add watchers to object audit  https://review.opendev.org/21282419:12
*** efried_afk is now known as efried19:32
*** gmann is now known as gmann_afk20:13
claygi'm going to look at p 69879920:23
patchbothttps://review.opendev.org/#/c/698799/ - swift - Add normalize_etag() helper function - 1 patch set20:23
claygsee if the functest failure is anything 🤷‍♂️20:24
*** gyee has quit IRC20:35
*** gyee has joined #openstack-swift21:17
claygyeah that functest failure isn't anything, testFileThenContainerDelete I think is just maybe gunna exceed the retry limit very occasionally?21:18
claygchange looks good to me otherwise!21:18
openstackgerritClay Gerrard proposed openstack/swift master: Test normalize_etag in swob  https://review.opendev.org/69902221:19
*** mvkr has joined #openstack-swift22:38
*** pcaruana has quit IRC22:48

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