| *** renich has quit IRC | 00:03 | |
| *** diablo_rojo has quit IRC | 00:04 | |
| *** nanzha has joined #openstack-swift | 01:04 | |
| *** redrobot has quit IRC | 01:07 | |
| *** nanzha has quit IRC | 01:10 | |
| *** nanzha has joined #openstack-swift | 01:13 | |
| *** mvkr has quit IRC | 01:18 | |
| *** gyee has quit IRC | 01:29 | |
| *** onovy has quit IRC | 02:09 | |
| *** onovy has joined #openstack-swift | 02:11 | |
| *** baojg has joined #openstack-swift | 02:46 | |
| *** mvkr has joined #openstack-swift | 03:12 | |
| *** nanzha has quit IRC | 05:18 | |
| *** nanzha has joined #openstack-swift | 05:19 | |
| *** baojg has quit IRC | 05:31 | |
| *** baojg has joined #openstack-swift | 05:34 | |
| *** pcaruana has joined #openstack-swift | 05:43 | |
| *** openstackstatus has joined #openstack-swift | 06:09 | |
| *** ChanServ sets mode: +v openstackstatus | 06:09 | |
| *** pcaruana has quit IRC | 06:56 | |
| *** rcernin has quit IRC | 06:58 | |
| *** nanzha has quit IRC | 07:04 | |
| *** nanzha has joined #openstack-swift | 07:04 | |
| *** ccamacho has joined #openstack-swift | 07:48 | |
| *** manuvakery has quit IRC | 08:17 | |
| *** tesseract has joined #openstack-swift | 08:18 | |
| *** rdejoux has joined #openstack-swift | 08:29 | |
| *** pcaruana has joined #openstack-swift | 08:36 | |
| *** tkajinam has quit IRC | 08:56 | |
| *** FlorianFa has joined #openstack-swift | 08:58 | |
| *** mikecmpbll has joined #openstack-swift | 08:58 | |
| *** baojg has quit IRC | 09:01 | |
| *** rpittau|afk is now known as rpittau | 09:08 | |
| *** pawan-gupta has quit IRC | 09:17 | |
| *** mahatic has joined #openstack-swift | 09:57 | |
| *** ChanServ sets mode: +v mahatic | 09:57 | |
| *** tkajinam has joined #openstack-swift | 13:56 | |
| *** tkajinam has quit IRC | 13:56 | |
| *** tkajinam has joined #openstack-swift | 13:57 | |
| *** tkajinam has quit IRC | 15:00 | |
| *** pcaruana has quit IRC | 15:50 | |
| *** pcaruana has joined #openstack-swift | 15:51 | |
| *** gyee has joined #openstack-swift | 16:05 | |
| *** nanzha has quit IRC | 16:17 | |
| timburke | clayg, tdasilva so i had a thought last night about trying to create hard links or SLOs in normal containers where the target is in a container with versioning enabled | 16:32 |
|---|---|---|
| openstackgerrit | Thierry Carrez proposed openstack/swift master: Start README.rst with a better title https://review.opendev.org/695026 | 16:32 |
| timburke | i wonder if *symlink* (rather than versioned writes) should be responsible for allowing the null-namespace when following a versioning link | 16:33 |
| timburke | maybe take our SYMLOOP_EXTEND header and turn it into a "system symlink" concept, where it both prevents the hop from counting against symloop_max *and* drops in the X-Backend-Allow-Reserved-Names header | 16:35 |
| clayg | timburke: I think that's reasonable - but you probably have some initial starting point context that you didn't state explicitly | 16:37 |
| clayg | what is happening currently if you create a hard link or slo in a normal container where the target is in a container with versioning enabled? | 16:37 |
| tdasilva | timburke: did you see this gist from clayg: https://gist.githubusercontent.com/clayg/c4bac5e7f0cee65688a68238b3574002/raw/00e028087c58ccdc4811b8efe36f153be53d48ef/fix-hardlinks.patch | 16:39 |
| timburke | i suspect (haven't confirmed yet) that the hardlink will fail. *maybe* slo will be ok, since it's left of VW? | 16:39 |
| tdasilva | are you referring to something like that? | 16:39 |
| timburke | similar, i think -- does that pass or fail right now? | 16:42 |
| tdasilva | pass | 16:43 |
| clayg | the hardlink test fails on master w/o the included fix in symlink to pass on the -backend header from the req to the new_req | 16:43 |
| timburke | and if the static link gets created in some *other* container? | 16:44 |
| clayg | timburke: yeah i just tested that - it's failing | 16:46 |
| clayg | doesn't have to be static - symlink to a name in a versioned container will fail | 16:46 |
| clayg | 😞 | 16:46 |
| timburke | fail on GET, not PUT, though, yeah? | 16:47 |
| clayg | right you can create the symlink to anything 😁 | 16:47 |
| *** tesseract has quit IRC | 16:51 | |
| clayg | timburke: yeah so I'm aboslutely fine with a sysmeta you can put on a symlink that makes symlink automatically include the x-backend header for the null namespace | 16:51 |
| clayg | sounds totally reasonable to me | 16:51 |
| clayg | very much like symloop_extend | 16:51 |
| clayg | not sure yet if there's an obvious reason to conflate the two under a generic "system symlink" umbrella | 16:52 |
| timburke | fair enough -- maybe it's a separate header | 16:52 |
| timburke | second thought i had: forbidding user names in reserved containers is 100% the way to go -- because otherwise you have to worry about people doing dumb things pre-upgrade, like `curl http://saio:8090/v1/AUTH_test/c -X PUT -H x-history-location:%00versions%00not-c`, waiting for not-c to get versioning enabled *post*-upgrade, then writing a bunch of data that is basically inaccessible | 16:52 |
| openstackgerrit | Charles Hsu proposed openstack/python-swiftclient master: WIP: Support uploading Swift symlinks without content. https://review.opendev.org/694211 | 16:53 |
| clayg | ^ whoa! wtg @chaz | 16:54 |
| timburke | we probably need to think about people creating DLOs that try to grab all versions in a container | 16:54 |
| clayg | @timburke uhhh, no we don't 😁 | 16:55 |
| clayg | @timburke I mean... if we have a "future work" list going somewhere we can add that | 16:55 |
| clayg | I think we also wanted to "think about" having symlinks to specific versions - but it seems like having "symlinks to objects in versioned containers" is probably more on topic | 16:56 |
| clayg | @timburke currently @tdasilva has DELETE?version-id=<current-version> responding with 400 | 16:56 |
| tdasilva | or maybe 501 | 16:57 |
| clayg | I think we need to talk more about an API to create a static link to a specific version so that s3api can implement "restore on DELETE" at least in the standard case | 16:57 |
| clayg | then maybe we can leave the bulk delete case still resulting with a tombstone if you happen to send a delete for the current version - see if people complain | 16:58 |
| clayg | we don't currently support PUT?version-id= | 16:58 |
| clayg | ^ can we hijack that to mean "make a symlink to a given version" | 16:59 |
| clayg | that plus DELETE?version-id=null I think solves pretty much anything a user or middleware might want to do with the is_latest pointer | 16:59 |
| openstackgerrit | Charles Hsu proposed openstack/python-swiftclient master: WIP: Support uploading Swift symlinks without content. https://review.opendev.org/694211 | 17:00 |
| *** rpittau is now known as rpittau|afk | 17:06 | |
| *** rdejoux has quit IRC | 17:13 | |
| *** ccamacho has quit IRC | 17:23 | |
| *** mikecmpbll has quit IRC | 17:33 | |
| DHE | to clarify something, if keystoneauth middleware is in use, any user using their own project normally must be in a role in which is listed in "operator_roles", correct? | 17:55 |
| DHE | (ACLs notwithstanding) | 17:55 |
| openstackgerrit | Tim Burke proposed openstack/swift master: py3: Fix s3api header casing https://review.opendev.org/695053 | 17:57 |
| timburke | DHE, correct. if not explicitly configured, that defaults to "admin" and "swiftoperator" | 18:02 |
| timburke | my impression is that a lot of deployments add "member" | 18:02 |
| DHE | okay, thanks. I'll take care of that then | 18:04 |
| DHE | I guess I was hoping for a distinct tier level or something... | 18:04 |
| openstackgerrit | Thiago da Silva proposed openstack/swift master: New Object Versioning mode https://review.opendev.org/682382 | 18:05 |
| timburke | DHE: a distinct tier to do what? the keystoneauth middleware was last updated like two years ago, it almost certainly needs more love than it receives -- what would you like to see out of it? | 18:06 |
| DHE | I'm not entirely sure. Maybe 3 tiers: "admin" (can create/delete accounts), "operator" (can create containers and set container fields within their project/project), and "user" (can manipulate objects within existing containers) | 18:07 |
| timburke | (i realize this has a very high likelihood of devolving to a conversation about how we ought to have something like policy.json, preferably with defaults in code ;-) | 18:08 |
| DHE | hahaha.. probably... | 18:08 |
| timburke | fwiw, create/delete accounts mostly maps to our idea of a "reseller admin", which *does* at least have some support | 18:08 |
| DHE | or maybe an ACL that takes 3 fields: user, project, and role, with the expectation that if you use the 'role' field then for 'user' you would use a * | 18:09 |
| timburke | and i've often thought it would be useful to have a read-only tier, where users can do listings and fetch objects, but not modify anything | 18:10 |
| DHE | meh, a man can dream. I can manage with what I have | 18:11 |
| openstackgerrit | Tim Burke proposed openstack/swift master: Switch py2 DSVM jobs to only run swift under py2 https://review.opendev.org/695057 | 18:17 |
| timburke | i *think* ^^^ is the right idea in light of http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010938.html ? | 18:18 |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: New Object Versioning mode https://review.opendev.org/682382 | 18:49 |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: WIP: s3api: Implement object versioning API https://review.opendev.org/673682 | 18:49 |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: Allow internal clients to use reserved namespace https://review.opendev.org/682138 | 18:52 |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: New Object Versioning mode https://review.opendev.org/682382 | 18:52 |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: WIP: s3api: Implement object versioning API https://review.opendev.org/673682 | 18:52 |
| clayg | i might have done it right that time 🤷♂️ | 18:52 |
| timburke | LGTM! | 18:52 |
| timburke | thanks clayg | 18:53 |
| timburke | i think i'm still gonna take a crack at version-aware listings for non-version-y containers -- let zuul chew on those ceph tests a while, see what they look like in a bit | 18:54 |
| *** gmann is now known as gmann_afk | 19:57 | |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: New Object Versioning mode https://review.opendev.org/682382 | 20:30 |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: WIP: s3api: Implement object versioning API https://review.opendev.org/673682 | 20:30 |
| *** openstackgerrit has quit IRC | 20:35 | |
| *** openstackgerrit has joined #openstack-swift | 20:47 | |
| openstackgerrit | Merged openstack/swift master: Start README.rst with a better title https://review.opendev.org/695026 | 20:47 |
| DHE | til rings (or rather, builders) built by python2 are not compatible with python3 and vice versa... | 21:02 |
| *** gmann_afk is now known as gmann | 21:03 | |
| clayg | oh man, test.unit.common.middleware.helpers.FakeSwift and test.unit.common.middleware.s3api.helpers.FakeSwift are *very* similar | 21:29 |
| timburke | DHE, which version of py2? i knew about https://bugs.launchpad.net/swift/+bug/1644387 and assumed that we could just tell people to upgrade to at least 2.7.13 (or whatever version first fixed that array/pickle interaction) | 21:40 |
| openstack | Launchpad bug 1644387 in OpenStack Object Storage (swift) "Ring builder files need a consistent format" [Undecided,New] | 21:40 |
| timburke | i wasn't aware of any issue reading py2-generated builders on py3... :-/ | 21:42 |
| timburke | also: is that similar to the error you were seeing? whatever the error, if we *can* fix it in swift, i'd certainly like to... | 21:42 |
| openstackgerrit | Tim Burke proposed openstack/swift master: New Object Versioning mode https://review.opendev.org/682382 | 21:57 |
| openstackgerrit | Tim Burke proposed openstack/swift master: WIP: s3api: Implement object versioning API https://review.opendev.org/673682 | 21:57 |
| *** rcernin has joined #openstack-swift | 21:59 | |
| timburke | hmm... should we do a meeting tomorrow? idk that i'll have much to go over... | 22:01 |
| *** rcernin has quit IRC | 22:01 | |
| timburke | we should *definitely* skip next week's | 22:01 |
| *** rcernin has joined #openstack-swift | 22:01 | |
| *** rcernin has quit IRC | 22:01 | |
| *** rcernin has joined #openstack-swift | 22:02 | |
| mattoliverau | morning | 22:09 |
| *** pcaruana has quit IRC | 22:33 | |
| openstackgerrit | Tim Burke proposed openstack/swift master: Remove a bunch of known-failures that moved from boto to boto3 https://review.opendev.org/695109 | 22:57 |
| timburke | a little unfortunate that those weren't flagged as missing tests... | 22:58 |
| *** tkajinam has joined #openstack-swift | 23:07 | |
| DHE | timburke: 2.7.5 from centos7... | 23:17 |
| timburke | DHE, ah. does the error match the bug? and if you take a builder written on py2, can py3 read it? if not, how does it fail? | 23:18 |
| DHE | timburke: I think so, but there's a twist. the main ring builder did work, but the composite ring builder did not | 23:20 |
| timburke | oh, interesting... yeah, i definitely haven't looked at composite builders in a while :-/ | 23:21 |
| DHE | it's also possible there are some version mismatches. this host has swift installed for both python2 and python3, so maybe there's a version incompatibility? | 23:21 |
| DHE | it wasn't a very scientific testing | 23:22 |
| timburke | if you've still got the traceback handy, i wouldn't mind taking a look... | 23:34 |
| DHE | sadly I don't... | 23:34 |
| timburke | no worries -- i'll look into it a bit more | 23:35 |
| DHE | it started with an error that the component builder files were missing an 'id' field, and in my attempt to disassemble the builder files with python straight up there were pickle errors about unicode/utf8 characters | 23:35 |
| DHE | that might be a version difference if the main ring builder were older than the composer... | 23:36 |
| openstackgerrit | Tim Burke proposed openstack/swift master: Allow internal clients to use reserved namespace https://review.opendev.org/682138 | 23:58 |
| openstackgerrit | Tim Burke proposed openstack/swift master: New Object Versioning mode https://review.opendev.org/682382 | 23:58 |
| openstackgerrit | Tim Burke proposed openstack/swift master: WIP: s3api: Implement object versioning API https://review.opendev.org/673682 | 23:58 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!