*** zaitcev has quit IRC | 00:03 | |
*** UnfairFunction has joined #openstack-swift | 00:32 | |
*** gyee has quit IRC | 00:50 | |
*** BjoernT has joined #openstack-swift | 02:26 | |
*** baojg has quit IRC | 02:45 | |
*** baojg has joined #openstack-swift | 02:45 | |
*** baojg has quit IRC | 02:53 | |
*** idlemind has quit IRC | 02:54 | |
*** BjoernT has quit IRC | 03:01 | |
*** BjoernT has joined #openstack-swift | 03:02 | |
*** pcaruana has joined #openstack-swift | 04:46 | |
*** UnfairFunction has joined #openstack-swift | 04:46 | |
*** BjoernT has quit IRC | 04:48 | |
*** e0ne has joined #openstack-swift | 05:14 | |
*** e0ne has quit IRC | 05:14 | |
*** e0ne has joined #openstack-swift | 05:16 | |
*** UnfairFunction has quit IRC | 05:30 | |
*** e0ne has quit IRC | 05:50 | |
*** e0ne has joined #openstack-swift | 06:21 | |
*** e0ne has quit IRC | 06:26 | |
*** rcernin has quit IRC | 06:57 | |
openstackgerrit | Matthew Oliver proposed openstack/swift master: Sharding: Clean up old CleaveConext's during audit https://review.opendev.org/681970 | 07:11 |
---|---|---|
*** e0ne has joined #openstack-swift | 07:57 | |
*** tkajinam has quit IRC | 08:04 | |
*** pcaruana has quit IRC | 08:57 | |
*** pcaruana has joined #openstack-swift | 09:01 | |
*** tesseract has joined #openstack-swift | 09:44 | |
*** openstackgerrit has quit IRC | 10:06 | |
*** pcaruana has quit IRC | 11:19 | |
*** e0ne_ has joined #openstack-swift | 11:20 | |
*** e0ne has quit IRC | 11:23 | |
*** psachin has joined #openstack-swift | 11:25 | |
*** pcaruana has joined #openstack-swift | 11:28 | |
*** redrobot has joined #openstack-swift | 12:26 | |
*** NM has joined #openstack-swift | 12:32 | |
*** psachin has quit IRC | 13:33 | |
*** BjoernT has joined #openstack-swift | 13:48 | |
NM | Hi timburke. As a workarround for the "too many headers" error (https://bugs.launchpad.net/swift/+bug/1843313) , I changed the max_meta_count (https://github.com/openstack/swift/blob/master/etc/swift.conf-sample#L132) so I could list the container and use de primaries nodes. | 14:38 |
openstack | Launchpad bug 1843313 in OpenStack Object Storage (swift) "Sharding handoffs creates a *ton* of container-server headers" [Undecided,New] | 14:38 |
*** gkadam has joined #openstack-swift | 14:54 | |
*** gkadam_ has joined #openstack-swift | 14:55 | |
*** gkadam has quit IRC | 14:56 | |
*** gkadam_ has quit IRC | 15:04 | |
*** gyee has joined #openstack-swift | 15:08 | |
*** theintern_ has joined #openstack-swift | 15:09 | |
*** NM has quit IRC | 15:44 | |
*** henriqueof has quit IRC | 16:02 | |
*** ormandj has joined #openstack-swift | 16:19 | |
ormandj | heya folks, when using vhost naming (for s3 access) - how do public buckets work? i couldn't find docs on it. aws s3 handles this by requiring globally unique bucket names | 16:20 |
ormandj | i ask since amazon is deprecating non-virtual style access in s3 in 2020 | 16:22 |
*** gmann is now known as gmann_afk | 16:23 | |
ormandj | i'm guessing public access will be via the normal naming scheme only, not allowing virtual host style, but was just curious | 16:28 |
*** NM has joined #openstack-swift | 16:32 | |
ormandj | (in the sense that we'll only allow public access via the swift mechanisms) | 16:37 |
*** e0ne_ has quit IRC | 16:50 | |
*** openstackgerrit has joined #openstack-swift | 16:51 | |
openstackgerrit | Tim Burke proposed openstack/swift master: proxy: Don't trust Content-Length for chunked transfers https://review.opendev.org/682173 | 16:51 |
*** tesseract has quit IRC | 16:53 | |
clayg | tdasilva: does p 682668 make it so functests pass even when allow_versioned is disabled? it gets auto inserted in the pipeline right - so I can't take it out? | 16:57 |
patchbot | https://review.opendev.org/#/c/682668/ - swift - Skip test when object versioning is not enabled - 1 patch set | 16:57 |
tdasilva | clayg: correct. You can't take versioned_writes out of the pipeline, but you can set the `allow_versioned_writes` to False. In that case a container PUT with a 'x-versions-location' will return a 412 | 17:12 |
timburke | NM, that makes sense as a workaround, thanks for mentioning it. hopefully we can get mattoliverau's patch reviewed and landed soon so you can crank it back down ;-) | 17:13 |
tdasilva | clayg: we have that check on the other Test classes, it was just the SLO that was missing: https://github.com/openstack/swift/blob/master/test/functional/test_versioned_writes.py#L73 | 17:14 |
timburke | ormandj, fortunately, we don't have to follow AWS's deprecation policies ;-) *un*fortunately, we don't currently have a way to do anonymous bucket access, since we give each tenant their own bucket namespace | 17:15 |
ormandj | yeah, that was my suspicion. unfortunately, everyone follows amazon s3 for compatibility, we already ran into an issue a few days back where synology requires virtualhost style support to use s3 api | 17:16 |
ormandj | luckily we were able to support that | 17:16 |
timburke | tdasilva, will it? i thought the container server simply refused to store the meta... | 17:17 |
ormandj | so i suspect when 2020 roles around and they disable non-vhost style access, you'll see more and more clients that rely on that behavior by default | 17:17 |
ormandj | for public access, not such a big deal luckily | 17:17 |
timburke | ormandj, we *do* support virtualhost-style naming, though -- look for the storage_domain option: https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L536-L538 | 17:18 |
ormandj | yeah, i've got it working now | 17:18 |
ormandj | that's what i meant when i said we were able to support that, apologies for lack of clarity :) | 17:19 |
timburke | 👍 glad to hear it's working for you | 17:19 |
ormandj | yeah working well, synology was plug and play afterwards, just got lucky i saw the snippit in the sample config before i went digging through code :) | 17:20 |
tdasilva | timburke: https://github.com/openstack/swift/blob/master/swift/common/middleware/versioned_writes.py#L714,L719 | 17:20 |
timburke | the DNS and wildcard certs make it a bit trickier to set up, of course :-( | 17:20 |
ormandj | yeah, we had 'fun' with the cert issue, ended up having to define another acceptable domain, luckily we use letsencrypt and have automated cert pushes | 17:20 |
ormandj | but it did work | 17:21 |
timburke | tdasilva, oh cool, right -- i was thinking of the auto-inserted case | 17:21 |
clayg | tdasilva: 👍 | 17:26 |
openstackgerrit | Clay Gerrard proposed openstack/swift master: s3api: Implement object versioning API https://review.opendev.org/682953 | 17:27 |
clayg | ^ i didn't mean that push that up yet, mis-type 😢 | 17:27 |
clayg | oh good, i was worried I'd pushed over p 673682 - but it's a fresh patch set | 17:28 |
patchbot | https://review.opendev.org/#/c/673682/ - swift - s3api: Implement versioning status API - 3 patch sets | 17:28 |
clayg | so no worries! | 17:29 |
NM | Helo eeryone. Is it recommend to have a single memcache pool for swift or can I have one for each location? Let's say I have 3 proxies in San Franscisco and 3 in Miami. Is it ok to have two distinct pools for each region? | 17:37 |
*** theintern_ has quit IRC | 17:40 | |
clayg | NM: distinct pool for each reason is very much a good idea! there may be some implications for cached auth tokens tho - which auth are you using? | 17:47 |
*** e0ne has joined #openstack-swift | 17:48 | |
*** e0ne has quit IRC | 17:49 | |
*** theintern_ has joined #openstack-swift | 17:56 | |
NM | clayg: thanks! right now I'm using keystone. My main concern is about the container process using a distinct pool. Because proxies don't talk to each other. But containers does. | 18:00 |
clayg | Yeah, but it's just a cache - if there's a miss whatever local process needs the info will just go to swift and get whatever it needs to know sticking it in the cache along the way | 18:00 |
openstackgerrit | Merged openstack/swift master: Add python3 to setup.cfg https://review.opendev.org/668578 | 18:01 |
*** e0ne has joined #openstack-swift | 18:01 | |
clayg | a region aware cache system would be super hawt - but as it seperate pools work a treat | 18:01 |
clayg | no worries with keystone - a token cached in region A will still have to "go to auth" when a request is made to region B, but thankfully clients don't typically seem to jump back and forth | 18:02 |
*** SkyRocknRoll has joined #openstack-swift | 18:28 | |
*** SkyRocknRoll has quit IRC | 18:28 | |
*** NM has quit IRC | 18:32 | |
*** NM has joined #openstack-swift | 18:33 | |
*** SkyRocknRoll has joined #openstack-swift | 18:36 | |
*** openstackgerrit has quit IRC | 18:37 | |
*** SkyRocknRoll has quit IRC | 18:39 | |
*** NM has quit IRC | 18:48 | |
*** NM has joined #openstack-swift | 18:49 | |
*** NM has quit IRC | 19:28 | |
*** NM has joined #openstack-swift | 19:29 | |
*** hoonetorg has quit IRC | 20:01 | |
*** theintern_ has quit IRC | 20:08 | |
*** pcaruana has quit IRC | 20:10 | |
clayg | tdasilva: timburke: so it looks like we do the name check on all requests, not just PUT | 20:44 |
clayg | but we could certainly change that - letting in null bytes for internal container names was fine | 20:44 |
*** openstackgerrit has joined #openstack-swift | 20:47 | |
openstackgerrit | Thiago da Silva proposed openstack/swift master: WIP: New Object Versioning mode https://review.opendev.org/682382 | 20:47 |
timburke | meeting time! | 21:01 |
openstackgerrit | Merged openstack/swift master: versioned_writes: checks for SLO object before copy https://review.opendev.org/681656 | 21:10 |
*** NM has quit IRC | 21:24 | |
*** e0ne has quit IRC | 21:41 | |
clayg | rledisez: what's the recommendation? | 21:59 |
clayg | is it like... don't bring anything and buy a phone/laptop when you get there? | 21:59 |
clayg | or maybe that's worse!? | 21:59 |
clayg | yeah I'm really curious | 21:59 |
kota_ | for shanghi? | 22:00 |
clayg | kota_: yeah are you bringing all your regular work equipment and personal phone with you? | 22:00 |
rledisez | bascially, blank laptop, blank phone. stickers on both to recognise them, no connections to the office (no mail/vpn or whatever). returning the hardware to the helpdesk when coming home | 22:00 |
kota_ | AFAIK, if you bring roaming SIM, it's not so matter to access any internet service like google | 22:00 |
mattoliverau | some people have been talking about a burner laptop. Ie. something that your happy nuking | 22:00 |
rledisez | and to not forget that encryption is forbidden there | 22:00 |
kota_ | but if you bought the local SIM, you will be alone. | 22:00 |
clayg | rledisez: I can swing the "blank laptop" - i'll just grab one of my old ones and do a re-install | 22:01 |
clayg | rledisez: but where do I get a "blank phone"!? | 22:01 |
kota_ | clayg: oic. | 22:01 |
rledisez | clayg: i mean we can't use our profesionnal phone, they are preconfigured with VPN and mails & co. it must be just a SIM card | 22:02 |
clayg | kota_: so you think bring my t-mobile phone number with me? honestly I've used it all over the world and it's never let me down - i'd be nervous to be overseas without it!? | 22:02 |
kota_ | hmm... i don't think we need blank phones/laptops | 22:02 |
kota_ | but I'll try to ask someone more for preparation | 22:02 |
clayg | kota_: that would be much simpler! I've never been concerned about traveling with a work laptop before | 22:03 |
clayg | kota_: rledisez: thank you guys for sharing what you know! | 22:03 |
timburke | oh! which hotels are people booking? if you're all congregating somewhere already... i ought to do that one, too :-) | 22:10 |
kota_ | timburke: in my memo, my hotel booking is to Courtyard Shanghai Pudong | 22:17 |
kota_ | and my quick survey, the roaming SIM seems to work, but the google map doesn't seem to be updated so the recommendation looks to install baidu map, https://apps.apple.com/jp/app/%E7%99%BE%E5%BA%A6%E5%9C%B0%E5%9B%BE-%E7%A7%91%E6%8A%80%E8%AE%A9%E5%87%BA%E8%A1%8C%E6%9B%B4%E7%AE%80%E5%8D%95/id452186370?ign-mpt=uo%3D4 | 22:19 |
*** tkajinam has joined #openstack-swift | 23:02 | |
clayg | timburke: I was gunna do Marriott | 23:14 |
*** rcernin has joined #openstack-swift | 23:16 | |
*** BjoernT has quit IRC | 23:30 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!