Wednesday, 2019-12-11

openstackgerritTim Burke proposed openstack/swift master: Add proxy-server option to quote-wrap all ETags
*** gyee has quit IRC01:09
tdasilvatimburke, 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
openstackgerritTim Burke proposed openstack/swift master: py3: Make seamless reloads work
timburkei really need to get some py3 probe tests in the gate :-/01:14
timburketdasilva, my only concern would be complicating the testing of the combined state -- but probe tests can manage a split-brain just fine01:16
tdasilva+1 to py3 probe test01:17
tdasilvatimburke: yeah, i was thinking we would need a probe test01:17
tdasilvaand direct_client doesn't have a direct_post_container :/01:18
*** rcernin has quit IRC01:53
claygtdasilva: timburke: I think we could "resolve" conflict just by saying x-versions-enabled always trumps container-sync02:43
claygso if you have a container-sync'ing container - but through split brain you manage to get it versioned - ok, no more syncing02:44
tdasilvaclayg, 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 syncing02:48
openstackgerritThiago da Silva proposed openstack/swift master: WIP: prevent cont-sync when versioning enabled
*** rcernin has joined #openstack-swift02:54
tdasilvaclayg: ^ no tests yet02:54
*** psachin has joined #openstack-swift03:41
*** diablo_rojo has quit IRC04:29
*** ianychoi has joined #openstack-swift05:32
*** pcaruana has joined #openstack-swift06:09
*** himes_ has joined #openstack-swift06:32
*** himes_ is now known as Hxdoom06:32
*** ianychoi_ has joined #openstack-swift07:08
*** ianychoi has quit IRC07:11
*** tesseract has joined #openstack-swift07:57
*** tkajinam has quit IRC08:12
*** ccamacho has joined #openstack-swift08:13
*** pcaruana has quit IRC08:22
*** rpittau|afk is now known as rpittau08:36
*** ccamacho is now known as ccamacho|pto08:50
openstackgerritCharles Hsu proposed openstack/python-swiftclient master: Support uploading Swift symlinks without content.
*** zaitcev has quit IRC09:20
openstackgerritThiago da Silva proposed openstack/swift master: Update list of experimental upgrade tests
*** zaitcev has joined #openstack-swift09:34
*** ChanServ sets mode: +v zaitcev09:34
*** ccamacho|pto has quit IRC09:38
*** ccamacho has joined #openstack-swift09:38
*** rcernin has quit IRC09:50
*** ccamacho is now known as ccamacho|pto09:54
*** farhanjamil has joined #openstack-swift09:55
*** ianychoi_ has quit IRC09:56
*** farhanjamil has quit IRC10:07
*** Hxdoom has quit IRC10:56
*** pcaruana has joined #openstack-swift11:36
*** ianychoi has joined #openstack-swift11:49
*** spsurya has joined #openstack-swift12:05
manuvakery@alecuyer hi13:58
*** gyee has joined #openstack-swift16:55
*** rpittau is now known as rpittau|afk17:13
*** psachin has quit IRC17:19
*** diablo_rojo has joined #openstack-swift17:44
openstackgerritMerged openstack/swift master: Update list of experimental upgrade tests
timburketdasilva, 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
timburkemaybe 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 - swift - Enable s3api and staticweb tests across all func t... - 6 patch sets18:06
openstackgerritClay Gerrard proposed openstack/swift master: WSGI server workers must drop_privledges
timburkethose 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, 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-swift18:50
openstackgerritClay Gerrard proposed openstack/swift master: s3api: Implement object versioning API
*** mvkr has quit IRC19:06
*** spsurya has quit IRC19:14
tdasilvatimburke: 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 - swift - Enable s3api and staticweb tests across all func t... - 6 patch sets19:35
tdasilvatimburke: if we want to keep queens, we could try to add some version checking to make sure it's added only after queens19:35
*** tesseract has quit IRC19:46
claygso it turns out maybe p 691877 doesn't have quite as many test_shell updates as I'd like 😬20:33
patchbot - python-swiftclient - WIP: object versioning features - 6 patch sets20:33
timburkealmost meeting time!20:53
timburketdasilva, 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
timburkelike, 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 cases20:58
mattoliveraukota_: o/20:58
kota_mattoliverau: hi20:58
mattoliverauseongsoocho: o/20:59
kota_seongsoocho: o/20:59
*** rcernin has joined #openstack-swift21:23
*** mvkr has joined #openstack-swift21:30
*** pcaruana has quit IRC21:38
*** henriqueof has quit IRC21:52
*** henriqueof has joined #openstack-swift21:52
tdasilvawe could continue here22:01
timburkesorry to run a little over -- go get breakfast you time-travelers from the future!22:01
rledisezi 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 other22:02
seongsoocho( See you on next meeting !! )22:02
timburkemmm... interop is definitely a concern22:02
timburkethanks for coming seongsoocho!22:02
rledisezwe have at ovh a middleware that allow users to enable the correct etag format on a per container basis (through a meta)22:02
timburkei exposed it in /info at least... oh, per-container mware solution might be nice...22:03
rledisezwe don't communicate on it, but when we get feedback about that, we just pass the information22:03
tdasilvarledisez: i think timburke just makes that a cluster option22:04
rledisezwe could even, at some point, do the opposite (enable it by default and allow to disable it on per account/container basis)22:04
timburkeif it were its own middleware, it should be pretty easy to have a global default22:05
tdasilvai think ideally we should have a roadmap to be rfc compliant by default and deprecate current behavior, no?22:05
rlediseztdasilva: 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 customers22:05
rledisezbut if a new operator start from fresh, he can decide to enable it (i get that)22:05
rlediseztdasilva: I agree with the roadmap22:06
tdasilvarledisez: yeah totally22:06
timburkefwiw, 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-container22:06
timburkerledisez, what do you think about proposing the middleware you've got upstream?22:06
rlediseztimburke: same for us, it was fastly22:07
rlediseztimburke: sure, i'll push it22:07
timburkeer, akamai. you know who i mean ;-)22:07
timburkethanks! i think i'd be fine with that as a solution -- even having the middleware in our default, recommended pipelines22:08
rledisezi have to go, i'll try to push it this week22:08
timburke(with everything off by default for backwards compat, etc...)22:08
rledisezgood day/night all22:08
tdasilvarledisez: good night!22:09
tdasilvatimburke: re p  691877...22:10
patchbot - python-swiftclient - WIP: object versioning features - 6 patch sets22:10
tdasilvanope, wrong patch22:10
tdasilvap p 69174722:11
patchbot - swift - Enable s3api and staticweb tests across all func t... - 6 patch sets22:11
tdasilvayou 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
timburketdasilva, well, i'm not *sure* that the region change is the cause...22:16
*** mvkr has quit IRC22:16
timburkebut 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 recommendation22:17
timburkeand it's not clear that operators still using rocky would be following along and trying to get their config to more-closely match new recommendations22:18
tdasilvatimburke: yeah I agree, but I do want to make the recommendations that were given out in rocky for example22:18
tdasilvaif that's the earliest release we would be testing against22:19
*** mvkr has joined #openstack-swift22:20
tdasilvafor example, did the region change come after rocky?22:20
timburkeyep -- 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't22:21
timburkethis seems similar in my mind to arguments about what should and shouldn't be backported...22:22
timburkebut 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
tdasilvatimburke: 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 updated22:26
tdasilvai guess those config files should reflect the defaults from the earliest release we are testing against?22:27
timburkeand 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
timburkethat was my thought. using the old config is *definitely* a valuable test22:28
tdasilvaside node, we should expand that test to also upgrade the proxy22:29
timburkeif we drop the make_rings change, we still get the new recommendation in the rolling upgrade jobs *eventually*, right?22:30
timburkejust gotta wait for the next release22:30
tdasilvabut how would we test s3api with rocky?22:31
tdasilvaor are you saying we wouldn't ?22:32
timburkewe don't, i think22: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, though22:34
timburkeeven 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 test22:35
timburke(i feel like, anyway)22:35
timburkedoes that turn on s3api for the DSVM job? i forget now, and the logs have expired...22:37
timburkemaybe it's just the in-process guys...22:38
timburkei 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 swift322:39
tdasilvayeah, i think that's right22:39
tdasilvai'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
tdasilvai 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 jobs22:42
*** tkajinam has joined #openstack-swift23:08
*** ccamacho|pto has quit IRC23:59

Generated by 2.15.3 by Marius Gedminas - find it at!