seongsoocho | timburke: mattoliver NHN Cloud want to suggest a "s3 orphan part expirer daemon" to upstream (which I mentioned in PTG). Can I write the blueprint for the launchpad first? | 00:58 |
---|---|---|
seongsoocho | It is related with this bug. https://bugs.launchpad.net/swift/+bug/1813202 | 01:40 |
opendevreview | Jianjian Huo proposed openstack/swift master: Container-server: add container namespaces GET https://review.opendev.org/c/openstack/swift/+/890470 | 05:05 |
opendevreview | Jianjian Huo proposed openstack/swift master: Container-server: add container namespaces GET https://review.opendev.org/c/openstack/swift/+/890470 | 05:15 |
opendevreview | Jianjian Huo proposed openstack/swift master: Container-server: add container namespaces GET https://review.opendev.org/c/openstack/swift/+/890470 | 05:18 |
mattoliver | seongsoocho: sounds great! either a launchpad feature request/blueprint or a doc (google doc or something, that allows comments) and link to to ideas page. Or maybe a mix. A blueprint that doesn't need to say too much, but links to the gdoc or something, where the design requirements can be more in flux? | 07:12 |
mattoliver | Just a thought, a yway you want to provide and work is great for us 😀 | 07:13 |
mattoliver | *anyway | 07:13 |
seongsoocho | mattoliver: ok great. I will share the blueprint and docs in there when we are ready to review. | 07:17 |
opendevreview | ASHWIN A NAIR proposed openstack/swift master: Support swift.proxy_logging_status in request env https://review.opendev.org/c/openstack/swift/+/784808 | 17:44 |
opendevreview | ASHWIN A NAIR proposed openstack/swift master: proxy_logging: catch and log errors during reiterate https://review.opendev.org/c/openstack/swift/+/899483 | 17:44 |
opendevreview | ASHWIN A NAIR proposed openstack/swift master: s3api: add option to log '503 Slow Down' as 429 https://review.opendev.org/c/openstack/swift/+/883415 | 17:45 |
timburke | paladox, it's because swift is sending a `Content-Length: 7` header, for the "Bad URL" that would be sent on GET. curl is waiting for those 7 bytes, but being a HEAD request, there will be no body (nor should there be). curl knows to expect no body when you use the -I/--head flag, but doing -X HEAD it doesn't realize | 18:57 |
paladox | Oh, that's interesting. MediaWiki sends a head url: https://github.com/wikimedia/mediawiki/blob/master/includes/jobqueue/jobs/ThumbnailRenderJob.php#L118 | 18:58 |
timburke | as for why it works with HTTP/1.0 but not 1.1 -- with 1.0 (and no `Connection: keep-alive` header), the server will close the connection after sending back the one response. 1.1 defaults to keep-alive, so the server is waiting for another request while the client is waiting for those 7 bytes | 19:00 |
paladox | seems that it receives a "Content-Length: 36". Response looks correct: | 19:04 |
paladox | https://www.irccloud.com/pastebin/s05BEr8l/ | 19:04 |
timburke | it *looks like* they should be doing the right thing... https://github.com/wikimedia/mediawiki/blob/3e7ab8d9e793df845c1685918be0465ffa8bec2d/includes/libs/http/MultiHttpClient.php#L383 | 19:13 |
timburke | but maybe there's some other way they end up talking to curl? | 19:14 |
paladox | hmm, I get it timedout in the log | 19:24 |
*** zigo_ is now known as zigo | 19:57 | |
opendevreview | Tim Burke proposed openstack/swift master: docs: Document WSGI reload process https://review.opendev.org/c/openstack/swift/+/900256 | 23:37 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!