Thursday, 2020-07-23

*** gyee has quit IRC00:03
claygi love how no one even suggests a test for p 742549 (poor container sync)00:32
patchbothttps://review.opendev.org/#/c/742549/ - swift - Actually interpolate error message - 1 patch set00:32
*** mvkr has quit IRC02:17
*** baojg has quit IRC02:17
*** baojg has joined #openstack-swift02:18
*** mvkr has joined #openstack-swift02:30
*** rcernin has quit IRC03:28
*** rcernin has joined #openstack-swift03:43
*** rcernin has quit IRC03:47
*** rcernin has joined #openstack-swift03:49
*** m75abrams has joined #openstack-swift05:35
openstackgerritMerged openstack/swift master: Actually interpolate error message  https://review.opendev.org/74254908:11
*** rcernin has quit IRC08:56
*** tristan888 has joined #openstack-swift10:06
*** tristan888 has quit IRC12:07
*** baojg has quit IRC12:53
*** baojg has joined #openstack-swift12:54
*** jadonn has quit IRC12:58
*** baojg has quit IRC13:35
*** baojg has joined #openstack-swift13:37
* ktsuyuzaki noticed he missed the meeting in this week because of holiday week in Japan, sorry.13:49
*** m75abrams has quit IRC14:04
*** baojg has quit IRC15:48
*** baojg has joined #openstack-swift15:49
openstackgerritTim Burke proposed openstack/swift master: Allow replication servers to handle all request methods  https://review.opendev.org/74086716:11
openstackgerritTim Burke proposed openstack/swift master: Allow direct and internal clients to use the replication network  https://review.opendev.org/73575116:11
openstackgerritTim Burke proposed openstack/swift master: wip: Allow probe tests to run with separate replication network  https://review.opendev.org/74172316:11
claygit seems like rolling upgrades with encryption has some difficulties p 74203316:12
patchbothttps://review.opendev.org/#/c/742033/ - swift - py3: Work with proper native string paths in crypt... - 3 patch sets16:12
timburkehmm... we forgot about that for the v1->v2 transition...16:14
timburkeor we just decided to accept that some 500s on read were acceptable so long as the upgrade window was reasonably short16:15
timburkeand of course, it only affects new data written since the upgrade began. so *that's* good (or, about as good as we could hope for, anyway)16:17
*** gyee has joined #openstack-swift16:17
timburkehmm... since py2 was already writing things in this format, i suppose we could continue calling it v2... the only time that you really want the certainty of knowing that data was written after this fix is if you've also got a bad pipeline so you're affected by https://bugs.launchpad.net/swift/+bug/181372516:52
openstackLaunchpad bug 1813725 in OpenStack Object Storage (swift) "Object encryption key truncated sometimes when used with Barbican" [Medium,Confirmed]16:52
timburkeclayg, i wonder if maybe we should've had a sense of major/minor versions for encryption key ids... the variations that we have today are all trying for the same core idea; in most cases, all three versions likely produce the same value... but at the same time, i really like that we have a way of saying "this was written *after* this fix was applied; you don't need to waste time checking for x y and z"17:01
timburkeupgrade step 1: turn on https://github.com/openstack/swift/blob/master/swift/common/middleware/read_only.py :P17:02
openstackgerritTim Burke proposed openstack/swift master: Allow direct and internal clients to use the replication network  https://review.opendev.org/73575117:16
openstackgerritTim Burke proposed openstack/swift master: wip: Allow probe tests to run with separate replication network  https://review.opendev.org/74172317:16
claygyeah there's not a whole lot that can be done now is there; even if we wrote "version 2.1" it still wouldn't be in (1, 2) - stupid old code17:40
openstackgerritTim Burke proposed openstack/swift master: container-sharding: Stable overlap order  https://review.opendev.org/74253517:41
timburkeclayg, so... what do we want to do about it? is it ok to bump versions? or should we punt for now and say we're just making py3 behave like py2, so keep it v2?17:46
timburkethere'll still be an opportunity for old proxies to 500 because of writes during the upgrade, though17:47
claygeven if we don't change the version ?17:47
timburkeyup -- think about seongsoocho's cluster, that's py3 today. during the upgrade, both old and new proxies will be able to read already-written data, but newly written data will only be readable by new proxies (if there's non-ascii in the path)17:48
timburkepy2 -> py3-with-latest should be smooth at least, though17:50
claygwell then blowing up on a version check seems more reasonable than blowing up unexpected metadata formatting17:50
timburkethe downside, of course, is that the version check (currently) blows up on *all* paths, even ascii-only ones17:51
timburkemaybe there's a reasonable middle ground? write down that it's v2 if all ascii, v3 if not?17:52
claygis there18:00
clayglet me look more closely at the data format and see if i have any ideas18:00
claygnm, i still don't know what a "wsgi string" is; I'm not going to be any help 😞18:23
openstackgerritMerged openstack/swift stable/ussuri: py3: Stop munging RAW_PATH_INFO  https://review.opendev.org/74233818:25
timburkeclayg, sorry, that's on me for not explaining it enough/well enough. i'm debating about whether we should apply http://paste.openstack.org/show/796261/, basically -- so if the v2 and v3 paths would be the same on both py2 and py3, write it down as v219:09
claygheh, I don't think it's your fault I don't know what a wsgi string is 😁19:10
timburkei made up the term, i think it's on me to explain it ;-)19:11
claygheh19:11
timburkeanyway, doing something similar for the v1/v2 split seems *way* trickier/more dangerous because of the copy pipeline placement problem19:11
claygi'm not familiar with "the copy pipeline placement problem"19:12
claygthe paste seems good and bad - on one hand if it's the best we can do it's probably "good enough" for us in that most of our ML dataset is ascii19:13
claygthe bad parts are 1) it doesn't work in general and 2) there's ambiguity about version/format going forward19:13
claygi.e. more cruft & less obvious for "only just barely works in this one cluster" that we happen to care about disproportionately - not a great trade off19:14
claygi'm remembering something similar about quoted-roots - were we wanted to get to the new format, but ended up just deprecating the old despite always still writing it 🤔19:15
timburke"the copy pipeline placement problem": we don't have good checks on pipeline ordering (i should rebase p 635040 ...) which makes it easy to have "bad" pipelines. middleware auto-insertion makes this worse -- in particular, in bug 1813725 i found that if you didn't explicitly place copy *and* you only had one proxy-logging middleware (at the end of the pipeline, after encryption), then when users copy data around, the crypto meta continues19:18
openstackbug 1813725 in OpenStack Object Storage (swift) "Object encryption key truncated sometimes when used with Barbican" [Medium,Confirmed] https://launchpad.net/bugs/181372519:18
timburkepointing at the old location19:18
patchbothttps://review.opendev.org/#/c/635040/ - swift - Include some pipeline validation during proxy-serv... - 5 patch sets19:18
timburkeas for quoted-root, looks like we intentionally chose *not* to continue writing the old meta: https://github.com/openstack/swift/blob/2.25.0/swift/container/sharder.py#L673-L67619:22
timburkei think i'd originally had it writing down both, though19:22
claygoh, good there was some sort of graceful degradation - that's good that we didn't have to write both19:23
claygso it's a similar problem yeah?  1) we need new py3 proxies to read old py2 data 2) we want to have less variety in what we write down19:24
claygwhat would it take to write down something that old py2 proxies would read?19:25
timburkejust gotta say that it's v2. we could do that in all cases, but it'd make old py3 proxies sad. maybe i add a config option? write_metadata_version = 2|3 ? default to 2 this cycle, 3 the next, and hope to get rid of it... someday?19:29
timburkeif we're going that route, i'm inclined to have it *really* write the old (bad) format on py3 when you set it to 2. should ensure a smooth upgrade for everyone, assuming nobody's running a mixed py2/py3 environment in perpetuity19:32
claygyeah there's some ambiguity in the v2 format?  it's writes one set of bytes on py2 and a different set on py319:35
timburkeyup19:35
claygthe only thing i'm sure of we should introduce code that provides a way for future us to write data in backwards compatible format19:35
claygi.e. only blow up on version < 2 or something19:36
claygyou said major minor - which might make sense with a write_metadata_version tunable for when we want to cross major versions19:36
timburkeall right, i'll see what it's like to add a config option to continue writing down the bad until everybody's upgraded. my plan for the default seem reasonable? 2 for now, put something on my calendar to remind me to switch it to 3 in like 6mos or a year? that way you can upgrade without needing to change configs first19:39
claygi'm not sure i follow well enough to say19:42
timburkei'm a little surprised that nobody noticed or complained about the break in https://github.com/openstack/swift/commit/43103319d more than a year ago... should i try to support v1, too? 🤮19:43
claygit seems like maybe the default that makes sense depends on python you're running somehow?  as log as new code can read everything - what's the driver to start writing down in a different format?19:43
timburkewanting to minimize the ambiguity that gets written down19:45
claygmaybe it was just early enough we didn't have a lot of encryption19:45
claygcan v2 just grow a new meta-meta that says what the encoding is?19:45
timburkestill has the same trouble of "what's the driver to start writing down in a different format," no?19:54
*** renich has joined #openstack-swift21:03
openstackgerritMerged openstack/swift master: Allow replication servers to handle all request methods  https://review.opendev.org/74086721:23
clayghugokuo: lp bug #1778002 is going to be annoying... ssync has some cheeky assumptions about durablity https://github.com/openstack/swift/blob/master/swift/obj/ssync_receiver.py#L26521:27
openstackLaunchpad bug 1778002 in OpenStack Object Storage (swift) "EC non-durable fragment won't be deleted by reconstructor. " [High,Confirmed] https://launchpad.net/bugs/177800221:27
claygtechnically there's not currently a protocol to send a non-durable frag archive 🤔21:27
openstackgerritTim Burke proposed openstack/swift master: crypto: Add config option to support rolling upgrades  https://review.opendev.org/74275621:57
timburkeclayg, see what you think of ^^^ -- i'd be happy to squash it in, too21:57
*** dsariel has joined #openstack-swift22:11
*** dsariel has quit IRC22:12
timburkeugh -- that doesn't actually work right, it starts using the wrong path when making the key... gonna take me a bit to get it right, i think :-(22:18
*** dsariel has joined #openstack-swift22:21
*** dsariel has quit IRC22:22
openstackgerritTim Burke proposed openstack/swift master: crypto: Add config option to support rolling upgrades  https://review.opendev.org/74275622:57
openstackgerritTim Burke proposed openstack/swift master: crypto: Add config option to support rolling upgrades  https://review.opendev.org/74275623:28

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!