Tuesday, 2018-08-14

timburkei think it was this stretch: https://github.com/s3tools/s3cmd/blob/74eb55a724f30198e264def7c212571b5aebb90f/S3/FileLists.py#L523-L54300:01
timburkeit'd complain about an md5 mismatch instead of disabling the md5 check00:01
*** rcernin_ has joined #openstack-swift00:02
*** rcernin has quit IRC00:03
openstackgerritTim Burke proposed openstack/swift master: Move legacy-swift-dsvm-functional job in-tree  https://review.openstack.org/58927000:12
openstackgerritTim Burke proposed openstack/swift master: Add IPv6 DSVM tests  https://review.openstack.org/59149700:12
*** rcernin has joined #openstack-swift00:29
*** rcernin has quit IRC00:29
*** rcernin has joined #openstack-swift00:30
*** rcernin_ has quit IRC00:32
*** hugokuo has quit IRC00:57
*** hugokuo has joined #openstack-swift01:04
*** openstackgerrit has quit IRC01:06
kota_good morning02:21
*** psachin has joined #openstack-swift02:36
mattoliveraukota_: morning02:36
*** openstackgerrit has joined #openstack-swift03:19
openstackgerritMatthew Oliver proposed openstack/swift master: Add support for multiple root encryption secrets  https://review.openstack.org/57787403:19
openstackgerritMatthew Oliver proposed openstack/swift master: Multi-key KMS keymaster  https://review.openstack.org/59155503:19
mattoliverau^ timburke theres a kms version that seems to work on my barbican + swift dev env. It still needs tests, but that key master seems to have missed your multi key improvements03:20
mattoliveraunow to go test the kmip multi key keymaster.03:23
mattoliverau..hmm, maybe lunch first.03:23
openstackgerritMerged openstack/slogging master: fix a typo in sample.proxy-server.conf  https://review.openstack.org/57018903:58
*** links has joined #openstack-swift04:43
*** gyee has quit IRC05:05
*** pcaruana has joined #openstack-swift06:44
*** ccamacho has joined #openstack-swift07:01
*** rcernin has quit IRC07:02
*** quicker_io has joined #openstack-swift07:44
*** cbartz has joined #openstack-swift08:03
*** mikecmpbll has joined #openstack-swift08:03
*** openstackstatus has quit IRC08:12
*** mvkr has quit IRC08:20
*** mvkr has joined #openstack-swift08:52
*** mahatic has joined #openstack-swift08:58
*** ChanServ sets mode: +v mahatic08:58
*** hseipp has joined #openstack-swift09:11
*** gkadam has joined #openstack-swift09:18
*** mahatic has quit IRC09:19
*** pavelkv has quit IRC09:41
*** mahatic has joined #openstack-swift09:41
*** ChanServ sets mode: +v mahatic09:41
*** openstackstatus has joined #openstack-swift09:42
*** ChanServ sets mode: +v openstackstatus09:42
*** hoonetorg has quit IRC09:43
*** hoonetorg has joined #openstack-swift09:57
*** hseipp has quit IRC10:07
viks_hi, what all system(kernel) parameters(i.e. in /etc/sysctl.conf) should be tuned for proxy and storage nodes for better performance ? Is there any specific guide ? can anyone help me?10:16
*** mvkr has quit IRC10:22
DHEdocs suggest some TIME_WAIT parameters because you'll be churning through those real fast...11:01
DHEotherwise I'd say you're better off tuning the services themselves for number of CPUs/threads to use11:02
viks_DHE:  i came across a script in github where some many kernel parameters are being tuned. But not sure it is required or not and if required on what basis should i set appropriate value. i.e. https://github.com/goldyfruit/openstack-os-tuning/blob/master/Swift/tuning.sh11:10
viks_DHE: which docs are you referring abt `TIME_WAIT parameters`?11:11
DHEtcp_tw_*11:11
DHEhttps://docs.openstack.org/swift/ocata/deployment_guide.html#general-system-tuning11:12
DHEthis github link is pretty thorough...11:12
viks_DHE:  i'm not sure all those params in that github link should be tuned? and what basis i should be setting appropriate value? any idea/ suggestions?11:16
DHEthere's lots of parameters here. from how much dirty data can stay in memory before a disk flushout to iptables' nf_conntrack module settings11:18
DHEi'm not sure how much I agree with the notion it needs to be changed, unless you're mixing proxy and storage nodes and want to make sure the TCP stack is extra well fed11:19
viks_in my setup i have separate proxy and storage nodes.. So is it okay to go with default values?11:23
viks_i mean default values set by OS?11:26
DHEthey're fine to use. maybe not optimal. how hard are you going to stress the system?11:34
viks_ok.. i do not have any idea on how hard i should be stressing the system... just finding out if i should be tuning any kernel params to get a better performance out of it in specific to swift proxy and storage nodes..11:45
DHEthese settings really feel like they expect to run all components at 100% at some point. from tweaking swap usage to fixing the TCP stack memory usage to making read IOs much higher priority over write IOs12:15
viks_ok12:19
*** quicker_io has quit IRC12:59
*** psachin has quit IRC13:06
zaitcevTIME_WAIT is the duration for the packets to exist in the network. The closed socket is kept around enough so a packet sent erroneously will still match against its state and not against an equivalent, but newly-open socket.13:37
zaitcevDo keep in mind though, if you have a dual-homed proxy, the same TIME_WAIT applies to inside and outside. So, you can only lower it if the proxy is protected by a load balancer.13:39
DHEI think I would disable connection tracking for connections swift internal connections and client connections could be good as well... should eliminate the need for conntrack tuning.13:45
* DHE is still interested in Unix sockets for services to be able to run from...13:48
DHEpartially for this reason13:48
DHEor alternatively, run as a dedicated uwsgi application. I can make that work as well..14:11
*** ccamacho has quit IRC14:34
*** ccamacho has joined #openstack-swift14:56
timburkegood morning15:18
*** ccamacho has quit IRC15:19
timburkemattoliverau: thanks for the multi-key barbican patch! i knew there was something else i ought to do on that chain...15:19
timburkekota_: thanks for the review on p 575860! i'll look at splitting out the normal-SLO retro-fit from the rest of the patch, and try to explain better why i wanted that part in particular15:21
patchbothttps://review.openstack.org/#/c/575860/ - swift - Include '-' in multipart ETags - 10h 2m 43s spent in CI15:21
*** psachin has joined #openstack-swift15:26
* DHE keeps this script though...15:30
timburkeoh, DHE: you might be interested in https://review.openstack.org/#/c/324136/ -- i liked the idea, too, but i'm not sure when i'd be able to get around to reviving the patch15:32
patchbotpatch 324136 - swift - Support binding to Unix domain sockets. (ABANDONED) - 0h 41m 44s spent in CI15:32
claygtdasilva: you making any progress on the s3 stuff?15:33
claygI finally feel like i'm getting somewhere with the multi-key stuff (I had to catch up on the kmips progress!)15:33
timburkeclayg: there's all sort of people reviewing s3 stuff! it's great! kota_ wants me to break up one of the patches, zaitcev seems to like (or at least tolerate) what he sees...15:34
claygthat's GREAT15:34
clayggo team swift!15:34
zaitcevtimburke: I'm not all that sure about the ACL thing. I deduced that the attacker sets the ACLs and then uses those ACLs in order to create buckets. Not sure if that's actually what you want to fix.15:36
timburkezaitcev: the root trouble is that the s3_acl option basically trows us into some alternate-reality where auth middlewares only really handle *authentication*, not so much *authorization*15:39
tdasilvatimburke: one of my takeaways from looking at the acl patch yesterday was the need for more docs :/15:39
tdasilvaespecially for users regarding the new behavior where container listing (json) might return more info15:40
tdasilvaclayg, timburke: currently looking at p 57794115:40
patchbothttps://review.openstack.org/#/c/577941/ - swift - s3_acl: Require swift_owner authz to create buckets - 2h 3m 56s spent in CI15:40
claygtimburke: does p 586902 support N keymasters or exactly 2?15:40
patchbothttps://review.openstack.org/#/c/586902/ - swift - Allow multiple keymasters - 3h 11m 57s spent in CI15:40
timburkezaitcev: as a result test:tester3 could create buckets in AUTH_test despite not being able to do so via the swift API15:40
claygit looks like it just stashes the existing CRYPTO_KEY_CALLBACK if any?  But maybe... that can chain?15:41
*** links has quit IRC15:41
timburkeclayg: since all known keymasters subclass that one, they should all do it and it should chain. i suppose i hadn't actually tested with 3 or more though...15:42
claygok, cool15:43
timburkeon the plus side, you should be able to stuff multiple trivial keymasters in a single pipeline to validate without standing up additional services15:43
timburkethat patch really needs tests and docs; it almost certainly shouldn't merge as-is15:44
timburkeas much as anything, i pushed it up because with all these multi-key-aware keymasters it seemed weird to not be able to mix and match a bit15:45
DHEtimburke: https://blueprints.launchpad.net/swift/%2Bspec/wsgi-application-interface I also saw this which seem to have stagnated. It could be another option by running in uwsgi which would do the unix socket listening. And I'd probably want to run nginx in front of the proxy anyway15:46
*** cbartz has quit IRC15:47
*** cbartz has joined #openstack-swift15:47
*** cbartz has quit IRC15:48
timburkeDHE: https://review.openstack.org/#/c/33169/ (which added a bunch of files under https://github.com/openstack/swift/tree/master/examples ) seems related?15:49
patchbotpatch 33169 - swift - Add example Apache config files (MERGED) - 5h 5m 25s spent in CI15:49
timburkei must admit, though, i've never tried using them...15:50
DHEhmm... interesting..15:50
timburkeclayg: fwiw, i'd focus on https://review.openstack.org/#/c/590024/ ahead of the multiple-keymasters patch15:52
patchbotpatch 590024 - swift - Factor out a proper BaseKeyMaster class - 1h 32m 21s spent in CI15:52
claygtimburke: ah, ok, thanks for the heads up15:54
*** itlinux has joined #openstack-swift15:54
*** ccamacho has joined #openstack-swift15:56
*** gyee has joined #openstack-swift16:02
*** pcaruana has quit IRC16:02
*** d0ugal has quit IRC16:28
*** mikecmpbll has quit IRC16:31
DHEtimburke: that works... though I had to do some dirty stuff in nginx to do it...16:37
DHEapparently CONTENT_LENGTH is always sent to the proxy server, but is a blank field if the calling application didn't actually send such an HTTP header16:38
timburkehey, as long as it doesn't involve using gdb to patch it at run time, it's not *so* bad, amiright?16:38
timburkehuh. curious16:38
DHEseems to be a quirk of nginx.. and I guess python treats the empty string as boolean true ?16:39
*** ccamacho has quit IRC16:39
timburkemaybe related? https://bugs.launchpad.net/python-swiftclient/+bug/1586690 https://bugs.launchpad.net/python-swiftclient/+bug/162158116:43
openstackLaunchpad bug 1586690 in python-swiftclient "Uploading empty(0 B) file fails" [Undecided,Incomplete] - Assigned to Uday Swami (swamius)16:43
DHEor maybe any access of the content-length field invokes string2int which dies at https://github.com/openstack/swift/blob/master/swift/common/swob.py#L21316:43
openstackLaunchpad bug 1621581 in python-swiftclient "swiftclient returns response headers without 'Content-Length' param, thus causing upload object to fail" [Undecided,Invalid] - Assigned to Arun Mani (arun-mani)16:43
DHEI'm just using curl to GET a container for an object listing and making sure the proxy does its thing. right now all my other services are down in my lab but I can see it trying to contact the account servers so that's very reassuring16:45
timburkefwiw, i'm pretty sure eventlet would bomb out on a blank (but still present) Content-Length: https://github.com/eventlet/eventlet/blob/v0.24.1/eventlet/wsgi.py#L434-L44316:45
DHEright, but this is nginx acting as a middle man and that's where it's going wrong.16:45
DHE400 bad request from eventlet be completely reasonable, but nginx is clearly misbehaving here16:46
DHEoh here we go, nginx has "if_not_empty"16:47
DHEthat does the trick16:48
DHEthat is cool...16:49
*** psachin has quit IRC17:22
timburkecd ..17:38
*** gkadam has quit IRC17:53
DHEwhile it looks like it will work, it doesn't seem to be using any kind of eventlet or similar IO system to allow one thread to handle multiple requests. I think this would negatively impact overall throughput. maybe it's not such a good idea for now.18:10
timburkeman, there are a bunch of interesting S3 features that you only discover by poking around in random clients... https://github.com/aws/aws-sdk-go/blob/v1.15.11/service/s3/body_hash.go#L144-L14518:29
tdasilvatimburke: yeah, isn't it nice that the industry decided to default to a proprietary api?18:37
openstackgerritThiago da Silva proposed openstack/swift master: s3_acl: Require swift_owner authz to create buckets  https://review.openstack.org/57794120:59
kota_timburke: ack, and thx! unfortunately i'm at dayoff today for bridal anniversary lunch but i promise i'll be back to the patch tomorrow morning.21:16
timburkekota_: enjoy the day off!21:18
*** mikecmpbll has joined #openstack-swift21:18
timburkekota_: am i right to think that's *your* anniversary? happy anniversary!21:18
tdasilvatimburke: can you share the reasoning for p 575838 ?21:20
patchbothttps://review.openstack.org/#/c/575838/ - swift - Listing of versioned objects when versioning is no... - 1h 24m 27s spent in CI21:20
timburkeso, some clients (cyberduck for example, iirc) request a versioned listing regardless of whether versioning is enabled on the bucket. even though we don't support enabling versioning (yet), we could at least reply with the objects that are present (with a null version)21:22
tdasilvatimburke: i'm assuming that's because aws s3 has no concept of versioning being enabled/disabled? is that the case?21:24
timburkeit *does* (see https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGETversioningStatus.html which lists the three versioning states), it' just that the version-aware listing (see https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGETVersion.html) works even when versioning is suspended or never-enabled21:28
timburkewell that's a terrifying sort of a note. "A 200 OK response can contain valid or invalid XML. Make sure to design your application to parse the contents of the response and handle it appropriately."21:32
timburkewhy the hell would you send me a 200 when you're gonna send back a garbage response??21:35
*** mikecmpbll has quit IRC21:36
tdasilvalol21:36
*** mikecmpbll has joined #openstack-swift21:51
*** itlinux has quit IRC21:54
*** mikecmpbll has quit IRC22:27
openstackgerritTim Burke proposed openstack/swift master: s3api: Stop mangling Authorization header for v4 signatures  https://review.openstack.org/59186222:38
*** zaitcev has quit IRC22:45
*** kei-ichi has quit IRC22:51
*** kei-ichi has joined #openstack-swift22:55
kota_timburk: that's approximately 6 years anniversary to me.23:00
timburkecongrats!23:01
kota_thx23:01
*** mvkr has joined #openstack-swift23:05
mattoliveraumorning23:15
timburke*sigh* it took me _way_ longer than it should have to realize that i messed up my pipeline ordering and put s3api after auth instead of before...23:42
openstackgerritMerged openstack/swift master: Fix up test_static_web_pretend_to_be_giant_json  https://review.openstack.org/59152023:46
mattoliverau:( it happens.23:47

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!