| *** threestrands has joined #openstack-swift | 01:21 | |
| *** rcernin has quit IRC | 02:01 | |
| *** rcernin has joined #openstack-swift | 02:02 | |
| openstackgerrit | Tim Burke proposed openstack/swift master: Fix container-sync objects with offset timestamp https://review.opendev.org/698092 | 02:13 |
|---|---|---|
| openstackgerrit | Tim Burke proposed openstack/swift master: Enable s3api and staticweb tests across all func tests https://review.opendev.org/691747 | 02:17 |
| *** rcernin has quit IRC | 02:20 | |
| *** rcernin has joined #openstack-swift | 02:52 | |
| *** dasp has quit IRC | 02:54 | |
| seongsoocho | morning ~ | 02:55 |
| *** dasp has joined #openstack-swift | 03:00 | |
| *** threestrands has quit IRC | 03:36 | |
| *** gyee has quit IRC | 03:59 | |
| *** rcernin has quit IRC | 04:19 | |
| *** rcernin has joined #openstack-swift | 04:22 | |
| *** evrardjp has quit IRC | 04:33 | |
| *** evrardjp has joined #openstack-swift | 04:33 | |
| *** psachin has joined #openstack-swift | 04:39 | |
| *** threestrands has joined #openstack-swift | 05:26 | |
| openstackgerrit | Matthew Oliver proposed openstack/swift master: Add branch and tag tags to docker image https://review.opendev.org/732480 | 05:38 |
| mattoliverau | ^ tdasilva: not actually sure that'll work.. but in theory if the variable is empty it "shouldn't" get added as a tag (I assume). | 05:39 |
| *** lifeless has quit IRC | 06:38 | |
| *** lifeless has joined #openstack-swift | 06:39 | |
| *** ravsingh has joined #openstack-swift | 06:53 | |
| *** ravsingh has quit IRC | 06:58 | |
| *** tkajinam has quit IRC | 07:13 | |
| *** tkajinam has joined #openstack-swift | 07:13 | |
| *** dtantsur|afk is now known as dtantsur | 07:39 | |
| *** rpittau|afk is now known as rpittau | 07:45 | |
| *** rcernin has quit IRC | 07:48 | |
| * kota_ is looking around EC Gets | 08:08 | |
| *** threestrands has quit IRC | 08:32 | |
| *** ccamacho has joined #openstack-swift | 09:01 | |
| *** rpittau is now known as rpittau|bbl | 10:28 | |
| *** m75abrams has joined #openstack-swift | 11:49 | |
| *** rpittau|bbl is now known as rpittau | 12:21 | |
| *** ababolcai has joined #openstack-swift | 12:37 | |
| timburke | good morning | 12:44 |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: wip: asyc concurrent ecfragfetcher https://review.opendev.org/711342 | 12:45 |
| clayg | kota_: sorry, it was a bit out of date - still needs some work I think | 12:45 |
| clayg | we're jumping in a zoom room soon yeah? | 12:45 |
| timburke | yep! 15 mins to ops feedback session | 12:46 |
| seongsoocho | Hi ! | 12:52 |
| clayg | mattoliverau: I think http://paste.openstack.org/show/794225/ is testing about the same thing as https://github.com/openstack/swift/blob/master/test/unit/container/test_server.py#L2374 | 12:56 |
| mattoliverau | ahh yes, looks like it might, let me read it a bit more closely, but I suspect your right.. which is great cause it means I can change my vote ;) | 12:58 |
| kota_ | clayg: thanks for the response, just looked as a reference. | 12:58 |
| kota_ | if i understand correctly, the code looks like all resuming getters will try to connect n_unique_frag nodes that seems not to be intended... | 12:59 |
| * kota_ is scrolling back to find the zoom place... | 13:00 | |
| clayg | mattoliverau: idk, they brake slightly differenty -> https://gist.github.com/clayg/66f344bd4172cd0a6a2285c6546786e2 | 13:00 |
| * kota_ may be missing conversation here because in my home, i use just a laptop w/o any screens so... it's hard to open many application window. | 13:02 | |
| *** psachin has quit IRC | 13:07 | |
| *** dsariel has joined #openstack-swift | 13:14 | |
| *** ravsingh has joined #openstack-swift | 13:23 | |
| *** rpittau is now known as rpittau|brb | 13:28 | |
| *** ababolcai has quit IRC | 13:31 | |
| clayg | timburke: so this one p 698092 | 13:51 |
| patchbot | https://review.opendev.org/#/c/698092/ - swift - Fix container-sync objects with offset timestamp - 3 patch sets | 13:51 |
| timburke | https://meetpad.opendev.org/p/swift-victoria-ops-feedback | 13:52 |
| seongsoocho | 404 not found :-( | 13:55 |
| clayg | https://etherpad.opendev.org/p/swift-victoria-ops-feedback ??? | 13:55 |
| clayg | i don't know how to meetpad - it's different than zoom? | 13:55 |
| seongsoocho | yes. remove the letter p | 13:55 |
| seongsoocho | it works | 13:55 |
| timburke | bah! sorry | 13:56 |
| timburke | https://meetpad.opendev.org/swift-victoria-ops-feedback | 13:56 |
| *** billp has quit IRC | 14:00 | |
| *** rpittau|brb is now known as rpittau | 14:01 | |
| zaitcev | Audio and video were frozen for me. | 14:02 |
| zaitcev | on meetpad | 14:02 |
| *** mugsie_ is now known as mugsie | 14:06 | |
| kota_ | :/ | 14:09 |
| kota_ | s3 bucket inventory? -> https://docs.aws.amazon.com/AmazonS3/latest/dev/storage-inventory.html | 14:19 |
| seongsoocho | Zoom's video and audio is better than meetpad.. :-( | 14:41 |
| timburke | kota_, yes, that's the one | 15:53 |
| timburke | seongsoocho, yeah, that was my impression too. meetpad worked well enough when it was me and one other person, but 8-10 people seemed to cause troubles | 15:53 |
| *** gyee has joined #openstack-swift | 15:53 | |
| seongsoocho | I found this email in mailing list. There are some trouble in meetpad during our call. | 15:59 |
| seongsoocho | http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015206.html | 15:59 |
| zaitcev | I see. | 16:14 |
| *** rpittau is now known as rpittau|afk | 16:32 | |
| timburke | clayg, mattoliverau thinking some more about p 731653, now you guys have me nervous about a shard reporting stats to a root in the middle of a rebalance -- i could see that popping a root DB into existence that only knows about one shard | 16:36 |
| patchbot | https://review.opendev.org/#/c/731653/ - swift - Don't auto-create shard containers based on object... - 1 patch set | 16:36 |
| clayg | hahah! | 16:36 |
| clayg | @timburke I'm curious how you figured out this remediation? like "this could happen; seems bad; should fix" or "observed precisely this bad; this is the most obvious fix I can think of" | 16:37 |
| clayg | I mean we could fix this; AND fix other things - and this seems pretty ok - BUT if we have to write "container listing survey" code in the proxy *regardless* 🤷♂️ | 16:38 |
| timburke | oh! except the root db won't start with the autocreate prefix anymore! *whew* | 16:38 |
| clayg | so a shard trying report to a missing root just sits on a 404 and retries? They probably report to ALL replicas right? | 16:39 |
| timburke | clayg, which part? the shard DB popping into existence and making large swaths of a container's namespace disappear until replication caught up is *definitely* something we've observed | 16:39 |
| timburke | yeah, they should report to all replicas | 16:39 |
| timburke | probably worth a probe test to verify that what we expect to happen does in fact happen, though | 16:40 |
| *** dtantsur is now known as dtantsur|afk | 16:41 | |
| timburke | fwiw, i'm running probe tests with a change like http://paste.openstack.org/show/794261/ -- should make it a little more defensive about protecting listings | 16:41 |
| *** ravsingh has quit IRC | 16:43 | |
| openstackgerrit | Andreas Jaeger proposed openstack/swift master: Switch to newer openstackdocstheme and reno versions https://review.opendev.org/732741 | 17:00 |
| openstackgerrit | Andreas Jaeger proposed openstack/python-swiftclient master: Switch to newer openstackdocstheme and reno versions https://review.opendev.org/732742 | 17:04 |
| openstackgerrit | Andreas Jaeger proposed openstack/swift-specs master: Switch to newer openstackdocstheme version https://review.opendev.org/732744 | 17:07 |
| *** tkajinam has quit IRC | 17:16 | |
| timburke | so sharding probe tests passed... but i noticed occasional tracebacks in my logs, like http://paste.openstack.org/show/794264/ | 17:24 |
| timburke | i see that now and then even *without* the diff, though 🤔 | 17:27 |
| clayg | @timburke is line container_server.py#L576 from that traceback on your branch https://github.com/openstack/swift/blob/master/swift/container/server.py#L559 ? ! | 17:31 |
| timburke | clayg, yeah, i forget if that particular traceback was on top of p 731653 directly, or with http://paste.openstack.org/show/794261/ applied | 17:34 |
| patchbot | https://review.opendev.org/#/c/731653/ - swift - Don't auto-create shard containers based on object... - 1 patch set | 17:34 |
| timburke | i can also get one pretty easily in a get path like http://paste.openstack.org/show/794265/ | 17:36 |
| timburke | lemme try it on master... | 17:38 |
| timburke | yup -- run `nosetests test/probe/test_sharder.py:TestContainerSharding.test_async_pendings` a couple times while running `tail -f /var/log/syslog | sed '/raceback/!d;s/#012/\n/g'` in another window -- should be able to hit one of those without too much trouble :-/ | 17:45 |
| clayg | no, that doesn't sound fun 😞 | 17:48 |
| timburke | i guess the good news is, that patch didn't make anything any *worse* | 17:49 |
| openstackgerrit | Andreas Jaeger proposed openstack/swift-specs master: Switch to newer openstackdocstheme version https://review.opendev.org/732744 | 18:16 |
| timburke | clayg, thinking more about your comment "so with unsharded dbs this happens all the time, you do a rebalance - then someone does an upload preceeded by a container put and followed by a container listing - voila stale listing" -- i wonder if we could do something akin to our PUT-If-None-Match semantics for objects. it gets a little messy since we still want the metadata to apply if the DB exists, but i think we could make it work | 18:21 |
| timburke | like, include an 'expect: 100-continue'; if DB already exists, apply metadata and respond 202. if not, respond 100 Continue and wait for the (empty) request body before creating the DB. proxy side, gather a first round of responses -- if any 202s, respond 202 (if quorum) or 503 (if not) and drop the connection. if quorum of 100s, send a zero-byte chunk to cleanly end the request and gather up the 201s | 18:24 |
| *** AJaeger has joined #openstack-swift | 18:34 | |
| AJaeger | swift team, do you still need swift-specs - or is it time to retire the repository? | 18:35 |
| timburke | AJaeger, we can absolutely retire that repo. sorry that we haven't done it already; it's been dead for a fairly long while | 18:36 |
| AJaeger | yeah noticed after fixing ;( | 18:36 |
| AJaeger | timburke: https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#retiring-a-project is the instructions on retiring | 18:37 |
| AJaeger | if you need help, please tell me | 18:37 |
| timburke | thanks! i'll aim to work on that today | 18:37 |
| AJaeger | thanks | 18:37 |
| AJaeger | I pushed some changes for swift and python-swiftclient - and both fail requirements-check since you still have py27 handling in there. Are you still taking care of py27? | 18:38 |
| AJaeger | changes are https://review.opendev.org/732741 and https://review.opendev.org/732742 . What do you propose to do here? | 18:39 |
| patchbot | patch 732741 - swift - Switch to newer openstackdocstheme and reno versions - 1 patch set | 18:39 |
| patchbot | patch 732742 - python-swiftclient - Switch to newer openstackdocstheme and reno versions - 1 patch set | 18:39 |
| AJaeger | Remove py27 support? Disable check-requirements to get these in? OR wait (for howlong)? | 18:40 |
| timburke | yes, we are still supporting py27. intend to for at least the next cycle; just today we were looking at operator's plans for moving to py3 | 18:41 |
| timburke | clayg: huh. apparently one of the failures could happen during https://github.com/openstack/swift/blob/2.25.0/test/probe/test_sharder.py#L1363 -- i guess the caching in https://github.com/openstack/swift/blob/2.25.0/swift/container/backend.py#L428-L442 means you get have a race where one node's sharder asks for shard info from a root db just as that root is moving from sharding to sharded. if we get unlucky, the server pulls up a broker and | 18:42 |
| timburke | does the listdir, then the sharder unlinks the retiring db, then the server actually queries the old DB | 18:42 |
| AJaeger | my changes should be fine - but we cannot merge them due to global requirements not supporting py27 anymore and thus they fail | 18:42 |
| clayg | timburke: NICE WORK!!! | 18:42 |
| clayg | AJaeger: it's not exactly clear to me what that failed requirements-check is telling me 🤔 | 18:45 |
| AJaeger | clayg: https://zuul.opendev.org/t/openstack/build/1057630277aa44df8df1da70b4efa14f tells you for exmaple for dnspython: | 18:46 |
| timburke | AJaeger, fwiw, our releasenotes tox env uses py3, and i think we'd be fine with dropping any pretense of py2 support there. dnspython can probably drop the env marker -- we'd want it for all pythons. fwiw, eventlet already pulls in >= 1.15.0, so we'd need that anyway | 18:47 |
| AJaeger | https://opendev.org/openstack/swift/src/branch/master/requirements.txt#L5 does not match the entry in global requirements which is https://opendev.org/openstack/requirements/src/branch/master/global-requirements.txt#L48 | 18:47 |
| timburke | ipaddress is messier | 18:48 |
| AJaeger | the problem is the "python_version" | 18:48 |
| AJaeger | yeah, ipadress is not in global-requirements anymore | 18:48 |
| AJaeger | clayg: does that explain it? | 18:49 |
| AJaeger | timburke: so, back to my question: Disable requirements-check - or should I wait with my changes? | 18:51 |
| AJaeger | No need for an answer today ;) | 18:51 |
| openstackgerrit | Hervé Beraud proposed openstack/python-swiftclient master: Stop to use the __future__ module. https://review.opendev.org/732936 | 18:52 |
| timburke | given the moves toward py3-only, is requirements-check sane enough to ignore packages not in g-r that have markers like `;python_version=='2.7'`? | 18:55 |
| AJaeger | no, it's not - that would need extra work | 18:55 |
| AJaeger | not sure whether the requirements would entertain such an option, best discuss with them | 18:56 |
| openstackgerrit | Hervé Beraud proposed openstack/swift master: Stop to use the __future__ module. https://review.opendev.org/732955 | 18:59 |
| timburke | i'll see what i can do for it. it may also be that we end up hacking up our requirements-check job to remove this one line before running 🤮 | 19:01 |
| AJaeger | you're evil ;) | 19:03 |
| AJaeger | evil AJaeger was thinking of disable requirements-check, merge his change and enabling it again ;) | 19:04 |
| timburke | yeah, i was debating about that, too. at some point though, we'll probably end up needing to touch that file again (like whenever eventlet gets a fix for https://github.com/eventlet/eventlet/issues/526) | 19:06 |
| AJaeger | yep | 19:07 |
| AJaeger | timburke: if you found a solution, tell me what to do with my two changes, please ;) | 19:07 |
| timburke | AJaeger, back on retiring swift-specs, am i right in understanding that step 2 will effectively unpublish all existing specs? i'm guessing that's why we haven't done this already -- can we skip that part? | 19:10 |
| AJaeger | timburke: no, see specs.openstack.org/openstack/docs-specs/ - docs-specs is retired | 19:12 |
| timburke | excellent -- thanks! | 19:12 |
| AJaeger | timburke: it would only unpublish if you have a job to publish - but step removes all jobs ;) | 19:12 |
| timburke | makes sense now | 19:12 |
| clayg | AJaeger: so there's some code called "the requirements-check" that does some linting/validation of our requirements file for semantic correctness - and despite the requirements.txt being as correct as we can express it the check still fails? | 19:23 |
| clayg | timburke: can we just opt to publish a py2-requirements.txt that our check job ignores? Or have it test a "eventually-this-will-be-the-correct-py3-only-requirements.txt" and we just keep on doing our thing that seems to work for us? | 19:24 |
| AJaeger | clayg: yeah, since ages ;) | 19:24 |
| AJaeger | clayg: that jobs lives in requirements repository | 19:25 |
| timburke | clayg, yeah, that might be simpler. we already have a py2-constraints.txt -- we'd just want to make sure our various py2 tox jobs know to use the new file (but presumably they'd break otherwise, so it should be easy to tell if we forgot one) | 19:27 |
| AJaeger | yeah, py2-requirements.txt will get ignored by check-requirements - but requirements-py2.txt is a known file it would handle | 19:30 |
| clayg | AJaeger: I'm trying to muster up some roundtuits for you cause here, but I'm at an extream disadvantage of context. Can you tell me then how we've violated this agreement? https://docs.openstack.org/project-team-guide/dependency-management.html#enforcement-in-projects | 19:30 |
| clayg | we already HAVE a dependency not in global-requirements, or we're trying to add one that's not in global-requirements? | 19:30 |
| AJaeger | clayg: https://opendev.org/openstack/requirements/src/branch/master/openstack_requirements/project.py#L132-L139 | 19:30 |
| AJaeger | clayg: you have one already - since global-requirements removed ipaddress from the list while swift is still using it. requirements remove all py27 support a week or two ago | 19:31 |
| AJaeger | clayg: I'm trying to add a valid entry - but the check tests *all* entries in it. | 19:32 |
| clayg | ok, but nothing triggered to show that was "problem" until now? | 19:32 |
| AJaeger | clayg: correct, the job only runs if you touch one of those files | 19:32 |
| timburke | makes evil AJaeger's idea awfully appealing as a short-term remedy | 19:33 |
| clayg | timburke: i.e. "go back to oblivious" ? | 19:34 |
| AJaeger | clayg: https://review.opendev.org/#/ca727246/ is a change that run into the same problem | 19:34 |
| AJaeger | but nobody noticed or cared to bring it up | 19:35 |
| clayg | Can I ask a dumb question - do we not *depend* on ipaddress? It's not clear to me what it means exactly that "global requirements removed this dependency" if we *actually* depend on it? | 19:35 |
| AJaeger | clayg: "ipaddress>=1.0.16;python_version<'3.3' " is the line | 19:36 |
| AJaeger | so, you need it for older python. global-requirments has python 3.6 as oldest supported version | 19:36 |
| AJaeger | ipaddress is part of python 3.3, so no need to have a requires on it for 3.3 and newer | 19:37 |
| timburke | clayg, we use it in tempurl following https://github.com/openstack/swift/commit/26b20ee7296442231e74c982891a9b85c217ff79 | 19:37 |
| clayg | so looking at https://review.opendev.org/#/c/569404/ it's not clear to me what we thought we were going to do with python > 3.3 ??? | 19:40 |
| patchbot | patch 569404 - swift - IP Range restrictions in temp urls (MERGED) - 17 patch sets | 19:40 |
| clayg | timburke: beat me to it; took me 3 blame sha^ to dig down to that one 🤣 | 19:40 |
| timburke | that's what global-requirements had listed at the time, i believe | 19:40 |
| clayg | I'm SO confused, what was the last thing global-requirements had before they removed it? Since we depend on it can we like... put it back!? | 19:42 |
| openstackgerrit | Andreas Jaeger proposed openstack/swift master: Switch to newer openstackdocstheme and reno versions https://review.opendev.org/732741 | 19:42 |
| openstackgerrit | Andreas Jaeger proposed openstack/swift master: Temporary disable requirements check https://review.opendev.org/732989 | 19:42 |
| openstackgerrit | Andreas Jaeger proposed openstack/swift master: Enable requirements check again https://review.opendev.org/732990 | 19:42 |
| AJaeger | let me try it ^ | 19:42 |
| clayg | LOL, SURE! why not! 🤣 | 19:42 |
| AJaeger | clayg: 569404 will work just fine since with python 3.2 and older you import the external ipaddress module but with 3.3 and newer, ipaddress is part of the python standard library. So, you don't need to install it anymore, it's on every system | 19:44 |
| AJaeger | clayg: global-requirements removed py27 support. You're on your own now. | 19:44 |
| clayg | we depend on ipaddress in py3 too - i'm not sure what removing py27 support has to do with removing ipaddress | 19:45 |
| AJaeger | clayg: you're mixing things up. | 19:46 |
| AJaeger | Let me state it a bit differently | 19:46 |
| clayg | when you say "removed py27" support that extends to mean "removed support py<3.3" as well? | 19:47 |
| clayg | AJaeger: thank you! I'm trying. | 19:47 |
| AJaeger | 1) for python 2.7, you need to install an external ipaddress module and thus put it into requirements.txt | 19:47 |
| AJaeger | 2) for python 3.3 and newer, no need to install an external ipaddress module, thus you don#t put it into requirements.txt | 19:47 |
| AJaeger | 3) the global requirements list only supports python 3.5 *external* references, thus when they removed handling of py27 entries in the global requirements list, they removed ipaddress from the list | 19:48 |
| AJaeger | 4) the check-requirements job checks each entry in requirements.txt, test-requirements.txt etc for matching the global-requirements. The match neeeds to include python_version; so a "libX" in global-requirements will *not* match "libX;python_version < '3.3'" | 19:50 |
| AJaeger | 5) when you change any entry in the requirements files, the requirements-check job will be run and complain about failures | 19:50 |
| AJaeger | clayg: does that make it clearer? | 19:51 |
| clayg | I think only #4 is confusing me - because our requirements file seems to correctly describe what a packager should do if they're targeting a py3.2 install 🤷♂️ | 19:51 |
| clayg | or py27 - but as you said - we're on our own there 💪 | 19:51 |
| AJaeger | clayg: see 3. with Ussuri release done, global-requirements is not supporting anything older than py35. | 19:53 |
| AJaeger | clayg: so, that's the trigger - they left you behind ;( | 19:53 |
| openstackgerrit | Merged openstack/swift master: Simplify wsgify() https://review.opendev.org/731008 | 19:53 |
| clayg | no, that's fine - so we need a py3.5and-above-requirements.txt that the check job can test; or we can make our requirements.txt have a note "this is only for py3.5 and above; all other packagers can use package-requirements.txt" | 19:55 |
| AJaeger | that's one way, yes. | 19:55 |
| clayg | Do you have a sense of which of those would be better? both from the openstack consistency standpoint - and also downstream packagers still building py2 packages that have always used requirements.txt? | 19:55 |
| AJaeger | I would say the later - downstream packagers are all now on py3. | 19:56 |
| clayg | I'm downstream; i still build py2 packages; but I'm happy to be in the minority - it's a sad state of affairs 😁 | 19:56 |
| AJaeger | so, for consistency: Use requirements.txt for py3 ; and for downstream it works as well. | 19:56 |
| AJaeger | The note will help that minority ;) | 19:57 |
| clayg | AJaeger: as long as they're not building for py3.2 ;) | 19:57 |
| * AJaeger hugs clayg | 19:57 | |
| AJaeger | clayg: I meant with downstream packagers Fedora, Ubuntu, SUSE, Arch - they are either py3 only or in that process | 19:58 |
| * AJaeger has to signoff for today now, will stay in channel in case you have further questions for me tomorrow | 19:59 | |
| * clayg hugs AJaeger | 20:00 | |
| clayg | rledisez: i just checked and SwiftStack/Nvidia's package building is FINE with removing ipaddress or whatever from requirements.txt (we've maintained that separately for awhile) - can you validate you're fine with our requirements.txt moving to >=py3.5 only? | 20:06 |
| timburke | clayg, fwiw, i have no expectation that swift can run on pythons >=3.0,<3.5 -- and even 3.5 is iffy (it worked when last i tried it, but now... who knows) | 20:07 |
| timburke | anyone who wants to build swift packages for py32 is likely in for a world of hurt regardless :P | 20:08 |
| clayg | oh, that's VERY good to know! 👍 | 20:08 |
| timburke | we've only ever *declared support* for 3.6 and above | 20:08 |
| clayg | now I think I understand why "dropped py2 support" sounds so much like "supported >=py3.5 only" - we're even focusing our testing on what... 3.7? 3.8? | 20:09 |
| rledisez | clayg: so the change is something like that, right? ipaddress>=1.0.16;python_version>='3.5' | 20:09 |
| clayg | rledisez: no after 3.3 that module got rolled into stdlib | 20:10 |
| clayg | so it should be "removed" - since it only makes sense on py2.7 - all versions of py3 we wat to support have it already 💪 | 20:10 |
| rledisez | ok, i'll just throw that in our CI/CD see how it goes, but I don't see any reason not to do it | 20:12 |
| timburke | rledisez, the thing to watch for would be tempurl func tests, fwiw -- making sure the functionality from https://github.com/openstack/swift/commit/26b20ee still works | 20:13 |
| clayg | the FEELS https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/ | 20:13 |
| timburke | though i suppose *really*, if removing ipaddress causes problems, tempurl will trip ImportErrors and your proxies won't even start, so... it should be an obvious failure ;-) | 20:14 |
| timburke | clayg, yeah, i remember reading that around when it came out -- and very much agreeing with a lot of points | 20:16 |
| openstackgerrit | Tim Burke proposed openstack/swift master: sharding: Raise fewer errors when the on-disk files change out from under us https://review.opendev.org/732996 | 20:17 |
| openstackgerrit | Tim Burke proposed openstack/python-swiftclient master: Remove references to swift-specs and blueprints https://review.opendev.org/732998 | 20:35 |
| openstackgerrit | Tim Burke proposed openstack/swift-specs master: Retire swift-specs https://review.opendev.org/733001 | 20:51 |
| rledisez | clayg, timburke: concerning ipaddress/tempurl, all is green for me | 21:02 |
| seongsoocho | morning~ no meeting now? I saw `6/3 2100-2300 UTC (1400-1600 PDT, 0600-0800 JST)` in etherpad. | 21:11 |
| timburke | seongsoocho, o/ | 21:19 |
| timburke | yeah, the meeting we'd normally have tomorrow will be a zoom session instead | 21:20 |
| seongsoocho | timburke: oh i see. see you tomorror! | 21:20 |
| timburke | sorry for the confusion -- i believe 6/3 2100 UTC will be 6/4 for you | 21:20 |
| seongsoocho | oh yeah . 6/3 2100 UTC is 6/4 0600 to me. :-) | 21:23 |
| *** m75abrams has quit IRC | 21:54 | |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: Remove <py3.5 dependencies from requirements.txt https://review.opendev.org/732990 | 22:02 |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: Remove <py3.5 dependencies from requirements.txt https://review.opendev.org/732989 | 22:05 |
| timburke | anybody got a moment to look at https://review.opendev.org/#/c/728589/ ? it gives (you the option to give) clients more context when they try to figure out what to do after a failed CompleteMultipartUpload request | 22:23 |
| patchbot | patch 728589 - swift - s3api: Add config option to include uploadId in GE... - 2 patch sets | 22:23 |
| openstackgerrit | Merged openstack/swift master: Enable s3api and staticweb tests across all func tests https://review.opendev.org/691747 | 22:25 |
| clayg | timburke: do you think there's some jobs that run <py3.5 who will install from requirements.txt and fail when they try and import ipaddress? | 22:43 |
| timburke | i was expecting our py27 jobs would -- unit and func | 22:44 |
| timburke | but they didn't | 22:44 |
| clayg | well that would certainly throw a wrench in the plan - but I guess "we're on our own" to fix jobs like that | 22:45 |
| clayg | did they not? I can't tell what ran... | 22:45 |
| timburke | ah.... `Requirement already satisfied, skipping upgrade: ipaddress; python_version < "3" in ./.tox/py27/lib/python2.7/site-packages (from cryptography>=2.0.2->swift==2.26.0.dev70) (1.0.23)` | 22:45 |
| timburke | i just look at https://zuul.openstack.org/status and filter for "swift" | 22:46 |
| timburke | got me to a log url like https://2f384c1c1ff3a2efa147-8c61a4fa8250eb01b1a81b20edeb2930.ssl.cf2.rackcdn.com/732989/2/check/swift-tox-py27/000514c/ | 22:46 |
| timburke | requirements-check still failed though -- i think the patches will have to be squashed together | 22:47 |
| clayg | maybe that specific bionic image for some reason had ipaddress installed already - it's possible not having that dependency in requirements.txt will be brittle | 22:48 |
| *** tkajinam has joined #openstack-swift | 22:50 | |
| timburke | clayg, our dep on cryptography mean that we picked up ipaddress transitively | 22:56 |
| *** rcernin has joined #openstack-swift | 22:57 | |
| timburke | there's a similar thing where eventlet would drag in dnspython even if we didn't specify it | 22:57 |
| timburke | (though i tend to prefer explicitly listing anything we import as a requirement, i'm totally on board with making an exception for ipaddress) | 22:57 |
| *** rcernin has quit IRC | 22:59 | |
| openstackgerrit | Tim Burke proposed openstack/swift master: Add a new URL parameter to allow for async cleanup of SLO segments https://review.opendev.org/733026 | 23:19 |
| timburke | needs tests, but i'm liking how ^^^ is shaping up | 23:19 |
| *** rcernin has joined #openstack-swift | 23:23 | |
| timburke | that's getting us close to atomic large objects -- remaining delta would mainly be 1. have the object-server kick off the UPDATE (somewhere around cleanup_ondisk_files) so there's no way to get into a situation where the manifest is still there but the segments are gone | 23:25 |
| timburke | 2. get a initiate-upload-complete API for swift, and 3. get the segment data out to the reserved namespace (though this would probably be done in tandem with 2) | 23:25 |
| *** jv|afk has quit IRC | 23:35 | |
| mattoliverau | morning | 23:43 |
| clayg | mattoliverau: oh nice! so I think we should squash all pastes on https://review.opendev.org/#/c/731653/ and merge it! | 23:51 |
| patchbot | patch 731653 - swift - Don't auto-create shard containers based on object... - 1 patch set | 23:51 |
| clayg | timburke: do you have any lingering concerns? I'm mostly reserved to the idea that the current state is bad enough we should do SOMETHING and not auto creating containers we never really intended too seems sufficient, reasonable and complete! | 23:54 |
| openstackgerrit | Tim Burke proposed openstack/swift master: sharding: Raise fewer errors when the on-disk files change out from under us https://review.opendev.org/732996 | 23:54 |
| timburke | clayg, wfm -- i'll get 'em squashed | 23:55 |
| timburke | oh, though -- mattoliverau, do we ever actually do a PUT with an empty shard range list like that? that feels kinda weird... | 23:58 |
| mattoliverau | yeah, that's just to get to the 201. We could put something in there. But the json fails and causes a 400 if you don't give it a body. | 23:59 |
| mattoliverau | I was just trying to, hackly, prove we could still 201 :) | 23:59 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!