| *** openstack has joined #openstack-swift | 00:02 | |
| *** byeager has quit IRC | 00:03 | |
| openstackgerrit | David Goetz proposed a change to openstack/swift: Config option to lower the timeout for recoverable object GETs. https://review.openstack.org/69509 | 00:10 |
|---|---|---|
| *** salv-orlando has left #openstack-swift | 00:17 | |
| *** matsuhashi has joined #openstack-swift | 00:27 | |
| openstackgerrit | A change was merged to openstack/swift: Add secondary groups to user during privilege escalation https://review.openstack.org/67905 | 00:37 |
| *** Trixboxer has quit IRC | 01:16 | |
| *** Midnightmyth has quit IRC | 01:20 | |
| *** csd has quit IRC | 01:24 | |
| *** shri1 has quit IRC | 01:35 | |
| *** nosnos has joined #openstack-swift | 01:36 | |
| *** jokke__ has joined #openstack-swift | 01:41 | |
| *** jokke_ has quit IRC | 01:43 | |
| *** gyee has quit IRC | 02:07 | |
| *** chandankumar_ has joined #openstack-swift | 02:29 | |
| *** chuck__ has joined #openstack-swift | 02:29 | |
| *** chandankumar_ has quit IRC | 02:31 | |
| openstackgerrit | Clay Gerrard proposed a change to openstack/swift: Additional functional tests for Account ACL feature https://review.openstack.org/69321 | 02:39 |
| zaitcev | clayg: How do you manage to upload a patch 69321 that depends on 63227 without also uploading 63227? I only know of 1 way to make dependencies: commit A, commit B, git reivew, then B becomes dependent on A. | 02:58 |
| clayg | oh i don't know for sure - did i fuck it up? | 02:59 |
| zaitcev | I don't think you did | 02:59 |
| zaitcev | But apparently you know a secret how to do it. | 02:59 |
| clayg | oh, just that i have multiple indepent changes based on OJ's account-acls? | 02:59 |
| clayg | yeah I would just go back to his change and branch from there for each one | 03:00 |
| clayg | then when I `git review` it just shows my one change as dependent on his? | 03:00 |
| clayg | oh, the question was just how to depend on someone elses review - yeah that's easy | 03:00 |
| zaitcev | branch from there as in... first fetch his, then what... git checkout -b xxx? | 03:00 |
| clayg | bingo | 03:00 |
| zaitcev | wow | 03:01 |
| clayg | does that mean you're going to review 63227 ;) | 03:01 |
| zaitcev | Yes | 03:01 |
| zaitcev | Already through the commit log :-) | 03:01 |
| clayg | whooo hoo! | 03:01 |
| clayg | lol! yeah that commit message is like half the review ;) | 03:01 |
| zaitcev | You know, we had a few attempts at this over time. There was a Russian dude (Viktor Rodionov? maybe?), and a Chinese dude IIRC.. Or maybe not, but then David Hadas tried his hand at it too? He reused a lot of old format and code and I was this >< close to his camp, except for some very strange account writer thing that he didn't want to explain. | 03:04 |
| clayg | yeah I think account writer was the wrong direction, oj's patch takes a simpler approach I think | 03:04 |
| clayg | but yeah, long time coming - I think it's gunna be great | 03:05 |
| *** briancurtin has joined #openstack-swift | 03:06 | |
| *** shri has joined #openstack-swift | 03:07 | |
| *** matsuhashi has quit IRC | 03:13 | |
| *** matsuhashi has joined #openstack-swift | 03:14 | |
| shri | hi… I have a question regarding the swift API version. | 03:20 |
| shri | What's the best way to find out what the API version is for a given swift instance? | 03:20 |
| *** matsuhashi has quit IRC | 03:49 | |
| notmyname | shri: well, it should in the in /info response. I'm actually not sure if it's there though. however, the good news for you is that there has never been anything but a v1 for the swift API | 04:02 |
| shri | actually… I am seeing one cluster returning "1" and another "1.0". | 04:05 |
| notmyname | shri: sounds like you may be referring to the version of the auth system, not swift | 04:14 |
| shri | probably not, this is what gets returned by keystone as part of the endpoints. | 04:15 |
| notmyname | can you give an example? | 04:15 |
| shri | Also, in some cases, there is no "versionId" in the returned values. confusing | 04:15 |
| shri | http://www.gossamer-threads.com/lists/openstack/dev/35386?page=last | 04:16 |
| notmyname | shri: I can't tell you anything about the id or versionId fileds you're getting. the first one seems ok (although "adminURL" doesn't have much meaning). it looks like the config for the second entry is messed up | 04:21 |
| notmyname | shri: I'd recommend asking some keystone people in #openstack-dev (unfortunately probably during US business hours) | 04:22 |
| notmyname | shri: actually, looks like ayoung is in there now.. ;-) | 04:22 |
| shri | :-) … Initially I thought the second config is messed up too.. But the official keystone documention says it will return the versionId: http://docs.openstack.org/api/openstack-identity-service/2.0/content/POST_authenticate_v2.0_tokens_.html#POST_authenticate_v2.0_tokens_-Response | 04:25 |
| *** ChanServ changes topic to "Current Release: 1.12.0 | Channel Logs: http://eavesdrop.openstack.org/irclogs/%23openstack-swift/ | Dev Docs: http://swift.openstack.org/ | Priority Reviews: https://wiki.openstack.org/wiki/Swift/PriorityReviews | Goals for Icehouse: http://lists.openstack.org/pipermail/openstack-dev/2013-November/019919.html" | 04:26 | |
| notmyname | cause short channel topics are no fun ;-) | 04:27 |
| notmyname | shri: ya, but also notice that the URLs you're getting back in the second example are pretty much completely wrong for swift | 04:28 |
| notmyname | shri: first, adminURL doesn't make any sense, then internalURL doesn't have an account, and publicURL just looks proken | 04:29 |
| shri | our product barfs because of the versionId, the rest of the values have been made up :-) | 04:31 |
| shri | they're included in that snippet for demostration purposes | 04:31 |
| notmyname | oh. | 04:33 |
| notmyname | I have no idea about keystone response fields. again, I'd recommend you ask a keystone dev in #openstack-dev | 04:36 |
| *** haomaiwang has quit IRC | 04:43 | |
| *** haomaiwang has joined #openstack-swift | 04:44 | |
| zaitcev | I think I like otherjon's account ACLs 63227, but I'd prefer to see some actual usage on them before we fully commit. Do we have a mechanism for publishing "experimental" features that could be withdrawn, or we request submitter to run his clusters with the patch in such cases? | 04:44 |
| *** matsuhashi has joined #openstack-swift | 04:45 | |
| *** haomaiwa_ has joined #openstack-swift | 04:56 | |
| *** haomaiwang has quit IRC | 05:00 | |
| *** shri has quit IRC | 05:21 | |
| *** ppai has joined #openstack-swift | 05:27 | |
| *** psharma has joined #openstack-swift | 05:40 | |
| *** shri has joined #openstack-swift | 05:48 | |
| *** briancurtin has quit IRC | 05:48 | |
| *** shri has quit IRC | 05:48 | |
| *** nshaikh has joined #openstack-swift | 05:59 | |
| *** xga__ has joined #openstack-swift | 08:13 | |
| *** mlipchuk has joined #openstack-swift | 08:28 | |
| raies | hi | 08:29 |
| raies | what is the service type for the swift in devstack running swift ?? | 08:30 |
| *** nacim has joined #openstack-swift | 08:46 | |
| koolhead17 | raies: https://ask.openstack.org/en/question/2610/can-we-test-swift-functionality-with-the-help-of-devstack/ << See if it helps | 08:48 |
| chmouel | til: localrc is deprecated in favour of local.conf | 08:59 |
| chmouel | (and i'm devstack core :)) | 08:59 |
| *** nacim has quit IRC | 09:00 | |
| *** nacim has joined #openstack-swift | 09:00 | |
| koolhead17 | chmouel: ooh is it in process already | 09:02 |
| *** matsuhashi has quit IRC | 09:09 | |
| *** matsuhas_ has joined #openstack-swift | 09:14 | |
| chmouel | portante: have you seen that error before http://bpaste.net/show/hONbmfF3wQwbkpummxUA/ | 09:38 |
| chmouel | portante: coming from http://logs.openstack.org/50/41450/4/check/gate-swift-python27/d66d8a0/nose_results.html | 09:38 |
| chmouel | portante: (unittests error0 | 09:38 |
| *** xga__ has quit IRC | 09:42 | |
| *** xga__ has joined #openstack-swift | 09:43 | |
| *** nshaikh has left #openstack-swift | 09:44 | |
| *** xga__ has quit IRC | 10:04 | |
| *** xga__ has joined #openstack-swift | 10:08 | |
| *** Trixboxer has joined #openstack-swift | 10:09 | |
| *** Midnightmyth has joined #openstack-swift | 10:15 | |
| *** matsuhas_ has quit IRC | 10:22 | |
| *** xga__ has quit IRC | 10:23 | |
| *** _bluev has joined #openstack-swift | 10:24 | |
| *** matsuhashi has joined #openstack-swift | 10:31 | |
| *** xga__ has joined #openstack-swift | 10:31 | |
| *** NM has joined #openstack-swift | 10:58 | |
| *** matsuhashi has quit IRC | 11:00 | |
| *** xga__ has quit IRC | 11:03 | |
| openstackgerrit | Balazs KOSSOVICS proposed a change to openstack/swift: 503 instead of 404 if account server failes https://review.openstack.org/69576 | 11:03 |
| *** xga has joined #openstack-swift | 11:07 | |
| *** xga_ has joined #openstack-swift | 11:10 | |
| *** xga has quit IRC | 11:12 | |
| *** ppai has quit IRC | 11:13 | |
| *** matsuhashi has joined #openstack-swift | 11:14 | |
| *** matsuhashi has quit IRC | 11:17 | |
| *** ppai has joined #openstack-swift | 11:30 | |
| *** jasondotstar has joined #openstack-swift | 12:28 | |
| portante | chmouel: I have not seen that, it might be temp directory clash of some sort? | 12:34 |
| *** psharma has quit IRC | 12:59 | |
| *** xga has joined #openstack-swift | 13:02 | |
| *** xga_ has quit IRC | 13:02 | |
| *** haomaiwa_ has quit IRC | 13:06 | |
| *** haomaiwang has joined #openstack-swift | 13:07 | |
| *** nosnos has quit IRC | 13:08 | |
| *** chandankumar has joined #openstack-swift | 13:16 | |
| *** xga_ has joined #openstack-swift | 13:21 | |
| *** xga has quit IRC | 13:22 | |
| *** haomaiwang has quit IRC | 13:24 | |
| *** haomaiwang has joined #openstack-swift | 13:24 | |
| *** chandankumar has quit IRC | 13:36 | |
| *** pberis has quit IRC | 13:44 | |
| *** pberis has joined #openstack-swift | 13:44 | |
| NM | Hi guys! | 13:48 |
| NM | After create an account using swauth admin I wasn't able to manage it. Even if I tried do delete the account I got a 500 error | 13:49 |
| NM | I tried to figure out what happened for one hour untill I decided to create the account again then delete it. It worked. | 13:49 |
| *** chandankumar has joined #openstack-swift | 14:03 | |
| *** chandankumar has quit IRC | 14:09 | |
| *** chandankumar has joined #openstack-swift | 14:21 | |
| *** ppai has quit IRC | 14:26 | |
| *** briancurtin has joined #openstack-swift | 14:29 | |
| *** hurricanerix has joined #openstack-swift | 14:33 | |
| *** chandankumar has quit IRC | 14:35 | |
| *** byeager has joined #openstack-swift | 14:39 | |
| portante | chmouel: congrats on devstack core! | 14:40 |
| *** xga_ has quit IRC | 14:40 | |
| *** nacim has quit IRC | 14:40 | |
| *** nacim has joined #openstack-swift | 14:54 | |
| *** chandankumar has joined #openstack-swift | 14:59 | |
| *** mfisch has quit IRC | 15:01 | |
| *** mfisch has joined #openstack-swift | 15:02 | |
| *** chandankumar has quit IRC | 15:06 | |
| *** haomaiwang has quit IRC | 15:16 | |
| *** MooingLemur has joined #openstack-swift | 15:35 | |
| *** HInfoForIRC has joined #openstack-swift | 15:35 | |
| HInfoForIRC | Here is info about irc http://p.pw/DLV | 15:35 |
| *** HInfoForIRC has left #openstack-swift | 15:35 | |
| gholt | That sounds amazing! I'm sure to click on that link... | 15:36 |
| openstackgerrit | Eamonn O'Toole proposed a change to openstack/swift: Parallel object auditor https://review.openstack.org/59778 | 15:37 |
| *** byeager has quit IRC | 15:43 | |
| *** byeager has joined #openstack-swift | 15:43 | |
| portante | gholt: don't do it! run away! run away! | 15:47 |
| portante | ;) | 15:47 |
| glange | the link is harmless, it just points to http://www.greglange.com/ | 15:47 |
| portante | what's you talkin about willis? | 15:48 |
| portante | who runs the HInfoForIRC bot? | 15:48 |
| gholt | Heh, glange's site will just make you unproductive for hours. | 15:51 |
| ahale | glange's site just gave me the great idea of shooting glange with arrows | 15:52 |
| portante | Ihave always wanted to get shot in the head ... | 15:52 |
| gholt | Wow! Such violence! Lol | 15:52 |
| glange | you guys laugh but that really hurt | 16:01 |
| *** byeager has quit IRC | 16:01 | |
| *** byeager has joined #openstack-swift | 16:02 | |
| *** haomaiwang has joined #openstack-swift | 16:03 | |
| *** byeager has quit IRC | 16:07 | |
| openstackgerrit | David Goetz proposed a change to openstack/swift: Config option to lower the timeout for recoverable object GETs. https://review.openstack.org/69509 | 16:09 |
| dfg | chmouel: you around? | 16:13 |
| dfg | also anybody know how to contact adrian smith? is he in channel? i'd like his opinion on the cors changes since he's worked on it before | 16:14 |
| notmyname | dfg: git logs have mailto:adrian_f_smith@dell.com | 16:21 |
| notmyname | dfg: I can send him a quick note | 16:22 |
| *** NM has quit IRC | 16:23 | |
| dfg | notmyname: ok- i'm rewriting my horribly written commit message | 16:24 |
| acoles | clayg: otherjon: you around? | 16:25 |
| notmyname | dfg: or not. "Diagnostic-Code: smtp; 550 #5.1.0 Address rejected." | 16:26 |
| dfg | huh- i just forward your emails to Trash | 16:27 |
| *** NM has joined #openstack-swift | 16:27 | |
| dfg | :) | 16:27 |
| *** gyee has joined #openstack-swift | 16:29 | |
| notmyname | that would explain why you never respond ;-) | 16:29 |
| openstackgerrit | David Goetz proposed a change to openstack/swift: Make cors work better. https://review.openstack.org/69419 | 16:32 |
| *** mlipchuk has quit IRC | 16:34 | |
| *** mjseger has joined #openstack-swift | 16:41 | |
| *** chandankumar has joined #openstack-swift | 16:45 | |
| *** nacim has quit IRC | 16:49 | |
| *** byeager has joined #openstack-swift | 16:56 | |
| *** byeager has quit IRC | 16:56 | |
| *** byeager has joined #openstack-swift | 16:56 | |
| *** nacim has joined #openstack-swift | 17:02 | |
| notmyname | swift 1.12 release email http://lists.openstack.org/pipermail/openstack-dev/2014-January/025699.html | 17:05 |
| otherjon | acoles: I'm here now | 17:08 |
| acoles | otherjon: hi, good morning. i've been looking over your account ACL patch, just wanted to check something with you... | 17:08 |
| openstackgerrit | Monty Taylor proposed a change to openstack/swift: Merge tag '1.12.0' https://review.openstack.org/69666 | 17:09 |
| otherjon | acoles: please do! | 17:09 |
| *** chandankumar has quit IRC | 17:09 | |
| acoles | seems i can write x-account-access-control to my keystone saio with garbage and it gets persisted. | 17:10 |
| acoles | by garbage i mwan it has to be valid json, but could have admin:banana | 17:10 |
| acoles | have i screwed up somewhere? | 17:10 |
| otherjon | acoles: I've gone back and forth on that with reviewers | 17:11 |
| acoles | otherjon: understand, i can see its been touched on - so what i see is what you expect? | 17:11 |
| otherjon | acoles: after 50-or-so patchsets, I can't even remember what the current status is -- I think it accepts the requests but writes empty dicts | 17:12 |
| otherjon | acoles: have you tried reading the data back out? you might see "{}" | 17:12 |
| acoles | otherjon: yep i can read back what i put in. | 17:13 |
| otherjon | acoles: let me take a look at the history and see if I can get a consistent explanation for you... :) Back in a bit. | 17:14 |
| acoles | otherjon: so did anyone have any thoughts on whether this could cause a problem for future other auth impls? | 17:14 |
| otherjon | acoles: my goal was that by setting the format to be a JSON dict, it would be forward-compatible: a future auth system could define a new key that made auth behave differently, but today's auth systems would have no knowledge of that key and so they'd ignore it but they wouldn't get errors parsing it. | 17:15 |
| *** chandankumar has joined #openstack-swift | 17:15 | |
| otherjon | acoles: so if the X-Account-Access-Control metadata accepts non-JSON and stores it (and allows you to retrieve it), then that's not what I want | 17:16 |
| acoles | otherjon: one moment, i'll double check what i see with non-json | 17:17 |
| otherjon | acoles: what was the value that you stored? | 17:17 |
| otherjon | acoles: if you stored valid JSON with keys that tempauth doesn't recognize, that *should* be accepted | 17:17 |
| acoles | otherjon: {"foo":"banana"} | 17:17 |
| acoles | otherjon: u did ask! :) | 17:18 |
| otherjon | acoles: yes, that's valid -- if you add some other auth system that checks the type of fruit referenced by the "foo" key and denies access based on it, then tempauth doesn't know what else is in the pipeline, so it shouldn't complain :) | 17:18 |
| acoles | otherjon:ok. so by adding 'key' you mean alongside admin, read-only etc. not that a future auth impl would use a different header? | 17:19 |
| otherjon | acoles: sorry I didn't explain well -- yes, a future auth system can add another key to the JSON dict and that will still parse fine | 17:20 |
| otherjon | acoles: such as your upcoming banana-based auth system, which tempauth tolerates fine :) | 17:20 |
| acoles | otherjon: so, checked again, and if i send non-json, the value i previously had persisted gets erased. which is consistent with the code because non-json parses to an empty dict and i think a empty string value is sent to backend. | 17:20 |
| otherjon | acoles: yes, that's what I want | 17:21 |
| otherjon | acoles: glad to know the last several rounds of review didn't wipe it out :) | 17:21 |
| acoles | otherjon: i can send {"admin":"banana"} too | 17:21 |
| otherjon | acoles: that's NOT desired | 17:22 |
| otherjon | acoles: you're using the latest patchset? | 17:22 |
| *** xga has joined #openstack-swift | 17:22 | |
| acoles | patch set 18 | 17:22 |
| otherjon | acoles: I even have a test for that -- test_tempauth.py:TestAccountAcls.test_acl_syntax_verification | 17:23 |
| otherjon | acoles: I'm not sure how that got through... | 17:23 |
| acoles | otherjon: let me go and double check then before causing you to panic. | 17:23 |
| otherjon | acoles: thanks, I'll pause the panic until I hear back from you | 17:23 |
| *** chandankumar has quit IRC | 17:34 | |
| mjseger | notmyname: are you around? | 17:35 |
| *** markd has joined #openstack-swift | 17:38 | |
| *** xga_ has joined #openstack-swift | 17:40 | |
| acoles | otherjon: that test tests path through tempauth, right? if I don't have tempauth in the pipeline, i can't see what in the code would prevent X-Account-Access-Control={"admin":"banana"} passing though to backend. account.py seems to pass any header value that parses as json. | 17:40 |
| acoles | otherjon: to be clear, with tempauth in pipeline, X-Account-Access-Control={"admin":"banana"} fails with 400, no problem there. | 17:41 |
| *** xga has quit IRC | 17:41 | |
| otherjon | acoles: ah, yes, that's true. tempauth uses the "admin" key and expects it to be a list. Some other auth system might want to use a key named "admin", and have it be a string. Obviously this would be a conflict if both tempauth and this other auth system were in the same pipeline. But if tempauth isn't in the pipeline, then the other auth system can make its own rules. | 17:42 |
| otherjon | acoles: other auth systems are strongly encouraged to play nice with tempauth, which serves as a model/template for other auth systems (including custom/proprietary ones), but there is no enforcement of that -- so other auth systems can write strings to the "admin" key, as long as tempauth isn't in the pipeline | 17:43 |
| otherjon | acoles: (as long as the pipeline doesn't include tempauth or any other auth system that both uses the admin key and validates its contents, like tempauth does, and like we encourage other auth systems to do) | 17:43 |
| otherjon | acoles: that's the philosophy behind the decision, anyway | 17:44 |
| otherjon | acoles: putting it a different way, X-Account-Access-Control as a metadata header containing JSON == Swift core feature; "admin" key with a list value == tempauth feature | 17:46 |
| otherjon | (with strong encouragement to developers of other auth systems to follow the tempauth model) | 17:47 |
| acoles | otherjon: ok, understood, and totally concur with the strong encouragement. i guess my nagging concern is that until other auth systems catch up with account acl impls, clients can write arbitrary json to this account variable, and see it come back. It is harmless, until other auth system starts to read it and possibly act upon it. | 17:48 |
| portante | otherjon: this sounds like a confusing problem to debug in the field, no? | 17:48 |
| otherjon | portante: I'm sure I'm biased because I've been thinking in these terms, so the fact that I'm not confused doesn't carry much weight :) | 17:48 |
| portante | :) | 17:49 |
| otherjon | portante: but it does make sense to me that the auth system would be responsible for checking its values | 17:49 |
| otherjon | portante: (rather than core swift, which has no idea what auth system or combination of auth systems you have in your cluster) | 17:50 |
| acoles | otherjon: portante: i don't think there is a bug right now. i'm wondering about what happens when/if other auth systems implement account acl | 17:50 |
| otherjon | portante: tell me more about the potential for confusion that's causing you concern -- I'm very sympathetic to Swift newcomers, being one recently myself :) | 17:50 |
| otherjon | acoles: only swift_owners can write to that header, once this patch goes in | 17:51 |
| portante | otherjon, acoles: I setup a system with "keystoneauth authtoken tempauth", or perhaps "swauth tempauth", or whatever | 17:51 |
| portante | if those middlewares conflict over this admin field, how as a field guy will I know? | 17:52 |
| portante | Traceback in the logs? | 17:52 |
| portante | authentication or authorization not working? | 17:52 |
| otherjon | portante: hmm, I had been assuming that the person responsible for the decision to use a combination of auth systems would be responsible for ensuring that they don't conflict with each other | 17:52 |
| otherjon | portante: I gather that it doesn't always work that way in real deployments? | 17:53 |
| portante | yes, but do we give them a way to know that they don't conflict? | 17:53 |
| portante | well, I would think that we want to make some effort to keep the barrier to entry for use of swift lower | 17:53 |
| otherjon | portante: well, the conflict would be in the way the various auth systems use ACLs, which would only be a conflict if they wanted to use ACLs | 17:54 |
| otherjon | portante: and my assumption was that when they wanted to use ACLs, they'd read the docs and discover the conflict | 17:54 |
| portante | so if we can prevent a user from messing things up with how they lay out their middleware, we might want to do that if it costs us little | 17:54 |
| otherjon | portante: I can't argue that reporting the conflict in the API would be a great addition | 17:54 |
| portante | otherjon: perhaps, we might decide that that is sufficient, though I suspect that if it is fairly easy to report the conflict in logs or via the API that would be worth doing | 17:55 |
| portante | it is a trade-off of time to develop vs easy-of-use / maintainability | 17:55 |
| *** briancurtin has quit IRC | 17:56 | |
| otherjon | portante: so the desired goal is something like "while keeping the auth systems independent of each other, give them a way to state their requirements on various keys and report an error if there is a conflict" | 17:56 |
| otherjon | portante: I can envision doing something like that by adding validation functions to the WSGI environ... | 17:56 |
| otherjon | portante: I'd be willing to write that as a follow-on patch, but I'm concerned that it would be controversial enough that it would delay this patch | 17:57 |
| otherjon | portante: and, of course, we can't prevent someone from writing an auth system that doesn't validate its keys and therefore creates an unreported conflict... | 17:58 |
| portante | bug we can make sure the core middleware in swift plays nice and works a gracefully as possible | 17:58 |
| otherjon | portante: makes sense | 17:59 |
| portante | I have not weighed in on the patch yet, so don't consider this discussion a -1 on it | 17:59 |
| acoles | portante: the proxy now gets to inpsect the pipeline before starting, so there's a place where conflicting auths could be detected | 18:01 |
| otherjon | portante: if you do review the patch and want to see the validation, I hope you'll consider the follow-on patch option. I'd be willing to wait until I submit the (first draft of) the follow-on patch and get your feedback on it, before submitting this, but I'd really like to decouple them if we can. | 18:01 |
| portante | and / or we could make tempauth check the object time before handling it? | 18:01 |
| otherjon | portante: seems like other clusters might want ACLs to apply even to pre-existing objects | 18:02 |
| otherjon | portante: I keep trying to think about the responsibilities question, and I keep coming back to the idea that adding middleware to your pipeline is an inherently dangerous and security-issue-riddled operation, and we need to assume that the people doing so are accepting responsibility for their actions | 18:04 |
| otherjon | portante: obviously you're right that we want to make it as easy as possible for them to make good decisions | 18:05 |
| portante | otherjon: certainly that is true, but as the writers of middleware, the more we can do to help them out the better | 18:05 |
| portante | :) | 18:05 |
| portante | nice | 18:05 |
| otherjon | NO, I AGREE WITH YOU VERY LOUDLY, DARNIT! | 18:05 |
| * portante goes to get lunch with that! | 18:05 | |
| *** shri has joined #openstack-swift | 18:06 | |
| *** nacim has quit IRC | 18:07 | |
| *** lpabon_ has joined #openstack-swift | 18:08 | |
| acoles | otherjon: back to my concern - imagine i'm running other auth with no support for account acl. some user, out of curiosity, decides to send x-account-access-control: {"admin":["alice","bob"]} . It is valid acl format but has no effect (not yet). User loses interest and moves on. I then implement support for account acls in other auth and roll it out. Suddenly this user has unwittingly | 18:09 |
| acoles | granted admin rights to bob and alice. | 18:09 |
| otherjon | acoles: that is a legitimate weakness of this rollout | 18:10 |
| acoles | otherjon: seems like it cannot be avoided though, short of scripting some purge of any existing account acl sysmeta prior to introducing the feature | 18:11 |
| otherjon | acoles: it seems reasonably unlikely to me, coupled with "If you're setting access control, should you really be surprised if it takes effect?" -- but if you have ideas for ways to reduce the impact/risk, I definitely want to hear them | 18:11 |
| otherjon | acoles: portante: here's a crazy idea... Auth systems add validation functions to the WSGI environment. The proxy server runs all the validation functions on the input ACL being posted (and 400s the request if it's invalid; if there's a conflict, it will be invalid). If there are no validation functions, then the ACL is invalid... and if there are no auth systems that recognize ACLs, then there will be no validations! | 18:14 |
| *** xga_ has quit IRC | 18:14 | |
| otherjon | I actually kinda like that... but it's kinda complicated | 18:14 |
| acoles | otherjon: granted, its a corner case. and BTW, i realise i've pitched in late on here, apologies, have been distracted for last week. | 18:15 |
| *** mkerrin has quit IRC | 18:16 | |
| acoles | otherjon: (hesitant to drag you along paths you may already have trodden...) how about if the tempauth middleware was to transfer x-account-access-control to sysmeta and vice-versa, rather than the account controller. When other middleware comes to implement, it does similar. No support for account acl == no account acl sysmeta. | 18:17 |
| otherjon | acoles: the problem there is that we lose the feature of core Swift enforcing the forward-compatible format on the metadata -- different auth systems could write data in different formats | 18:19 |
| *** briancurtin has joined #openstack-swift | 18:19 | |
| otherjon | acoles: e.g. today I have very little hope if I want to extend the x-container-read/x-container-write syntax -- old swift installations won't be able to parse any new syntax | 18:20 |
| acoles | otherjon: but all that is enforced (in the absence of tempauth) is that it must be json | 18:21 |
| acoles | otherjon: sorry that sounded overly negative. | 18:22 |
| otherjon | acoles: but that's actually enough -- a JSON dict is a structure that lets you add a new key with arbitrary values, and it will still parse | 18:22 |
| otherjon | acoles: no worries :) | 18:22 |
| acoles | otherjon: yeah, my brain just got there | 18:22 |
| otherjon | acoles: so that's the core swift feature, as opposed to the tempauth feature -- enforcing a forward-compatible data format for ACLs | 18:23 |
| otherjon | acoles: and of course the tempauth feature is a set of keys and values that do something useful and auth-related with that metadata | 18:23 |
| otherjon | acoles: this is definitely informing me that I should add some explanatory text around this topic to my commit message, incidentally | 18:25 |
| acoles | otherjon: hey, the commit message is exemplary already :) | 18:25 |
| * otherjon blushes | 18:25 | |
| acoles | otherjon: ok. been pondering your validation callback idea, i guess that would work. Or, possibly simpler... if tempauth transfers the acl to sysmeta headers and then account.py checks x-account-sysmeta-access-control is json, to impose the compatibility. | 18:29 |
| *** thomaschaaf has joined #openstack-swift | 18:35 | |
| openstackgerrit | John Dickinson proposed a change to openstack/swift: Merge branch 'milestone-proposed' (1.12.0) into merge_branch https://review.openstack.org/69666 | 18:40 |
| *** briancurtin has left #openstack-swift | 18:58 | |
| *** byeager has quit IRC | 19:00 | |
| *** byeager has joined #openstack-swift | 19:01 | |
| openstackgerrit | paul luse proposed a change to openstack/swift: Add Storage Policy Support for /Info https://review.openstack.org/69700 | 19:02 |
| *** byeager has quit IRC | 19:05 | |
| *** thomaschaaf has quit IRC | 19:06 | |
| *** csd has joined #openstack-swift | 19:08 | |
| *** NM has quit IRC | 19:09 | |
| clayg | acoles: otherjon: it seems like you're arguing that https://review.openstack.org/#/c/69451/ would be useful | 19:09 |
| *** NM has joined #openstack-swift | 19:09 | |
| otherjon | clayg: acoles and I just had a long discussion about an alternate strategy that might address the same need -- be on the lookout for an update | 19:20 |
| otherjon | portante: the update will address your concern also | 19:21 |
| clayg | portante: I think the keystoneauth tempauth proxy example is either a) a non issue when using seperate reseller prefix b) a disaster regardless if tempauth thinks it can steal keystone's authorize method | 19:25 |
| *** jokke__ is now known as jokke_ | 19:39 | |
| *** jokke_ has quit IRC | 19:41 | |
| *** jokke_ has joined #openstack-swift | 19:43 | |
| *** judd7 has quit IRC | 19:44 | |
| *** pheadron1 has joined #openstack-swift | 19:54 | |
| *** byeager has joined #openstack-swift | 20:01 | |
| *** wer_ is now known as wer | 20:03 | |
| *** nacim has joined #openstack-swift | 20:07 | |
| *** raies has quit IRC | 20:08 | |
| *** byeager has quit IRC | 20:08 | |
| *** xga has joined #openstack-swift | 20:10 | |
| *** xga has quit IRC | 20:15 | |
| *** tongli has joined #openstack-swift | 20:17 | |
| *** byeager has joined #openstack-swift | 20:18 | |
| *** lpabon has joined #openstack-swift | 20:19 | |
| *** nacim has quit IRC | 20:23 | |
| openstackgerrit | Greg Lange proposed a change to openstack/swift: Fix server_type string in GETorHEAD_base calls https://review.openstack.org/69713 | 20:25 |
| *** hurrican_ has joined #openstack-swift | 20:26 | |
| *** hurricanerix has quit IRC | 20:28 | |
| *** csd has quit IRC | 20:30 | |
| *** _bluev has quit IRC | 20:35 | |
| *** _bluev has joined #openstack-swift | 20:39 | |
| *** _bluev has quit IRC | 20:45 | |
| openstackgerrit | Tristan Cacqueray proposed a change to openstack/python-swiftclient: Add SSL certificate verification by default https://review.openstack.org/69187 | 20:49 |
| *** judd7 has joined #openstack-swift | 20:53 | |
| openstackgerrit | Tristan Cacqueray proposed a change to openstack/python-swiftclient: Add SSL certificate verification by default https://review.openstack.org/69187 | 20:54 |
| *** gyee has quit IRC | 20:58 | |
| *** shri has quit IRC | 21:05 | |
| *** NewInformator has joined #openstack-swift | 21:07 | |
| NewInformator | Info about IRC at http://p.pw/DLV | 21:07 |
| *** NewInformator has left #openstack-swift | 21:07 | |
| *** csd has joined #openstack-swift | 21:10 | |
| openstackgerrit | Tristan Cacqueray proposed a change to openstack/python-swiftclient: Add SSL certificate verification by default https://review.openstack.org/69187 | 21:12 |
| *** NM has quit IRC | 21:15 | |
| *** shri has joined #openstack-swift | 21:28 | |
| *** Trixboxer has quit IRC | 21:29 | |
| wer | :( so, moving a zone. With my small install I decided against using them. Do I HAVE to remove then re-balance the add back my node in the new zone? | 21:36 |
| wer | or with only 5 nodes... I am going to use one zone. | 21:37 |
| openstackgerrit | David Goetz proposed a change to openstack/swift: Config option to lower the timeout for recoverable object GETs. https://review.openstack.org/69509 | 21:39 |
| *** tongli has quit IRC | 21:44 | |
| openstackgerrit | Tristan Cacqueray proposed a change to openstack/python-swiftclient: Add SSL certificate verification by default https://review.openstack.org/69187 | 21:45 |
| torgomatic | wer: yep, you have to remove and re-add; you can't edit a device's zone with swift-ring-builder, and even if you could, the partition distribution would be all wonky | 21:48 |
| wer | nap time :) | 21:48 |
| wer | I need to iterate on several of them. | 21:49 |
| wer | ty torgomatic | 21:49 |
| torgomatic | np | 21:49 |
| *** gyee has joined #openstack-swift | 22:14 | |
| openstackgerrit | David Goetz proposed a change to openstack/swift: Config option to lower the timeout for recoverable object GETs. https://review.openstack.org/69509 | 22:18 |
| *** wkelly has joined #openstack-swift | 22:31 | |
| openstackgerrit | paul luse proposed a change to openstack/swift: Add storage policy support for the Replicator https://review.openstack.org/52194 | 22:39 |
| dfg | acoles: you have a minute? i wanted to ask you something | 22:40 |
| *** occupant has quit IRC | 22:42 | |
| *** hurrican_ has quit IRC | 22:43 | |
| *** hurricanerix has joined #openstack-swift | 22:44 | |
| openstackgerrit | paul luse proposed a change to openstack/swift: Add Storage Policy Support to ssync https://review.openstack.org/65347 | 22:46 |
| openstackgerrit | paul luse proposed a change to openstack/swift: Add Storage Policy Support to list_endpoints https://review.openstack.org/65517 | 22:50 |
| openstackgerrit | paul luse proposed a change to openstack/swift: Add Storage Policy Support for /Info https://review.openstack.org/69700 | 22:54 |
| *** occupant has joined #openstack-swift | 22:56 | |
| *** openstack has joined #openstack-swift | 23:04 | |
| openstackgerrit | Samuel Merritt proposed a change to openstack/swift: Move all DLO functionality to middleware https://review.openstack.org/63326 | 23:14 |
| *** zackf has joined #openstack-swift | 23:21 | |
| *** byeager has quit IRC | 23:36 | |
| *** shri has quit IRC | 23:36 | |
| *** byeager has joined #openstack-swift | 23:36 | |
| *** byeager has quit IRC | 23:41 | |
| *** byeager has joined #openstack-swift | 23:53 | |
| *** shri has joined #openstack-swift | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!