| openstackgerrit | Tim Burke proposed openstack/swift master: Add proxy-server option to quote-wrap all ETags https://review.opendev.org/695131 | 00:31 |
|---|---|---|
| *** gyee has quit IRC | 01:09 | |
| tdasilva | timburke, clayg: re object-versioning and container-sync, besides skipping x-versions-enabled containers, i think it also makes sense to prevent users from enabling sync on already versioned-enabled containers and vice-versa, thoughts? | 01:14 |
| openstackgerrit | Tim Burke proposed openstack/swift master: py3: Make seamless reloads work https://review.opendev.org/698347 | 01:14 |
| timburke | i really need to get some py3 probe tests in the gate :-/ | 01:14 |
| timburke | tdasilva, my only concern would be complicating the testing of the combined state -- but probe tests can manage a split-brain just fine | 01:16 |
| tdasilva | +1 to py3 probe test | 01:17 |
| tdasilva | timburke: yeah, i was thinking we would need a probe test | 01:17 |
| tdasilva | and direct_client doesn't have a direct_post_container :/ | 01:18 |
| *** rcernin has quit IRC | 01:53 | |
| clayg | tdasilva: timburke: I think we could "resolve" conflict just by saying x-versions-enabled always trumps container-sync | 02:43 |
| clayg | so if you have a container-sync'ing container - but through split brain you manage to get it versioned - ok, no more syncing | 02:44 |
| tdasilva | clayg, timburke: yeah, that's basically how I have it. Also need to add the skip static link piece which would further prevent versioned objects from syncing | 02:48 |
| clayg | boom! | 02:48 |
| openstackgerrit | Thiago da Silva proposed openstack/swift master: WIP: prevent cont-sync when versioning enabled https://review.opendev.org/698139 | 02:54 |
| *** rcernin has joined #openstack-swift | 02:54 | |
| tdasilva | clayg: ^ no tests yet | 02:54 |
| *** psachin has joined #openstack-swift | 03:41 | |
| *** diablo_rojo has quit IRC | 04:29 | |
| *** ianychoi has joined #openstack-swift | 05:32 | |
| *** pcaruana has joined #openstack-swift | 06:09 | |
| *** himes_ has joined #openstack-swift | 06:32 | |
| himes_ | hi | 06:32 |
| *** himes_ is now known as Hxdoom | 06:32 | |
| *** ianychoi_ has joined #openstack-swift | 07:08 | |
| *** ianychoi has quit IRC | 07:11 | |
| *** tesseract has joined #openstack-swift | 07:57 | |
| *** tkajinam has quit IRC | 08:12 | |
| *** ccamacho has joined #openstack-swift | 08:13 | |
| *** pcaruana has quit IRC | 08:22 | |
| *** rpittau|afk is now known as rpittau | 08:36 | |
| *** ccamacho is now known as ccamacho|pto | 08:50 | |
| openstackgerrit | Charles Hsu proposed openstack/python-swiftclient master: Support uploading Swift symlinks without content. https://review.opendev.org/694211 | 09:19 |
| *** zaitcev has quit IRC | 09:20 | |
| openstackgerrit | Thiago da Silva proposed openstack/swift master: Update list of experimental upgrade tests https://review.opendev.org/698429 | 09:32 |
| *** zaitcev has joined #openstack-swift | 09:34 | |
| *** ChanServ sets mode: +v zaitcev | 09:34 | |
| *** ccamacho|pto has quit IRC | 09:38 | |
| *** ccamacho has joined #openstack-swift | 09:38 | |
| *** rcernin has quit IRC | 09:50 | |
| *** ccamacho is now known as ccamacho|pto | 09:54 | |
| *** farhanjamil has joined #openstack-swift | 09:55 | |
| *** ianychoi_ has quit IRC | 09:56 | |
| *** farhanjamil has quit IRC | 10:07 | |
| *** Hxdoom has quit IRC | 10:56 | |
| *** pcaruana has joined #openstack-swift | 11:36 | |
| *** ianychoi has joined #openstack-swift | 11:49 | |
| *** spsurya has joined #openstack-swift | 12:05 | |
| manuvakery | @alecuyer hi | 13:58 |
| *** gyee has joined #openstack-swift | 16:55 | |
| *** rpittau is now known as rpittau|afk | 17:13 | |
| *** psachin has quit IRC | 17:19 | |
| *** diablo_rojo has joined #openstack-swift | 17:44 | |
| openstackgerrit | Merged openstack/swift master: Update list of experimental upgrade tests https://review.opendev.org/698429 | 17:58 |
| timburke | tdasilva, on ^^^ i'm kinda torn... i get the need to limit the number of jobs at some point, but queens doesn't seem *so* far back... | 18:01 |
| timburke | maybe related: i'm still not sure about the make_rings change in p 691747 -- i guess the question is: what signal are we trying to get from the upgrade jobs? currently, we test moving from an old deployment using the old recommended configs to latest version while keeping existing config. that patch would have us testing an old deployment with currently-recommended configs -- but idk that anyone would actually be *doing that*... | 18:06 |
| patchbot | https://review.opendev.org/#/c/691747/ - swift - Enable s3api and staticweb tests across all func t... - 6 patch sets | 18:06 |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: WSGI server workers must drop_privledges https://review.opendev.org/698563 | 18:16 |
| timburke | those SignatureDoesNotMatch errors on rocky still don't make sense to me :-( i thought i was on to something when i noticed that the default region changed between rocky and stein in https://github.com/openstack/swift/commit/692a034, but there are a bunch of v4 tests that *do* pass... if it was because of the region mismatch, i would've thought they'd *all* fail... | 18:18 |
| *** henriqueof has joined #openstack-swift | 18:50 | |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: s3api: Implement object versioning API https://review.opendev.org/673682 | 18:53 |
| *** mvkr has quit IRC | 19:06 | |
| *** spsurya has quit IRC | 19:14 | |
| tdasilva | timburke: regarding the make_rings change in p 691747. Are you referring to adding s3api to the pipeline? If so, I'd argue that's a suggested deployment config that would have been used since s3api was released, no? | 19:35 |
| patchbot | https://review.opendev.org/#/c/691747/ - swift - Enable s3api and staticweb tests across all func t... - 6 patch sets | 19:35 |
| tdasilva | timburke: if we want to keep queens, we could try to add some version checking to make sure it's added only after queens | 19:35 |
| *** tesseract has quit IRC | 19:46 | |
| clayg | so it turns out maybe p 691877 doesn't have quite as many test_shell updates as I'd like 😬 | 20:33 |
| patchbot | https://review.opendev.org/#/c/691877/ - python-swiftclient - WIP: object versioning features - 6 patch sets | 20:33 |
| timburke | almost meeting time! | 20:53 |
| timburke | tdasilva, yeah, s3api was certainly something we'd would've recommended as far back as rocky -- but what about the region issue, say? not sure that's actually the cause of the failures, but it seems closer to representative of what i'd worry about WRT retroactively applying new recommendations... | 20:55 |
| kota_ | morning | 20:57 |
| mattoliverau | morning | 20:58 |
| timburke | like, if we *do* need to apply the new default (or update what we're using for test.conf, or... *something*) to get tests passing -- would it still have the utility that we're looking for? i could probably be convinced that s3api could be a special case -- i'm just trying to feel out where the consensus opnion would be on more general cases | 20:58 |
| mattoliverau | kota_: o/ | 20:58 |
| kota_ | mattoliverau: hi | 20:58 |
| seongsoocho | morning | 20:59 |
| mattoliverau | seongsoocho: o/ | 20:59 |
| kota_ | seongsoocho: o/ | 20:59 |
| *** rcernin has joined #openstack-swift | 21:23 | |
| *** mvkr has joined #openstack-swift | 21:30 | |
| *** pcaruana has quit IRC | 21:38 | |
| *** henriqueof has quit IRC | 21:52 | |
| *** henriqueof has joined #openstack-swift | 21:52 | |
| tdasilva | we could continue here | 22:01 |
| timburke | sorry to run a little over -- go get breakfast you time-travelers from the future! | 22:01 |
| mattoliverau | lol | 22:02 |
| rledisez | i have reserve on etag patch. i'm afraid we end up with different public cloud api and we have users complaining they can't switch from one to an other | 22:02 |
| seongsoocho | ( See you on next meeting !! ) | 22:02 |
| timburke | mmm... interop is definitely a concern | 22:02 |
| timburke | thanks for coming seongsoocho! | 22:02 |
| rledisez | we have at ovh a middleware that allow users to enable the correct etag format on a per container basis (through a meta) | 22:02 |
| timburke | i exposed it in /info at least... oh, per-container mware solution might be nice... | 22:03 |
| rledisez | we don't communicate on it, but when we get feedback about that, we just pass the information | 22:03 |
| tdasilva | rledisez: i think timburke just makes that a cluster option | 22:04 |
| rledisez | we could even, at some point, do the opposite (enable it by default and allow to disable it on per account/container basis) | 22:04 |
| timburke | if it were its own middleware, it should be pretty easy to have a global default | 22:05 |
| tdasilva | i think ideally we should have a roadmap to be rfc compliant by default and deprecate current behavior, no? | 22:05 |
| rledisez | tdasilva: I know I would never enable it for now, because it would break so many clients that I would have to run forever to avoid angry customers | 22:05 |
| rledisez | but if a new operator start from fresh, he can decide to enable it (i get that) | 22:05 |
| rledisez | tdasilva: I agree with the roadmap | 22:06 |
| tdasilva | rledisez: yeah totally | 22:06 |
| timburke | fwiw, what prompted me to go poking at it was a customer hitting issues with a CDN (akami, i think?) -- i could certainly ask how many containers need to have this new behavior and whether it'd work to enable per-container | 22:06 |
| timburke | rledisez, what do you think about proposing the middleware you've got upstream? | 22:06 |
| rledisez | timburke: same for us, it was fastly | 22:07 |
| rledisez | timburke: sure, i'll push it | 22:07 |
| timburke | er, akamai. you know who i mean ;-) | 22:07 |
| timburke | thanks! i think i'd be fine with that as a solution -- even having the middleware in our default, recommended pipelines | 22:08 |
| rledisez | i have to go, i'll try to push it this week | 22:08 |
| timburke | (with everything off by default for backwards compat, etc...) | 22:08 |
| timburke | 👍 | 22:08 |
| rledisez | good day/night all | 22:08 |
| timburke | g'night | 22:09 |
| tdasilva | rledisez: good night! | 22:09 |
| tdasilva | timburke: re p 691877... | 22:10 |
| patchbot | https://review.opendev.org/#/c/691877/ - python-swiftclient - WIP: object versioning features - 6 patch sets | 22:10 |
| tdasilva | nope, wrong patch | 22:10 |
| tdasilva | p p 691747 | 22:11 |
| patchbot | https://review.opendev.org/#/c/691747/ - swift - Enable s3api and staticweb tests across all func t... - 6 patch sets | 22:11 |
| tdasilva | you mentioned "region issue", is that what's causing the rocky failures, what's the "region issue" is that the need to add the us-east or something like that? | 22:14 |
| timburke | tdasilva, well, i'm not *sure* that the region change is the cause... | 22:16 |
| *** mvkr has quit IRC | 22:16 | |
| timburke | but it seems like a pretty solid example of where we had one recommended config, then changed the recommendation (because we realized it wasn't a great recommendation), but we certainly still need to assume that there *are* working, happy deployments with the old recommendation | 22:17 |
| timburke | and it's not clear that operators still using rocky would be following along and trying to get their config to more-closely match new recommendations | 22:18 |
| tdasilva | timburke: yeah I agree, but I do want to make the recommendations that were given out in rocky for example | 22:18 |
| tdasilva | if that's the earliest release we would be testing against | 22:19 |
| *** mvkr has joined #openstack-swift | 22:20 | |
| tdasilva | for example, did the region change come after rocky? | 22:20 |
| timburke | yep -- between rocky and stein, we switch from recommending (and defaulting to) "US" to recommending "us-east-1" | 22:21 |
| timburke | *this particular case* is probably fine; i think i'd even be fine with changing regions in whatever places are necessary to get rocky passing. but more generally, i'd like to establish some consensus on guidelines for when we should be willing to update the previosuly-issued recommendation and when we shouldn't | 22:21 |
| timburke | this seems similar in my mind to arguments about what should and shouldn't be backported... | 22:22 |
| timburke | but if i were just guided by that, my gut feeling would definitely be: don't change the default or even the recommendation! continue testing what we previously told you to use, and make sure we don't paint ourselves into a corner :-) | 22:24 |
| tdasilva | timburke: I think we are in agreement on the intent of that tests. my only point is that it doesn't mean those configurations files (both tests.conf (client) and server configs) NEVER get updated | 22:26 |
| tdasilva | i guess those config files should reflect the defaults from the earliest release we are testing against? | 22:27 |
| timburke | and again -- i don't *think* that's the cause for the rocky failures. both proxy and test runner should be on old code, right? only backend servers are running updated. and old test.conf on the test runner, and i don't _think_ the proxy conf would specify a region either way... | 22:28 |
| timburke | that was my thought. using the old config is *definitely* a valuable test | 22:28 |
| tdasilva | +1 | 22:29 |
| tdasilva | side node, we should expand that test to also upgrade the proxy | 22:29 |
| tdasilva | s/node/note | 22:30 |
| timburke | +1 | 22:30 |
| timburke | if we drop the make_rings change, we still get the new recommendation in the rolling upgrade jobs *eventually*, right? | 22:30 |
| timburke | just gotta wait for the next release | 22:30 |
| tdasilva | but how would we test s3api with rocky? | 22:31 |
| tdasilva | or are you saying we wouldn't ? | 22:32 |
| timburke | we don't, i think | 22:33 |
| timburke | *maybe* we try to come up with something where we could *also* test that swift3 -> s3api transition? idk that it's a good trade-off in terms of developer time, though | 22:34 |
| timburke | even if we do that, i'm not sure we should try to backport/retrofit it to rocky. we made the best recommendation we could at the time, that's what we ought to test | 22:35 |
| timburke | (i feel like, anyway) | 22:35 |
| timburke | does that turn on s3api for the DSVM job? i forget now, and the logs have expired... | 22:37 |
| timburke | maybe it's just the in-process guys... | 22:38 |
| timburke | i seem to recall that devstack's swift3 support was part of why we didn't put s3api in the default pipeline as soon as we repatriated swift3 | 22:39 |
| tdasilva | yeah, i think that's right | 22:39 |
| tdasilva | i've got an idea for making the change to the pipeline conditional to a version number, i'll play with that later and update the patch, see how that comes out... | 22:40 |
| tdasilva | i think for now we could back out the changes to the rolling upgrade tests and let that patch merge thou? still valuable to reduce the number of jobs | 22:42 |
| timburke | 👍 | 22:44 |
| *** tkajinam has joined #openstack-swift | 23:08 | |
| *** ccamacho|pto has quit IRC | 23:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!