| gyee | region, subregion, whatever | 00:00 |
|---|---|---|
| jamielennox | gyee: right, so i've been thinking on subregions and thats where it starts to feel clunky | 00:00 |
| gyee | jamielennox, right, the deployment options various | 00:01 |
| jamielennox | gyee: ok - so what about i take service_type and endpoint= {}? | 00:02 |
| gyee | region, subregion, continent, cell, who know | 00:02 |
| gyee | who knows | 00:02 |
| jamielennox | i just pass endpoint as kwargs through to the catalog | 00:02 |
| jamielennox | or some other way of passing kwargs to get_endpoint | 00:03 |
| gyee | whatever ayoung did for the search_by_tree token revocation, you may get some inspiration there | 00:04 |
| jamielennox | gyee: i like passing service_type and endpoint_type because it lets me do this: https://review.openstack.org/#/c/60752/8/keystoneclient/baseclient.py | 00:04 |
| gyee | though I haven't had time to look at that code yet | 00:04 |
| gyee | jamielennox, service_type, endpoint_type are just attributes are an endpoint | 00:05 |
| gyee | there are others | 00:05 |
| jamielennox | gyee: so i'm not trying to redesign the service catalog at the moment - just allow for future expansion | 00:06 |
| gyee | being able to support a generic filter's going to give us a lot of mileage | 00:06 |
| gyee | jamielennox, you can have a solution without worry about the service catalog | 00:07 |
| gyee | just think abstractly | 00:07 |
| gyee | endpoint = url + attributes | 00:07 |
| jamielennox | right, so abstract is what i'm aiming for | 00:07 |
| jamielennox | and region_name feels clunky | 00:07 |
| gyee | region_name is just another attribute | 00:07 |
| gyee | think of them as attributes | 00:08 |
| jamielennox | what if i changed that whole part then to make request() take an endpoint dict | 00:08 |
| gyee | don't worry the names | 00:08 |
| jamielennox | if dict: pass it off to the plugin and never try to interpret it | 00:08 |
| gyee | sure, they may even use the policy code to do matches | 00:09 |
| gyee | the code we use to do authorization check | 00:09 |
| jamielennox | i think though that in general we should require supporting 'service_type' and 'endpoint_type' and then also allow kwargs | 00:09 |
| gyee | I see them as attributes :) | 00:10 |
| jamielennox | the client will need to know some of this though to be able to make calls so we need to be able to fix on certain attributes | 00:10 |
| gyee | make the client pass a filter | 00:10 |
| gyee | dictionary or whatever | 00:10 |
| jamielennox | i want a keystoneclient to say it needs 'identity' service_type and never have to think about it again | 00:11 |
| gyee | {'serviceType': 'abc', 'attrbitue':'value'} | 00:11 |
| gyee | you just need to do the match | 00:11 |
| jamielennox | is it still valid then to construct that dict from https://review.openstack.org/#/c/60752/8/keystoneclient/baseclient.py | 00:11 |
| gyee | if an endpoint matches the given filter, you found it | 00:11 |
| jamielennox | i can't see why not | 00:12 |
| *** henrynash has quit IRC | 00:12 | |
| gyee | I don't think you want to hardcode service_type and endpoint_type | 00:12 |
| jamielennox | (and i think maybe i just ignore region_name for this patch) | 00:12 |
| gyee | they are just attributes | 00:12 |
| gyee | at the end, its the URL that you need | 00:13 |
| jamielennox | gyee: right, but they are attributes that every client is going to want to set | 00:13 |
| gyee | everything else are there to help you find that url | 00:13 |
| jamielennox | keystoneclient is always going to want to talk to the 'identity' service | 00:13 |
| gyee | not necessary, it the url | 00:14 |
| gyee | call it 'identity' service or whatever, that's not important | 00:14 |
| jamielennox | gyee: i'm all for keeping it flexible but unless we can define some standards for a client to follow no-one will no what to do with an auth_plugin | 00:15 |
| jamielennox | the auth_plugin in use is supposed to be kept abstract from the client | 00:15 |
| *** bknudson has joined #openstack-keystone | 00:16 | |
| jamielennox | so it knows how to ask for certain things, and some things are left up to the plugin's interpretation to use or ignore | 00:16 |
| jamielennox | and possibly endpoint_type falls into that category | 00:16 |
| jamielennox | but if i'm implementing a plugin i need to know the parameters i'm expecting to get from a client so i can make decisions | 00:17 |
| gyee | what is required? | 00:17 |
| gyee | url right | 00:17 |
| gyee | why do you care about the service_type, service_name, region_name, etc | 00:18 |
| gyee | at the end of the day, you want the url can you can talk to some service to do stuff | 00:18 |
| jamielennox | right | 00:18 |
| *** arborism is now known as amcrn | 00:19 | |
| gyee | you just need to figure out a way to find the url based on the attributes | 00:19 |
| jamielennox | right, but so how do you expect a user to provide those attributes? | 00:19 |
| jamielennox | if i create a client i shouldn't need to say keystoneclient.Client(endpoint={'service_type': 'identity', 'endpoint_type': 'public'}) | 00:20 |
| gyee | user of the CLI/client already know that information | 00:20 |
| gyee | operating manual | 00:20 |
| jamielennox | i can override that information for a client sure, but some of that should be set and known | 00:20 |
| jamielennox | because keystoneclient should always want a very similar set of attributes | 00:21 |
| jamielennox | gyee: they don't know service_type and endpoint_type | 00:21 |
| gyee | for UI, that information is in the user's profile most like | 00:21 |
| gyee | most likely | 00:21 |
| jamielennox | that information has always been set by the client | 00:21 |
| gyee | for CLI, that information is probably sitting on a conf file | 00:21 |
| gyee | right, for CLI, just a generic filter, something as simple as "attr=value;attr=value;attr=value" | 00:22 |
| *** david_lyle_ has quit IRC | 00:23 | |
| jamielennox | gyee: so i agree for region name and some general filtering stuff it should be extensible | 00:23 |
| jamielennox | but we still need to optimize this for the keystone auth case | 00:23 |
| jamielennox | and allow a plugin to ignore those attributes if it wants | 00:23 |
| gyee | jamielennox, sure, plugin can manipulate the filter at their discretion | 00:23 |
| jamielennox | gyee: right, and i'm not saying we should ban it outright but there is no point i can see it letting people do keystoneclient.Client(endpoint={'service_type': 'compute'}) | 00:24 |
| jamielennox | it's just going to fail in 99% of cases | 00:24 |
| gyee | why? | 00:25 |
| jamielennox | in what i'm proposing people can still force that by client.service_type = 'compute' | 00:25 |
| jamielennox | because you've pointed a keystoneclient at a nova endpoint | 00:26 |
| gyee | what's the problem? | 00:26 |
| jamielennox | gyee: alright, so i don't disagree with the theory - people can set whatever they like, but we do need the baseclient to be able to set some defaults if present | 00:26 |
| jamielennox | because when people (probably me) implement a new client i want to say | 00:27 |
| jamielennox | class NovaClient: | 00:27 |
| jamielennox | service_type = 'compute' | 00:27 |
| gyee | no default, just a filter should be good enough | 00:27 |
| jamielennox | and never worry about it again | 00:27 |
| jamielennox | gyee: who is setting this filter though? i think it's wrong to be completely set by the user, overridable sure | 00:28 |
| jamielennox | but otherwise you are passing this filter everywhere | 00:28 |
| gyee | jamielennox, you hardcode the service_type, you are at the mercy of the service catalog structure | 00:29 |
| gyee | which may change on you in a hurry | 00:29 |
| gyee | you want to avoid that if you can | 00:29 |
| jamielennox | no, if i hardcode the service_type then i define that a plugin should probably expect that it will receive at least the service_type parameter to a get_endpoint() call | 00:30 |
| jamielennox | how the plugin relates to the service catalog is not a current problem | 00:30 |
| jamielennox | and if we get rid of the service_type then we have bigger architectural problems that the service catalog | 00:30 |
| jamielennox | remember plugins can deal with this information however they see fit, all i'm defining here is what they should expect to receive in a call | 00:31 |
| *** lnxnut has joined #openstack-keystone | 00:32 | |
| jamielennox | how they translate the parameters that i give them into a service catalog or other lookup is not this problem | 00:32 |
| gyee | but you've just demanded that they must provide a service_type | 00:32 |
| jamielennox | the client? | 00:33 |
| gyee | right | 00:33 |
| gyee | sorry, I mean whoever subclass it | 00:33 |
| jamielennox | sure, if they want to use the get_endpoint of a catalog | 00:33 |
| jamielennox | s/catalog/plugin | 00:33 |
| jamielennox | gyee: but this is only relevant to people who are subclassing baseclient - which is going to be openstack clients - who will want to provide a service_type | 00:34 |
| jamielennox | if you are dealing with the session direct then you are free to do whatever you like | 00:34 |
| gyee | right, but they'll have to manipulate the filter | 00:34 |
| gyee | filter + their own service_type | 00:35 |
| jamielennox | sure, they can | 00:35 |
| gyee | so the filter passed in is not exactly the one it will be used | 00:35 |
| jamielennox | gyee: ok, i see your point and i think it's fair to split it like this: | 00:36 |
| jamielennox | session object will take a generic dict that provides the filter | 00:36 |
| jamielennox | baseclient will define a service_type and endpoint_type that are added to the filter | 00:36 |
| jamielennox | this will make development easier for the current client model | 00:36 |
| jamielennox | if service_type and endpoint_type do not fit your design then you are free to leave them as None like the current impl, or simply not subclass baseclient | 00:37 |
| gyee | jamielennox, but there's a problem | 00:37 |
| gyee | what if an endpoint have no service_type or endpoint_type? | 00:37 |
| gyee | they you can support them without code changes | 00:37 |
| gyee | you can't | 00:37 |
| jamielennox | for all current identity.* plugins then that will fail - but that is expected | 00:38 |
| jamielennox | for non-identity plugins then it will make no difference they can use or ignore as they see fit | 00:38 |
| jamielennox | non-identity plugins are under no obligation to even pay attention to the service_type and endpoint_type if it is passed | 00:40 |
| jamielennox | they should perform best effort with what they know | 00:40 |
| gyee | how about this for a compromise | 00:40 |
| gyee | if service_type and endpoint_type are already in the given filter, do override them? | 00:40 |
| gyee | deal? | 00:41 |
| gyee | don't override them I mean | 00:41 |
| jamielennox | gyee: of course | 00:41 |
| gyee | shake on it! | 00:41 |
| jamielennox | that's the way base client works now | 00:41 |
| gyee | :D | 00:41 |
| gyee | U DA MAN! | 00:42 |
| jamielennox | done, i'll do it up as passing a dict and ping you with it | 00:42 |
| gyee | kool | 00:42 |
| jamielennox | do i still call the dict endopint_type? | 00:42 |
| jamielennox | probably endpoint_filter | 00:42 |
| jamielennox | yea | 00:43 |
| gyee | endpoint_filter sound more correct | 00:43 |
| *** theocean154 has quit IRC | 00:47 | |
| *** morganfainberg is now known as morganfainberg_Z | 00:50 | |
| *** dolphm_503 is now known as dolphm | 00:53 | |
| *** morganfainberg_Z is now known as morganfainberg | 01:00 | |
| *** dolphm is now known as dolphm_503 | 01:02 | |
| *** harlowja_away is now known as harlowja | 01:05 | |
| *** henrynash has joined #openstack-keystone | 01:15 | |
| *** gokrokve_ has quit IRC | 01:16 | |
| *** gokrokve has joined #openstack-keystone | 01:16 | |
| *** thedodd has joined #openstack-keystone | 01:19 | |
| *** gokrokve has quit IRC | 01:20 | |
| *** thedodd has quit IRC | 01:22 | |
| henrynash | ayoung: so maybe using a uuid for the domain_id is overkill…we could have a smaller "domain_index" portion (that was a field in the domain table so we could look it up)... | 01:25 |
| *** devlaps1 has quit IRC | 01:26 | |
| *** lnxnut has quit IRC | 01:27 | |
| *** lnxnut has joined #openstack-keystone | 01:27 | |
| ayoung | henrynash, yep | 01:29 |
| *** lbragstad has joined #openstack-keystone | 01:29 | |
| ayoung | henrynash, domain_index | 01:30 |
| henrynash | ayoung: would still mean that the entityID portion is restricted to something less than 64 chars... | 01:30 |
| ayoung | henrynash, I think that is ok | 01:31 |
| henrynash | ayoung: which is find for SQL, but I guess might be a restriction for some LDAP scenarios….but probably not many | 01:31 |
| ayoung | uuid is 32 chars, what do we expect from ldap? | 01:31 |
| ayoung | email address> | 01:31 |
| henrynash | well it depends what they chose…but yes, I'd have thought something like that | 01:31 |
| henrynash | raw DN is prettyyucky | 01:31 |
| *** lnxnut has quit IRC | 01:31 | |
| henrynash | (and I have seen that be more than 64 chars as customer sites anyway…so isn't a good choose today anyway) | 01:32 |
| ayoung | raw DN is out, I think | 01:33 |
| ayoung | I mean, I suggested it at one point and was pretty firmly convinced of the error in my ways | 01:33 |
| henrynash | ayoung: I'm kind of thinking we do it this way with the restriction that LDAP entityIDs are 32 (or maybe even 48) chars…..and if it proves painful we increase the since of the user/group ID fields for Juno | 01:33 |
| henrynash | ayoung: but the concept is the same | 01:33 |
| henrynash | (agreed on DN) | 01:34 |
| henrynash | ayoung: remind me, were we ever going to put the iDP in there as well…or is that tied to the domain? | 01:36 |
| ayoung | henrynash, I was thinking that one IdP could potentially support multiple domains. I want to keep the domain Id in there...but domain_index might be the way to go. | 01:37 |
| henrynash | ayoung: I think you are right that one iDP might support multiple domains…but that would work….the problem would be the other way round if we had multiple iDPs for one domain…THEN you might need the iDP in the user ID | 01:38 |
| ayoung | Nope...not going to support that | 01:38 |
| henrynash | ayoung: ok, we're good in that case | 01:38 |
| ayoung | if a domain is split over multiple IdPs, we treat them as a virtual single IdP. | 01:39 |
| ayoung | just different mechanisms for getting at the same data. Otherwise, they are disjoint user sets, and thus separate domains. Make sense? | 01:39 |
| henrynash | ayuong: I guess the question is, given a user_id do you need to get back to the specific iDP…if so, not sure how this works for domain split over multiple IdPs | 01:40 |
| henrynash | given that you have a domain_id (or index) | 01:41 |
| *** henrynash has quit IRC | 01:53 | |
| *** dolphm_503 is now known as dolphm | 01:55 | |
| *** marcoemorais has quit IRC | 01:57 | |
| *** dolphm is now known as dolphm_503 | 02:00 | |
| *** theocean154 has joined #openstack-keystone | 02:01 | |
| *** gokrokve has joined #openstack-keystone | 02:01 | |
| ayoung | gyee, morganfainberg dstanek_afk should I merge the Revocation patches? | 02:04 |
| ayoung | jamielennox, smae question....do you think I should merge the 3 revoke patches, since sql is kindof baseline, and the matching logic is much different? | 02:11 |
| *** dstanek_afk is now known as dstanek | 02:11 | |
| jamielennox | ayoung, i haven't looked for a few days | 02:11 |
| dstanek | ayoung: which ones are you talking about? all of them? | 02:11 |
| ayoung | dstanek, yeah | 02:12 |
| ayoung | dstanek, specifically, the "revoke by tree" patch replaces all the "matches" logic in model.py | 02:12 |
| ayoung | there were fixdes for the matches logic...but that just gets moved to the tests in revoke by tree as a check on | 02:12 |
| ayoung | dstanek, and the model.py file gets some changes due to the SQL driver using the same set of properties... | 02:14 |
| ayoung | I origianlly split them up thinking that the revoke extension would go in long before the others...that has not happend | 02:14 |
| *** henrynash has joined #openstack-keystone | 02:14 | |
| dstanek | ayoung: i'll take a look; why are you thinking of merging? | 02:16 |
| ayoung | dstanek, due to the things that will change in the first (extension) patch | 02:16 |
| ayoung | dstanek, mostly it is changes to model.py | 02:16 |
| ayoung | dstanek, it might not make much sense to merge now, but the second two patches haven't seen much review since YorikSar joind the revoke by tree (now a coauthor) and lbragstad went over them both | 02:19 |
| gyee | ayoung, I don't have any major objections | 02:20 |
| gyee | will take another look after dinner | 02:20 |
| ayoung | gyee, it will make the rebasing (constant) much simpler, too | 02:20 |
| lbragstad | ayoung: am I +1 on those? | 02:20 |
| lbragstad | I can give it another once over tonight to if it helps | 02:20 |
| ayoung | gyee, BTW< on the "domain_id" it is covered by project_domain_id...I probably should have called it assignment_domain_id | 02:20 |
| ayoung | lbragstad, sure...I don't think you +1ed either | 02:21 |
| ayoung | both have been adjusted since your last review | 02:21 |
| lbragstad | ayoung: ok, I'll give them another pass | 02:21 |
| lbragstad | ayoung: this one https://review.openstack.org/#/c/47441/ and .... | 02:22 |
| ayoung | much obliged....sql and revoke tree should show that they are out of sync due to a repost of the base patch... | 02:22 |
| lbragstad | https://review.openstack.org/#/c/55908/ | 02:22 |
| lbragstad | ? | 02:22 |
| ayoung | lbragstad, no not remember the dn...I think I need to fix that one too | 02:23 |
| lbragstad | ok | 02:23 |
| ayoung | lbragstad, yeah, that one | 02:23 |
| dstanek | ayoung: i don't think it would be bad to merge | 02:23 |
| ayoung | dstanek, ok...I'm going to do it...I'll keep the base commit number | 02:23 |
| lbragstad | it's all the efficient-revocation-check stuff isn't it | 02:25 |
| lbragstad | bp I mean | 02:25 |
| *** richm has quit IRC | 02:25 | |
| ayoung | lbragstad, yeah | 02:34 |
| ayoung | but..they really go together. the revoke check in the base patch is hopelessly naive | 02:35 |
| ayoung | nkinder_, are you still working on https://review.openstack.org/#/c/47441/ Remember the DN? If not, I can take it back and close out on it | 02:39 |
| *** achampion has joined #openstack-keystone | 02:40 | |
| jamielennox | gyee: ok, done: https://review.openstack.org/#/c/60752/ | 02:50 |
| jamielennox | (going for food) | 02:50 |
| nkinder_ | ayoung: I thought you said you were taking it. | 02:53 |
| ayoung | nkinder_, didn't remember...I will | 02:53 |
| nkinder_ | ayoung: ok, I saw you submitted some further patches, but haven't looked at the inline comments | 02:55 |
| ayoung | nkinder_, still working on the revocation events...just merged the 3 patches into one | 02:55 |
| *** david-lyle has joined #openstack-keystone | 03:36 | |
| ayoung | http://blogs.gnome.org/markmc/2014/02/20/naked-pings/ Oh yes.... | 03:36 |
| *** ayoung has quit IRC | 03:57 | |
| gyee | jamielennox, will take a look later, babysitting right now, can barely type with one hand | 04:00 |
| jamielennox | gyee: no problem - just letting you know | 04:00 |
| *** lnxnut has joined #openstack-keystone | 04:29 | |
| *** lnxnut has quit IRC | 05:02 | |
| *** ved_ has joined #openstack-keystone | 05:17 | |
| *** ved_ has quit IRC | 05:40 | |
| *** KanagarajM_ has joined #openstack-keystone | 05:57 | |
| *** andreaf has joined #openstack-keystone | 06:23 | |
| *** saju_m has joined #openstack-keystone | 06:48 | |
| *** marcoemorais has joined #openstack-keystone | 06:48 | |
| *** marcoemorais1 has joined #openstack-keystone | 06:51 | |
| *** dstanek has quit IRC | 06:51 | |
| *** gokrokve has quit IRC | 06:53 | |
| *** marcoemorais has quit IRC | 06:53 | |
| *** chandan_kumar has joined #openstack-keystone | 06:54 | |
| *** gyee has quit IRC | 07:00 | |
| *** theocean154 has quit IRC | 07:01 | |
| *** theocean154 has joined #openstack-keystone | 07:06 | |
| *** topol has quit IRC | 07:17 | |
| *** harlowja is now known as harlowja_away | 07:23 | |
| *** gokrokve has joined #openstack-keystone | 07:23 | |
| *** _ved has joined #openstack-keystone | 07:24 | |
| *** gokrokve_ has joined #openstack-keystone | 07:25 | |
| _ved | Question: In Havana, do other services like nova, neutron & cinder work with Keystone's V3 API? | 07:26 |
| _ved | In other words, can they be configured to use Keystone's V3 API? | 07:26 |
| *** gokrokve has quit IRC | 07:28 | |
| *** theocean154 is now known as tim_ | 07:29 | |
| *** tim_ is now known as tim_p | 07:29 | |
| *** gokrokve_ has quit IRC | 07:30 | |
| *** _ved is now known as ved_ | 07:42 | |
| *** jamielennox is now known as jamielennox|away | 07:43 | |
| *** tim_p has quit IRC | 07:58 | |
| *** ved_ has quit IRC | 08:03 | |
| *** saju_m has quit IRC | 08:10 | |
| *** saju_m has joined #openstack-keystone | 08:11 | |
| *** chandan_kumar has quit IRC | 08:16 | |
| *** jamielennox|away has quit IRC | 08:18 | |
| *** jamielennox|away has joined #openstack-keystone | 08:21 | |
| *** saju_m has quit IRC | 08:25 | |
| *** gokrokve has joined #openstack-keystone | 08:26 | |
| *** saju_m has joined #openstack-keystone | 08:26 | |
| *** chandan_kumar has joined #openstack-keystone | 08:29 | |
| *** gokrokve has quit IRC | 08:30 | |
| *** chandankumar_ has joined #openstack-keystone | 08:32 | |
| *** chandan_kumar has quit IRC | 08:35 | |
| *** amcrn has quit IRC | 08:48 | |
| *** saju_m has quit IRC | 08:52 | |
| *** marekd|away is now known as marekd | 08:56 | |
| *** tim_p has joined #openstack-keystone | 09:15 | |
| *** tim_p has quit IRC | 09:20 | |
| *** gokrokve has joined #openstack-keystone | 09:26 | |
| *** gokrokve has quit IRC | 09:31 | |
| *** andreaf has quit IRC | 09:34 | |
| *** morganfainberg is now known as morganfainberg_Z | 09:43 | |
| *** gokrokve has joined #openstack-keystone | 10:26 | |
| *** gokrokve_ has joined #openstack-keystone | 10:28 | |
| *** gokrokve has quit IRC | 10:31 | |
| *** gokrokve_ has quit IRC | 10:32 | |
| *** saju_m has joined #openstack-keystone | 10:35 | |
| *** tim_p has joined #openstack-keystone | 11:03 | |
| *** marcoemorais has joined #openstack-keystone | 11:04 | |
| *** marcoemorais1 has quit IRC | 11:07 | |
| *** tim_p has quit IRC | 11:08 | |
| *** marcoemorais has quit IRC | 11:09 | |
| *** henrynash has quit IRC | 11:10 | |
| *** KanagarajM_ has quit IRC | 11:17 | |
| *** gokrokve has joined #openstack-keystone | 11:26 | |
| *** gokrokve has quit IRC | 11:31 | |
| *** marcoemorais has joined #openstack-keystone | 11:34 | |
| *** henrynash has joined #openstack-keystone | 11:35 | |
| *** marcoemorais1 has joined #openstack-keystone | 11:35 | |
| *** marcoemorais has quit IRC | 11:36 | |
| *** marcoemorais1 has quit IRC | 11:40 | |
| *** gokrokve has joined #openstack-keystone | 12:26 | |
| *** gokrokve has quit IRC | 12:30 | |
| *** marcoemorais has joined #openstack-keystone | 12:36 | |
| *** marcoemorais has quit IRC | 12:40 | |
| *** tim_p has joined #openstack-keystone | 12:52 | |
| *** saju_m has quit IRC | 12:53 | |
| *** tim_p has quit IRC | 12:57 | |
| *** dstanek has joined #openstack-keystone | 13:05 | |
| *** ChanServ sets mode: +v dstanek | 13:05 | |
| *** dolphm_503 is now known as dolphm | 13:06 | |
| *** david-lyle has quit IRC | 13:16 | |
| *** achampion has quit IRC | 13:20 | |
| *** gokrokve has joined #openstack-keystone | 13:26 | |
| *** dolphm is now known as dolphm_503 | 13:27 | |
| *** gokrokve has quit IRC | 13:30 | |
| *** dolphm_503 is now known as dolphm | 13:31 | |
| *** marcoemorais has joined #openstack-keystone | 13:37 | |
| *** browne has joined #openstack-keystone | 13:37 | |
| *** orion195 has joined #openstack-keystone | 13:40 | |
| orion195 | hy guys | 13:41 |
| orion195 | anyone online for some keystone vs AD integration question? | 13:41 |
| dolphm | orion195: ask away! no promises on useful answers though :P | 13:41 |
| orion195 | dolphm: :) | 13:41 |
| *** marcoemorais has quit IRC | 13:42 | |
| orion195 | I have keystone serving identities | 13:42 |
| orion195 | trough a AD | 13:42 |
| orion195 | I can list users | 13:42 |
| orion195 | I can upload images to glance | 13:42 |
| orion195 | I see the instances and network | 13:42 |
| orion195 | the only think I cannot do is: listing the projects | 13:42 |
| orion195 | in horizon | 13:42 |
| dolphm | orion195: grizzly / havana / master? | 13:43 |
| orion195 | havana, sorry | 13:43 |
| dolphm | orion195: do you have any need to store projects in AD? (you can also store them in SQL) | 13:43 |
| orion195 | sure | 13:43 |
| orion195 | no problem | 13:43 |
| orion195 | just wondering what am I missing | 13:44 |
| orion195 | I sure something is missing from my config | 13:44 |
| dolphm | orion195: i'm guessing there's something wrong with the [ldap] tenant_* config options in your keystone.conf, but... | 13:44 |
| dolphm | orion195: you can also set [assignment] driver to SQL, and then those variables no longer apply | 13:44 |
| orion195 | with my username, I can issue: keystone tenant-list | 13:44 |
| dolphm | orion195: so keystone will use AD for users (and user groups), but that's it | 13:45 |
| orion195 | I do see all the tenants | 13:45 |
| dolphm | orion195: oh okay... but not in horizon? | 13:45 |
| orion195 | no | 13:45 |
| dolphm | orion195: how are you authenticating on the command line? | 13:45 |
| orion195 | I generetad the rc file | 13:45 |
| orion195 | from the dashboard | 13:45 |
| orion195 | I source the .rc | 13:45 |
| orion195 | with OS_USERNAME, OS_PASSWORD | 13:46 |
| dolphm | orion195: what other variables does it set? | 13:47 |
| orion195 | OS_AUTH_URL | 13:47 |
| orion195 | OS_TENANT_ID | 13:47 |
| orion195 | OS_TENANT_NAME | 13:48 |
| orion195 | (IMHO< I should not set OS_TENANT...) | 13:48 |
| dolphm | orion195: you must set either OS_TENANT_ID or _NAME to get authorization | 13:51 |
| dolphm | orion195: or ideally OS_PROJECT_ID / OS_PROJECT_NAME as those _TENANT_ is deprecated | 13:51 |
| dolphm | _TENANT_ variables* | 13:51 |
| orion195 | ok | 13:51 |
| orion195 | cool | 13:51 |
| orion195 | this for the CLI | 13:52 |
| orion195 | what should I set in the horizon then? | 13:52 |
| orion195 | is this: OPENSTACK_KEYSTONE_DEFAULT_ROLE = "member" correct? | 13:52 |
| dolphm | orion195: i'm not sure how horizon uses that | 13:52 |
| orion195 | do you have any ideas on why I cannot list the projects? | 13:53 |
| *** bknudson has quit IRC | 13:57 | |
| orion195 | dolphm: ? :) | 13:59 |
| *** nkinder_ has quit IRC | 13:59 | |
| dstanek | orion195: you can list them throuh the keystone cli, but not through horizon? | 14:05 |
| orion195 | yes | 14:15 |
| orion195 | right | 14:15 |
| *** lbragstad has quit IRC | 14:15 | |
| dstanek | orion195: it sounds like maybe a misconfiguration in horizon? i don't know much about horizon though | 14:16 |
| *** bknudson has joined #openstack-keystone | 14:19 | |
| *** gokrokve has joined #openstack-keystone | 14:26 | |
| *** gokrokve has quit IRC | 14:31 | |
| *** marcoemorais has joined #openstack-keystone | 14:38 | |
| *** lbragstad has joined #openstack-keystone | 14:39 | |
| *** tim_p has joined #openstack-keystone | 14:40 | |
| *** marcoemorais has quit IRC | 14:42 | |
| *** tim_p has quit IRC | 14:45 | |
| marekd | dolphm: https://review.openstack.org/#/c/71353/43/keystone/common/authorization.py wasn't creds['group_ids'] something that might be used in a non-federated use-case in the near future? | 14:48 |
| dolphm | marekd: yeah, i'll reply | 14:51 |
| marekd | dolphm: thanks. | 14:52 |
| dolphm | marekd: done | 14:54 |
| marekd | dolphm: cool! | 14:55 |
| dolphm | marekd: i'm setting up a federated apache server today to test your patch -- any config you can share would be helpful! | 14:55 |
| marekd | dolphm: sure. | 14:55 |
| dstanek | Federated Apache! | 14:55 |
| marekd | BTW - did you have a chance to read my e-mail about securing /auth/tokens with mod_shib ? | 14:55 |
| dolphm | marekd: it sounds like we have to use the original design? | 14:57 |
| *** nkinder_ has joined #openstack-keystone | 14:57 | |
| marekd | dolphm: something like that...at least not /auth/tokens | 14:57 |
| dolphm | marekd: unless ayoung can demonstrate what he's talking about, he doesn't have much of an argument | 14:58 |
| dolphm | marekd: both solutions provide for the same end-user experience AFAICT, so I don't care which we choose as long as it's technically viable... which is why i want to stand up an apache instance today | 14:59 |
| bknudson | even trying to use REMOTE_USER with regular http auth doesn't work with /auth/tokens | 14:59 |
| bknudson | because /auth/tokens is used for more than just getting a token | 15:00 |
| marekd | dolphm: i will look for some configs i was using to setup websso apache. | 15:00 |
| marekd | dolphm: are you going to setup something accessible from the internet or a local apache instance? | 15:01 |
| *** ayoung has joined #openstack-keystone | 15:02 | |
| dolphm | marekd: i'm writing an ansible playbook to deploy to vagrant, so you'll be able to reproduce locally | 15:02 |
| marekd | dolphm: fantastic! | 15:03 |
| *** gokrokve has joined #openstack-keystone | 15:11 | |
| *** gokrokve_ has joined #openstack-keystone | 15:12 | |
| dstanek | dolphm: does this just happen every night? https://review.openstack.org/#/c/64347/ | 15:12 |
| *** browne1 has joined #openstack-keystone | 15:12 | |
| *** lnxnut has joined #openstack-keystone | 15:14 | |
| *** gokrokve has quit IRC | 15:15 | |
| *** dstanek has quit IRC | 15:19 | |
| *** dstanek has joined #openstack-keystone | 15:20 | |
| *** ChanServ sets mode: +v dstanek | 15:20 | |
| *** browne has quit IRC | 15:21 | |
| *** chandankumar_ has quit IRC | 15:21 | |
| *** achampion has joined #openstack-keystone | 15:22 | |
| *** stevemar has joined #openstack-keystone | 15:23 | |
| *** ChanServ sets mode: +v stevemar | 15:23 | |
| *** david-lyle has joined #openstack-keystone | 15:29 | |
| *** chandankumar_ has joined #openstack-keystone | 15:29 | |
| *** richm has joined #openstack-keystone | 15:32 | |
| *** topol has joined #openstack-keystone | 15:35 | |
| orion195 | dolphm: ping | 15:40 |
| orion195 | ping * | 15:40 |
| orion195 | I'm having trouble gettin the corresponding roles out of AD | 15:40 |
| orion195 | my user is admin on the tenant | 15:41 |
| orion195 | and in the AD is also added to the role= _member_ | 15:41 |
| orion195 | unfortunately, once I query the keystone with: keystone user-role-list, I only see the admin account there and not the _member_ | 15:41 |
| richm | help - I keep getting strange db errors from my jenkins run for my commit submission | 15:43 |
| richm | http://logs.openstack.org/02/76002/2/check/gate-keystone-python27/f81a9c8/console.html | 15:43 |
| *** zhiyan has joined #openstack-keystone | 15:43 | |
| richm | 2014-02-27 01:59:42.888 | OperationalError: (OperationalError) unable to open database file None None | 15:43 |
| richm | These errors don't seem to have anything to do with my commit, so I am confused about how to proceed | 15:43 |
| bknudson | richm: for some reason your commit removed keystone/tests/tmp/.gitkeep | 15:45 |
| richm | arg | 15:45 |
| bknudson | which probably causes the tmp directory to not be there | 15:45 |
| richm | because I mounted it as a ramdisk for testing purposes | 15:45 |
| richm | ok | 15:45 |
| richm | so this is another one of those git update-index --assume-unchanged things I need to do | 15:48 |
| bknudson | I usually revert the change after doing the ramdisk | 15:48 |
| richm | I don't suppose there is some way to change the tmp dir without having git involved . . . | 15:49 |
| dolphm | richm: sounds like you used git commit -a and included changes irrelevant to your patch | 15:56 |
| richm | dolphm: probably, yes | 15:56 |
| richm | hmm - doesn't rm automatically stage the deletion? | 15:57 |
| dolphm | richm: git rm or rm? | 15:58 |
| richm | rm | 15:58 |
| dolphm | no | 15:58 |
| richm | ok | 15:58 |
| richm | then I must have done a git commit -a, and will not be so careless in the future | 15:58 |
| bknudson | I usually do a git reset --hard after the ramdisk setup | 15:58 |
| * richm would rather not have to touch any unnecessary files in git . . . | 15:59 | |
| bknudson | our tmp directory should really be /tmp | 15:59 |
| bknudson | not keystone/tests/tmp | 15:59 |
| richm | should be configurable | 15:59 |
| richm | e.g. /dev/shm/keystone-tmp | 15:59 |
| bknudson | an env var or whatever for the directory would work for me. | 16:00 |
| bknudson | the file might be read out of a config file... | 16:01 |
| bknudson | which we shouldn't have all these test config files either. | 16:01 |
| *** nkinder_ has quit IRC | 16:01 | |
| dolphm | i only got as far as wsgi & paste config yesterday, but i'll eventually have a federation branch here https://github.com/dolph/keystone-deploy | 16:03 |
| dolphm | marekd: ^ | 16:03 |
| ayoung | orion195, dolphm is not the LDAP go-to-guy | 16:03 |
| *** nkinder_ has joined #openstack-keystone | 16:03 | |
| ayoung | but I might be able to help, although my AD know-how is limited | 16:03 |
| dolphm | ayoung: ++ | 16:04 |
| orion195 | ayoung: :) | 16:04 |
| orion195 | this is what I followed: http://behindtheracks.com/2014/02/openstack-active-directory-integration/ | 16:04 |
| marekd | dolphm: ack | 16:04 |
| ayoung | orion195, looking | 16:04 |
| orion195 | ayoung: thank you | 16:05 |
| ayoung | orion195, so are you using LDAP for the assignment backend, or are you using SQL? And, if you are Using LDAP, would you be OK with switching over to SQL? | 16:06 |
| ayoung | note...I am talking about leaving users and groups in AD, just the Assignments | 16:07 |
| orion195 | I'm fine using AD only for user/group auth | 16:07 |
| ayoung | cuz...if you are talking to AD, you probably want it in REad only mode | 16:07 |
| orion195 | and I don't want to generate a lot of load on it | 16:08 |
| ayoung | excelleent...so do you have the assignments driver explcictly set to sql? | 16:08 |
| ayoung | [assignment] | 16:08 |
| ayoung | 167 driver = keystone.assignment.backends.sql.Assignment | 16:08 |
| orion195 | mmm ok | 16:09 |
| *** tim_p has joined #openstack-keystone | 16:09 | |
| orion195 | do I have to comment the lines about tenant_tree and role_ ? | 16:09 |
| *** zhiyan has quit IRC | 16:09 | |
| orion195 | ayoung: I have to comment out the sql driver for assignment as now it is comment | 16:09 |
| orion195 | ed | 16:09 |
| ayoung | orion195, ok, once yiou do that, none of the role assignments you set up in LDAP will be in effect. You probably need to use a service token to add a role to your Admin user before you can do anything | 16:10 |
| ayoung | so | 16:10 |
| ayoung | at the top of your comnfig file, you see: | 16:11 |
| *** zhiyan has joined #openstack-keystone | 16:11 | |
| ayoung | [DEFAULT] | 16:11 |
| ayoung | 2 admin_token = freeipa4all | 16:11 |
| ayoung | er | 16:11 |
| ayoung | admin_token = freeipa4all | 16:11 |
| *** tim_p has left #openstack-keystone | 16:11 | |
| ayoung | the freeipa4all is my stock throwaway password | 16:11 |
| ayoung | but usually it is set to a uuid, and then commented out | 16:11 |
| orion195 | I do have the token | 16:11 |
| orion195 | ayoung: just a confirmation: I do have to comment the tenant_tree and role_tree right? | 16:12 |
| ayoung | cool, use that token to assign the admin role to your admin user in some project, and then comment it back out, restart keystone, and restart | 16:12 |
| orion195 | I need to leave commented out only the user_tree | 16:12 |
| ayoung | you do not need to comment the tenete etc data | 16:12 |
| ayoung | it is just ignored | 16:12 |
| orion195 | ah ok | 16:12 |
| ayoung | HTH | 16:12 |
| orion195 | ok doing what you said | 16:12 |
| orion195 | just a sec | 16:12 |
| orion195 | ayoung: ImportError: No module named driver = keystone.assignment.backends.sql | 16:16 |
| orion195 | ah | 16:16 |
| orion195 | mistake, I mispelled it | 16:16 |
| orion195 | ayoung: I didn't mispelled anything, it was correct | 16:17 |
| ayoung | driver = keystone.assignment.backends.sql.Assignment | 16:17 |
| ayoung | orion195, ^^ | 16:17 |
| orion195 | cool | 16:17 |
| orion195 | ok | 16:18 |
| orion195 | I do see now my tenant admin and service admin | 16:18 |
| ayoung | orion195, good to go? | 16:18 |
| orion195 | ayoung: keystone user-role-list returns: 'Client' object has no attribute 'auth_tenant_id' | 16:19 |
| ayoung | orion195, what versions are you running with? | 16:19 |
| orion195 | openstack-keystone-2013.2.2-1.fc20.noarch | 16:20 |
| *** zhiyan has quit IRC | 16:20 | |
| orion195 | just a sec | 16:20 |
| ayoung | orion195, comment out the service token and user username and password like I said earlier: https://lists.launchpad.net/openstack/msg17047.html | 16:20 |
| orion195 | keystone user-role-add --user=myuser --tenant=admin --role=admin | 16:23 |
| orion195 | returned ok | 16:23 |
| orion195 | but: keystone user-role-list, returns: 'Client' object has no attribute 'auth_tenant_id' | 16:23 |
| dolphm | orion195: user-role-list --user=myuser ? | 16:23 |
| orion195 | the same | 16:24 |
| dolphm | all i remember is that call has very strange semantics about what you're asking for, and what it does to get that info | 16:25 |
| dolphm | it's overloaded as both an end-user call and an admin call, and tries to figure out what you actually wanted | 16:25 |
| bknudson | dolphm: got a minute to discuss enabled atttibute in /v3/endpoints? | 16:26 |
| dolphm | bknudson: sure | 16:26 |
| bknudson | dolphm: so my first stab was to do what I thought was the "right" thing to do | 16:26 |
| bknudson | which is, make enabled a real attribute in the model | 16:27 |
| bknudson | rather than storing it in the "extras" | 16:27 |
| dolphm | bknudson: ++ | 16:27 |
| bknudson | ok, so that makes sense, but now we've introduced an incompatibility | 16:27 |
| dolphm | bknudson: ? | 16:27 |
| bknudson | because you could store anything in "enabled" before... | 16:27 |
| bknudson | you could set it to "puppies" if you wanted | 16:27 |
| dolphm | bknudson: ah | 16:27 |
| bknudson | whereas it would be a boolean in db | 16:28 |
| dolphm | bknudson: there's some terrible "guess if this is a boolean or not" code in some migration | 16:28 |
| ayoung | orion195, if yousend in the ENV vars for Service token, I think they take preference. Make sure you unset them, and have it commented out of the config file, so you can't be possibly using the service token by accident | 16:28 |
| *** henrynash has quit IRC | 16:28 | |
| bknudson | dolphm: so one thing I could try -- haven't done this yet -- is do the translation in the controller. | 16:28 |
| dolphm | bknudson: if s.lower()[:1] in ['y', '1', 't'] then endpoint.enabled=True | 16:29 |
| bknudson | do the "guess if it's a boolean" in the controller. | 16:29 |
| dolphm | bknudson: do it in a migration | 16:29 |
| bknudson | dolphm: that's in the migration -- https://review.openstack.org/#/c/75727/3/keystone/common/sql/migrate_repo/versions/041_endpoint_enabled.py | 16:29 |
| orion195 | ayoung: after I assigned the user to admin role | 16:29 |
| bknudson | dolphm: used strutils.bool_from_string(enabled, default=True) | 16:29 |
| orion195 | I have to comment out the ENV var pointing to the SERVICE TOKEN? | 16:29 |
| dolphm | bknudson: there you go | 16:29 |
| bknudson | dolphm: apparently there are tempest tests that pass in different values. | 16:29 |
| dolphm | bknudson: ugh.. like what? | 16:30 |
| bknudson | dolphm: I'll check the logs. I haven't taken a close look yet. | 16:30 |
| dolphm | bknudson: are they actually asserting they can store strings in 'enabled' ? | 16:30 |
| lbragstad | bknudson: this could be another things we could use the jsonschema Validator for... It might take some time to get that working but I suppose we could not your translation so we don't forget to switch it over to validating with jsonschema if that is the route we go? I did some playing with it last night but still have some work to do | 16:31 |
| lbragstad | s/not/note/ | 16:31 |
| bknudson | dolphm: alright, I'm going to look into this more. | 16:32 |
| bknudson | I thought they were passing some different values but maybe not. | 16:32 |
| *** thedodd has joined #openstack-keystone | 16:32 | |
| dolphm | lbragstad: ++ | 16:33 |
| bknudson | so looks like in this case they passed u'True' | 16:33 |
| bknudson | so maybe all we need to do is translate in controller. | 16:33 |
| lbragstad | https://github.com/openstack/nova/blob/master/nova/api/validation/parameter_types.py#L19-L23 | 16:34 |
| *** devlaps has joined #openstack-keystone | 16:34 | |
| bknudson | I don't know how we're going to do input validation in a backwards compatible way | 16:34 |
| bknudson | or how we're going to do input validation when we've got an "extras" column. | 16:34 |
| dolphm | bknudson: fix tempest and return a 400- it's not part of our spec, and our client does the right thing. they shouldn't be asserting misbehavior | 16:35 |
| bknudson | dolphm: alright. | 16:36 |
| orion195 | ayoung: ping | 16:36 |
| ayoung | orion195, http://blogs.gnome.org/markmc/2014/02/20/naked-pings/ | 16:37 |
| orion195 | :) sorry | 16:37 |
| orion195 | I think I'm lost after what you told me | 16:38 |
| ayoung | orion195 | 16:38 |
| ayoung | can you talk to the keystone server using userid/password? | 16:38 |
| orion195 | is unauthorized for tenant admin | 16:40 |
| *** henrynash has joined #openstack-keystone | 16:41 | |
| dolphm | ayoung: need a znc filter for "ping" | 16:42 |
| ayoung | dolphm, nah, we just need to teach people to just say what they want on their first message | 16:43 |
| orion195 | ayoung: you're right :) | 16:43 |
| ayoung | orion195, I could get used to hearing that. | 16:43 |
| orion195 | do you have anything in mind that I should check for this: unauthorized ? | 16:44 |
| dolphm | ayoung: ping | 16:45 |
| dolphm | ayoung: can I ask you a question | 16:45 |
| dolphm | ayoung: can you help with my question? | 16:45 |
| ayoung | dolphm, its twice as annoying as I now have my headphones in, and each "opin" makes a sound effect | 16:46 |
| ayoung | ping: unknown host ayoung | 16:46 |
| orion195 | uhm, I apologized for that, but it seems to be still funny :) | 16:46 |
| dolphm | ayoung: that would be a fun script | 16:47 |
| ayoung | orion195, are you tracking, or are you still stuck? Do you have SERVICE_TOKEN clearly disabled? | 16:48 |
| orion195 | yes, I have it disabled | 16:48 |
| orion195 | the ENV var I have are: OS_TENANT_ID, OS_PASSWORD, OS_AUTH_URL, OS_USERNAME, OS_TENANT_NAME | 16:49 |
| ayoung | and keystont token-get works fine, right? | 16:49 |
| ayoung | keystone token-get works fine, right? | 16:50 |
| orion195 | is unauthorized for tenant admin (HTTP 401) | 16:51 |
| ayoung | orion195, well there you go | 16:53 |
| ayoung | with SERVICE_TOKEN once more enabled, add the admin role to the admin user. | 16:54 |
| orion195 | ok | 16:55 |
| orion195 | I try it | 16:55 |
| orion195 | already has role 830a8384808745599983d34047c86dc4 in tenant 32b45a4fdf5c471a86bd50d27e3278ac (HTTP 409) | 16:56 |
| ayoung | dolphm, so I am discussing with our internal QA how to get them more involved upstream. One thing that has come up is that we use Nitrate for Test planning. https://fedoraproject.org/wiki/Nitrate There doesn't seem to be a way to take what they are doing and make it public without losing a lot of functionality. | 16:58 |
| ayoung | There are some screenshots buried on the fedorahosted site | 16:58 |
| ayoung | https://fedorahosted.org/nitrate/raw-attachment/wiki/WikiStart/Screen%20Shot-Test%20Run.png | 16:59 |
| ayoung | https://fedorahosted.org/nitrate/raw-attachment/wiki/WikiStart/Screen%20Shot-Test%20Plan.png | 16:59 |
| orion195 | ayoung: if you're online tomorrow, we can keep debugging the problem, it's time to leave the office now :) thank you | 16:59 |
| ayoung | orion195, I think you can solve this one yourself. You have the tools now. But feel free to bug me if you are stuck. | 17:00 |
| dolphm | ayoung: rackspace had the same challenge - our QA used their own tooling instead of tempest... the answer was just to contribute to tempest | 17:00 |
| ayoung | dolphm, but tempest is the end product | 17:01 |
| ayoung | before writing the test, they want to make sure they are testing the right thing. | 17:01 |
| ayoung | then end result is that they know exactly what to write when they get there...I had that discussion with them | 17:01 |
| dolphm | ayoung: how does 'nitrate' address that? | 17:02 |
| dolphm | ayoung: that doesn't seem like a problem for more tooling | 17:02 |
| ayoung | dolphm, yeah, I'm not certain that I would have jumped to Nitrate myself, especially for an Open Source proejct, more that the question is "how do we write up test plans" | 17:03 |
| ayoung | they want to say "we are going to run through these steps" to test , say a new blueprint | 17:03 |
| ayoung | going so far as writing code is too much of a commitment | 17:03 |
| ayoung | let me see if I can find a good example | 17:03 |
| ayoung | I'd almost thinkg that they should be blueprints themselves...but the UI there is clunky and also...they would want to link to an existing blueprint | 17:04 |
| ayoung | I have a QA guy working on an RBAC based test case | 17:06 |
| dolphm | ayoung: i know what you mean - it seems fair for tempest blueprints to just cite blueprints in other projects | 17:06 |
| ayoung | yeah. | 17:06 |
| dolphm | ayoung: or write the test plan in a commit message to tempest or something | 17:06 |
| ayoung | dolphm, this has destroyed the formatting, but https://etherpad.openstack.org/p/RBAC_TEST | 17:07 |
| dolphm | ayoung: right, that would be a great docstr in a tempest test | 17:07 |
| dolphm | ayoung: commit message would be less useful in the long run, i take that back | 17:08 |
| ayoung | I would love to be able to link this off the blueprint. | 17:08 |
| ayoung | the blueprint should have a testplan link | 17:08 |
| dolphm | ayoung: blueprints link to commits already | 17:08 |
| ayoung | right...the testplan would be implemented in tempest, though, | 17:09 |
| ayoung | and this would be the planning for the testing...so...maybe we could do it in the spec document? | 17:09 |
| ayoung | Or in the whiteboard? Yuck | 17:09 |
| dolphm | ayoung: right, so write an empty test method (pass) with a test plan in the docstr and keep it as WIP until it's verified as 'the right thing to test' | 17:09 |
| richm | ok - now jenkins pep8 is complaining that I have missing help strings for several config attributes that I didn't touch . . . | 17:10 |
| henrynash | dolphm: see my comment to the dev list on the multi-domain…interested in your view of a 64-bit composite ID (i.e. don't increase the size of the field) vs the mapping table approach | 17:10 |
| ayoung | dolphm, but these are not written by the developer | 17:10 |
| henrynash | dolphmL…err I meant 64-char | 17:10 |
| ayoung | its a different person coming up with the test than the code | 17:11 |
| bknudson | richm: tox -e sample_config | 17:11 |
| henrynash | ayoung: this expands on what we were discussing yesterday | 17:11 |
| dolphm | henrynash: that just seems to be regressing to the same idea we just rejected -- it's fragile and impacts other projects | 17:11 |
| *** marcoemorais has joined #openstack-keystone | 17:12 | |
| henrynash | dolphm: why does it affect other projects | 17:12 |
| dolphm | ayoung: okay.. so? | 17:12 |
| dolphm | henrynash: you're making id's longer, right? | 17:12 |
| ayoung | dolphm, not certain the solution...but if I can fingure it out, I can get out QE much more engaged. | 17:12 |
| henrynash | dolphm: nope | 17:12 |
| ayoung | henrynash, well, yes you are | 17:13 |
| ayoung | even if it still fits in 64 chars, right now they are 32 chars | 17:13 |
| henrynash | ayoung: not if you use the LDAP driver | 17:13 |
| ayoung | but...we never told Nova that they would be 32 chars, and LDAP has already borken that as henrynash | 17:13 |
| ayoung | yes | 17:13 |
| dolphm | henrynash: so morganfainberg_Z's proposal that follow jaypipe's suggestion was to always use UUID's for externally exposed ID's -- the mapping table approach | 17:14 |
| henrynash | ayoung: can't the user chose the ID they want (e.g. email address, CN) | 17:14 |
| dolphm | henrynash: that way nova is not affected, and you can't have 66 char id's, etc | 17:14 |
| henrynash | dolphm: yep, he and I discussed that at length | 17:14 |
| ayoung | dolphm, so nova needs to expand their ID field to 64 chars minimum, or LDAP based IDs are going to break | 17:14 |
| ayoung | UUIDs are...dumb | 17:14 |
| henrynash | dolphm: so nova is broken today, since the default LDAP driver can return more than 32 chards | 17:14 |
| dolphm | whether or not nova migrates to match the length of our varchar ID's shouldn't be a blocker for us | 17:14 |
| ayoung | lets not force that, as we already have moved beyond it in LDAP....which is fairly heavily used as is | 17:15 |
| henrynash | dolphm: nothing to do with multi-backends | 17:15 |
| dolphm | henrynash: i understand | 17:15 |
| ayoung | but...we can put a firm limit on ids at 64 chars, and do the composite approach for multi backends without breaking anything else | 17:15 |
| dolphm | henrynash: fix the problem in keystone by introducing the mapping table, rather than depending on a fix in nova (and then fix nova anyway) | 17:16 |
| ayoung | dolphm, too late | 17:16 |
| dolphm | ayoung: too late for what? | 17:16 |
| ayoung | the userids from Keystone are already exported to Nova | 17:16 |
| ayoung | just thye havn't hit the size limit\ | 17:16 |
| ayoung | we'd have to make everyone currrently using LDAP do a migration across all projects | 17:16 |
| dolphm | ayoung: i understand, so stop emitting those ID's and start using new ones | 17:16 |
| ayoung | tell that to CERN. I'm sure they'd be thrilled | 17:17 |
| dolphm | (side rant- other projects shouldn't track users, at all...) | 17:17 |
| dolphm | (related: keystone shouldn't emit identity information in tokens) | 17:18 |
| henrynash | dolphm, ayoung: IF we go with the mapping table, as dolphm says, we need to fix nova anyway…and for the default driver we would NOT do the mapping (i.e. keep this IDs as they are today) | 17:18 |
| henrynash | dolphm: like the backward_compatible option in the current patch | 17:18 |
| dolphm | henrynash: that sounds like the safest approach | 17:19 |
| ayoung | dolphm, it is a mistake in another way. THe Userid out of LDAP is something that anysystem can query. THe Keystone admin can let the organization know , this is the LDAP query to find a user in LDAP based on their userid. If we do a mapping table in Keystone, they need to lookup the uuid<->mapping in keystone. You've just put keystone in the hot path. And for the autditing of events, it is going to be even more painful. I th | 17:20 |
| ayoung | ink I want to kep the current approach as is. | 17:20 |
| ayoung | lets treat the column size in Nova as a bug to fix, but focus on "64 char limit" as our design constraint | 17:20 |
| dolphm | ayoung: keystone is supposed to be the abstraction layer between openstack and an existing identity system -- you're advocating for that abstraction to leak quite badly | 17:21 |
| ayoung | dolphm, yep. And I am OK with that. THe leak is going to be deployment specific. Nothing we have to support directly, just something we don't want to break. | 17:22 |
| dolphm | ayoung: it's not deployment specific, as you're forcing the leak onto openstack, and other projects naively exploit it | 17:23 |
| dolphm | the leak has nothing to do with LDAP and everything to do with the token architecture | 17:23 |
| ayoung | No...they don't the leak is deplopyment specific as it comes from values specified in the LDAP mapping in the config file. I'm all for information hiding when appropriate, but in this case, it doesn't buy us anything | 17:23 |
| dolphm | ayoung: we're constrained by nova because we're leaking identity information to nova, period | 17:24 |
| ayoung | nothing about this is token architecture. Making the ephemeral users in Keystone has always been a bad idea, and we should not be pushing to that | 17:24 |
| ayoung | dolphm, the API doc says only that Ids are blobs. We've standardized on 64 character max implicitly. Nova has assumed 342 cahr. That is a disconnect. I think we need to make it a hard liomit of 64 chars. | 17:25 |
| *** ayoung is now known as ayoung-lunch | 17:27 | |
| ayoung-lunch | groups is leaving.... | 17:27 |
| ayoung-lunch | I'll be back ina few | 17:27 |
| *** gokrokve_ has quit IRC | 17:37 | |
| *** gokrokve has joined #openstack-keystone | 17:37 | |
| *** gokrokve has quit IRC | 17:41 | |
| bknudson | looks like with the xml serializer you need to do <endpoint enabled='true'> rather than <endpoint><enabled>true</enabled> | 17:53 |
| bknudson | deserializer | 17:53 |
| *** tim_p has joined #openstack-keystone | 18:00 | |
| *** marekd is now known as marekd|away | 18:02 | |
| *** arborism has joined #openstack-keystone | 18:05 | |
| dstanek | bknudson: looking at https://review.openstack.org/#/c/70610/2/keystone/tests/test_wsgi.py again | 18:05 |
| *** arborism is now known as amcrn | 18:05 | |
| dstanek | bknudson: what i was saying is that after the other review goes in you comment is no longer true | 18:05 |
| bknudson | dstanek: I'll try it with the other patch. | 18:06 |
| dstanek | bknudson: it looks like oslo (as we are using it) does two gettext lookups for some of our _() | 18:07 |
| *** arosen has joined #openstack-keystone | 18:07 | |
| bknudson | dstanek: I haven't seen that. | 18:08 |
| dstanek | bknudson: you made a test that proves it :-) | 18:08 |
| bknudson | dstanek: well, it has to do 1 lookup to get the message to be sent back to the user based on their accept-language | 18:09 |
| bknudson | not sure what the other is for. | 18:09 |
| bknudson | I don't have a check that says it's called multiple times. | 18:09 |
| dstanek | bknudson: you don't check for it, but you had to implement two different classes; one for en_US and the other that you actually wanted to test | 18:11 |
| *** tim_p_ has joined #openstack-keystone | 18:11 | |
| dstanek | bknudson: http://git.openstack.org/cgit/openstack/oslo-incubator/tree/openstack/common/gettextutils.py#n168 | 18:11 |
| *** harlowja_away is now known as harlowja | 18:12 | |
| dstanek | if _() is passed just a message id then it does an initial lookup for the default local or en_US (the default) | 18:12 |
| *** tim_p has quit IRC | 18:12 | |
| dstanek | eventually when the string is rendered it does a lookup for local of the user | 18:13 |
| arosen | Hi, I was chatting with dolphm in openstack-dev but figured I should continue the conversation here. | 18:15 |
| arosen | We have the need in neutron to notify nova when certain events occur in neutron for example, something like the instance's port is ready then nova can start the instance. | 18:15 |
| arosen | The problem is if we have multiple nova regions then we need to make sure we send the notification to the right region. I've added code so that nova tells neutron which region each of it's ports are in. Though what I'm trying to avoid is having neturon query keystone for the endpoint for a specific region if i can. | 18:15 |
| arosen | I see that X_SERVICE_CATALOG is include in the header that neutron receives (I hear it's part of the token). I was wondering if relying on this would be okay? | 18:16 |
| arosen | I see that's one can disable this info from coming in which kind of concerns me a little though :/ | 18:16 |
| arosen | Which seems in that case we'd have to query keystone or have the nova regions manually configured in neutron or just says that's not supported. | 18:17 |
| arosen | just wanted to ping the keystone guys to see if you could give me any insight on what's the best approach :) | 18:17 |
| bknudson | dstanek: ok, I think I see... wondering why there's an IdentityTranslator and LangTranslator. | 18:18 |
| bknudson | because apparently it's getting called with a different language then the one we're expecting. | 18:19 |
| bknudson | there's a lot of code involved here. | 18:19 |
| *** tim_p_ has quit IRC | 18:21 | |
| *** tim_p has joined #openstack-keystone | 18:22 | |
| dstanek | bknudson: yeah, Message.__init__ is strange to me | 18:22 |
| bknudson | dstanek: it might get the english language "translation" just to cache it or something. | 18:23 |
| *** bvandenh_ has quit IRC | 18:29 | |
| *** tim_p_ has joined #openstack-keystone | 18:29 | |
| *** tim_p_ has quit IRC | 18:29 | |
| *** gokrokve has joined #openstack-keystone | 18:30 | |
| *** gokrokve has quit IRC | 18:30 | |
| *** gokrokve_ has joined #openstack-keystone | 18:30 | |
| *** tim_p_ has joined #openstack-keystone | 18:30 | |
| *** ayoung-lunch is now known as ayoung | 18:32 | |
| *** tim_p has quit IRC | 18:32 | |
| *** chandan_kumar has joined #openstack-keystone | 18:35 | |
| *** saju_m has joined #openstack-keystone | 18:37 | |
| ayoung | nkinder_, wouldn't hurt for you to re +1 this. https://review.openstack.org/#/c/47441/ | 18:38 |
| nkinder_ | ayoung: checking... | 18:39 |
| nkinder_ | ayoung: sure, I'll look over the changes. What did you change since my patch? | 18:40 |
| ayoung | Not much. Just made one of the suggestions that gyee made. Put the args in a list and iterate through them... Was just outside the code you touched | 18:41 |
| ayoung | also rebased, which was the big thing nkinder_ | 18:41 |
| *** saju_m has quit IRC | 18:41 | |
| *** tim_p has joined #openstack-keystone | 18:43 | |
| *** tim_p_ has quit IRC | 18:47 | |
| *** saju_m has joined #openstack-keystone | 18:51 | |
| henrynash | dolphm: so getting back to the multi-backend and ID question, your view remains that we should use the mapping approach?…and I think your argument is that (although we will have to grandfather in our existing users), keystone should be insulating its clients from the actually underlying identifiers from foreign identity providers (and I include LDAP as such thing in this case) | 18:54 |
| *** tim_p has quit IRC | 18:55 | |
| *** tim_p has joined #openstack-keystone | 18:55 | |
| *** tim_p has quit IRC | 18:59 | |
| *** tim_p has joined #openstack-keystone | 18:59 | |
| *** tim_p has quit IRC | 19:01 | |
| *** ved_ has joined #openstack-keystone | 19:22 | |
| *** chandan_kumar has quit IRC | 19:24 | |
| *** zhiyan_ has joined #openstack-keystone | 19:25 | |
| *** saju_m has quit IRC | 19:35 | |
| *** ved_ has quit IRC | 19:45 | |
| *** chandan_kumar has joined #openstack-keystone | 19:50 | |
| dolphm | henrynash: correct | 19:52 |
| *** mriedem has joined #openstack-keystone | 19:52 | |
| henrynash | dolphm: ok | 19:52 |
| *** devlaps has quit IRC | 19:53 | |
| mriedem | hey keystone people, new gate bug as of 2/23, hitting token fails on cinder and heat APIs, thinking it's a keystone issue if someone could take a look https://bugs.launchpad.net/heat/+bug/1285833 | 19:53 |
| mriedem | i looked at keystone/client commits on 2/23 and nothing really jumps out at me | 19:53 |
| *** jog0 has joined #openstack-keystone | 19:54 | |
| dolphm | ayoung: any chance you landed something that would have caused that recently ^ ? | 19:55 |
| dolphm | mriedem: thanks! | 19:55 |
| dolphm | mriedem: that's an error i've seen before, but not as a transient (usually it's my fault!) | 19:55 |
| mriedem | i'm looking at oslo syncs too | 19:56 |
| ayoung | dolphm, the client lib change? | 19:58 |
| ayoung | dolphm, smells like permissions or SELinux to me | 20:02 |
| *** henrynash has quit IRC | 20:16 | |
| *** dstanek has quit IRC | 20:19 | |
| *** gyee has joined #openstack-keystone | 20:25 | |
| *** mriedem has left #openstack-keystone | 20:28 | |
| *** dolphm is now known as dolphm_503 | 20:56 | |
| *** henrynash has joined #openstack-keystone | 21:10 | |
| *** devlaps has joined #openstack-keystone | 21:13 | |
| *** bknudson has quit IRC | 21:14 | |
| *** dolphm_503 is now known as dolphm | 21:16 | |
| *** gokrokve has joined #openstack-keystone | 21:17 | |
| *** marekd|away is now known as marekd | 21:18 | |
| *** gokrokve_ has quit IRC | 21:20 | |
| *** stevemar has quit IRC | 21:23 | |
| *** bknudson has joined #openstack-keystone | 21:40 | |
| *** marcoemorais has quit IRC | 21:45 | |
| *** chandan_kumar has quit IRC | 21:45 | |
| ayoung | bknudson, meant to send that to you here | 21:48 |
| ayoung | , no, it was not a mistake to merge the Revocation extension...SQL and the revoke by tree code really should go in with it. Also, there were changes being requested in model.py that really were unnecessary, as that code was radically different in the later patches. It was simpler just to merge the three patches into the complete solution. | 21:49 |
| *** lnxnut has quit IRC | 21:51 | |
| *** lnxnut has joined #openstack-keystone | 21:53 | |
| *** lnxnut has quit IRC | 21:54 | |
| *** lnxnut has joined #openstack-keystone | 21:54 | |
| *** jog0 has left #openstack-keystone | 21:55 | |
| *** lnxnut_ has joined #openstack-keystone | 21:58 | |
| richm | did something change in jenkins recently with respect to config checking? I'm wondering why my commit was dinged for not including help strings for use_dumb_member dumb_member user_enabled_mask etc. | 21:58 |
| *** lnxnut has quit IRC | 21:58 | |
| *** morganfainberg_Z is now known as morganfainberg | 22:01 | |
| morganfainberg | henrynash, ++ on that | 22:02 |
| henrynash | morganfainberg: hope to post implementation tomorrow | 22:03 |
| morganfainberg | dolphm, i think i ran across a race in revocation_list cache | 22:03 |
| *** dolphm is now known as dolphm_503 | 22:09 | |
| bknudson | ayoung: ok, I'll start reviewing it again | 22:11 |
| *** ayoung has quit IRC | 22:17 | |
| *** lnxnut_ has quit IRC | 22:24 | |
| *** marcoemorais has joined #openstack-keystone | 22:27 | |
| *** lnxnut has joined #openstack-keystone | 22:29 | |
| *** lnxnut has quit IRC | 22:33 | |
| *** marcoemorais has quit IRC | 22:33 | |
| *** marcoemorais has joined #openstack-keystone | 22:36 | |
| *** achampion has quit IRC | 22:37 | |
| *** lnxnut has joined #openstack-keystone | 22:44 | |
| *** lnxnut has quit IRC | 22:48 | |
| *** dolphm_503 is now known as dolphm | 23:01 | |
| *** lbragstad has quit IRC | 23:14 | |
| richm | should I file a ticket to add the missing help strings? It seems outside the scope of bug/1282676 | 23:14 |
| bknudson | richm: the missing help strings doesn't cause a failure? | 23:15 |
| richm | it causes jenkins pep8 to fail | 23:15 |
| bknudson | when I run pep8 I get some warnings about missing help strings but it doesn't fail | 23:16 |
| richm | - gate-keystone-pep8 http://logs.openstack.org/02/76002/3/check/gate-keystone-pep8/7668ff4 : FAILURE in 3m 40s | 23:16 |
| bknudson | richm: that's failing because "keystone.conf.sample is not up to date." | 23:17 |
| bknudson | the missing help strings aren't causing it to fail | 23:17 |
| bknudson | the diff output is showing what's different between this commit's sample config and the expected one. | 23:17 |
| richm | is it because I manually edited keystone.conf.sample? | 23:17 |
| bknudson | probably | 23:18 |
| morganfainberg | richm, keystone.conf.sample is auto generated and we pep8 validate against it being in sync w/ the options | 23:18 |
| bknudson | use tox -e sample_config to regenerate it | 23:18 |
| morganfainberg | richm, ^ | 23:18 |
| bknudson | and don't edit it by hand. | 23:18 |
| richm | ok - thanks - new commit submitted | 23:19 |
| *** topol has quit IRC | 23:23 | |
| *** dolphm is now known as dolphm_503 | 23:34 | |
| *** browne1 has quit IRC | 23:38 | |
| nkinder_ | richm: looks good so far... | 23:45 |
| *** richm has quit IRC | 23:45 | |
| *** nkinder_ has quit IRC | 23:45 | |
| *** jamielennox|away is now known as jamielennox | 23:46 | |
| *** ChanServ sets mode: +v jamielennox | 23:46 | |
| *** richm has joined #openstack-keystone | 23:47 | |
| *** nkinder_ has joined #openstack-keystone | 23:47 | |
| *** nkinder_ is now known as nkinder | 23:54 | |
| *** nkinder has quit IRC | 23:55 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
