| *** mat128 has joined #openstack-swift | 00:37 | |
| *** mat128 has quit IRC | 00:45 | |
| *** tovin07_ has joined #openstack-swift | 00:52 | |
| *** cshastri has joined #openstack-swift | 01:26 | |
| kota_ | good morning | 02:03 |
|---|---|---|
| *** two_tired has quit IRC | 02:20 | |
| kota_ | hmm... it looks like my exhausive test script went into bad loops??? the script for isa_l_cauchy, has been running since the last Friday didn't finish yet??? | 02:52 |
| *** lan has joined #openstack-swift | 03:06 | |
| lan | Hi , is there a simple way to count all objects in swift ? | 03:08 |
| notmyname | lan: all objects across the entire cluster? the object counts are in each container, so you'd need to query all the accounts and sum their respective object counts | 03:09 |
| lan | notmyname, this is the only way right? | 03:10 |
| lan | notmyname, and how can I query all the accounts in swift way ? | 03:11 |
| notmyname | correct it's the only way | 03:11 |
| notmyname | there are two ways to query all the accounts | 03:11 |
| notmyname | ...depending on how much access you have to the cluster and what your needs are | 03:11 |
| mahatic_ | good morning | 03:12 |
| notmyname | the first way is to know what all the accounts are (ie possibly from your auth system) and then HEAD each as a reseller_admin and get the object counts | 03:12 |
| notmyname | this way is simple, but it (1) requires knowledge of the accounts to be stored somewhere else and (2) does a bunch of client requests to the cluster | 03:12 |
| notmyname | the second way is to walk the drives that have the account dbs on them, query the DBs as you find them, store that info, and aggregate it | 03:13 |
| notmyname | this second way is more complex and requires more access to the cluster, but you'll find "dark data" that's not referenced in an external system and it works regardless of which or how many auth systems you have | 03:14 |
| notmyname | but no there is no single api command like GET cluster/object_totals or anything like that | 03:14 |
| lan | notmyname, hmm , yes I liked the first way but also be afraid of the performance. | 03:15 |
| lan | notmyname, thanks for your detail reply : ) | 03:16 |
| notmyname | lan: what's your situation? why are you needing this info, and what auth system are you using? | 03:16 |
| lan | notmyname, we used keystone and we think admin may need to know some statistics like total object counts, total used size .... | 03:19 |
| notmyname | cool, yeah that can be really helpful info | 03:19 |
| lan | notmyname, yes thanks! | 03:19 |
| notmyname | FWIW, if you want to do something like the second way I described, you could use slogging https://github.com/notmyname/slogging | 03:20 |
| notmyname | but know that I don't really maintain slogging. (eg last commit was in 2015) | 03:20 |
| notmyname | it should probably still work | 03:20 |
| lan | notmyname, ok I will take a look. | 03:20 |
| notmyname | and I know it's been used in some very large swift clusters before (and still, IIRC) | 03:20 |
| notmyname | for the first way, ceilometer can do the individual account querying based on what's in keystone | 03:21 |
| lan | seems cool ! | 03:21 |
| notmyname | I think ceilometer is what people still use? I don't know | 03:21 |
| notmyname | but there's also gnocchi and monasca that are related (but I don't know how, exactly) | 03:22 |
| notmyname | the good news is that you aren't the first to ask, so there's some solutions out there | 03:22 |
| notmyname | the bad news is that you'll still have to do some work | 03:22 |
| lan | Yes, but sadly we didn't use ceilometer in our project yet. | 03:23 |
| notmyname | no need to be sad about that. if you don't have a need for it, then runnign other stuff will just bring complexity and problems | 03:25 |
| lan | notmyname, you are right, I will learn slogging firstly and then choose which way I should use. Hava a good day ! | 03:28 |
| notmyname | good luck | 03:28 |
| notmyname | please feel free to ask questions in here, any time | 03:28 |
| lan | notmyname, ok will do thanks! | 03:29 |
| *** lan has quit IRC | 03:46 | |
| *** Dinesh_Bhor has joined #openstack-swift | 03:52 | |
| *** psachin has joined #openstack-swift | 03:56 | |
| *** sanchitmalhotra has joined #openstack-swift | 04:12 | |
| *** sanchitmalhotra has quit IRC | 04:13 | |
| *** sanchitmalhotra has joined #openstack-swift | 04:13 | |
| *** chsc has joined #openstack-swift | 04:45 | |
| *** chsc has quit IRC | 05:51 | |
| *** Venkata has joined #openstack-swift | 05:59 | |
| Venkata | Hello timburke, I am Venkata from Red Hat. I have question on swift3 plugin in openstack-swift | 06:00 |
| *** dfflanders has joined #openstack-swift | 06:09 | |
| *** skudlik has joined #openstack-swift | 06:11 | |
| *** skudlik has left #openstack-swift | 06:11 | |
| *** Venkata has quit IRC | 06:15 | |
| *** bkopilov has joined #openstack-swift | 06:25 | |
| *** Venkata has joined #openstack-swift | 06:29 | |
| *** dfflanders has quit IRC | 06:29 | |
| *** ChubYann has quit IRC | 06:40 | |
| *** abhitechie has joined #openstack-swift | 06:47 | |
| *** rcernin has joined #openstack-swift | 06:47 | |
| *** abhitechie has quit IRC | 07:06 | |
| *** abhitechie has joined #openstack-swift | 07:07 | |
| *** cschwede has joined #openstack-swift | 07:09 | |
| *** ChanServ sets mode: +v cschwede | 07:09 | |
| *** openstackgerrit has joined #openstack-swift | 07:13 | |
| openstackgerrit | Mathias Bjoerkqvist proposed openstack/swift master: Retrieve encryption root secret from Barbican https://review.openstack.org/364878 | 07:13 |
| *** kiennt has joined #openstack-swift | 07:32 | |
| kiennt | hi, i saw Swift already had assert:supports-rolling-upgrade tag. | 07:33 |
| kiennt | How you test rolling upgrade in gate job? I am woking on Heat rolling upgrade and have to setup the CI to test this. But now, i don't know how to do it. | 07:33 |
| *** cbartz has joined #openstack-swift | 07:36 | |
| *** tesseract has joined #openstack-swift | 07:36 | |
| *** oshritf has joined #openstack-swift | 07:39 | |
| cbartz | cschwede: Good morning cschwede. Could you pls take a look over the small p 481117 ? | 07:39 |
| patchbot | https://review.openstack.org/#/c/481117/ - python-swiftclient - Option to ignore mtime metadata entry. | 07:39 |
| *** oshritf has quit IRC | 07:45 | |
| cschwede | cbartz: Hi! patch looks good, it's in the gate now and should be merged in an hour or so | 08:05 |
| *** abhitechie has quit IRC | 08:06 | |
| cbartz | cschwede: Thanks a ton. | 08:08 |
| *** abhitechie has joined #openstack-swift | 08:08 | |
| *** silor has joined #openstack-swift | 08:23 | |
| *** jistr|off is now known as jistr | 08:25 | |
| *** afazekas|away is now known as afazekas | 08:34 | |
| *** oshritf has joined #openstack-swift | 08:38 | |
| *** kiennt has quit IRC | 08:39 | |
| *** hieulq has quit IRC | 08:39 | |
| *** tovin07_ has quit IRC | 08:40 | |
| *** Venkata has quit IRC | 09:08 | |
| *** kiennt has joined #openstack-swift | 09:15 | |
| *** hieulq has joined #openstack-swift | 09:15 | |
| *** acoles has joined #openstack-swift | 09:16 | |
| *** ChanServ sets mode: +v acoles | 09:16 | |
| *** mvk has joined #openstack-swift | 09:21 | |
| openstackgerrit | Merged openstack/python-swiftclient master: Option to ignore mtime metadata entry. https://review.openstack.org/481117 | 09:23 |
| *** Venkata has joined #openstack-swift | 09:25 | |
| Venkata | Hello all, I am looking into swift3 plugin to support s3 interface. is there any development going on to support ACLs for s3 interface | 09:26 |
| Venkata | I am from Red hat and we integrated Gluster with openstack-swift to support s3 interface and looking for ACLs support in S3 | 09:27 |
| *** kei_yama has quit IRC | 09:30 | |
| kota_ | Venkata: are you mening object ACL/ | 09:52 |
| kota_ | ? | 09:52 |
| Venkata | kota_ , we are looking for both bucket and object ACLs . | 09:53 |
| kota_ | Venkata: AFAIK, bucket ACL (except public read/write) can be used for all configuration in swift3, for object ACL, turning on s3_acl option to be True, it works to support object ACL | 09:55 |
| kota_ | https://github.com/openstack/swift3/blob/master/etc/proxy-server.conf-sample#L77 | 09:55 |
| kota_ | note that swift3 has some overhead to keep the object ACL and owner information in the object metadata so keep your mind if the overhead can be accepted for your system. | 09:56 |
| *** mat128 has joined #openstack-swift | 09:59 | |
| Venkata | kota_ thanks for responding, are these features ready for production?. I see in wiki ACLs are in development | 10:01 |
| *** kiennt has quit IRC | 10:03 | |
| Venkata | kota_ github for swift3 says ACLs are under development. | 10:04 |
| kota_ | Venkata: good question, idk. However, the compatibility seems not so bad for usage, e.g. (recent CI result with ceph-s3 tests) http://logs.openstack.org/39/473939/3/check/gate-swift3-tox-s3tests_keystone-ubuntu-xenial/2ba5fee/console.html.gz#_2017-06-13_21_35_45_624636 | 10:08 |
| kota_ | Venkata: the reason, we still hold the word "under development" is the perspective for performance/overhead | 10:09 |
| kota_ | for large deployment | 10:09 |
| Venkata | kota_ ok, Got it. thanks for your help. | 10:09 |
| kota_ | so it's nice if you are testing and calling 'ok, it's ready for our production'. Probably it will be great feedback to remove the "under development" mark | 10:10 |
| *** cshastri has quit IRC | 10:13 | |
| Venkata | kota_ sure. I will keep you posted after our testing is completed. | 10:18 |
| kota_ | Venkkata: thanks a lot! | 10:18 |
| cbartz | kota_: Hello Kota. Do you have an opinion on p 475873 ? | 10:35 |
| patchbot | https://review.openstack.org/#/c/475873/ - swift3 - Introduce auth middleware using account metadata. | 10:35 |
| kota_ | hello cbartz | 10:36 |
| cbartz | hello | 10:37 |
| kota_ | it looks like timburke has both love and fear on that (looking at review logs) | 10:38 |
| kota_ | so... | 10:38 |
| kota_ | i didn't look at the detail but I'm wondering what is the benefit rather than tempauth architecture | 10:40 |
| kota_ | cbartz: that sounds super light-weight, yes exactly | 10:40 |
| kota_ | but at the same time, account meta data can be readable for the tenant admin user so that it seems weak for the security | 10:41 |
| kota_ | cbartz: is it vulnerable when saving secret key in the account metadata? | 10:42 |
| cbartz | kota_: I think the benefit is that it can be used by the auth middleware which is currently deployed. This auth middleware usally manages the account mapping (tenant -> swift storage account). If tempauth must be used, then it is also required to use the test_tenant storage account name. | 10:43 |
| cbartz | kota_: I think it is not more vulnerable than e.g. tempurl secret keys, which can also be used/modified by the tenant admin. | 10:44 |
| kota_ | hmm... good answer | 10:46 |
| kota_ | for vulnerable | 10:46 |
| kota_ | I didn't get the benefit for the account name mapping | 10:47 |
| *** abhinavtechie has joined #openstack-swift | 10:48 | |
| cbartz | kota_ : If I use a custom auth middleware, e.g. one which uses ldap authentication, thus it would map ldap account names to storage account names, how could I use s3 with these ldap account names? tempauth does not know anything about this mapping. | 10:49 |
| kota_ | yes, your custom auth middleware needs to map the swift accounts to your ldap accounts | 10:51 |
| *** abhinavtechie has quit IRC | 10:51 | |
| cbartz | But currently, I could not use s3 with the custom auth middleware, because it has not implemented the s3 auth verification. The middleware would have the benefit, that it has one generic implementation which works for all custom auth middlewares, and not only tempauth (and swauth) and keystone | 10:52 |
| *** abhitechie has quit IRC | 10:52 | |
| kota_ | so the primary benefit is making reference architecture for custom auth (strictly, show https://review.openstack.org/#/c/475873/1/swift3/s3_auth_middleware.py@47)? | 10:56 |
| patchbot | patch 475873 - swift3 - Introduce auth middleware using account metadata. | 10:56 |
| *** hieulq has quit IRC | 10:57 | |
| cbartz | yes, you could say it so | 10:57 |
| kota_ | agh, why not we have not merged https://review.openstack.org/#/c/441520/ yet!?!? | 10:58 |
| patchbot | patch 441520 - swift - Use swift3's check_signature function | 10:58 |
| kota_ | hmm... | 11:02 |
| kota_ | cbartz: current my feeling: it could be nice to have reference how to check your secret for swift3. On the other hand, I'm not strongly willing to have secret key management in the swift3 repo. | 11:04 |
| kota_ | that is because basically swift3 depends on the auth for Swift deployment so separation from swift auth management could confuse users. | 11:06 |
| kota_ | just current status/opinion though | 11:07 |
| cbartz | kota_: Ok, I understand. I mean, there is no problem for me to implement this inside my auth middleware. I am just thinking, that other people with custom auth middlewares will run into the same issue. | 11:08 |
| kota_ | cbartz: perhaps, it would be nice to have the docs how to create your own custom auth middlware | 11:09 |
| cbartz | kota_: The problem with s3 is that it relies on the fact that the auth middleware can access the secret key in plaintext (because it is used to generate the signature). But good/secure auth architectures should not store/access secret keys in plaintext.... Do you have any access to stats how people use the s3 middleware? | 11:10 |
| kota_ | cbartz: exactly, it's problem on tempauth | 11:11 |
| kota_ | cbartz: if you could refer s3_token_middleare/keystone impl | 11:12 |
| *** hieulq has joined #openstack-swift | 11:12 | |
| kota_ | it could help you | 11:12 |
| kota_ | with the keystone, | 11:13 |
| kota_ | it sends credential and signature from header info, and then | 11:14 |
| kota_ | keystone can verify the credential against to signatature and the secret inside. | 11:14 |
| kota_ | as well as actuall S3 doing | 11:15 |
| kota_ | around https://github.com/openstack/keystone/blob/master/keystone/contrib/s3/core.py#L85-L100 | 11:17 |
| kota_ | for v4 signature, https://github.com/openstack/keystone/blob/master/keystone/contrib/s3/core.py#L102-L126 | 11:17 |
| cbartz | kota_: Ok, but what happens here if the secret key is stored not in plaintext but hashed inside keystone? | 11:18 |
| kota_ | cbartz: idk, keystone may keep plaintext? | 11:20 |
| kota_ | cbartz: i think your question is how to avoid the plaintext handling in *middleware* in swift proxy pipeline? | 11:21 |
| cbartz | kota_: My auth middleware does not have access to secret keys in plaintext. So, I am not able to verify the signatures the s3 users provide. | 11:23 |
| kota_ | er | 11:24 |
| kota_ | you cannot touch the key but users signed with the plain secret key... | 11:25 |
| kota_ | w/o secret key... how to role play the signature calculation described in AWS docs? http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html | 11:25 |
| kota_ | i have no answer for that | 11:26 |
| kota_ | right now | 11:26 |
| cbartz | kota_: Yes, I think its a principal "problem" (not for amazon, because it seems they store the keys in plaintext) of the s3 protocol. | 11:27 |
| kota_ | understood | 11:27 |
| cbartz | kota_: This is why I am curious how other deployers use the swift3 middleware. | 11:28 |
| kota_ | so, i'm wondering how you verify the account for your auth system? | 11:28 |
| kota_ | even if you deploys non-plaintext to account meta | 11:29 |
| kota_ | the signature calculation won't match because users sign with their plaintext secret? | 11:29 |
| kota_ | am... i missing something? | 11:30 |
| cbartz | My auth middleware uses a LDAP server, and this stores the key in a hashed format. So, the LDAP server will hash the plaintext key and compare the result with the hashed password (same way as unix systems do it). | 11:31 |
| cbartz | The auth middleware proposed for s3 would store it in plaintext, not hashed, because the s3 protocol requires it in plaintext. | 11:31 |
| kota_ | yes, s3 requires plaintext | 11:32 |
| kota_ | thinking of that we need plaintext for the verification, if we could have auth server in the out of swift cluster as well as keystone implementation seems safer than account metadata implementation? | 11:37 |
| *** abhitechie has joined #openstack-swift | 11:37 | |
| cbartz | kota_: Why do you think its safer? | 11:40 |
| kota_ | it can be managed by the key management system | 11:41 |
| kota_ | probably, at least, encrypted in the disk or it will have security deffensive. | 11:42 |
| kota_ | for key management system | 11:42 |
| kota_ | basically, the acount metadata will store in the swift account sqlite db as raw data | 11:43 |
| kota_ | though depending on the your swift cluster architecture, if you don't do anything on sort of disk encryption, it can be readable | 11:44 |
| cbartz | kota_: Ok, I see. | 11:45 |
| kota_ | cbartz: note that, I'm not strong opinion to oppose to you, just want to clarify what is lack and what we need to improve | 11:47 |
| kota_ | and would love to think good solution | 11:47 |
| kota_ | exactly, it may be painful, we cannot use hashed password for s3 protocol | 11:48 |
| cbartz | kota_: Ok, thank you. | 11:49 |
| kota_ | cbartz: thanks for bringing that, perhaps timburke could have a hint for such a case. I think they have various integration experiments for various auth systems. | 11:50 |
| kota_ | rather than me. | 11:51 |
| kota_ | it's time to get back home. it's around 9:00 pm for me | 11:52 |
| kota_ | see you guys | 11:52 |
| kota_ | clayg: ah, I'm on https://review.openstack.org/#/c/428408/, currently the code looks good to me. just I've not yet finished to look at the test change and will do tommorow morning | 11:54 |
| patchbot | patch 428408 - swift - Don't rehash primaries in reconstructor handoffs_o... | 11:54 |
| cbartz | See you kota_ | 12:03 |
| *** philipw has joined #openstack-swift | 12:03 | |
| *** hieulq has quit IRC | 12:04 | |
| *** philipw has quit IRC | 12:04 | |
| *** d0ugal has joined #openstack-swift | 12:04 | |
| *** d0ugal has joined #openstack-swift | 12:04 | |
| *** Venkata has left #openstack-swift | 12:05 | |
| *** d0ugal has quit IRC | 12:12 | |
| *** hieulq has joined #openstack-swift | 12:19 | |
| *** remix_tj has joined #openstack-swift | 12:53 | |
| *** d0ugal has joined #openstack-swift | 12:54 | |
| *** d0ugal has quit IRC | 12:54 | |
| *** d0ugal has joined #openstack-swift | 12:54 | |
| *** d0ugal has quit IRC | 12:59 | |
| *** catintheroof has joined #openstack-swift | 13:04 | |
| *** hieulq has quit IRC | 13:16 | |
| *** abhitechie has quit IRC | 13:17 | |
| tdasilva | good morning | 13:26 |
| *** xrb has joined #openstack-swift | 13:35 | |
| *** hieulq has joined #openstack-swift | 13:36 | |
| xrb | hi all, | 13:37 |
| xrb | I have got a setup with Open Stack swift which uses Keystone for authentication. I have got a bucket, all users defined in Keystone within this tenant have read-write access, cannot manage to restrict the access by using ACLs on the bucket.. | 13:40 |
| xrb | Is it something that is supposed to work? | 13:40 |
| acoles | xrb: ACLs do not restrict role based access rights, they only extend them | 13:43 |
| xrb | Is it possible to defined users in Keystone (within a tenant) that will get only read access to a bucket? | 13:44 |
| openstackgerrit | Béla Vancsics proposed openstack/swift master: Reduce code duplication https://review.openstack.org/476025 | 13:45 |
| *** klamath has joined #openstack-swift | 13:46 | |
| *** klamath has quit IRC | 13:46 | |
| *** klamath has joined #openstack-swift | 13:46 | |
| acoles | xrb: AFAIK that is not possible using keystone roles - any user with a operator_role (e.g. admin) has read/write access to project (tenant) containers. You could have a user that does not have an operator_role and then grant read access via an ACL, or have container be in a different project and use ACLs to grant read access to users of another project. | 13:49 |
| xrb | I tried to grant a user from another tenant a read or full_control access using an ACL. But that did not work either. For him, the container from the other tenant was not visible at all... | 13:52 |
| xrb | (maybe I had an issue with the ACL, I tried defining the ACL as 'READ:<user id>' or 'READ:<username>:<username>' using s3cmd) | 13:54 |
| *** vint_bra has joined #openstack-swift | 13:54 | |
| xrb | (was using Swift version 2.13.0-0ubuntu1~cloud0 on Ubuntu 16.04) | 13:55 |
| acoles | xrb: I'm not familiar with how s3 interacts with the swift ACLs. For keystone I'd expect soemthing like <project-id>:<user-id> (see https://docs.openstack.org/swift/latest/overview_acl.html) | 14:06 |
| *** vint_bra has quit IRC | 14:07 | |
| *** gyee has joined #openstack-swift | 14:07 | |
| acoles | xrb: try #swift3 or ask again here in a couple of hours when CA is awake | 14:11 |
| xrb | thx! will do! | 14:11 |
| *** chlong_ has joined #openstack-swift | 14:23 | |
| *** bombart has joined #openstack-swift | 14:24 | |
| bombart | Hello. I'm using python-swiftclient to try and stat a "pseudo-folder" but can't figure out the right syntax. I can stat the container, I can stat objects in that container, but not a "pseudo-folder" in that container. Would you be able to point me in the right direction? | 14:27 |
| *** psachin has quit IRC | 14:28 | |
| *** zhurong has joined #openstack-swift | 14:29 | |
| *** bombart has quit IRC | 14:31 | |
| *** bombart has joined #openstack-swift | 14:33 | |
| bombart | This only seems to be happening when I have spaces in my container name and I need to use quotations around it. | 14:34 |
| cbartz | bombart: A pseudofolder is a 0-byte object, so if you are able to stat objects you should also be able to stat pseudofolders. Try "swift list" to see if the pseudofolder object really exist. Perhaps you have to add a trailing "/" at the end. | 14:40 |
| bombart | It works when my container doesn't have spaces in it's name, but doesn't when it has spaces. | 14:42 |
| bombart | swift --os-tenant-name admin stat "ABCD" this/ | 14:44 |
| bombart | This works. | 14:44 |
| bombart | Account: AUTH_9287349872iou3i2i389 Container: ABCD Object: this/ Content Type: application/directory Content Length: 0 Last Modified: Wed, 29 Mar 2017 17:48:10 GMT ETag: d41d8cd98f00b204e9800998ecf8427e Accept-Ranges: bytes X-Timestamp: 1490809689.45526 X-Trans-Id: tx099995d68270400f84882-00596392d1 | 14:45 |
| bombart | swift --os-tenant-name admin stat "A B C D" this/ | 14:48 |
| bombart | Object HEAD failed: https://swift.url.com:8080/v1/AUTH_98734jkjkkj823h4j2/A%20B%20C%20D/this/ 404 Not Found Failed Transaction ID: tx196e3ase68440ya4sd23d8a170-0059639353 | 14:48 |
| tdasilva | rledisez: hi, still around? | 14:50 |
| *** hieulq has quit IRC | 14:51 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-swiftclient master: Updated from global requirements https://review.openstack.org/89250 | 14:54 |
| *** zhurong has quit IRC | 14:56 | |
| *** rcernin has quit IRC | 14:57 | |
| rledisez | hi tdasilva :) | 15:03 |
| cbartz | bombart: Look in your proxy server logs for trouble shooting. | 15:05 |
| *** chsc has joined #openstack-swift | 15:05 | |
| *** chsc has joined #openstack-swift | 15:05 | |
| tdasilva | rledisez: hi! last Friday we were talking about an issue I ran into with probe tests and I was wondering if you had seen something similar? | 15:06 |
| tdasilva | it seems it might have something to do with this change: https://github.com/openstack/swift/commit/5d7b0d1edb279cb5713365690fce856a94d3b289 | 15:06 |
| tdasilva | but I'm not really certain. | 15:06 |
| bombart | cbartz: I just see a 404 in the proxy server log. but it's there! | 15:07 |
| bombart | I can list it! | 15:07 |
| bombart | just can't stat it. | 15:07 |
| *** hieulq has joined #openstack-swift | 15:09 | |
| rledisez | tdasilva: what is the issue? (for info, we've been running this patch in production for at least 2 years) | 15:09 |
| bombart | swift --os-tenant-name gale stat "The T D A" TDA_GDA_1785-2007/ Object HEAD failed: https://swift.storage.info:8080/v1/AUTH_5665268s0c3e4c88asg445afbd80336d7/The%20T%20D%20A/TDA_GDA_1785-2007/ 404 Not Found | 15:11 |
| bombart | swift --os-tenant-name gale list "The T D A" -p TDA_GDA_1785-2007/ | 15:11 |
| bombart | works and lists all objects | 15:12 |
| tdasilva | rledisez: i've started seeing different probe tests fail sort of randomly. Basically when tests restart a server and try to send a request right away, that request might fail: https://github.com/openstack/swift/blob/master/test/probe/test_object_partpower_increase.py#L113,L116 | 15:12 |
| tdasilva | bombart: IIRC, pseudo-folders are not real objects, right? not sure you can HEAD them? i might be missing something here | 15:13 |
| *** chlong_ has quit IRC | 15:16 | |
| rledisez | tdasilva: we don't use the "manager' to manage processes, so i don't have feedback on that. but i can't see anything obvious by looking at the code | 15:18 |
| *** d0ugal has joined #openstack-swift | 15:20 | |
| *** d0ugal has quit IRC | 15:20 | |
| *** d0ugal has joined #openstack-swift | 15:20 | |
| tdasilva | rledisez: yeah, i think it's really a timing issue. for example, if I put a sleep(1) right after like 113 in that code snippet above, then tests pass... | 15:22 |
| rledisez | tdasilva: as it is binding later, the head_object can be sent before process binded port? the manager is probably not waiting for the port to be opened | 15:23 |
| *** hieulq has quit IRC | 15:28 | |
| *** chlong_ has joined #openstack-swift | 15:30 | |
| *** hieulq has joined #openstack-swift | 15:43 | |
| *** noxdafox_ has joined #openstack-swift | 15:55 | |
| *** d0ugal has quit IRC | 15:56 | |
| *** noxdafox has quit IRC | 15:57 | |
| *** oshritf has quit IRC | 15:59 | |
| *** chsc has quit IRC | 16:00 | |
| *** xrb has quit IRC | 16:00 | |
| *** xrb has joined #openstack-swift | 16:01 | |
| *** chlong_ has quit IRC | 16:06 | |
| openstackgerrit | Merged openstack/swift master: Don't rehash primaries in reconstructor handoffs_only mode https://review.openstack.org/428408 | 16:16 |
| *** chlong_ has joined #openstack-swift | 16:20 | |
| *** oshritf has joined #openstack-swift | 16:21 | |
| cbartz | bombart: Look at the %20 quotes. How are they displayed in the logs? | 16:22 |
| *** JimCheung has joined #openstack-swift | 16:29 | |
| *** hieulq has quit IRC | 16:36 | |
| bombart | @tdasilva: If I understand it correctly, pseudo-folders are objects with the Content Type: application/directory and Content Length: 0 | 16:37 |
| *** chlong_ has quit IRC | 16:38 | |
| bombart | @cbartz: Spaces show up as "%2520" | 16:38 |
| cbartz | bombart: What happens if you list the container with space: swift list "A B C D" . Does this/ appear in the list? | 16:40 |
| *** oshritf has quit IRC | 16:40 | |
| *** xrb has quit IRC | 16:40 | |
| timburke | good morning | 16:49 |
| notmyname | hello, world | 16:50 |
| *** hieulq has joined #openstack-swift | 16:51 | |
| timburke | cbartz: fwiw, on the swift3 secret storage, i've played around with two options: first, using a hash-of-the-hash for the secret (which is sometimes tolerable but certainly not great -- if the stored hash is discovered, it's comparable to knowing the plaintext password), and second, having the user auth as normal then using the auth token that's returned as a temporary secret | 16:55 |
| *** hieulq has quit IRC | 16:59 | |
| cbartz | timburke: Interesting, but what happens if the auth mw does not persist tokens and allows multiple tokens to exist at the same time? | 17:00 |
| *** tesseract has quit IRC | 17:01 | |
| *** bombart has quit IRC | 17:01 | |
| timburke | idk. i shove one token per user in memcache | 17:03 |
| timburke | as far as multiple tokens, you might be able to do something more like sts and issue both a temp secret and temp identifier, using the temp id to look up the secret | 17:04 |
| timburke | but if you're really striving to not persist anything, it's gonna get hard, real fast | 17:04 |
| cbartz | timburke: Ok. Thx for sharing your ideas. | 17:06 |
| timburke | sure. sorry i don't have something more concrete to point you toward | 17:07 |
| openstackgerrit | Merged openstack/swift master: Fix sporadic failures in test_reconstructor.py https://review.openstack.org/460359 | 17:18 |
| clayg | is this done? https://review.openstack.org/#/c/472659/ | 17:31 |
| patchbot | patch 472659 - swift - Allow to rebuild a fragment of an expired object | 17:31 |
| clayg | rledisez: didn't you have a change for getting rid of that stupid do_listdir arg on the primary suffix hashing? | 17:34 |
| *** hieulq has joined #openstack-swift | 17:40 | |
| *** cbartz has quit IRC | 17:43 | |
| *** hieulq has quit IRC | 17:43 | |
| *** MVenesio has joined #openstack-swift | 17:47 | |
| notmyname | who's on for chairing the 0700 meeting this week? | 17:52 |
| *** chsc has joined #openstack-swift | 17:55 | |
| *** cschwede has quit IRC | 17:57 | |
| *** hieulq has joined #openstack-swift | 17:58 | |
| acoles | clayg: IMHO patch 472659 is ready for review. | 18:00 |
| patchbot | https://review.openstack.org/#/c/472659/ - swift - Allow to rebuild a fragment of an expired object | 18:00 |
| *** dmellado has quit IRC | 18:02 | |
| *** dmellado has joined #openstack-swift | 18:02 | |
| clayg | acoles: sweet - I added it to priority reviews and starred it for myself! | 18:04 |
| *** tonanhngo has joined #openstack-swift | 18:15 | |
| *** Sukhdev has joined #openstack-swift | 18:24 | |
| *** zaitcev has joined #openstack-swift | 18:26 | |
| *** ChanServ sets mode: +v zaitcev | 18:26 | |
| *** ChubYann has joined #openstack-swift | 18:34 | |
| *** nizam037 has joined #openstack-swift | 18:36 | |
| *** nizam037 has quit IRC | 18:47 | |
| *** mat128 has quit IRC | 19:06 | |
| mathiasb | zaitcev: thanks for the reviews! | 19:13 |
| zaitcev | mathiasb: sure | 19:14 |
| zaitcev | I generally stay away from encryption, but the Barbician review was easy to understand. | 19:24 |
| *** hieulq has quit IRC | 19:38 | |
| *** silor has quit IRC | 19:47 | |
| *** JimCheung has quit IRC | 19:57 | |
| *** d0ugal has joined #openstack-swift | 19:57 | |
| *** JimCheung has joined #openstack-swift | 20:12 | |
| *** JimCheung has quit IRC | 20:17 | |
| openstackgerrit | Thiago da Silva proposed openstack/swift master: Fix swiftdir option and usage of storage policy aliases https://review.openstack.org/344693 | 20:18 |
| tdasilva | zaitcev: I noticed that in your PUT+POST patch you were fixing much of what's in this patch above ^^^, so I thought we could just continue on that, which should make your patch a little smaller and more focused??? wdyt? | 20:19 |
| *** tonanhngo has quit IRC | 20:27 | |
| *** JimCheung has joined #openstack-swift | 20:29 | |
| *** tonanhngo has joined #openstack-swift | 20:31 | |
| *** JimCheung has quit IRC | 20:33 | |
| *** tonanhngo has quit IRC | 20:35 | |
| *** tonanhngo has joined #openstack-swift | 20:35 | |
| *** JimCheung has joined #openstack-swift | 20:39 | |
| *** tonanhngo has quit IRC | 20:40 | |
| *** tonanhngo has joined #openstack-swift | 20:42 | |
| *** tonanhngo has quit IRC | 20:46 | |
| *** d0ugal has quit IRC | 20:52 | |
| *** catintheroof has quit IRC | 20:53 | |
| *** MVenesio has quit IRC | 20:53 | |
| *** tonanhngo has joined #openstack-swift | 20:54 | |
| *** tonanhngo has quit IRC | 20:58 | |
| *** tonanhngo has joined #openstack-swift | 21:00 | |
| *** klrmn has joined #openstack-swift | 21:02 | |
| *** tonanhngo has quit IRC | 21:04 | |
| *** tonanhngo has joined #openstack-swift | 21:24 | |
| *** tonanhngo has quit IRC | 21:28 | |
| *** tonanhngo has joined #openstack-swift | 21:32 | |
| *** tonanhngo has quit IRC | 21:38 | |
| *** tonanhngo has joined #openstack-swift | 21:39 | |
| *** tonanhngo has quit IRC | 21:43 | |
| *** hieulq has joined #openstack-swift | 21:54 | |
| *** tonanhngo has joined #openstack-swift | 21:57 | |
| *** vint_bra has joined #openstack-swift | 21:58 | |
| *** tonanhngo has quit IRC | 22:01 | |
| *** tonanhngo has joined #openstack-swift | 22:02 | |
| *** tonanhngo has quit IRC | 22:07 | |
| *** hieulq has quit IRC | 22:12 | |
| *** deep-book-gk_ has joined #openstack-swift | 22:20 | |
| *** tonanhngo has joined #openstack-swift | 22:20 | |
| *** deep-book-gk_ has left #openstack-swift | 22:23 | |
| *** tonanhngo has quit IRC | 22:25 | |
| *** hieulq has joined #openstack-swift | 22:27 | |
| zaitcev | tdasilva: I'll have a look at it. | 22:28 |
| openstackgerrit | Clay Gerrard proposed openstack/swift master: Clean up some assertions in test_reconstructor https://review.openstack.org/467710 | 22:32 |
| openstackgerrit | John Dickinson proposed openstack/swift master: moved install guide and removed tox env definition https://review.openstack.org/481714 | 22:32 |
| *** tonanhngo has joined #openstack-swift | 22:32 | |
| *** tonanhngo has quit IRC | 22:37 | |
| *** catintheroof has joined #openstack-swift | 22:43 | |
| *** JimCheung has quit IRC | 22:58 | |
| *** JimCheung has joined #openstack-swift | 22:58 | |
| *** JimCheung has quit IRC | 23:24 | |
| *** JimCheung has joined #openstack-swift | 23:24 | |
| *** vint_bra has quit IRC | 23:25 | |
| *** JimCheung has quit IRC | 23:29 | |
| *** kei_yama has joined #openstack-swift | 23:31 | |
| *** JimCheung has joined #openstack-swift | 23:41 | |
| *** chsc has quit IRC | 23:45 | |
| *** JimCheung has quit IRC | 23:45 | |
| *** bkopilov has quit IRC | 23:57 | |
| *** catintheroof has quit IRC | 23:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!