| *** rcernin has quit IRC | 02:41 | |
| *** rcernin has joined #openstack-swift | 02:42 | |
| *** camelCaser has quit IRC | 03:10 | |
| *** camelCaser has joined #openstack-swift | 03:15 | |
| *** psachin has joined #openstack-swift | 03:39 | |
| *** rcernin has quit IRC | 04:21 | |
| *** rcernin has joined #openstack-swift | 04:45 | |
| *** rcernin has quit IRC | 04:53 | |
| *** benj_ has quit IRC | 05:04 | |
| *** benj_ has joined #openstack-swift | 05:07 | |
| *** evrardjp has quit IRC | 05:33 | |
| *** evrardjp has joined #openstack-swift | 05:33 | |
| *** rcernin has joined #openstack-swift | 05:48 | |
| *** rcernin has quit IRC | 05:57 | |
| *** m75abrams has joined #openstack-swift | 06:09 | |
| *** psachin has quit IRC | 08:12 | |
| *** rpittau|afk is now known as rpittau | 09:22 | |
| *** rcernin has joined #openstack-swift | 09:24 | |
| *** rcernin has quit IRC | 09:45 | |
| *** m75abrams has quit IRC | 10:31 | |
| *** rcernin has joined #openstack-swift | 10:41 | |
| *** rcernin has quit IRC | 10:55 | |
| *** m75abrams has joined #openstack-swift | 11:39 | |
| *** ianychoi has joined #openstack-swift | 12:24 | |
| *** dosaboy has quit IRC | 16:29 | |
| *** jv has quit IRC | 16:31 | |
| zaitcev | timburke: Are you back up yet? I don't understand why exactly the ALO namespace must be hidden. | 16:33 |
|---|---|---|
| *** jv has joined #openstack-swift | 16:39 | |
| *** m75abrams has quit IRC | 16:54 | |
| *** rpittau is now known as rpittau|afk | 17:08 | |
| timburke | zaitcev, the idea is that by keeping the namespace hidden, we can ensure we're the only ones making requests in it (both reads and writes) | 18:06 |
| clayg | zaitcev: maybe "only able to be modified by the system" is the more correct requirement - it's possibly listing or downloading individual segments could be supported and potentially useful... | 18:06 |
| clayg | using the null namespace means we could expose APIs for listing and fetching segments (partId query param?) after the fact with no problems | 18:07 |
| zaitcev | timburke: It is as I thought. However, aren't we giving up some value in the ease of diagnostics this way? A bigger danger to keep those segments in a user-visible container that I see is some users coming to depend on its contents. | 18:07 |
| timburke | yeah, that's a way better explanation of my reasoning and thought process than i was able to manage rn :-) | 18:07 |
| clayg | how is https://bugs.launchpad.net/swift/+bug/1833287 not biting more people? Just does like no one use staticweb? I know we don't enable it... | 18:07 |
| openstack | Launchpad bug 1833287 in OpenStack Object Storage (swift) "staticweb redirects cause 500s in s3api" [Undecided,In progress] | 18:07 |
| zaitcev | I'm more interested in this: do you ever want to list, or possibly clean up, segments administratively while you're debugging the ALO itself? | 18:09 |
| clayg | zaitcev: well, we're probably not going to get rid of SLOs because of old clients - so maybe we can have our cake and eat it to. Lots of users with experience with aws don't want to think about segments after the fire the "complete MPU" command | 18:09 |
| timburke | zaitcev, you can still have an internal proxy that lets ops do requests in the reserved namespace (ie, has allow_reserved_names_header=true in the gatekeeper) | 18:09 |
| zaitcev | We can set it up so the user itself does not have the right credentials, but his account reseller does. | 18:10 |
| zaitcev | Ah, okay | 18:10 |
| clayg | and THATS what we're really trying to solve - how to make overwrite or delete of MPU never result in "orphaned segments" - by making segments the clusters responsibility | 18:10 |
| timburke | (fwiw, my workaround for my dev env is to have an anti-gatekeeper: https://github.com/tipabu/no_op_gatekeeper/blob/master/no_op_gatekeeper.py#L28-L33) | 18:11 |
| zaitcev | I don't see how this is relevant at all. As long as the separate container is not accessed by AWS applications, they do not work differently in any way. The system is allowed to delete contents, user knows that. | 18:12 |
| timburke | i want ALO as a first-class swift api | 18:12 |
| zaitcev | Again, making its technical container visible does not make ALO a 2nd class API. | 18:13 |
| zaitcev | The only question is, do you want implementation to _rely_ on the integrity of the contents of the container (against ESR deleting lib_comerr2). | 18:14 |
| zaitcev | So, I was thinking about it this night and thought: but this is Swift, you cannot rely on 100% integrity of this stuff. So, you must program it defensively. | 18:15 |
| zaitcev | Therefore, if users tampers with the special container, the system ought to survive it anyway. | 18:15 |
| zaitcev | If you agree with this postulate, you don't need a special character or syntax. | 18:18 |
| timburke | what does "recovery" look like if the user goes and overwrites a segment with new content? i feel like the closest thing to a reasonable behavior would be to quarantine everything related to the original | 18:18 |
| zaitcev | GETs may return 500 in this case, I think. The checksum in the manifest will be wrong. | 18:19 |
| zaitcev | Again, do you remember what happened when ESR deleted lib_comerr? | 18:20 |
| zaitcev | His desktop no longer worked and the whole Internet laughed at him | 18:20 |
| zaitcev | You can overwrite random files in ~/.config, see how well that works. | 18:21 |
| zaitcev | Many amusing effects! | 18:21 |
| zaitcev | That said, as long as the middleware does not leak something interesting or does not crash or worse, loops, then it's fine, isn't it? | 18:22 |
| zaitcev | https://geekz.co.uk/lovesraymond/page/5 | 18:23 |
| zaitcev | (yes, now mjg59's sense of humor is guiding important architectural decisions in Swift, and I'm comfortable with it) | 18:24 |
| timburke | my point was more that if we allow clients the means to tamper with things, at some point they likely *will*, and when they start getting back 500s they'll just assume swift is broken | 18:40 |
| timburke | the safe, defensive thing (to me) seems to be not allowing the tampering to begin with -- we've got escape hatches we can use if we *really* get ourselves into trouble | 18:40 |
| zaitcev | And allow_reserved_names_header=true is one such hatch, then. | 18:45 |
| *** persia has quit IRC | 20:08 | |
| *** persia has joined #openstack-swift | 20:09 | |
| *** hoonetorg has quit IRC | 20:10 | |
| openstackgerrit | Tim Burke proposed openstack/swift master: Be willing to send hashes as JSON https://review.opendev.org/758638 | 20:13 |
| *** hoonetorg has joined #openstack-swift | 20:23 | |
| *** rcernin has joined #openstack-swift | 20:41 | |
| *** dosaboy has joined #openstack-swift | 20:42 | |
| *** rcernin has quit IRC | 20:43 | |
| *** rcernin has joined #openstack-swift | 20:43 | |
| openstackgerrit | Merged openstack/liberasurecode master: Release 1.6.2 https://review.opendev.org/756924 | 20:48 |
| zaitcev | timburke: liberasurecode is not on tarballs.opendev.org anywhere, right? Just a tag and that's all? | 21:02 |
| timburke | not even a tag yet -- i still need to do that (or someone else could push a signed tag up) | 21:03 |
| zaitcev | ok | 21:03 |
| openstackgerrit | Merged openstack/swift master: ec: Add an option to write fragments with legacy crc https://review.opendev.org/739164 | 23:03 |
| openstackgerrit | Tim Burke proposed openstack/swift master: memcache: Make error-limiting values configurable https://review.opendev.org/761029 | 23:32 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!