| opendevreview | Merged openstack/swift master: tests: Functionally test account quotas https://review.opendev.org/c/openstack/swift/+/928475 | 04:01 |
|---|---|---|
| opendevreview | Chris Smart proposed openstack/swift master: functest: add checks for quota count API https://review.opendev.org/c/openstack/swift/+/928499 | 06:42 |
| opendevreview | Merged openstack/swift master: account_quotas: Fix X-Remove-Account-Quota-Bytes-Policy-<name> https://review.opendev.org/c/openstack/swift/+/928476 | 07:27 |
| opendevreview | Merged openstack/swift master: account_quota: migrate quota_bytes and quota_count to the sysmeta namespace https://review.opendev.org/c/openstack/swift/+/924549 | 07:27 |
| opendevreview | Alistair Coles proposed openstack/swift feature/mpu: Embed MPU created timestamp in upload id https://review.opendev.org/c/openstack/swift/+/928459 | 12:10 |
| opendevreview | Merged openstack/swift master: proxy-logging: Clean up some timing assertions https://review.opendev.org/c/openstack/swift/+/928291 | 13:39 |
| opendevreview | Clay Gerrard proposed openstack/swift master: wip: probe testing timestamp collison https://review.opendev.org/c/openstack/swift/+/927327 | 14:54 |
| opendevreview | ASHWIN A NAIR proposed openstack/swift master: fix x-open-expired 404 on HEAD?part-number reqs https://review.opendev.org/c/openstack/swift/+/916547 | 15:08 |
| opendevreview | Tim Burke proposed openstack/swift master: CI: use private IPs for multinode tests https://review.opendev.org/c/openstack/swift/+/928667 | 16:39 |
| timburke | ^^^ should address the spate of `Cannot assign requested address` errors from rolling-upgrade jobs lately | 17:40 |
| opendevreview | ASHWIN A NAIR proposed openstack/swift master: fix x-open-expired 404 on HEAD?part-number reqs https://review.opendev.org/c/openstack/swift/+/916547 | 20:27 |
| opendevreview | Tim Burke proposed openstack/python-swiftclient master: Update master for stable/2024.2 https://review.opendev.org/c/openstack/python-swiftclient/+/928430 | 20:36 |
| opendevreview | Merged openstack/swift master: CI: use private IPs for multinode tests https://review.opendev.org/c/openstack/swift/+/928667 | 20:51 |
| opendevreview | Merged openstack/python-swiftclient master: Update master for stable/2024.2 https://review.opendev.org/c/openstack/python-swiftclient/+/928430 | 21:03 |
| opendevreview | Tim Burke proposed openstack/swift master: AUTHORS/CHANGELOG for 2.34.0 https://review.opendev.org/c/openstack/swift/+/928464 | 21:08 |
| rwmtinkywinky4 | timburke: did you have any thoughts about https://wiki.openstack.org/wiki/Swift/ideas/object-lock (I wrote it!) or know of anyone else who'd be interested in collaborating on an implementation? | 21:13 |
| fungi | rwmtinkywinky4: i remember seeing you post that to the mailing list a couple of weeks back too? | 21:41 |
| fungi | aha, yeah here: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/PGHHFTIUU4DIICVPV4D4CSK2QYIJ5QUV/#PGHHFTIUU4DIICVPV4D4CSK2QYIJ5QUV | 21:42 |
| fungi | i guess nobody's replied yet | 21:42 |
| rwmtinkywinky4 | yes, I did.. I did get one off-list reply but that I think was seeking paid work on something else which .. wasn't the intent | 21:42 |
| rwmtinkywinky4 | doesn't help I'm in UTC+12 so more or less as far away from many people as possible :) | 21:42 |
| fungi | i think you're in a similar tz to mattoliver | 21:44 |
| fungi | not sure which other swift core reviewers might also live in that region | 21:45 |
| mattoliver | Yeah, I'm utc+10 and +11 depending in time of year 😀 | 21:49 |
| mattoliver | rwmtinkywinky4: I'll have a read of your object-lock idea today. | 21:52 |
| mattoliver | You can also add it to the meeting agenda, we have a fairly apac friendly time (because we have some devs in apac). | 21:52 |
| mattoliver | From an initial pass it sounds like it could be a new swift middleware. Which can look at those set metadata a block delete requests. (A little link the read-only middleware). But better matches expected behaviour. | 21:57 |
| clarkb | could that also prevent deletion due to expiration metadata? (that makes me wonder what the proper behavior there should be I guess read only lock wins until the lock goes away then expiration can be processed normally) | 21:58 |
| timburke | rwmtinkywinky4, interesting! my first question is: where do you plan on notating the lock? on the object itself (in which case, how will you deal with eventual consistency?) or in some other service (in which case, which? how can we ensure it will it scale as we'd need it?) | 22:00 |
| mattoliver | Yeah, expiry and lock would be something to think about. If it was just a self contained middleware that looked up metadate and blocked deletes from incoming requests. Expirer could still be used internally. So would still work (not sure if that's correct or incorrect behaviour, depends how you word it 😜). | 22:24 |
| mattoliver | I guess I should read the s3 docs on how they expect it to work. | 22:24 |
| rwmtinkywinky4 | yeah the intent is to mirror the s3 logic largely as our customers mostly seem to want to drive it with S3 APIs and behaviour, but I defined the swift side since it needs to be consistent regardless of how it's accessed | 22:27 |
| rwmtinkywinky4 | I think expirer would need to be changed to honor the locks regardless of any policy for expiry (ah, tho, expirer is only acting on delete isn't it? not policy-driven automatic deletes) | 22:28 |
| rwmtinkywinky4 | timburke: I had expected on the object itself, although I had thought it was the case metadata is sync even if the data is only eventually in the "correct" places | 22:29 |
| opendevreview | Clay Gerrard proposed openstack/swift master: wip: probe testing timestamp collison https://review.opendev.org/c/openstack/swift/+/927327 | 22:38 |
| opendevreview | Merged openstack/swift master: functest: add checks for quota count API https://review.opendev.org/c/openstack/swift/+/928499 | 22:45 |
| timburke | rwmtinkywinky4, nope -- each diskfile has its own complete set of metadata that is written down alongside the data. you could get into situations where some primaries would have the data and know that object lock is enabled, while others think it isn't | 23:16 |
| rwmtinkywinky4 | the typical case is locked-on-write by the container settings, rather than applying a new lock to an existing object.. so I'm okay with eventual consistency on lock after write as just a fact of life, vs locked-on-write from the container settings.. | 23:18 |
| rwmtinkywinky4 | but that needs to be clarified so I'll edit the ideas page to note that assumption | 23:19 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!