| *** richm has quit IRC | 00:14 | |
| *** lbragstad has joined #openstack-keystone | 00:21 | |
| *** nachi has quit IRC | 00:25 | |
| *** arunkant has quit IRC | 00:26 | |
| *** arunkant has joined #openstack-keystone | 00:27 | |
| *** lnxnut has joined #openstack-keystone | 00:30 | |
| *** lnxnut has quit IRC | 00:34 | |
| *** achampion has quit IRC | 00:35 | |
| *** lnxnut has joined #openstack-keystone | 00:35 | |
| *** lnxnut has quit IRC | 00:40 | |
| *** david_lyle has quit IRC | 00:44 | |
| *** henrynash has joined #openstack-keystone | 00:49 | |
| *** lnxnut has joined #openstack-keystone | 00:50 | |
| *** hogepodge has quit IRC | 00:51 | |
| *** henrynash has quit IRC | 00:53 | |
| *** lnxnut has quit IRC | 00:54 | |
| *** lnxnut has joined #openstack-keystone | 00:54 | |
| *** lnxnut has quit IRC | 00:59 | |
| *** lnxnut has joined #openstack-keystone | 01:01 | |
| *** henrynash has joined #openstack-keystone | 01:04 | |
| *** browne has quit IRC | 01:08 | |
| *** lnxnut has quit IRC | 01:38 | |
| *** lnxnut has joined #openstack-keystone | 01:39 | |
| *** gokrokve has quit IRC | 01:40 | |
| *** gokrokve has joined #openstack-keystone | 01:41 | |
| *** gokrokve_ has joined #openstack-keystone | 01:42 | |
| *** gokrokve_ has quit IRC | 01:43 | |
| *** lnxnut has quit IRC | 01:44 | |
| *** gokrokve has quit IRC | 01:46 | |
| *** devlaps has quit IRC | 01:52 | |
| *** achampion has joined #openstack-keystone | 01:57 | |
| *** lnxnut has joined #openstack-keystone | 01:57 | |
| *** marcoemorais1 has joined #openstack-keystone | 02:15 | |
| *** marcoemorais has quit IRC | 02:15 | |
| *** gokrokve has joined #openstack-keystone | 02:19 | |
| *** lnxnut has quit IRC | 02:39 | |
| *** marcoemorais1 has quit IRC | 02:39 | |
| *** lnxnut has joined #openstack-keystone | 02:40 | |
| *** lnxnut has quit IRC | 02:44 | |
| *** henrynash has quit IRC | 03:13 | |
| ayoung | bknudson, dolphm_503 jamielennox really needs to move ahead. https://review.openstack.org/#/c/71455/ Needs to be in icehouse | 03:18 |
|---|---|---|
| jamielennox | ayoung: looking | 03:19 |
| *** lnxnut has joined #openstack-keystone | 03:19 | |
| ayoung | jamielennox, thanks. It makes client the owner of the common code.... | 03:19 |
| jamielennox | ayoung: what are we still doing the environment stuff for if we're using client cms? | 03:20 |
| ayoung | jamielennox, ask dstanek about that! | 03:20 |
| ayoung | jamielennox, when the monkey patching takes effect, it changes the class returned by the exception | 03:20 |
| ayoung | if we don't do the environment stuff, we look for the wrong exception | 03:21 |
| dstanek | heya | 03:21 |
| jamielennox | wrong exception from where? | 03:22 |
| dstanek | jamielennox: you mean where we catch the exception? | 03:22 |
| ayoung | jamielennox, popen | 03:22 |
| ayoung | jamielennox, dstanek figured that out, which is why is a coauthor | 03:22 |
| ayoung | cuz he's smaht! | 03:23 |
| jamielennox | ayoung: popen shouldn't be affected, because if you are doing the eventlet monkey patch then it will always raise the subprocess errror | 03:23 |
| * dstanek blushes | 03:23 | |
| jamielennox | dstanek: i don't think you're wrong i'm just wondering | 03:23 |
| jamielennox | environment.subprocess error shouldn't really be needed any more | 03:23 |
| ayoung | jamielennox, OK...so we were not properly monkeypatching in the client before | 03:24 |
| dstanek | jamielennox: the exception thrown from the eventlet subprocess is not the same as the one from the stdlib | 03:24 |
| jamielennox | ayoung: well we shouldn't be monkeypatching the client | 03:24 |
| ayoung | jamielennox, no, we need to detect monkeypatching in the client | 03:24 |
| jamielennox | dstanek: when you do a from environment.green import subprocess | 03:24 |
| ayoung | and call the write code accordingly | 03:24 |
| dstanek | jamielennox: check out the last 3 classes here: https://review.openstack.org/#/c/71455/5/keystone/tests/test_token_provider.py | 03:24 |
| dstanek | the problem (not really a problem) is that we are not monkey patching subprocess | 03:25 |
| jamielennox | oh, i see what you mean | 03:25 |
| dstanek | so everyone has to import the same one to interoperate | 03:25 |
| jamielennox | i hadn't seen cms.set_subprocess | 03:26 |
| dstanek | yeah, so environment has always been our shim to do that | 03:26 |
| jamielennox | we could probably have just relied on eventlet patching to do that for us | 03:26 |
| ayoung | jamielennox, nope | 03:26 |
| ayoung | popen is .... called by the monkeypatched version of popen | 03:26 |
| ayoung | so you cna;t just monkeypatch popen, you have to call the right version...its wonderful code | 03:26 |
| dstanek | gotta love magic! | 03:27 |
| jamielennox | ergh, i'm gonna assume you both know what's happening there | 03:27 |
| * ayoung having trouble finding the change | 03:28 | |
| ayoung | jamielennox, hold on. it was a one character fix | 03:28 |
| ayoung | https://review.openstack.org/#/c/71635/ | 03:28 |
| ayoung | .get('os'): OK a little more than one character | 03:29 |
| ayoung | but with that, we properly identified that the client should use the eventlet version....see, most of the openstack clients don't call monkeypatch for os.... | 03:29 |
| jamielennox | ayoung most of the *clients* shouldn't monkeypatch | 03:30 |
| jamielennox | it should only ever happen from a server | 03:30 |
| ayoung | jamielennox, but for Eventlet, they need to use the monkeypatched version of popen, or they block | 03:30 |
| ayoung | that is what I mean by clients | 03:30 |
| ayoung | auth token clients | 03:30 |
| *** marcoemorais has joined #openstack-keystone | 03:32 | |
| jamielennox | ayoung: surely (and i guess i mean hopefully) when you do eventlet.patcher.monkey_patch(os=False, select=True, socket=True, | 03:32 |
| jamielennox | thread=monkeypatch_thread, time=True, | 03:32 |
| jamielennox | psycopg=False, MySQLdb=False) | 03:32 |
| jamielennox | it patches popen | 03:32 |
| jamielennox | oh, | 03:32 |
| jamielennox | auth_token | 03:32 |
| ayoung | nopw | 03:32 |
| jamielennox | ahh | 03:32 |
| ayoung | yep | 03:32 |
| jamielennox | ;( | 03:33 |
| ayoung | Lurvely, eh Wot? | 03:33 |
| jamielennox | FILGTM | 03:33 |
| ayoung | STAMP | 03:34 |
| *** marcoemorais has quit IRC | 03:34 | |
| *** marcoemorais has joined #openstack-keystone | 03:35 | |
| *** marcoemorais has quit IRC | 03:39 | |
| *** morganfainberg is now known as morganfainberg_Z | 03:39 | |
| *** lnxnut has quit IRC | 03:55 | |
| *** lnxnut has joined #openstack-keystone | 03:56 | |
| *** lnxnut has quit IRC | 04:00 | |
| *** stevemar has quit IRC | 04:09 | |
| *** lnxnut has joined #openstack-keystone | 04:11 | |
| *** theocean154 has joined #openstack-keystone | 04:12 | |
| *** harlowja is now known as harlowja_away | 04:12 | |
| *** lnxnut has quit IRC | 04:16 | |
| theocean154 | noob question: I have a hello world api sitting in keystone/keystone/contrib, how to i hook it in to the routers list. do i need to modify keystone/service.py | 04:19 |
| ayoung | theocean154, not necessarily | 04:22 |
| ayoung | for an extension, add it to the pipeline, so it gets auto-registered. See how the others are done...I think it was oauth that we did that way first | 04:22 |
| *** david_lyle_ has joined #openstack-keystone | 04:23 | |
| ayoung | theocean154, extension.register_admin_extension or the public variant should wire it up | 04:24 |
| *** lnxnut has joined #openstack-keystone | 04:26 | |
| ayoung | jamielennox, OK, so I started working on a client extension for revocation events, and decided that before auth_token supports it, I want to do a CLI | 04:27 |
| ayoung | something like keystone validate_token $TOKEN | 04:28 |
| ayoung | it will do the cms call, then the revocation check | 04:28 |
| ayoung | once I get that working, we can integrate with AT-middle | 04:28 |
| jamielennox | ayoung: sounds fair | 04:29 |
| jamielennox | actually | 04:29 |
| ayoung | jamielennox, I was trying to figure out how to add an option to the CLI | 04:29 |
| jamielennox | no it means you are limited to the v2 api which doesn't have the revocation events | 04:29 |
| theocean154 | @ayoung is the path given by the alias key in core.py? | 04:30 |
| theocean154 | #ayound | 04:30 |
| ayoung | theocean154, sure | 04:30 |
| theocean154 | how do you cite a name in limechat anyone? | 04:30 |
| ayoung | theocean154, I think....I wrote this so long ago, I would have to read to code to remember. | 04:30 |
| theocean154 | i see your todos haha. i copied the basic code from the contrib/ec2 files | 04:31 |
| jamielennox | the path to an extension is a funny concept that im not sure is ever properly fleshed out | 04:31 |
| *** harlowja_away is now known as harlowja | 04:32 | |
| ayoung | jamielennox, you know, when I first read that, I thought you were talking about client extensions, but realize you meant server. I think it pretty much applies to anything I've touched in Keystone | 04:33 |
| jamielennox | ayoung: client doesn't have proper extensions, i was going to do that until the /extensions path was rejected | 04:33 |
| jamielennox | (someone came looking for that earlier this moning) | 04:34 |
| ayoung | yeah. yeah. | 04:34 |
| jamielennox | i don't know what happened to the IBM guys who wanted to do client extensions | 04:34 |
| jamielennox | anyway for CLI don't you need v3 for token revocation extensions? | 04:35 |
| ayoung | yep V3 | 04:35 |
| jamielennox | so no can do on the CLI | 04:36 |
| ayoung | I figured I start just a "list" | 04:36 |
| ayoung | ooh. can't we do --api-clinet-version=3 | 04:36 |
| jamielennox | that never worked | 04:36 |
| ayoung | I see some real ugliness in there | 04:37 |
| ayoung | https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/shell.py#L255 <--------- jamielennox what is that | 04:38 |
| ayoung | I know I should ask Gabe Hurley | 04:39 |
| ayoung | but I'm guessing he just inherited it from where ever.... | 04:40 |
| jamielennox | ayoung: somewhere between that and https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/shell.py#L432 is hwere it says ignore what the user asked for and use the v2 api | 04:40 |
| ayoung | yeah | 04:40 |
| *** lnxnut has quit IRC | 04:40 | |
| ayoung | pretty much the line I just showed you guaran-damn-tees it | 04:40 |
| ayoung | because you are ALWAYS getting a KeyError there | 04:41 |
| jamielennox | yea, your one doesn't give a warning :) | 04:41 |
| jamielennox | ayoung: i'm currently trying to figure out if it's worth trying to reuse the existing clients or do a rewrite of them for the SDK | 04:42 |
| jamielennox | rewrite is looking better and better | 04:42 |
| *** achampio1 has joined #openstack-keystone | 04:42 | |
| jamielennox | i fought kindof hard to reuse them, but ughh | 04:42 |
| ayoung | nah, we can fix this | 04:42 |
| ayoung | a rewrite is rarely worth it | 04:43 |
| ayoung | http://en.wikipedia.org/wiki/Second-system_effect | 04:43 |
| jamielennox | ayoung: the question i suppose is do we want to | 04:43 |
| ayoung | No, I want to get the client supporting v3, get ATM using the client code, and move on with my life | 04:43 |
| jamielennox | ATM? | 04:45 |
| *** achampion has quit IRC | 04:45 | |
| ayoung | Auth token middleware. ATM | 04:46 |
| jamielennox | makes sense | 04:47 |
| jamielennox | i've got some patches later in my review list that have ATM using the client | 04:48 |
| ayoung | yeah...need that | 04:48 |
| jamielennox | ayoung: does this vaguely make sense as an SDK pattern: https://github.com/jamielennox/python-mysdk/blob/master/mysdk/api/identity.py | 04:49 |
| ayoung | I started off with ATM for revocations, and realized I needed to fetch the list...which lead me looking at sessions...and thats how I ended up looking at the CLI | 04:49 |
| jamielennox | i'm not sure exactly why i'm asking it just seems a bit weird | 04:49 |
| *** achampio1 has quit IRC | 04:50 | |
| ayoung | jamielennox, its going to end up like the current client. .... the current client is a mess because it is a messy business. I'll take a look, but I'm none too hopeful that anything sane can stand | 04:50 |
| theocean154 | ayoung: thanks, it worked. The path was /v3/tfa. is the v3 appended to the path because my controller is a V3Controller class? | 04:50 |
| ayoung | theocean154, you going to submit what you are working on upstream? | 04:50 |
| ayoung | tfa? | 04:51 |
| theocean154 | im part of open academy | 04:51 |
| theocean154 | we're doing the two factor authentication stuff | 04:51 |
| ayoung | schweet | 04:51 |
| ayoung | you might be looking at the wrong code then | 04:51 |
| theocean154 | oh goody haha | 04:51 |
| ayoung | that probably should be an Auth plugin | 04:51 |
| theocean154 | we've been looking at soooo much code | 04:51 |
| ayoung | try to work within the auth controller under keystone/auth | 04:51 |
| *** achampion has joined #openstack-keystone | 04:52 | |
| ayoung | and just add a plugin to that....same thing the Federation work had to do | 04:52 |
| ayoung | Im just guessing, and can't say for sure until I see your code, though | 04:52 |
| ayoung | we need to rework the auth architecture into more of a pipeline, and ... its really plugable in two places right now. Auth plugins and the token provider.. the seond is way too course-grained a thing to replcae | 04:54 |
| *** KanagarajM_ has joined #openstack-keystone | 04:54 | |
| theocean154 | ok, i assume i can just move my code from the controllers, routers, and core in contrib to those in plugins? | 04:54 |
| ayoung | Nopew | 04:56 |
| ayoung | theocean154, post it as a WIP review and I'll look at it shortly, and I'll try to make it clear. I need to know the scope before I can be certain | 04:56 |
| ayoung | add me to the review once you've posted it | 04:56 |
| ayoung | going to bed now | 04:59 |
| *** ayoung has quit IRC | 04:59 | |
| lbragstad | dolphm_503: identity v3 api endpoint doc cleanup: https://review.openstack.org/#/c/76086/1 | 05:03 |
| jamielennox | lbragstad: commented | 05:05 |
| jamielennox | lbragstad: you can leave it to others though | 05:06 |
| lbragstad | endpoint ids shouldn't be public? | 05:06 |
| lbragstad | jamielennox: thanks for the review | 05:06 |
| jamielennox | lbragstad: we were having this conversation about something the other day | 05:07 |
| jamielennox | i don't see why they should be and i don't *think* they are in a service catalog | 05:08 |
| lbragstad | ahh | 05:08 |
| lbragstad | I must have missed the conversation? | 05:08 |
| lbragstad | either way, dolphm_503 and I were talking about it earlier because they had the 'name' attribute. | 05:09 |
| lbragstad | which isn't accessible through the clients | 05:09 |
| lbragstad | so I was working on cleaning that out of the docs, and dolphm mentioned that the --service--id and '...' could be replaced with realistic values. | 05:09 |
| lbragstad | jamielennox: like how this uses an actual ID in the example: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#endpoints-v3endpoints | 05:10 |
| lbragstad | but it doesn't remain consistent here: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#endpoints | 05:10 |
| jamielennox | lbragstad: yea, i would still show it, i think it's good other wise | 05:11 |
| jamielennox | looking at the way i read that doc an endpoint should have an id | 05:11 |
| lbragstad | jamielennox: yeah, do you know if there is a record of the #openstack-keystone channel? | 05:12 |
| jamielennox | lbragstad: i think there should be | 05:13 |
| jamielennox | i don't know how far back you would need to go | 05:13 |
| jamielennox | probably it was still in -dev | 05:13 |
| lbragstad | ahh ok | 05:13 |
| lbragstad | was gonna try and dig it up | 05:14 |
| lbragstad | a lot of the resources in the doc have that same thing going on | 05:14 |
| lbragstad | most of the examples use '...' or '--some--attribute--' | 05:14 |
| jamielennox | lbragstad: might be that i'm completely wrong | 05:15 |
| jamielennox | this is a token i just got from v3: http://paste.openstack.org/show/69267/ | 05:15 |
| jamielennox | and there is definetly an endpoint id in them | 05:15 |
| lbragstad | interesting | 05:16 |
| lbragstad | it is in catalog | 05:16 |
| lbragstad | and it has legacy_endpoint_id and region | 05:16 |
| jamielennox | ah | 05:16 |
| jamielennox | sorry | 05:16 |
| jamielennox | i definetly meant the catalog | 05:16 |
| lbragstad | :) | 05:16 |
| lbragstad | and the spec doesn't look like it has 'type'? | 05:17 |
| jamielennox | hmm, type we need | 05:18 |
| jamielennox | i went to +2, now back to -1 | 05:19 |
| lbragstad | I'll add that to the review | 05:19 |
| jamielennox | :) | 05:19 |
| *** theocean154 has quit IRC | 05:19 | |
| *** theocean154 has joined #openstack-keystone | 05:21 | |
| lbragstad | type should be optional | 05:23 |
| lbragstad | ? | 05:23 |
| *** marcoemorais has joined #openstack-keystone | 05:29 | |
| *** marcoemorais1 has joined #openstack-keystone | 05:32 | |
| *** marcoemorais has quit IRC | 05:33 | |
| jamielennox | lbragstad: i don't think so - type is like 'public' or 'admin' without it were kinda stuffed | 05:35 |
| jamielennox | ergh, hang on that's called interface in the catalog | 05:35 |
| lbragstad | mm | 05:35 |
| *** henrynash has joined #openstack-keystone | 05:36 | |
| jamielennox | 'type' is like 'compute' | 05:36 |
| lbragstad | yeah. interface is apparently either 'admin', 'public', or 'internal' | 05:36 |
| lbragstad | I feel like 'type' should be in service | 05:36 |
| jamielennox | but that's not a per endpoint thing apparently | 05:36 |
| jamielennox | yep | 05:36 |
| jamielennox | ... i have no good advice today ... | 05:36 |
| *** lnxnut has joined #openstack-keystone | 05:36 | |
| lbragstad | you *should* be able to associate a type with a service... which is correctly reflected in the doc | 05:37 |
| jamielennox | yep | 05:37 |
| jamielennox | and an endpoint needs a service_id | 05:37 |
| lbragstad | but I was a little mixed up when I saw your paste | 05:37 |
| jamielennox | and that should be enough | 05:37 |
| lbragstad | right | 05:37 |
| lbragstad | your paste listed endpoints | 05:37 |
| lbragstad | but they had 'type'? | 05:37 |
| * lbragstad might be missing something | 05:37 | |
| jamielennox | no they don't it's just not that well formatted | 05:39 |
| jamielennox | catalog endpoints are a list of dictionaries | 05:39 |
| *** theocean154 has left #openstack-keystone | 05:40 | |
| jamielennox | with a 'endpoints', 'type', and 'id' in them | 05:40 |
| lbragstad | ahh | 05:40 |
| lbragstad | I see it now | 05:40 |
| *** lnxnut has quit IRC | 05:41 | |
| lbragstad | services don't seem to reflect the 'enabled' field. I thought bknudson was working on something like that for endpoints too? | 05:48 |
| lbragstad | jamielennox: ^ | 05:48 |
| jamielennox | lbragstad: i'm not sure | 05:48 |
| lbragstad | I can investigate that tomorrow | 05:48 |
| jamielennox | swift's client is completely flat - there is support the swift bin and nothing else | 05:49 |
| jamielennox | :( | 05:49 |
| lbragstad | http://paste.openstack.org/show/69282/ | 05:50 |
| lbragstad | really? | 05:50 |
| *** lbragstad is now known as lbragstad_ | 05:53 | |
| *** harlowja is now known as harlowja_away | 06:01 | |
| *** chandan_kumar has joined #openstack-keystone | 06:07 | |
| *** saju_m has joined #openstack-keystone | 06:21 | |
| *** topol has joined #openstack-keystone | 06:21 | |
| *** topol has quit IRC | 06:23 | |
| *** topol has joined #openstack-keystone | 06:23 | |
| *** lnxnut has joined #openstack-keystone | 06:26 | |
| *** saju_m has quit IRC | 06:29 | |
| *** lnxnut has quit IRC | 06:31 | |
| *** gyee has quit IRC | 06:42 | |
| *** saju_m has joined #openstack-keystone | 06:42 | |
| *** bvandenh has joined #openstack-keystone | 06:59 | |
| *** topol has quit IRC | 07:01 | |
| *** gokrokve has quit IRC | 07:06 | |
| *** gokrokve has joined #openstack-keystone | 07:09 | |
| *** gokrokve_ has joined #openstack-keystone | 07:11 | |
| *** saju_m has quit IRC | 07:13 | |
| *** saju_m has joined #openstack-keystone | 07:13 | |
| *** gokrokve has quit IRC | 07:14 | |
| *** lnxnut has joined #openstack-keystone | 07:26 | |
| *** henrynash has quit IRC | 07:31 | |
| *** lnxnut has quit IRC | 07:31 | |
| *** leseb has joined #openstack-keystone | 08:13 | |
| *** dstanek has quit IRC | 08:25 | |
| *** lnxnut has joined #openstack-keystone | 08:27 | |
| *** gokrokve_ has quit IRC | 08:28 | |
| *** lnxnut has quit IRC | 08:31 | |
| *** gokrokve has joined #openstack-keystone | 09:12 | |
| *** gokrokve has quit IRC | 09:17 | |
| *** lnxnut has joined #openstack-keystone | 09:26 | |
| *** lnxnut has quit IRC | 09:31 | |
| *** marcoemorais1 has quit IRC | 09:40 | |
| *** gokrokve has joined #openstack-keystone | 10:12 | |
| *** gokrokve has quit IRC | 10:17 | |
| *** david_lyle_ has quit IRC | 10:21 | |
| *** lnxnut has joined #openstack-keystone | 10:26 | |
| *** lnxnut has quit IRC | 10:31 | |
| *** KanagarajM__ has joined #openstack-keystone | 10:50 | |
| *** KanagarajM_ has quit IRC | 10:53 | |
| *** leseb has quit IRC | 10:58 | |
| *** leseb has joined #openstack-keystone | 11:08 | |
| *** gokrokve has joined #openstack-keystone | 11:12 | |
| *** gokrokve has quit IRC | 11:17 | |
| *** lnxnut has joined #openstack-keystone | 11:26 | |
| *** lnxnut has quit IRC | 11:31 | |
| *** gokrokve has joined #openstack-keystone | 12:12 | |
| *** gokrokve has quit IRC | 12:17 | |
| *** lnxnut has joined #openstack-keystone | 12:26 | |
| *** lnxnut has quit IRC | 12:31 | |
| *** leseb has quit IRC | 12:39 | |
| *** leseb has joined #openstack-keystone | 12:54 | |
| *** gokrokve has joined #openstack-keystone | 13:14 | |
| *** gokrokve has quit IRC | 13:18 | |
| *** dstanek has joined #openstack-keystone | 13:19 | |
| *** ChanServ sets mode: +v dstanek | 13:19 | |
| *** topol has joined #openstack-keystone | 13:19 | |
| bknudson | lbragstad_: there's no enabled field in the schema. the enabled data goes in the extra json | 13:23 |
| *** lnxnut has joined #openstack-keystone | 13:26 | |
| *** lnxnut has quit IRC | 13:31 | |
| *** dolphm_503 is now known as dolphm | 13:34 | |
| *** browne has joined #openstack-keystone | 13:40 | |
| dstanek | bknudson: it's like our private nosql database inside our sql database! | 13:40 |
| bknudson | dstanek: it's webscale | 13:41 |
| dstanek | dolphm: nice catch on the import | 13:46 |
| dolphm | dstanek: the same thing resulted in a long convo at some point :P | 13:48 |
| dstanek | dolphm: i would not have even thought of that, but now that i see it... | 13:49 |
| *** saju_m has quit IRC | 13:50 | |
| dstanek | dolphm: i just came across https://review.openstack.org/#/c/75816 and i'm a little sad that we want to use a 409 on a PUT | 13:53 |
| dolphm | dstanek: me too- i think we can safely change that to a 200/201 within the wording of the api compatibility guidelines | 13:54 |
| dstanek | dolphm: the api docs explicitly say 409 | 13:55 |
| dolphm | dstanek: yeah, IIRC it's one of those implementation bugs that made it's way back into the spec | 13:56 |
| dstanek | dolphm: ah, i'd really like to see the POST just take an id and 409, leaving the PUT to just update | 13:57 |
| dolphm | dstanek: i'd rather not use PUTs, unless they're following the actual semantics of PUT (replace) | 13:57 |
| dolphm | dstanek: or create-or-replace | 13:57 |
| dolphm | PUT /domains/my-custom-domain-id | 13:58 |
| dstanek | dolphm: no i agree, that's what i meant - or we can just leave it out since patch is defined | 13:58 |
| *** nkinder_ has quit IRC | 13:59 | |
| dolphm | dstanek: ++ | 14:00 |
| dstanek | dolphm: do we already have code doing real PUTs? | 14:01 |
| *** marcoemorais has joined #openstack-keystone | 14:02 | |
| *** lnxnut has joined #openstack-keystone | 14:02 | |
| dolphm | dstanek: only for role assignments, v3 region creation, and some federation calls (IdP & protocol crud) | 14:02 |
| dolphm | dstanek: regions is a bit more flexible in that it allows... | 14:04 |
| dolphm | auto assigned ID's: POST /v3/regions | 14:04 |
| dolphm | and user-specified ID's: | 14:04 |
| dolphm | PUT /v3/regions/custom-region-id | 14:04 |
| dolphm | POST /v3/regions {"region": {"id": "custom-region-id"} | 14:04 |
| *** lbragstad_ has quit IRC | 14:05 | |
| *** marcoemorais1 has joined #openstack-keystone | 14:05 | |
| dolphm | there's a third combination of method / resource / body it allows, but that's sort of a subtle inconsequential bug in the implementation | 14:05 |
| *** marcoemorais has quit IRC | 14:06 | |
| dstanek | i'm going to submit a review for this to the identity-api | 14:07 |
| dstanek | does this break backward compatibility rules? | 14:07 |
| *** achampion has quit IRC | 14:08 | |
| dolphm | dstanek: nope! i've always wanted user specified ID's across the entire API :) i made sure there was room in the spec for them to be introduced later | 14:08 |
| dolphm | dstanek: the only caveat is that i would raise a 400 if user_specified_id != urllib.quote(user_specified_id), i think? | 14:09 |
| dolphm | especially if you support POST w/ ID's in the body -- it'd be easy to slip in something that's not URL friendly, and not realize it | 14:10 |
| dstanek | why is that? you only want web safe IDs? | 14:10 |
| dstanek | actually the id will have to be something that is path safe anyway | 14:11 |
| dolphm | dstanek: preferably | 14:11 |
| *** gokrokve has joined #openstack-keystone | 14:12 | |
| *** leseb has quit IRC | 14:15 | |
| *** leseb has joined #openstack-keystone | 14:16 | |
| dstanek | dolphm: i haven't looked at the impl yet, but the federation docs imply that it's using PUT as create only | 14:17 |
| dolphm | dstanek: correct - that should be true in the impl as well | 14:17 |
| *** gokrokve has quit IRC | 14:17 | |
| dstanek | what happens if the resource already exists? | 14:18 |
| dolphm | dstanek: L64 https://review.openstack.org/#/c/71353/38/keystone/contrib/federation/routers.py | 14:18 |
| *** KanagarajM__ has quit IRC | 14:20 | |
| *** jraim has quit IRC | 14:22 | |
| *** jraim_ has joined #openstack-keystone | 14:22 | |
| *** topol_ has joined #openstack-keystone | 14:23 | |
| *** stevemar has joined #openstack-keystone | 14:24 | |
| *** ChanServ sets mode: +v stevemar | 14:24 | |
| *** topol has quit IRC | 14:24 | |
| *** topol_ is now known as topol | 14:25 | |
| dstanek | dolphm: this may be an interesting discussion for today's meeting | 14:26 |
| dstanek | dolphm: even though there is room for user specified IDs if we remove PUT or change the semantics to be RESTful i think that's an API change | 14:27 |
| dolphm | dstanek: remove PUT from what? | 14:27 |
| dolphm | dstanek: nothing uses PUT except role assignments and regions in the core API | 14:28 |
| dolphm | dstanek: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#create-region-post-regions | 14:29 |
| dstanek | dolphm: right, in regions | 14:29 |
| dolphm | dstanek: what would you want to change about regions? | 14:29 |
| dstanek | dolphm: removing the 409 conflict | 14:30 |
| dstanek | actually is apparently doesn't 409 right now is 500s - that's what the review is trying to fix | 14:31 |
| *** lnxnut has quit IRC | 14:31 | |
| dolphm | dstanek: i can't find the wiki article at the moment, but we're free to tweak error codes and turn error codes into 200's | 14:32 |
| dolphm | dstanek: but then we can't go back (from 2xx to 4xx, for example) | 14:32 |
| *** marekd|away is now known as marekd | 14:33 | |
| dolphm | so, 500 -> 409 -> 200 would be a valid evolution (if desired) (or we can just skip to the 200) | 14:33 |
| dstanek | dolphm: the thing that worries me isn't just the status code, it's that we'd be updating (replacing) when previously we didn't touch the data | 14:33 |
| dstanek | i'm definitely OK with it if you are :-) | 14:34 |
| dolphm | dstanek: i guess i'm not following... example? | 14:34 |
| *** marcoemorais1 has quit IRC | 14:34 | |
| dstanek | dolphm: i don't have a usecase where this makes sense but right now if you PUT one you get a resource; if you then PUT again to the same URL you are given an error code | 14:35 |
| dstanek | that implies "change your ID and try again" - change it to a 200 may break a user if they actually depend on a failure | 14:36 |
| dstanek | their data would be replace - so two different user picking the same region to create "my-region" | 14:36 |
| dolphm | dstanek: ah, so you're worried about PUT to create-or-replace vs PUT to create-only | 14:37 |
| *** lbragstad has joined #openstack-keystone | 14:38 | |
| dstanek | yes, if should be less of an issue for this because we give a server error code, but i wanted to bring it up | 14:38 |
| dolphm | dstanek: i wonder if there are buggy clients out there that include null or blank ID's in POST requests - we might break them | 14:38 |
| dstanek | with POST we create the ID | 14:40 |
| dstanek | also federation doesn't behave as i expected - http://paste.openstack.org/show/69432/ - the second put() fails with a 409 | 14:41 |
| dolphm | dstanek: yeah - i'd *prefer* a 200, but i could have told you it was a 409 :P | 14:43 |
| dolphm | dstanek: we *could* make that configurable :-/ | 14:43 |
| dolphm | dstanek: allow_replace_on_create or something? | 14:43 |
| dstanek | nah, i think that would make is hard to interoperate on the client side - taking a script designed for CloudA and then pointing it to CloudB | 14:44 |
| *** ayoung has joined #openstack-keystone | 14:45 | |
| *** lnxnut has joined #openstack-keystone | 14:48 | |
| *** lnxnut has quit IRC | 14:48 | |
| dstanek | dolphm: sounds like the right thing to do might be just to make it 409 | 14:49 |
| dolphm | dstanek: i'm fine with that | 14:50 |
| *** nkinder_ has joined #openstack-keystone | 14:52 | |
| *** lnxnut has joined #openstack-keystone | 14:53 | |
| ayoung | arunkant, this is cool https://review.openstack.org/#/c/72026/21 | 14:56 |
| *** gokrokve has joined #openstack-keystone | 15:02 | |
| *** bknudson1 has joined #openstack-keystone | 15:02 | |
| *** bknudson has quit IRC | 15:05 | |
| *** bknudson1 has quit IRC | 15:07 | |
| *** bknudson has joined #openstack-keystone | 15:10 | |
| *** achampion has joined #openstack-keystone | 15:15 | |
| ayoung | tox is hanging again. Specifically, tox -epy27 or tox -edocs both with and with out -r and with and without an existing .tox subdir...-v produces no output. What the Tox? | 15:20 |
| *** david_lyle_ has joined #openstack-keystone | 15:26 | |
| stevemar | ayoung, can you ping pypi? maybe trouble downloading libs? | 15:27 |
| *** david_lyle_ is now known as david_lyle | 15:27 | |
| ayoung | stevemar, I'm running a "watch" on find . -print of the tox dir. They are growing, but slowly | 15:27 |
| ayoung | stevemar, for example | 15:28 |
| ayoung | stevemar, find py27/ -print | wc -l gives 11398 | 15:28 |
| ayoung | its growing by ... I'm guessing one python package ever 4 seconds or so | 15:29 |
| ayoung | Up to 12198 | 15:29 |
| ayoung | I'm running the commands for -epy27 and -edocs in parallel | 15:29 |
| ayoung | stevemar, how big is you .tox/py27? I'd like to know how long I'll be waiting | 15:30 |
| stevemar | ayoung, maybe it's not hanging, just slow? | 15:30 |
| *** marcoemorais has joined #openstack-keystone | 15:30 | |
| stevemar | checking debug directory, its the same as py27 | 15:30 |
| *** david_lyle_ has joined #openstack-keystone | 15:31 | |
| stevemar | ayoung, /opt/stack/keystone/.tox$ find debug/ -print | wc -l | 15:31 |
| stevemar | 7813 | 15:31 |
| stevemar | py27 is 6975 | 15:32 |
| ayoung | wow...much smaller | 15:32 |
| stevemar | thats weird | 15:32 |
| ayoung | and now mine is down to 7761 | 15:33 |
| ayoung | must be some interim processing that gets cleaned up | 15:33 |
| ayoung | this has been my general experience iwth tox, and why I kindof hate it | 15:33 |
| *** marcoemorais1 has joined #openstack-keystone | 15:34 | |
| stevemar | ayoung, i guess it's running the tests now | 15:34 |
| ayoung | stevemar, it musrt be. it looks like it is spewing the certificate dumps | 15:35 |
| *** david_lyle has quit IRC | 15:35 | |
| stevemar | yep | 15:35 |
| ayoung | Generating RSA private key, 2048 bit long modulus and so forth | 15:35 |
| *** david_lyle_ is now known as david_lyle | 15:35 | |
| stevemar | so not hanging, just slow | 15:35 |
| ayoung | painfully slow. I've been at this over an hour | 15:35 |
| dolphm | ayoung: i thought you were going to clean up that stdout at some point? | 15:35 |
| *** marcoemorais has quit IRC | 15:35 | |
| ayoung | granted I restarted | 15:35 |
| ayoung | dolphm, right now, it is the only indicator I have that things haven't hung | 15:36 |
| *** david_lyle_ has joined #openstack-keystone | 15:36 | |
| stevemar | ayoung, where does that stuff come from? | 15:37 |
| dolphm | stevemar: keystone.common.cms or keystone.cli, i think | 15:37 |
| ayoung | the pki generation? oneof the setup tests, I think. I haven't looked, but I don't think it was something I wrote....I just remember noticing it at somepoint. | 15:38 |
| ayoung | its probably a side effect of doing a shell out to the openssl commands | 15:38 |
| dstanek | ayoung: those extra files are probably from pip installing | 15:38 |
| *** marcoemorais1 has quit IRC | 15:38 | |
| ayoung | dstanek, yeah, and now I know the high water mark is around 12000 files, and then it curts down to 7K I can keep track of progress. | 15:39 |
| dstanek | when pip installs stuff it extracts the package and deps into venv/build | 15:39 |
| dolphm | stevemar: ayoung: i'm guessing keystone.common.openssl | 15:39 |
| *** david_lyle has quit IRC | 15:39 | |
| ayoung | dolphm, yeah. I want to change how we do certificates anyway. I want to user certmonger, and have it use the selfsign for this use case, or talk to a real CA. But there is something I need to work out in the selfsigned use case first, and haven't gotten to. | 15:40 |
| ayoung | selfsign doesn't generate a CA cert, and I need to test if we can get through the openssl cms call using the same selfsigned cert for both | 15:41 |
| ayoung | (both signing cert and ca cert) | 15:41 |
| ayoung | if so, it means common/openssl can go away | 15:41 |
| *** david-lyle has joined #openstack-keystone | 15:41 | |
| dolphm | just tried to repro, and it appears that keystone is refusing to use my keystone.conf [signing] config | 15:42 |
| dstanek | there was a patch to get rid of that output a while ago, but i don't remember what happened to it | 15:43 |
| dolphm | dstanek: i thought so too | 15:43 |
| dstanek | i think it died because of some subprocess issues | 15:44 |
| ayoung | dolphm, is that the change to use provider instead of the old config value? | 15:45 |
| *** david_lyle_ has quit IRC | 15:45 | |
| ayoung | actually, that should not factor into the generation | 15:45 |
| dolphm | that's weird... pki_setup fails with "EnvironmentError: makedirs('/etc/keystone/ssl/certs'): Permission denied" until i enabled debug+verbose, and then it succeeds | 15:45 |
| dolphm | because it stops trying to wriet to /etc/ and uses my keystone.conf instead | 15:46 |
| ayoung | dolphm, perms on the directory? Did you run it as root before? | 15:46 |
| ayoung | dolphm, sudo and then set the group as a CL option | 15:46 |
| dolphm | ayoung: i din't run it as root, and i don't want it to write to /etc/ | 15:46 |
| dolphm | ayoung: it's also not configured to write to /etc/ | 15:46 |
| ayoung | dolphm, its going to pick up conf from the search paths. I assume you don't have an /etc/keystone/keystone.conf | 15:48 |
| dolphm | ayoung: no i don't, and it otherwise picks up my conf just fine | 15:49 |
| ayoung | strange | 15:49 |
| ayoung | etc is the default, I think | 15:49 |
| ayoung | yeah | 15:50 |
| dolphm | ayoung: i'm using etc in cwd | 15:50 |
| ayoung | /etc/keystone/ssl/private/cakey.pem and so on | 15:50 |
| dolphm | ayoung: but that's *not* where i have keystone.conf configured to put those files | 15:51 |
| dolphm | ayoung: and it's ignoring my conf and trying to write there anyway | 15:52 |
| ayoung | dolphm, I am guessing it is skipping "all" of the config | 15:52 |
| ayoung | try running with pdb. | 15:52 |
| dolphm | ayoung: options like "debug" take effect just fine | 15:52 |
| dolphm | ayoung: http://pasteraw.com/1570jfzh8geg7o5t1yu2ywwkmflcpi1 | 15:53 |
| dolphm | ooh, there is a / i missed in there... | 15:54 |
| dolphm | YAY ayoung: fixed, my fault | 15:55 |
| dolphm | i must have made the exact same mistake twice -- i wiped my keystone.conf and started fresh, made the edits again, and ran into the same outcome | 15:55 |
| ayoung | I noticed that some had etc/ and some /etc/ | 15:56 |
| ayoung | I was still checking the openssl code to make sure it wasn't something we were doing | 15:56 |
| ayoung | anyway... dolphm that is what certmonger should be doing for us | 15:56 |
| ayoung | OK...let me try this | 15:56 |
| *** devlaps has joined #openstack-keystone | 15:58 | |
| stevemar | is there a reason why we call our own utils here: https://github.com/openstack/keystone/blob/master/keystone/policy/backends/rules.py#L56.L58 instead of https://github.com/openstack/keystone/blob/master/keystone/openstack/common/policy.py#L196.L212 ? | 16:08 |
| ayoung | ok, it works....I'll write it up | 16:08 |
| ayoung | stevemar, probably just has not been updated...but I want to move that logic to the client anyway | 16:16 |
| dolphm | stevemar: no - i don't think that existed at the time | 16:17 |
| *** thedodd has joined #openstack-keystone | 16:20 | |
| *** thedodd has quit IRC | 16:20 | |
| stevemar | dolphm, hopefully unrelated, but was there a change that added a whole lot more to stdout when running tests? i'm getting a lot of db setup related stuff at the beginning http://paste.openstack.org/show/69466/ | 16:22 |
| dstanek | stevemar: you get the output even when all of your tests pass? | 16:24 |
| stevemar | dstanek, the tests are still running, i'm running all of them | 16:25 |
| dstanek | stevemar: ping me tomorrow when their done running :-) | 16:25 |
| stevemar | dstanek, hehe, few more minutes, test_v3_auth takes a while | 16:26 |
| dolphm | stevemar: hmm, might be oslo.db related? | 16:26 |
| dstanek | stevemar: i usually only get output like that for failing tests | 16:26 |
| dolphm | paste isn't load for me.. | 16:26 |
| stevemar | dolphm, that's what i was thinking | 16:26 |
| dstanek | dolphm: it's just a ton of SQLAlchemy INFO/DEBUG logging | 16:26 |
| stevemar | i have killed paste | 16:26 |
| stevemar | ^^ | 16:27 |
| *** gyee has joined #openstack-keystone | 16:37 | |
| dstanek | dolphm: your crazy fast :-) | 16:39 |
| dolphm | dstanek: ? | 16:39 |
| dstanek | i just saw the email about the 'unimplemented v3 get token' review and when i got to the bug that caused it i saw that it was modified by dolphm 23 seconds ago | 16:40 |
| dolphm | dstanek: ah, i built a dashboard thing to monitor the gate with a raspberry pi | 16:41 |
| dolphm | dstanek: shows failed merges http://i.imgur.com/zGo55Hw.jpg | 16:42 |
| dstanek | dolphm: nice. is that in a shareable state? | 16:43 |
| dolphm | dstanek: not particularly :) but after icehouse releases i'll probably spend another weekend cleaning it up and making it project agnostic | 16:44 |
| dolphm | dstanek: right now it's very much hardcoded to keystone, and i don't have any automated deployment for it | 16:44 |
| dolphm | dstanek: it's basically chrome in kiosk mode + bootstrap + jquery + flask + celery + redis polling zuul, launchpad & gerrit | 16:46 |
| dstanek | dolphm: when you publish let me know so i can saltstack it up and deploy to my pi | 16:49 |
| *** chandankumar_ has joined #openstack-keystone | 16:53 | |
| *** chandan_kumar has quit IRC | 16:54 | |
| dolphm | dstanek: should i keep the ansible playbooks in a separate repo then? :P | 16:57 |
| *** fabiog has joined #openstack-keystone | 17:07 | |
| *** chandankumar_ has quit IRC | 17:10 | |
| *** marcoemorais has joined #openstack-keystone | 17:10 | |
| *** chandan_kumar has joined #openstack-keystone | 17:10 | |
| ayoung | dolphm, morganfainberg_Z the latest Token Revocation Extension review has support for persisted KVS https://review.openstack.org/#/c/55908/56 as it was fairly trivial to implement | 17:14 |
| *** amcrn has joined #openstack-keystone | 17:23 | |
| *** browne has quit IRC | 17:29 | |
| *** marekd is now known as marek|away | 17:32 | |
| *** leseb has quit IRC | 17:39 | |
| *** browne has joined #openstack-keystone | 17:43 | |
| *** richm has joined #openstack-keystone | 17:45 | |
| *** amerine has quit IRC | 17:50 | |
| *** amerine has joined #openstack-keystone | 17:51 | |
| *** fmarco76 has joined #openstack-keystone | 17:53 | |
| *** fmarco76 has left #openstack-keystone | 17:54 | |
| *** harlowja_away is now known as harlowja | 17:55 | |
| dolphm | bknudson: cc- deprecating XML in keystone, is there a patch for that? or shall i propose one? | 17:56 |
| bknudson | dolphm: I haven't had the time to propose a patch | 17:56 |
| bknudson | so go ahead if you have time | 17:56 |
| *** henrynash has joined #openstack-keystone | 17:58 | |
| *** morganfainberg_Z is now known as morganfainberg | 17:59 | |
| morganfainberg | ayoung, cool | 17:59 |
| ayoung | morganfainberg, yeah, would appreciate it if you bled on it | 18:00 |
| morganfainberg | ayoung, will do today. | 18:00 |
| morganfainberg | ayoung, it'll be about the only upstream thing i can do today (still doing internal things) but I'll hit it right now | 18:00 |
| ayoung | feels silly to switch to #openstack-meeting | 18:00 |
| * dolphm yay, blood | 18:00 | |
| morganfainberg | well post meeting that is | 18:00 |
| dolphm | ayoung: it generates meeting summaries *shrug* | 18:00 |
| morganfainberg | we could just add the meetbot to this channel :P | 18:01 |
| ayoung | yeah...its all good, and it gives us a reason to bug people to get off our lawn | 18:01 |
| morganfainberg | >.> | 18:01 |
| morganfainberg | GET OFF OUR LAWN | 18:01 |
| ayoung | its time, right? | 18:01 |
| morganfainberg | aye | 18:01 |
| *** topol has quit IRC | 18:02 | |
| *** gokrokve has quit IRC | 18:03 | |
| *** david_lyle_ has joined #openstack-keystone | 18:03 | |
| *** david_lyle_ is now known as david_lyle | 18:04 | |
| *** david-lyle has quit IRC | 18:07 | |
| *** nkinder_ has quit IRC | 18:07 | |
| *** arunkant has quit IRC | 18:07 | |
| *** arunkant has joined #openstack-keystone | 18:08 | |
| *** bvandenh has quit IRC | 18:12 | |
| *** nkinder has joined #openstack-keystone | 18:15 | |
| *** henrynash has quit IRC | 18:20 | |
| *** achampion has quit IRC | 18:22 | |
| *** chandan_kumar has quit IRC | 18:22 | |
| *** chandankumar_ has joined #openstack-keystone | 18:22 | |
| *** achampion has joined #openstack-keystone | 18:23 | |
| *** thedodd has joined #openstack-keystone | 18:30 | |
| *** chandankumar_ has quit IRC | 18:30 | |
| *** chandan_kumar has joined #openstack-keystone | 18:31 | |
| *** devlaps1 has joined #openstack-keystone | 18:32 | |
| *** gokrokve has joined #openstack-keystone | 18:33 | |
| *** devlaps has quit IRC | 18:33 | |
| *** browne has quit IRC | 18:36 | |
| *** jamielen- has joined #openstack-keystone | 18:39 | |
| *** leseb has joined #openstack-keystone | 18:40 | |
| *** jamielennox has quit IRC | 18:42 | |
| *** leseb has quit IRC | 18:45 | |
| *** browne has joined #openstack-keystone | 18:46 | |
| ayoung | last summits etherpads https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads#Keystone | 19:01 |
| ayoung | we don't need refactoring assingments | 19:01 |
| ayoung | Fedrated one session this time, I think | 19:01 |
| morganfainberg | nope | 19:01 |
| morganfainberg | yeah | 19:01 |
| dolphm | jamielen-: i was hoping the sdk meeting would be moved to today.. | 19:01 |
| ayoung | I want to propose on one on "distributing policy files" | 19:01 |
| gyee | ayoung, we need to discuss the signature stuff, ec2, s3, etc | 19:01 |
| stevemar | ayoung, yep, 1 session | 19:01 |
| dolphm | ayoung: GET /v3/policies | 19:02 |
| gyee | especially for ec2, scoping a key to a trust seem like a bad idea | 19:02 |
| jamielen- | dolphm: i think in general it is but they were skipping this week - i don't know why | 19:02 |
| ayoung | gyee, how about a crypto session? | 19:02 |
| dolphm | ayoung: it just needs to be implemented in oslo policy :) | 19:02 |
| morganfainberg | i would like to make sure we touch on performance et al, but not as an official session, unconference/dev lounge stuff | 19:02 |
| gyee | ayoung, sure, krypto | 19:02 |
| *** jamielen- is now known as jamielennox | 19:02 | |
| *** ChanServ sets mode: +v jamielennox | 19:02 | |
| dolphm | jamielen-: ah, we have a conference going on at rackspace | 19:02 |
| morganfainberg | performance, concurrency, etc | 19:02 |
| dolphm | jamielennox: i was looking forward to it, though | 19:03 |
| gyee | dolphm, which conference? | 19:03 |
| ayoung | dolphm, oslo needs to tell us where to put it, client can fetch it, but endpoint neeeds to know its identity to ask for the right policy file. | 19:03 |
| jamielennox | dolphm: i definetly have some queestions and want to see what's happening with it | 19:03 |
| dolphm | gyee: internal rackspace conference | 19:03 |
| stevemar | gyee rax.io i think? | 19:03 |
| dolphm | stevemar: ++ | 19:03 |
| gyee | ah | 19:03 |
| ayoung | either url or endpouint ID, I'm leaning toward Id | 19:03 |
| jamielennox | bknudson, gyee: can we have another round of auth plugins? i really want to get this figured out before the SDK stuff gathers much more steam | 19:03 |
| ayoung | jamielennox, client....one session or maybe two | 19:04 |
| dolphm | jamielennox: not much - the gate is wedged, that's all i know :P | 19:04 |
| gyee | jamielennox, I was looking at them last night, I am fine with them as long as bknudson go through the spelling and grammars :) | 19:04 |
| jamielennox | ayoung: there will be a lot of cross client stuff this time around | 19:04 |
| gyee | bknudson, sorry man, I was just kidding | 19:04 |
| ayoung | 2 sessions....lets find a way to differentiate them | 19:04 |
| jamielennox | dolphm: yea saw that, but i haven't seen any info coming out from the blueprints or anything either | 19:04 |
| *** alaski has joined #openstack-keystone | 19:05 | |
| alaski | morganfainberg: hi | 19:05 |
| morganfainberg | alaski, is here to talk user_id length changes w/ us! | 19:05 |
| morganfainberg | annd henrynash isn't here | 19:05 |
| dolphm | nice | 19:05 |
| gyee | jamielennox, is there a plan to push the session and httpclient to Oslo? | 19:05 |
| jamielennox | gyee: not oslo, but hopefully somewhere | 19:05 |
| morganfainberg | alaski, so we're proposing a change to increase the length of the user id, user_id@@domain | 19:06 |
| ayoung | I'm here | 19:06 |
| jamielennox | gyee: i would still like a base client library for all this stuf | 19:06 |
| morganfainberg | alaski, this means we will exceed the current UUID length | 19:06 |
| gyee | jamielennox, why not, as we want all the clients to share authentication and session management | 19:06 |
| ayoung | gyee, leave in the keystone client and make everyone bind to the keystoneclient | 19:06 |
| morganfainberg | alaski, not sure if this would cause any issues within nova, quotas, etc | 19:06 |
| jamielennox | gyee: i've been thinking about rewriting the Managers/Resources part of the clients as well | 19:06 |
| gyee | ayoung, right now the stuff is all over the place | 19:06 |
| gyee | I looked at all the clients, they are all doing their own stuff | 19:07 |
| morganfainberg | alaski, i don't remember nova using the userid beyond maybe auditing, but ... we don't want to break things :) | 19:07 |
| jamielennox | gyee: yea, but oslo is copy and paste and that's bad for clients that will often share the same process | 19:07 |
| ayoung | gyee, if we get it right, and solve the compression issue for swift, we should be in good position | 19:07 |
| jamielennox | it means everyone has a copy of the session which is completely wrong | 19:07 |
| morganfainberg | alaski, it's part of https://review.openstack.org/#/c/74214/12 | 19:07 |
| alaski | morganfainberg: what would be the max length of user_id@domain? | 19:07 |
| ayoung | and a security nightmare , jamielennox | 19:07 |
| jamielennox | gyee: yea, i've been going through them as well trying to figure out how much of a problem it will be to convert them | 19:07 |
| alaski | morganfainberg: right now user_id is stored in a varchar(255) in the nova db | 19:07 |
| morganfainberg | alaski, i think we're moving it to varchar(255) | 19:07 |
| dolphm | morganfainberg: we'd be at max 130 chars (64 + 2 + 64), right? | 19:07 |
| jamielennox | gyee: essentially - it's big | 19:07 |
| dolphm | (in terms of an actual migration) | 19:08 |
| ayoung | dolphm, yes | 19:08 |
| ayoung | uuid@@uuid | 19:08 |
| jamielennox | gyee: swift is the most interesting one - python-swiftclient is nothing but a CLI app, there is no library | 19:08 |
| alaski | okay, so that wouldn't involve a migration then. | 19:08 |
| gyee | jamielennox, ayoung, I really think we should push this to Oslo and press others to adopt it | 19:08 |
| dolphm | jamielennox: ? | 19:08 |
| dolphm | jamielennox: i've used the library... | 19:08 |
| alaski | user_id is used to store per user quotas for some resources | 19:08 |
| ayoung | gyee, nah..this way is working...watch | 19:08 |
| ayoung | gyee, https://review.openstack.org/#/c/76109/ | 19:09 |
| alaski | so we'd need to find a way to update those appropriately | 19:09 |
| morganfainberg | yes, we'd move to a varchar 255 https://review.openstack.org/#/c/74214/12/keystone/identity/backends/sql.py (top of new file, line 28) | 19:09 |
| ayoung | alaski, can you bump the size of the field in the DB? | 19:09 |
| jamielennox | dolphm: is it just flat then? | 19:09 |
| morganfainberg | so in theory, nova would need to support the same | 19:09 |
| ayoung | in practice, too | 19:09 |
| jamielennox | i took the fact that there was no class objects to mean they were donig the CLI thing and discovering commands | 19:09 |
| morganfainberg | ayoung, :P | 19:10 |
| morganfainberg | ayoung, in practice i think 130 is the reality | 19:10 |
| morganfainberg | but 255 limit means 255 | 19:10 |
| gyee | jamielennox, take a look at swiftclient/client.py | 19:10 |
| alaski | ayoung: we store it in a varchar(255) already, so a bump isn't needed | 19:10 |
| gyee | get_keystoneclient_2_0 | 19:10 |
| gyee | jamielennox, it just doing import of keystoneclient.v2_0 | 19:11 |
| jamielennox | gyee: hmm, ok, i took the fact that they are recreating a connection on every command if not passed in as evidence that they were doing one off calls | 19:11 |
| morganfainberg | ayoung, so i htinke a ML topic to -dev would be in order for the uid size bump | 19:12 |
| morganfainberg | but my guess is most people are using varchar255 | 19:12 |
| gyee | jamielennox, that's what I meant, if push the stuff to Oslo, it will eliminate these kind of stuff | 19:12 |
| jamielennox | gyee, dolphm: lets go with swift just went way out left field on there client | 19:12 |
| jamielennox | gyee: right, but session and stuff can just be imported from keystone or some other base library | 19:13 |
| alaski | morganfainberg: this will break quotas, though not all of them. we key some of them off of project_id and user_id | 19:13 |
| jamielennox | gyee: but the base client object and stuff can go somewhere | 19:13 |
| gyee | jamielennox, take a look at oslo-incubator/openstack/common/apiclient | 19:14 |
| jamielennox | gyee: i don't particularly want keystoneclient to be the special flower here, other than owning the auth | 19:14 |
| alaski | morganfainberg: we could probably just strip the @domain part for now to keep everything working, but eventually we'd want a better solution | 19:14 |
| jamielennox | gyee: oh - i know it well | 19:14 |
| morganfainberg | alaski, we're not planning on changing existing ids. | 19:14 |
| gyee | we want authentication and session management in there | 19:14 |
| alaski | morganfainberg: oh, excellent | 19:14 |
| jamielennox | gyee: not in oslo | 19:14 |
| morganfainberg | alaski, just making sure new ids are a new format. -- except in an explicit deployer "i want new id format and i use LDAP as the default domain" setup | 19:14 |
| jamielennox | gyee: i want this stuff to be imported once by everyone but not copied around everywhere | 19:15 |
| gyee | jamielennox, sure, just do the import thing in Oslo | 19:15 |
| gyee | def get_session() { from keystonclient import session, ...} | 19:15 |
| jamielennox | gyee: ok, can import from there, just don't have the code live there - for the baseclient sure it can go to oslo | 19:16 |
| gyee | jamielennox, the reason for Oslo is consistency | 19:16 |
| jamielennox | gyee: yes and no - the reason for oslo is at least partially that the projects can still do overrides locally for various oslo bits | 19:17 |
| jamielennox | i don't know if we want that for the clients | 19:17 |
| jamielennox | (beyond normal inheritance) | 19:17 |
| gyee | jamielennox, we can't prevent overrides | 19:18 |
| jamielennox | gyee: i know | 19:18 |
| gyee | we can only educate :) | 19:18 |
| jamielennox | gyee: have you looked through the code in oslo/apiclient? that base client object is kind of a mess | 19:18 |
| gyee | jamielennox, oh yeah, I spent a great deal of time staring at it | 19:20 |
| jamielennox | gyee: so i've been considering the idea of rewriting the Managers, any thoughts? | 19:20 |
| gyee | I understand your pain | 19:20 |
| alaski | morganfainberg: if the new format only applies to new users then everything should be fine with quotas. And everywhere else that user_id is used, except on spot that stores it as a varchar(36). | 19:20 |
| morganfainberg | alaski, ok so we should toss up a ML topic | 19:20 |
| morganfainberg | alaski, and get that one spot fixed | 19:20 |
| gyee | jamielennox, ++, I thought the keystoneclient layering design is awesome! | 19:21 |
| alaski | morganfainberg: yeah. the volume_usage_cache would need updating. | 19:21 |
| gyee | that why I was asking to push the stuff to Oslo | 19:21 |
| jamielennox | gyee: apparently now that KDS, auth plugins, and pecan are stuck on review i need some other completely immovable thing to bang my head against | 19:21 |
| jamielennox | gyee: oh yea, i definetly want to push that to the other clients - it's just whether we'll launch it from oslo or keystoneclient | 19:21 |
| gyee | jamielennox, I am all code review this week! sorry I got stuck in the HP internal stuff the past couple of weeks | 19:22 |
| jamielennox | gyee: nah, it's not stuff that moves very quickly - particularly around feature freeze | 19:22 |
| gyee | yeah, just need to pick our battles, too many changes | 19:23 |
| jamielennox | gyee: i'm not sure exactly what i want to fix yet in managers other than remove passing all those objects being created via **kwargs and build_url | 19:23 |
| gyee | jamielennox, I did a prototype sometime back to do away with all the CRUD managers | 19:25 |
| gyee | have one config file describing the API and the data types | 19:25 |
| jamielennox | gyee: i'd love to see it | 19:25 |
| jamielennox | hmm, not sure about config file - i still think we should do it in code | 19:26 |
| gyee | that way, you can add any API and any attributes | 19:26 |
| jamielennox | but possibly something with a bit more structure to it | 19:26 |
| gyee | by updating the config file | 19:26 |
| gyee | most of the CRUD manager are doing nothing but data type validation | 19:26 |
| gyee | that's pretty much it | 19:26 |
| jamielennox | gyee: i was messing around with the SDK concepts and got as far as: https://github.com/jamielennox/python-mysdk/blob/master/mysdk/api/identity.py | 19:27 |
| jamielennox | gyee: then i started looking at other clients and got disheartened again | 19:27 |
| jamielennox | gyee: agree on the validation - but if you do it via config it means that the user can modify the structure and i don't think thats a good idea | 19:28 |
| jamielennox | keystoneclient version X should support exactly the following things and having people tweak the local config files seems wrong | 19:28 |
| *** marek|away is now known as marekd | 19:29 | |
| gyee | jamielennox, we have a need to support extensions, I was trying to find way to do that without code changes | 19:29 |
| jamielennox | gyee: yea, extensions :( i don't know what to do about that | 19:29 |
| gyee | jamielennox, I was thinking schema discovery | 19:30 |
| gyee | but didn't get very far with it | 19:30 |
| jamielennox | /extensions is dead and i don't know if the clients can really support a full blown manager discovery approach | 19:30 |
| jamielennox | gyee: yea that's tricky | 19:30 |
| morganfainberg | ayoung, dolphm, do you want me to send the email for user_id size increase? | 19:31 |
| jamielennox | gyee: did you read the blog i did on the session object the other day? | 19:31 |
| morganfainberg | ayoung, dolphm, or do we want henrynash ? | 19:31 |
| gyee | jamielennox, not yet, still catching up on my emails | 19:32 |
| ayoung | morganfainberg, my thought is go ahead and send it. | 19:32 |
| jamielennox | gyee: that's ok, you should know most of it anyway - it's just showing examples of how to use the session: http://www.jamielennox.net/blog/2014/02/24/client-session-objects/ | 19:32 |
| jamielennox | (when it's complete) | 19:32 |
| morganfainberg | ayoung, i'll get something sent today. | 19:33 |
| ayoung | cool | 19:33 |
| morganfainberg | i'll tag it as [all] since it's not a keystone issue | 19:33 |
| gyee | jamielennox, like I say, I love the current design | 19:33 |
| morganfainberg | well [all][keystone] | 19:33 |
| jamielennox | gyee: yep, it's giving dtroyer some grief i think and i wanted to get it in front of the SDK guys as well | 19:34 |
| gyee | jamielennox, what part of that design dtroyer doesn't like? | 19:35 |
| ayoung | jamielennox, I think he means the whole auth problem is giving dtroyer grief | 19:37 |
| *** leseb has joined #openstack-keystone | 19:41 | |
| dtroyer | :) mostly I need something that works…ideally the knowledge isn't forced too low in the stack (i think it is again) but I can live with it if we get the next level up right | 19:41 |
| *** leseb has quit IRC | 19:42 | |
| *** leseb_ has joined #openstack-keystone | 19:43 | |
| gyee | dtroyer, all you need is Session right? it pretty does it all | 19:43 |
| gyee | pretty much | 19:43 |
| gyee | version discovery, auth, token management, caching | 19:44 |
| dtroyer | it does too much right now and sounds like folk want it to do more…I want Session to be JUST a wrapper around requests.Session that knows how to the the extra bits we want, ie headers, debug, logging, etc. Maybe the JSON e | 19:45 |
| dtroyer | that is too low for the caching as to do the cache right you have to know something about the data being passes, that isn't a transport layer problem | 19:45 |
| dtroyer | discovery uses Session but also isn't a transport layer problem | 19:45 |
| gyee | I don't view Session as a transport layer | 19:46 |
| jamielennox | dtroyer: i agree on the caching - i don't want that there | 19:46 |
| jamielennox | dtroyer: did you see the blog post i wrote (linked above) | 19:47 |
| dtroyer | I haven't read it all yet, been in DevStack-weekend-catchup mode | 19:47 |
| jamielennox | i don't disagree on the transport level isolation, but i'm fairly convinced that something like the session object is needed | 19:48 |
| gyee | anything in Session is customizable anyway | 19:48 |
| jamielennox | and given that we are 100% on requests now i'm not sure what begin able to swap out a transport layer gives us | 19:48 |
| dtroyer | swap out? ;) I'm on the start-over warpath | 19:48 |
| jamielennox | well what's in session is pretty much a start-over | 19:49 |
| dtroyer | right…now for the next layer up | 19:49 |
| morganfainberg | ayoung, dolphm, sent http://lists.openstack.org/pipermail/openstack-dev/2014-February/028125.html | 19:49 |
| morganfainberg | jamielennox, ^ | 19:49 |
| jamielennox | i was looking at whether i could have a requests transport layer and a httplib transport layer for the swift/cinder guys but i don't think it's worth it | 19:49 |
| morganfainberg | i'm leaving out the deployer choice to change the format for LDAP default domains, that is an exceptional case | 19:50 |
| morganfainberg | s/leaving/left | 19:51 |
| jamielennox | dtroyer: ok so moving up a layer | 19:51 |
| jamielennox | that gets us to the base client object right? | 19:51 |
| jamielennox | dtroyer: i wrote https://github.com/jamielennox/python-mysdk/blob/master/mysdk/api/identity.py yesterday trying to abstract v2 and v3 APIs | 19:52 |
| jamielennox | (it's pretty rough) | 19:52 |
| gyee | jamielennox, line 15-32 is eye sore | 19:53 |
| jamielennox | but from line 70 and 85 i think the baseclient object in keystone is enough | 19:53 |
| jamielennox | gyee: yep, i wanted to see what it would take to completely replace v2_0.client and v3.client | 19:53 |
| jamielennox | the only thing that they did that baseclient didn't was 35-87 and i had to import everything again | 19:54 |
| jamielennox | but yea the imports are exactly what was in v2_0.client and v3.client | 19:54 |
| jamielennox | (also i didn't intend to show this to people yet so it's very rough) | 19:56 |
| gyee | jamielennox, yeah, that prototype won't support extensions | 19:58 |
| jamielennox | gyee: yea, that one i think we don't want to | 19:58 |
| jamielennox | gyee: that was looking specifically at the openstack-SDK effort and whether we can use the existing clients and just have SDK do the abstraction (which i think is the right approach) | 19:59 |
| jamielennox | (though it will take a lot of effort to get the clients to that point) | 19:59 |
| dtroyer | FWIW, there isn't a lot of sympathy for using the existing clients, at least in their current form | 20:00 |
| jamielennox | anything that cannot cross API version boundaries doesn't belong in SDK IMO | 20:00 |
| gyee | dtroyer, you think?!!! :) | 20:00 |
| jamielennox | dtroyer: yea, i know | 20:00 |
| jamielennox | dtroyer: but i really don't like the duplication of effort | 20:00 |
| *** leseb_ has quit IRC | 20:01 | |
| jamielennox | because we will continue to support the python-*clients for a fair while and it means that for every new api we need to add it to both places | 20:01 |
| dtroyer | I don't either, which is one reason I want to use your new lower-level stuff from keystoneclient, I think it can be generalize easily enough to work for all of it | 20:01 |
| jamielennox | yep, my thought was if i can make a good enough baseclient then the SDK will push people towards the session object for there clients | 20:02 |
| dtroyer | but not as an import from ksc, absorb it directly | 20:02 |
| jamielennox | and i think that the base i've got in keystoneclient is pretty good | 20:03 |
| gyee | besides, version discovery, auth, token management, and caching, the CRUD managers are doing just plain data validations | 20:03 |
| jamielennox | dtroyer: i don't like oslo for this, i'd prefer that to be in it's own library - but sure | 20:03 |
| dtroyer | I've already turned it into an sdk-like package (without auth yet through) and it seemed to go well enough | 20:03 |
| dtroyer | not oslo either | 20:03 |
| dtroyer | the SDK is going to be built as a unit with multiple layers (packaging tbd) | 20:04 |
| dtroyer | one of the biggest pain points for any client is the installation nightmare we have now | 20:04 |
| gyee | Oslo is one package | 20:05 |
| dtroyer | actually, it isn't, there are multiple…oslo-incubator is one package, not everything goes through it though | 20:05 |
| gyee | but what is Oslo really, its purpose, is for everything that is common or shared isn't it | 20:06 |
| jamielennox | dtroyer: ++ on installation nightmare, but if we go down that route then we should kill of the python-*clients altogether | 20:07 |
| dtroyer | jamielennox: I want to make the alternative compelling enough that they will die a natural death, pain-free, unlike their users | 20:07 |
| jamielennox | dtroyer: this will mean though that whatever package assumes that umbrella is going to have to take changes for every new API in OpenStack | 20:08 |
| dtroyer | should those projects make that decision, yes. but everyone wants extensions too…that doesn't mean they can't maintain extensions, but on top of a clean base | 20:09 |
| dtroyer | I have a mechanism for anyone to add to OSC just by installing a properly written package | 20:09 |
| dtroyer | so at that level, we are there today | 20:09 |
| jamielennox | dtroyer: right the plugin approach which SDK has decided against | 20:10 |
| dtroyer | however, to push it down into the SDK we need a new mechanism | 20:10 |
| dtroyer | right | 20:10 |
| dtroyer | it needs the same effect but a different process | 20:10 |
| dtroyer | Rax will assure that works | 20:10 |
| dtroyer | the point is that the SDK will have to take on a lot of stuff, the same people can help do the work, but it will be vetted for consistency and sanity across a wider surface than a single project | 20:11 |
| *** leseb has joined #openstack-keystone | 20:13 | |
| jamielennox | dtroyer: do you have any idea what that process is? - i would prefer we didn't rewrite setuptools | 20:14 |
| dtroyer | I think they do plan on not using setuptools, so there needs to be something. I'm not the python guru, gaynor and noller jointly hold that title in that room... | 20:15 |
| dtroyer | entry points are a problem in a number of ways, it totally prevents decent pacakging of OSC for use on, say, windoes | 20:16 |
| jamielennox | dtroyer: yea, one of the writers of the packaging format for python works in my office and he essentially pleaded not to write a competitor | 20:16 |
| dtroyer | jamielennox: I don't want a competitor, but jeez, python packaging makes CPAN look totally sane | 20:17 |
| jamielennox | dtroyer: yea, i know | 20:18 |
| jamielennox | dtroyer: so do you think we drop the 'manager' concept for clients? | 20:19 |
| dolphm | jamielennox: morganfainberg: talking kite in openstack meeting | 20:19 |
| dolphm | TC meeting | 20:19 |
| dtroyer | ah, a better topic! I want to try, I don't think we need both managers and resources to do the pivot | 20:19 |
| dtroyer | and resources can actually be useful, sometimes. thats why the experiment with the object commands. I wanted to do another set with the usual CRUD operations to see how bad it would be | 20:21 |
| dtroyer | but, you know, time and all | 20:21 |
| *** marekd is now known as marekd|email-me | 20:23 | |
| jamielennox | i think the resources are very useful, i would much prefer all these things (resources) to exists as actual objects that you can do some sort of validation of rather than the passing of dicts that we do now | 20:24 |
| jamielennox | however the command objects would appear to work better for the CLI where you are mapping command -> object | 20:24 |
| jamielennox | in the library case the CRUD operations are going to be common for most resources | 20:25 |
| *** theocean154 has joined #openstack-keystone | 20:25 | |
| *** leseb has quit IRC | 20:27 | |
| *** theocean154 has quit IRC | 20:28 | |
| *** theocean154 has joined #openstack-keystone | 20:29 | |
| *** gyee has quit IRC | 20:30 | |
| *** leseb has joined #openstack-keystone | 20:30 | |
| *** alaski has left #openstack-keystone | 20:36 | |
| dtroyer | jamielennox: I think I lost the browser tab with your blog post in it, hit me with the url again please? | 20:42 |
| jamielennox | dtroyer: http://www.jamielennox.net/blog/2014/02/24/client-session-objects/ | 20:42 |
| dtroyer | thanks | 20:42 |
| *** fabiog has quit IRC | 20:50 | |
| *** jraim_ is now known as jraim | 20:56 | |
| ayoung | the automated sample conf file should not be checked into git. Autogenerated files should be autogenerated. Its causing rebase issues on every single one of my patches. Anything that touches config. | 21:01 |
| *** david_lyle is now known as david-lyle | 21:01 | |
| *** thedodd has quit IRC | 21:02 | |
| *** dolphm is now known as dolphm_503 | 21:18 | |
| *** topol has joined #openstack-keystone | 21:19 | |
| *** stevemar has quit IRC | 21:19 | |
| *** thedodd has joined #openstack-keystone | 21:21 | |
| *** chandan_kumar has quit IRC | 21:27 | |
| ayoung | what is that other stuff in tox? like debug helper? And why is there both py27 and venv? Why is sample_config in its own env? | 21:30 |
| *** gyee has joined #openstack-keystone | 21:34 | |
| *** amcrn has quit IRC | 21:40 | |
| *** lnxnut_ has joined #openstack-keystone | 21:48 | |
| *** lnxnut has quit IRC | 21:51 | |
| morganfainberg | simo, ping | 21:52 |
| *** gokrokve_ has joined #openstack-keystone | 21:55 | |
| *** leseb has quit IRC | 21:57 | |
| *** gokrokve has quit IRC | 21:57 | |
| *** theocean154 has quit IRC | 21:57 | |
| *** lnxnut_ has quit IRC | 22:03 | |
| *** lnxnut has joined #openstack-keystone | 22:04 | |
| *** leseb has joined #openstack-keystone | 22:05 | |
| *** lnxnut has quit IRC | 22:08 | |
| simo | morganfainberg: pong | 22:14 |
| *** topol has quit IRC | 22:14 | |
| bknudson | for some reason nova-api gets multiple auth_token token caches. | 22:14 |
| bknudson | so one cache might have the token cached and it works for 5 mins and another doesn't have it cache so the operation fails. | 22:15 |
| bknudson | maybe there's one per "thread" | 22:15 |
| morganfainberg | simo, so i understand your concern about storing plain-text keys, but if I want to extract a hexdigest of the data, why shouldn't that be available w/o having to load everything into hashlib separately? | 22:15 |
| morganfainberg | simo, re https://review.openstack.org/#/c/72259 | 22:15 |
| morganfainberg | simo, perhaps a separate method that does the same thing but is not claiming to be a "secure password hashing"? | 22:16 |
| simo | morganfainberg: it is not really difficult to run a blob of binary data through an hexifier | 22:19 |
| simo | you do not need to use hashlib for that | 22:19 |
| morganfainberg | simo, i just feel that rather than having to do that separately, we already have a mechanism that does in the lib you're relying on | 22:20 |
| simo | I am conservative with crypto stuff | 22:20 |
| simo | this is not necessary, and unnecessary stuff just increase the chances stuff can go wrong | 22:20 |
| simo | more code to review, more bloat, etc... | 22:20 |
| morganfainberg | simo, see i disagree that this here is not needed, adding in a "go make a hex digest" puts that code duplication on the consuming projects | 22:21 |
| morganfainberg | simo, and makes me feel like the provided lib is lacking in some base functionality that the underlying lib provides, why bother using it | 22:21 |
| morganfainberg | simo, /puts on the obnoxious dev hat ;) | 22:22 |
| simo | morganfainberg: and I have actually already been asked why the heck I separated the extract and expand phases in 2 functions, ideally we should think about coalescing them in a single function indeed | 22:22 |
| morganfainberg | simo, see that i would be a different landscape, i'd still argue a "digest" of the data should be available | 22:22 |
| morganfainberg | simo, it's useful functionality. | 22:23 |
| morganfainberg | obv. i can't force ya to accept something like this | 22:23 |
| simo | I do not deny it could be useful to someone | 22:23 |
| simo | morganfainberg: what do you need it for right now ? | 22:23 |
| bknudson | does a token_cache_time of 300 make sense? a token can be valid for 5 mins after it's revoked? | 22:23 |
| morganfainberg | simo, hexdigest of the data for memcache keys, i can't use binary data for the memcache key | 22:24 |
| morganfainberg | simo, and i was aiming to use the lib as a sign/encrypt mechanism for the backend. i wasn't expecting this hexdigest to be used as a key anywhere. | 22:24 |
| morganfainberg | simo, it's related to https://review.openstack.org/#/c/72291/ | 22:24 |
| morganfainberg | simo, so the back-end of a dogpile store can be validated as "good data" or "secure" data. the encryption key separate from the digest used as a cache/storage key for the Key Value Store | 22:25 |
| simo | morganfainberg: you are going to store derived keys in memcached ? | 22:25 |
| morganfainberg | simo, it's strictly as a unique memcache key for looking up the data | 22:26 |
| morganfainberg | simo, a digest of the signed or encrypted data | 22:26 |
| *** lnxnut has joined #openstack-keystone | 22:26 | |
| simo | why don't you just use a hash for that ? | 22:26 |
| simo | why do you need a key derivation function as a key handle ? | 22:26 |
| morganfainberg | simo, your key derivation function is just a hash ;) | 22:26 |
| morganfainberg | simo, and the data was already there. | 22:27 |
| simo | no, not just a hash, a hash with specific properties | 22:27 |
| simo | which is uselessly slow for your use case | 22:27 |
| morganfainberg | simo, in either case doesn't matter. i don't have time to work on this at the moment, i was wondering what your reasoning for not allowing a hexdigest was | 22:28 |
| simo | if you have a real use case I can be convinced to say yes, but you have my opinion above :) | 22:28 |
| morganfainberg | simo, sure. | 22:28 |
| morganfainberg | simo, it was more curiosity than anything else | 22:28 |
| *** marcoemorais has quit IRC | 22:29 | |
| simo | ack | 22:29 |
| *** dolphm_503 is now known as dolphm | 22:29 | |
| *** lbragstad has quit IRC | 22:36 | |
| *** theocean154 has joined #openstack-keystone | 22:39 | |
| morganfainberg | i think we have some potential concerns about the aggregate user_id stuff | 22:41 |
| morganfainberg | on the mailing list. | 22:41 |
| morganfainberg | i think i have all the responses i need but i might want dolphm, henrynash, or ayoung to weigh in as well | 22:42 |
| *** leseb has quit IRC | 22:42 | |
| morganfainberg | and it looks like heat and nova are the only two so far with table column length issues | 22:43 |
| morganfainberg | if someone else doesn't jump on in response, i'll do so later today/tonight | 22:43 |
| *** thedodd has quit IRC | 22:44 | |
| morganfainberg | simo, if i have a better formed use-case i'll let you know when i can circle back on that oslo thing | 22:45 |
| morganfainberg | simo, i might also punt the crypto bit until a second patchset anyway, so i can habe you and other more crypto minded people involved | 22:46 |
| morganfainberg | and less focused on the whole dogpile abstraction bit | 22:46 |
| dolphm | morganfainberg: we might be able to have the best of both worlds, sort of as jay described | 22:55 |
| morganfainberg | dolphm, perhaps | 22:56 |
| dolphm | morganfainberg: uuid.uuid4().hex[:CONFIGURABLE_LEN] + '@@' uuid.uuid4().hex[:CONFIGURABLE_LEN] | 22:56 |
| morganfainberg | dolphm, so always use a UUID and do a mapping table? | 22:56 |
| dolphm | morganfainberg: oh, i just mean provide some means to produce shorter IDs, so the combined UUID ends up being 32 or less | 22:57 |
| morganfainberg | dolphm, because remember, we do things like use bits of a DN for LDAP users | 22:57 |
| dolphm | morganfainberg: or under 64, at least? | 22:57 |
| morganfainberg | dolphm, i dunno if we can do that w/ the LDAP stuff included | 22:57 |
| morganfainberg | dolphm, it's an issue with the differing things each backend provides us | 22:58 |
| dolphm | morganfainberg: yeah, i guess not... | 22:58 |
| morganfainberg | dolphm, if we _always_ used a uuid and did internal mapping (maybe not the best idea?) | 22:58 |
| morganfainberg | dolphm, it becomes a non-issue | 22:59 |
| morganfainberg | but it adds overhead to each lookup | 22:59 |
| dolphm | morganfainberg: absolutely, but it solves the problem with zero impact... | 22:59 |
| morganfainberg | dolphm, ++ | 22:59 |
| dolphm | morganfainberg: and could be cached quite well | 22:59 |
| morganfainberg | dolphm, i'm thinking its likely a way better way. | 22:59 |
| morganfainberg | dolphm, create an internal map that simply says "take ID and get id@@domain" | 23:00 |
| morganfainberg | or well (id, domain) back or some such | 23:00 |
| morganfainberg | old ids can be dn partials or whatever, and we add a mapping bit in the middle | 23:00 |
| dolphm | morganfainberg: when would that table be populated? | 23:00 |
| dolphm | morganfainberg: on auth? | 23:00 |
| dolphm | post- successful auth? | 23:00 |
| morganfainberg | dolphm, on migration for upgrade, for new IDs on auth? | 23:01 |
| morganfainberg | dolphm, it feels icky to hold data about ephemeral users though | 23:01 |
| dolphm | morganfainberg: very... | 23:01 |
| morganfainberg | dolphm, perhaps we can make the map a reversible something or another so ephemeral user comes in, and the unique id (name?) we use + domain can be hashed/unhashed | 23:02 |
| morganfainberg | dolphm, so we can ensure it's always the same? | 23:02 |
| dolphm | morganfainberg: we talked about that... it'd have to be encrypted? | 23:03 |
| dolphm | or b64? | 23:03 |
| morganfainberg | dolphm, hm. b64 i think would be fine in this case | 23:03 |
| morganfainberg | dolphm, for federated users | 23:03 |
| *** marcoemorais has joined #openstack-keystone | 23:03 | |
| dolphm | morganfainberg: are we solving for federation or multildap? | 23:04 |
| morganfainberg | dolphm, both | 23:04 |
| morganfainberg | dolphm, federated would likely need a uid_transform method | 23:04 |
| morganfainberg | but if it was something we could subclass/call based on IDP info | 23:05 |
| morganfainberg | we could do something like uuid for LDAP, and add to the mapping table, and federated does b64 magic? | 23:05 |
| *** openstack has joined #openstack-keystone | 23:05 | |
| morganfainberg | or if is_uuid -> lookup in mapping, if b64 decode? | 23:06 |
| dolphm | morganfainberg: L77 https://review.openstack.org/#/c/71353/42/keystone/auth/plugins/saml2.py | 23:06 |
| morganfainberg | dolphm, aye ok so yes | 23:07 |
| dolphm | morganfainberg: name and, indirectly, ID are entirely defined by the mapping | 23:07 |
| dolphm | morganfainberg: ID = url safe ( name ) | 23:07 |
| morganfainberg | dolphm, alternatively we could b64 ALL new ids instead, and we can decode from that? | 23:08 |
| dolphm | morganfainberg: there's no guarantees as to uniqueness or anything about the name there | 23:08 |
| morganfainberg | dolphm, which is why we'd need something to include IDPID in those cases and be able to decode it | 23:08 |
| morganfainberg | multi-ldap would be eaiser with an internal mapping table, but could be done in the same manner | 23:08 |
| dolphm | morganfainberg: idp id is included in the token, ultimately | 23:08 |
| morganfainberg | dolphm, sure. | 23:09 |
| dolphm | morganfainberg: as is protocol id, but not a reference to the mapping | 23:09 |
| morganfainberg | dolphm, but we need to hold the idpid in the user_id for assignment grant table stuff | 23:09 |
| morganfainberg | etc. | 23:09 |
| morganfainberg | well, effectively | 23:09 |
| morganfainberg | because it needs uniqueness since we already know we can't trust an IDP to provide unique data | 23:09 |
| dolphm | morganfainberg: i really don't want to support user-based role assignments on ephemeral users :( | 23:09 |
| morganfainberg | the whole reason we want to include the idpid on the user_id. | 23:10 |
| morganfainberg | dolphm, i was on board with that, but i thought we lost that argument | 23:10 |
| dolphm | morganfainberg: unless we're just randomly assigning uuid's -- then it's viable but still dumb | 23:10 |
| morganfainberg | dolphm, maybe the way to provide unique IDs is a b64 encode of "name:idpid" basically. | 23:11 |
| dolphm | morganfainberg: i -2'd the two reviews allowing assignments on non-existent users | 23:11 |
| morganfainberg | dolphm, ah ++ cool then | 23:11 |
| dolphm | morganfainberg: (just last week, i think) | 23:11 |
| morganfainberg | dolphm, it would (potentially) work the same for ldap users. | 23:11 |
| morganfainberg | dolphm, multi-ldap that is | 23:11 |
| morganfainberg | if we can guarantee a maximum size of user-id data derived from ldap | 23:12 |
| morganfainberg | and sql is easy, but if it works the same, it keeps thing simple | 23:12 |
| morganfainberg | dolphm, if we can do the user+idp info w/ zero impact to the id field, i'd be happiest (I agree w/ jay/shardy on this) | 23:13 |
| morganfainberg | dolphm, though that we already support 64 and some people are limited to 32, that should be fixed to match what we currently allow as the maximum field size | 23:14 |
| morganfainberg | rather than us truncating down. | 23:14 |
| dolphm | morganfainberg: so, we'd literally have like an 'ephemeral_user' table? with (uuid, source) ? | 23:14 |
| morganfainberg | dolphm, if we used b64, we could do the same id generation and add idp | 23:14 |
| morganfainberg | and it's reversible | 23:15 |
| morganfainberg | dolphm, if we did something like an internal sql, yes. | 23:15 |
| dolphm | morganfainberg: who's limited to 32, btw? | 23:15 |
| *** dstanek has quit IRC | 23:15 | |
| morganfainberg | one table in nova (36?) and heat | 23:16 |
| morganfainberg | https://github.com/openstack/heat/blob/master/heat/db/sqlalchemy/migrate_repo/versions/027_user_creds_trusts.py#L23 | 23:16 |
| morganfainberg | oh | 23:16 |
| morganfainberg | nvm | 23:16 |
| morganfainberg | they are 64 | 23:16 |
| morganfainberg | read comment and didn't read code. comment says 32 is the max size, but they have acolumn at 64 | 23:16 |
| dolphm | len(str(uuid.uuid4())) == 36 | 23:16 |
| morganfainberg | so yeah nova has a single column that is 36 | 23:17 |
| morganfainberg | i'll propose a fix this weekend to solve that | 23:17 |
| morganfainberg | already talked to russtle about that | 23:17 |
| dolphm | morganfainberg: reduce to 32 or increase to 64? | 23:17 |
| morganfainberg | increase to 64 | 23:17 |
| morganfainberg | match our schema | 23:17 |
| dolphm | morganfainberg: why not reduce ours to 32? | 23:18 |
| morganfainberg | or to 255 if we go forward with the current proposed impl for henrynash | 23:18 |
| morganfainberg | dolphm, or if we reduce to 32, we can propose a fix to others | 23:18 |
| dolphm | or 25 if you encode uuid's to base36... or... | 23:18 |
| morganfainberg | i don't care which way, as long as our schema matches the other schemas | 23:18 |
| morganfainberg | if we set a max size of 64, no one should expect less data than that | 23:19 |
| morganfainberg | they should keep it in sync. | 23:19 |
| morganfainberg | we shouldn't be changing it often enouigh to warrant this discussion more than once in a very long time | 23:19 |
| morganfainberg | if ever again | 23:19 |
| dolphm | =) | 23:19 |
| morganfainberg | in fact... | 23:19 |
| morganfainberg | -2 if we ever need to talk about this again for the life of V3 | 23:20 |
| dolphm | lol | 23:20 |
| morganfainberg | dolphm, anyway. the question is... what do we do to uniquely identify a user in a way that we can determine the IDP (federated, multi-ldap, etc) with zero change to our schema | 23:24 |
| morganfainberg | dolphm, is it possible? | 23:24 |
| dolphm | morganfainberg: zero change to API or schema? | 23:24 |
| morganfainberg | dolphm, erm zero change to the maximum user_id length (64) as per our schema | 23:24 |
| morganfainberg | the API, i am assuming, wont care. | 23:25 |
| morganfainberg | the REST api that is | 23:25 |
| dolphm | morganfainberg: identity_api.get_domain_id(user_id) # SELECT domain_id FROM user_domain_map WHERE user_id={user_id}; | 23:27 |
| morganfainberg | dolphm, ok. | 23:28 |
| morganfainberg | dolphm, i'm fine with that | 23:28 |
| morganfainberg | dolphm, do we want this for I? https://review.openstack.org/#/c/74214/ would probably need it | 23:29 |
| dolphm | morganfainberg: i'm not really solving for domain_id vs idp_id though -- do we need to solve for both? | 23:29 |
| morganfainberg | dolphm, we can probably ignore the idp issue.... probably | 23:29 |
| dolphm | morganfainberg: yeah, i think i think it'd be the critical piece to that patch | 23:29 |
| morganfainberg | dolphm, though, i'd rather not have different logic for the two mechanisms | 23:30 |
| *** achampion has quit IRC | 23:30 | |
| dolphm | morganfainberg: right | 23:30 |
| *** theocean154 has quit IRC | 23:35 | |
| *** huats_ has quit IRC | 23:36 | |
| *** david-lyle has quit IRC | 23:38 | |
| dolphm | morganfainberg: want to respond on -dev or shall i? | 23:44 |
| morganfainberg | dolphm, i can respond later tonight but not atm | 23:45 |
| morganfainberg | dolphm, happy to let you respond | 23:45 |
| morganfainberg | dolphm, in the middle of setting up some infrastructure nodes for internal company CI stuff | 23:45 |
| dolphm | morganfainberg: YAY CI | 23:45 |
| morganfainberg | yep | 23:45 |
| dolphm | morganfainberg: i'm about to eat dinner anyway | 23:46 |
| morganfainberg | dolphm, well i'll response to -dev if you haven't once i'm done with this task | 23:46 |
| *** huats has joined #openstack-keystone | 23:54 | |
| *** nkinder has quit IRC | 23:54 | |
| *** browne has quit IRC | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
