Friday, 2014-10-17

gyeemarekd, ping00:07
*** drjones has joined #openstack-keystone00:15
*** _cjones_ has quit IRC00:17
*** ks-untriaged-bot has joined #openstack-keystone00:29
ks-untriaged-botUntriaged bugs for project keystone:00:29
uvirtbotLaunchpad bug 1381961 in keystone "Keystone API GET 5000/v3 returns wrong endpoint URL in response body" [Undecided,New]00:29
uvirtbotLaunchpad bug 1378270 in keystone "keystone-manage db_sync command failed" [Undecided,Incomplete]00:29
uvirtbotLaunchpad bug 1270378 in keystone "NormalizingFilter performs incorrect validation of PATH_INFO variable" [Undecided,Incomplete]00:29
ks-untriaged-botUntriaged bugs for project python-keystoneclient:00:29
uvirtbotLaunchpad bug 1376937 in keystone "No way to prevent duplicates in endpoints" [Undecided,Confirmed]00:29
uvirtbotLaunchpad bug 1377080 in python-keystoneclient "Stale endpoint selection logic in keystone client" [Undecided,In progress]00:29
uvirtbotLaunchpad bug 1372710 in python-keystoneclient "cfn-push-stats fails to authenticate" [Undecided,Incomplete]00:29
uvirtbotLaunchpad bug 1357567 in python-keystoneclient "auth_ref caching/retrieving is failing - user needs to provide password for every command" [Undecided,New]00:29
*** ks-untriaged-bot has quit IRC00:29
lhchenghi folks!  If I setup ldap as my identity backend, how will keystone authenticate the password of the user logging in?00:34
*** Tahmina has quit IRC00:36
lhchengI see a check_password() in the identity/backend/, but it seems like it is never used.00:36
*** ncoghlan has joined #openstack-keystone00:37
*** drjones has quit IRC00:53
*** _cjones_ has joined #openstack-keystone00:53
*** _cjones_ has quit IRC00:58
openstackgerritLin Hua Cheng proposed a change to openstack/keystone: Remove check_password() in identity.backend.ldap
*** jasondotstar has quit IRC01:17
*** henrynash_ has joined #openstack-keystone01:18
*** henrynash has quit IRC01:21
*** henrynash_ is now known as henrynash01:21
*** zzzeek has quit IRC01:43
*** zzzeek has joined #openstack-keystone01:45
*** diegows has quit IRC01:46
*** marcoemorais has quit IRC01:46
*** richm has quit IRC01:51
*** zzzeek has quit IRC02:00
*** tellesnobrega_ has joined #openstack-keystone02:02
*** zzzeek has joined #openstack-keystone02:02
*** tellesnobrega_ has quit IRC02:02
*** _cjones_ has joined #openstack-keystone02:04
*** _cjones_ has quit IRC02:08
*** ncoghlan is now known as ncoghlan_afk02:13
nkinderlhcheng: keystone performs an LDAP bind to authenticate the user02:14
lhchengnkinder: figured that out after reading the code :)  found some unused code ldap backend02:15
nkinderlhcheng: that horrible code needs to die :)02:15
nkinderlhcheng: there may have been a time where we actually expected to read the has from LDAP and compare it in keystone02:15
nkinderlhcheng: I ripped out some code that would hash the LDAP passwords a while back02:15
nkinderlhcheng: must have missed this code :(02:16
openstackgerritLin Hua Cheng proposed a change to openstack/keystone: Remove check_password() in identity.backend.ldap
nkinderlhcheng: yay!02:17
lhchengtake 2, forgot to remove the unused import02:17
lhchengnkinder: if I want to customize the authentication for ldap identity backend,  to perform auth to another system, do you recommend writing another auth/plugin? or just hack the identity.ldap.authenticate() method?02:19
nkinderlhcheng: what are you authenticating against?02:19
nkinderis this a different auth method against LDAP (like a SASL bind), or something completely different?02:20
lhchengproprietary authentication service, the password is not stored in ldap02:20
*** r-daneel has quit IRC02:21
nkinderlhcheng: so a plug-in seems more appropriate02:22
nkinderlhcheng: I wonder if you could do something like this -
nkinderlhcheng: I'm referring to the WSGI middleware approach at the bottom half of that page02:23
lhchengnkinder: interesting02:25
nkinderlhcheng: there's also a comment about the SQL driver's _check_password() being modeled off of the LDAP code.  I pointed it out in my review of your patch.02:25
nkinderlhcheng: probably should clean that at the same time to prevent further confusion02:26
lhchengwhat would be the advantage using WSGI than implementing auth plugin?02:26
lhchengnkinder: ha! I'll clean that up too02:26
nkinderlhcheng: I'm not sure if there is a big advantage.  It's just another possibility that might be simpler to write?02:27
nkinderlhcheng: I expect more use of external auth via REMOTE_USER going forward02:27
openstackgerritLin Hua Cheng proposed a change to openstack/keystone: Remove check_password() in identity.backend.ldap
nkinderlhcheng: things like mod_auth_kerb and mod_ssl performing auth in httpd and passing it through via REMOTE_USER02:28
nkinderlhcheng: it's similar to mod_shib or mod_auth_mellon doing authentication up front in a way02:28
lhchengnkinder: makes sense, the customization will be cleaner that02:30
*** alex_xu has quit IRC02:31
lhchengnkinder: long term, using apache is the way to run keystone02:32
nkinderlhcheng: ...however, if this is still password based auth, I think a plug-in might be better since you would still perform a token request with the exact same "password" method.02:32
nkinderlhcheng: I guess it depends if you are still just doing password auth against a different source, or if you are using a completely different type of authentication that is not password based.02:33
nkinderlhcheng: and ++ on apache!02:33
lhchengnkinder: yeah, it is still password based02:35
lhchengnkinder: I'll go with the plugin for now then02:35
lhchengnkinder: good stuff!02:36
lhchengnkinder: thanks for the guidance!02:37
*** alex_xu has joined #openstack-keystone02:44
*** stevemar has joined #openstack-keystone02:45
*** harlowja is now known as harlowja_away02:47
*** zzzeek has quit IRC03:00
*** stevemar has quit IRC03:08
*** stevemar has joined #openstack-keystone03:23
*** ncoghlan_afk is now known as ncoghlan03:50
*** swamireddy has joined #openstack-keystone04:11
*** swamireddy has quit IRC04:11
*** saipandi has quit IRC04:15
*** dims_ has quit IRC04:48
*** dims_ has joined #openstack-keystone04:48
*** dims_ has quit IRC04:53
*** _cjones_ has joined #openstack-keystone05:18
*** lhcheng has quit IRC05:25
*** lhcheng has joined #openstack-keystone05:25
*** lhcheng has quit IRC05:30
*** _cjones_ has quit IRC05:37
*** _cjones_ has joined #openstack-keystone05:37
*** gyee has quit IRC05:42
*** lhcheng has joined #openstack-keystone05:48
*** afazekas has joined #openstack-keystone05:50
*** drjones has joined #openstack-keystone05:50
*** _cjones_ has quit IRC05:54
*** drjones has quit IRC05:55
*** stevemar has quit IRC06:08
*** k4n0 has joined #openstack-keystone06:09
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Add max-complexity to pep8 for Keystone
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Add max-complexity to pep8 for Keystone
*** r1chardj0n3s is now known as r1chardj0n3s_afk06:22
*** tellesnobrega has quit IRC06:24
*** amcrn has quit IRC06:39
*** ncoghlan has quit IRC07:27
*** aix has joined #openstack-keystone08:19
*** jistr has joined #openstack-keystone08:24
*** vb has quit IRC08:33
*** vb has joined #openstack-keystone08:34
*** nellysmitt has joined #openstack-keystone08:57
*** lhcheng has quit IRC09:14
*** lhcheng has joined #openstack-keystone09:14
*** alex_xu has quit IRC09:15
*** lhcheng has quit IRC09:18
*** dims_ has joined #openstack-keystone09:27
*** dims_ has quit IRC09:32
*** f13o has quit IRC09:38
*** viklund has quit IRC09:51
*** f13o has joined #openstack-keystone09:56
*** dims_ has joined #openstack-keystone10:02
*** henrynash has quit IRC10:30
*** henrynash has joined #openstack-keystone10:31
*** henrynash has quit IRC10:31
*** nellysmitt has quit IRC11:13
*** nellysmitt has joined #openstack-keystone11:14
*** dims_ has quit IRC11:14
*** dims_ has joined #openstack-keystone11:15
*** dims_ has quit IRC11:18
*** dims_ has joined #openstack-keystone11:19
*** dims_ has quit IRC11:19
*** nellysmitt has quit IRC11:19
*** dimsum_ has joined #openstack-keystone11:19
*** lhcheng has joined #openstack-keystone11:30
*** lhcheng has quit IRC11:34
rodrigodsdolphm, there?11:44
*** raildo_away is now known as raildo11:56
marekdnavid_: o/11:57
rodrigodsmarekd, question for you: in k2k, when I generate the IdP SAML assertion, what is the URL of the SP I send it?12:03
*** vsilva is now known as victsou12:05
*** topol has joined #openstack-keystone12:06
marekdrodrigods: hey, you  check your SP's metadata12:09
marekdand look for one with ECP12:09
marekdit's generally specified by SP12:09
*** packet has joined #openstack-keystone12:10
*** packet has quit IRC12:12
*** topol has quit IRC12:15
rodrigodsmarekd, great, thanks12:16
*** mflobo has joined #openstack-keystone12:16
marekdrodrigods: np.12:19
*** thiagop has joined #openstack-keystone12:24
*** dimsum_ has quit IRC12:28
*** dimsum_ has joined #openstack-keystone12:28
*** g4rg4m3|_ has joined #openstack-keystone12:31
*** packet has joined #openstack-keystone12:38
*** andreaf has quit IRC12:38
*** andreaf has joined #openstack-keystone12:38
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: SAML2 wrapper plugin for full federation authN
*** k4n0 has quit IRC12:55
marekdmhu: looks like i found much easier and cleanerway to overcome out problems with function signatures.12:56
marekdi was so ignorant :-)12:57
mhumarekd, good ol' keyword arguments dict ?13:00
marekdmhu: but used with non keyword arguments.13:03
marekdand then i can mix the order.13:03
mhusmart !13:04
*** diegows has joined #openstack-keystone13:05
*** tellesnobrega has joined #openstack-keystone13:15
*** gordc has joined #openstack-keystone13:18
*** stevemar has joined #openstack-keystone13:18
*** openstackgerrit has quit IRC13:19
*** openstackgerrit has joined #openstack-keystone13:19
*** Kui has quit IRC13:20
marekdstevemar: we have call in ~1.5h, right?13:26
raildoayoung, ping13:29
raildostevemar, we have implemented a solution to revoke tokens if the IdP was deleted, but we have a problem.13:30
raildoFirst we implement the solution in keystoneclient and there we could use the token and get the identity provider.13:30
raildobut ayoung  say to me, that this is the wrong local to implement this.13:31
raildoso we went to implement in keystonemiddleware but never receive the token, only the token_id13:32
*** lhcheng has joined #openstack-keystone13:32
raildoso we can't retrieve the identity provider13:32
ayoungraildo, for UUID tokens revocation has to happen at the Server13:32
stevemarmarekd, yes we do13:34
raildoayoung,  we know but what about PKI? Shouldn't that be in middleware?13:35
stevemarayoung, raildo if the token is UUID the revocation must happen at server, if it's PKI it can happen at middleware?13:35
*** sigmavirus24_awa is now known as sigmavirus2413:36
*** lhcheng has quit IRC13:36
*** r-daneel has joined #openstack-keystone13:37
*** victsou is now known as vsilva13:38
vsilvastevemar, that's where we thought it could, but the middleware doesn't seem to have the token - only the token-id. The solution we discussed here needed the full token to get the IdP from it!13:39
vsilvacan we get that somewhere? I looked into the header but couldn't find it; I think it only gets the token id.13:41
*** vsilva is now known as victsou13:47
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: SAML2 wrapper plugin for full federation authN
marekdmhu: stevemar ^^ what do you think about it?13:51
mhumarekd, I'll have a look ASAP13:52
openstackgerritAlberto Planas proposed a change to openstack/keystone: Adds openSUSE support for developer documentation
stevemarvictsou, is there a way to ask the server for token details, once the middleware has the token-id?13:57
stevemarmarekd, lookin now13:57
stevemarnkinder, ping13:57
raildostevemar, That is our question, and it would not be costly, retrieve the token for every request in middleware.13:59
openstackgerritLance Bragstad proposed a change to openstack/keystone: Remove XML support
rodrigodsmarekd, stuck now with while sending the SAML assertion, when I googled for the error, just found the code that actually raises the exception. Do you have a moment to help me out?14:11
*** radez_g0n3 is now known as radez14:13
*** topol has joined #openstack-keystone14:14
*** saipandi has joined #openstack-keystone14:18
marekdrodrigods: i have ~30 minutes.14:24
marekdrodrigods: did you install pysaml2?14:25
rodrigodsmarekd, thanks... Yes, I have pysaml2 installed14:25
rodrigodsmarekd, sent the request details in pvt14:26
*** tellesnobrega has quit IRC14:27
*** tellesnobrega has joined #openstack-keystone14:28
*** rwsu has joined #openstack-keystone14:31
*** morganfainberg has quit IRC14:32
ayoungraildo, for PKI we are not yet using revocation events.  Until we use revocation events, we need to be able to enumerate the UUIDs from the server14:32
*** nellysmitt has joined #openstack-keystone14:33
ayoungI apologize that I have not been able to get Revocation events in, but my current requirement is sorting out all of the kerberos related issues.14:33
*** morganfainberg has joined #openstack-keystone14:33
ayoungAnd, I kindof think revocation is too complex and error prone,  we should be focused on short lived tokens instead14:34
raildoayoung, ok, but I think we should at least prevent the user from using the token, (we could throw an exception)14:35
ayoungraildo, that is revocation14:36
ayoungraildo, instead, lets get token lifespans down14:36
ayoungand then tokens just expire14:36
ayoung so if an IdP gets deactivated, we do not issue any new tokens for it14:36
ayoungraildo, considering that today, most systems use Memcached to avoid going back to keystone, revocations are kindof a joke anyway14:37
ayoungits part of the reason I've been so unwilling to put any more effort into revocations14:37
*** henrynash has joined #openstack-keystone14:37
*** jorge_munoz has joined #openstack-keystone14:38
raildoayoung, i understand...14:39
raildoayoung, ok, thank you14:39
ayoungraildo, sorry to be such a downer14:39
raildoayoung, no problem, sometimes we need to be :)14:40
ayoungraildo, that being said,   I think I am going to work on the IdP -> domain issue14:46
raildoayoung, great! I believe that would solve some of our problems14:47
ayoungraildo, OK...lets talk through this, then14:47
raildoayoung, sure14:48
stevemarayoung, did nkinder mention anything about improving the mapping function?14:48
ayoungraildo, right now, there is an assumption in Federation mapping that everything goes into the default domain14:48
ayoungstevemar, he and I have talked about it a bit, but I was thinking to have a more in depth discussion with him today14:49
stevemarayoung, cool, cc me when it starts (if it's on irc)14:49
ayoungso, today, there is no real way to disable all of the IdP driven accounts.14:49
ayoungbut...lets say that we fix that:14:50
ayoungfirst off, we specify that an IdP should have a domain associated with it:14:51
ayoungat least one per14:51
ayoungI would suspect that a single IdP would need to have a one-to-many relationship with domains14:51
ayoungstevemar, so domains are a namespace...there really is not a driving need for domains for users,  since usernames from an IdP should be implicitly namespaced but there is for groups.14:55
ayoungbut I think that even the implicit namespacing of users is suspect14:56
ayoungthe current Federation mapping code assumes REMOTE_USER becomes userid.14:56
ayoungAnd REMOTE_USER is set by the SAML configuration14:56
ayoungso, whatever mod_auth_shib  or comparable sets it to be, based on the SAML assertion14:57
*** nkinder has quit IRC15:03
*** tellesnobrega has quit IRC15:14
*** zzzeek has joined #openstack-keystone15:15
morganfainbergrodrigods, raildo, sorry I didn't get to merge forward the topic branch yesterday15:16
rodrigodsmorganfainberg, np15:16
rodrigodsif you could do that today, I'd appreciate15:17
rodrigodsand ask henrynash and gyee to readd their +2 =)15:17
morganfainbergrodrigods, yep, will do. going to first thing15:17
rodrigodsmorganfainberg, ++15:18
morganfainbergayoung, we aren't going to get token lifespan down much tbh in one cycle15:22
morganfainbergayoung, i think we're almost at the limit until we solve a lot of other issues.15:22
henrynashrodigods: what ya need?15:22
morganfainbergayoung, as it is most people i've been talking to have been re-increasing the token life span to ~1440015:23
morganfainbergin real deployments.15:23
morganfainbergand revocations are a real concern to them.15:23
ayoungmorganfainberg, lets fix that15:23
ayoungand they are caching tokens15:24
ayoungand not checking revocations15:24
morganfainbergayoung, they are caching tokens and relying on revocations to work because middleware does the revocation bit15:24
ayoung the "real life" deployments are frightening15:24
ayoungand I don't think we should design with those constraints ignored, but rather design to make those people  have a secure system to work with15:24
morganfainbergayoung, we can't ignore what we've done so far. we hava said "use revocations... we will support them"15:25
ayoungmorganfainberg, are they?  Or arethey running UUID tokens, memcache, and never checking to see if a token is revoked15:25
*** gsilvis has joined #openstack-keystone15:25
morganfainbergayoung, almost *no one* is using memcached in middleware15:25
morganfainbergunless they are running swift15:25
morganfainbergthey have done things like make keystone re-issue tokens with extended lifespans15:26
*** thedodd has joined #openstack-keystone15:26
morganfainbergi've been asked about revocation events for UUID tokens.15:26
morganfainbergso they can use memcached15:26
morganfainbergin short, if we're doing PKI tokens we're still going to need revocation events... if we're doing session tokens we still need to be able to revoke that session token.15:27
ayoungmorganfainberg, how High a priority?15:28
morganfainbergyou know. lets talk more in depth about this at the summit :)15:28
morganfainbergwe have a bunch of sessions / time set aside for it15:28
morganfainbergwe can prioritze correctly then15:28
morganfainbergsee where other things land15:28
*** thedodd has quit IRC15:28
*** thedodd has joined #openstack-keystone15:28
morganfainberglets say "not a priority until we know what the rest of kilo looks like" but definitely on the map.15:28
ayoungmorganfainberg, I can't keep chasing that review15:29
ayoungI had it full green in mid July and it sat there15:29
ayoungraildo, you want your revocation to work?  Get that patch back into shape15:29
morganfainbergayoung, so lets evaluate what things look like at the summit. if we have better options we can chase that, or we can all chip in and make events "complete"15:29
morganfainbergayoung, i'm fine dedicating time to it, but you're right unknown priority until we have a better view of all kilo targets15:30
ayoungmorganfainberg, I can't help but feel like we have things backwards.  When I first approached PKI tokens, I was thinking that we could have a system where the Keystone server could drop off and things would continue to run15:32
ayoungrevocation events implies all of these services getting more and more tied to a single point of failure and  bottleneck15:32
morganfainbergayoung, we've been there a long long long time.15:33
*** lhcheng has joined #openstack-keystone15:33
morganfainbergayoung, did you see joe gordon's service dependency graph?15:33
morganfainberglet me find it15:34
ayoungbut I can imagine what it looks like15:34
*** wwriverrat has joined #openstack-keystone15:34
ayoungeverything depends on Keystone.  Nova depends on cinder, glance, and neutron,  glance depends on swift15:34
ayoungmorganfainberg, what if UUID tokens were trusts?15:35
ayoungwhat's red mean there?15:35
ayounger..nova depends on ironc?  I guess that the colors of the arrows imply something about stage of deployment?15:36
morganfainbergred is a reverse dependency i think15:37
morganfainberglet me 2x check15:37
ayoungeverything depends on Keystone, keystone depends on nothing15:38
morganfainbergred is "depends on" as in can't run w/o15:38
*** lhcheng has quit IRC15:38
morganfainbergand bi-directional15:38
morganfainberge.g. nova needs cinder, and cinder needs nova15:38
morganfainbergor. huh maybe "nova can use" and cinder needs15:39
ayoungcinder needs nova is a scary concept.  Do you the justification for that?15:39
morganfainbergayoung, i think because in "openstack" what is cinder?15:39
morganfainbergi'm not 100% sure tbh15:39
morganfainbergfrom the why does cinder require nova15:40
*** thedodd has quit IRC15:40
ayoungits the block storage service.  It might be useless without Nova, but you could see someone using it directly15:40
ayoungIn fact, I could very much think of use cases for Cinder without Nova in the abstract15:40
ayoungsame with Neutron or Glance for that matter15:40
*** thedodd has joined #openstack-keystone15:40
morganfainbergyou can't attach the volume w/o nova15:40
morganfainbergthis is "openstack specific'15:40
ayoungOnly Nova can attach a volume from Cinder?15:41
morganfainbergred is "depends on", black is "requires", grey is "can use"15:41
morganfainbergin openstack15:41
ayoungMeh,  Nova has an inflated view of its own importance15:41
morganfainbergas in, running an openstack cloud - you need nova to consume cinder for VMs15:41
morganfainbergneutron can't attach a cinder volume to nova15:41
morganfainbergerm to a vm15:42
morganfainbergsimilarly keystone can't.15:42
morganfainbergif you're looking to attach a volume to a vm managed by nova, you must use nova.15:42
*** samuelms has quit IRC15:43
ayoungmorganfainberg, back to the topic at hand...what if we made it implicit in the nova client that, when getting a token for Keystone, you created a trust?15:43
ayoungsame logic from Horizon15:43
ayoungwhen calling Nova, you create a trust.  Or you reuse one if you have it already15:43
ayoungmake it trivial to reuse trusts15:44
rodrigodshenrynash, if the branch rebase remove your reviews at HM first patch, I'll ping you =)15:44
morganfainbergayoung, i'd say i am not sure about it and would want to spend some serious time exploring that / looking into the ramifications15:44
ayoungreally, that is what they are trying to use long lived tokens to do15:44
ayoungcould we insulate all of that logic in Auth Token Middleware?15:44
ayoungmorganfainberg, thought experiement:15:45
henrynashrodigods: ok….I haev looked at the changes…I think I spotted one issue though in the parent_id loop in sql.py15:45
henrynashrodigods: I added a comment15:45
morganfainbergayoung, so we've got a ton of things in flight, a lot aroudn authorization and how it works. this is why we have a heavily focused auth/policy cycle ahead of us15:45
*** __TheDodd__ has joined #openstack-keystone15:45
morganfainbergayoung, my biggest concern is we have so much in flight and a lot of things we need to solve (they are legitimate issues that we're finally at because we've solved a lot of other higher priority things with keystone) I don't want us to jump down the "implement something new and shiney and have another partially built thing15:46
ayounglets say that user X call "boot" on Nova with token T1.  Auth Token Middleware gets T1 and looks at the policy file.  From the policy file it deduces "this is a delegation type task, service user Nova1 is going to need to call glance;  let me get it a token to do that"15:46
morganfainbergayoung, so in short, i'm open to the concept, but it needs solid thought / direction.15:47
morganfainbergand a buy in that we can actually get everything moved over to it.15:47
*** thedodd has quit IRC15:47
morganfainbergayoung, ok keep going with the thought path.15:48
ayoungmorganfainberg, if we take jamie's unified client and session approach as the baseline....when nova calls glance, it should do so through the glance client, and reuse the session15:48
ayoungthe session gets initiated with the token that the user passed in15:49
ayoungnow, the "smart client"  approach is to say "this token is only good for nova, but there is a trust associated with it, let me get a token for glance"15:49
*** wwriverrat has left #openstack-keystone15:50
ayoungso the Nova service user calls into the glance client.  The glance client uses the nova service users credentials and the initial tokens aassociate trust to get a token for glance15:50
morganfainbergayoung, how do you know which trust is associated? the trust is locked to that specific token?15:51
ayoungget_trust_for_token  could have a lifespan longer than the initial token.  The initial token's  expiration is only checked by Nova15:52
*** wwriverrat has joined #openstack-keystone15:52
ayoungone to many token to trust15:52
morganfainbergwhat if i have 30 of these trusts in flight15:52
ayoungits just an association.  The trust id is just the primary key15:52
morganfainbergwhich one do i use?15:52
morganfainbergof i've delegated other trusts that look "similar"15:52
ayoungmorganfainberg, you only need one trust per service/project15:53
ayoungat least, in general15:53
ayoungyou really need one trust per  service/project/operation...or  maybe15:53
henrynashrodigods: I’ll be back on a bit later and will check on it15:54
ayoungso long as the trusts are identical,  go ahead and reuse them.  Now,  Delegation for trusts makes issues more complicated, but lets table that for the moment, and say this if just done by the end user with no redelegation15:54
ayoungand...infact, the same token could, in theory, be associated with different trusts depending on the caller15:54
ayoungbut I don;t think we need that15:55
ayoungwhen a user requests a token for Nova,  that token is locked to Nova...a specific endpoint even15:55
ayoungIf nova needs to call glance, which needs to call swift, it is done via two trusts15:56
ayoungnova uses the token to look up the trust, and get a token for glance15:56
ayoungglance uses its token to look up the trust and get a token for swift15:56
ayoungthe whole constraints approach would still work, as you would want to make the trusts specific to a workflow...15:57
raildoayoung, thanks! i will see and review this patch :)15:57
morganfainbergayoung, i think we need to solve the policy "what can i do with X token" and "what roles do i need to do X" before we can go down this path15:58
morganfainbergor s/token/authorization_we_end_up_using15:58
ayoungmorganfainberg, I think the whole thing would work if we started off with some way to make trusts easy to define15:58
ayoungmorganfainberg, and...I think that policy/constraints need to be fiurst class objects15:59
morganfainbergayoung, maybe revisit deleting the "trust" concept and making delegation a top-level part of the assignment api15:59
ayoungpolicy rules, that is15:59
morganfainberggive me X authorization for user Y [approved] with roles Z,Q,R15:59
*** zzzeek has quit IRC15:59
ayoungmorganfainberg, more than "roles" I think16:00
ayoungroles are collections of capabilities16:00
morganfainbergsure. capabilites16:00
ayoungwe assign roles to users, and then users delegate capabilities16:00
morganfainbergbut in this context of conversation role = capability16:00
morganfainbergor at least today16:00
*** afazekas has quit IRC16:01
ayoungright now I think capability is defined by the keys in the policy file:  identity:create_user...but even then, we limit based on project.  I think it would be hard to say what a capability is today16:01
ayoungas it really implies "what would this policy rule evaluate to in some request"16:02
*** bknudson has joined #openstack-keystone16:03
morganfainbergit sounds to me like this is interesting but likely we're going to need to solve the Kilo "issues" around policy, role definition/ownership, etc before we can go down this path too far16:03
morganfainbergit *could* be a kilo target, but i'm not sure we'll get there16:03
*** _cjones_ has joined #openstack-keystone16:04
ayoungmorganfainberg, Do we want to make policy rules a database managed value, and then generate the policy.json files?16:07
ayoungSo much of this would be easier if we had management of the rules themselves16:07
morganfainbergayoung, i've had a couple brief conversations that lend me to belive that something down that path is right.  likley though we need to revisit the policy "format" in general (whether that is put it in a DB or make it a DSL that isn't painful for deployers doesn't matter).16:08
ayoungmorganfainberg, then the first step is to get a good object model defined.16:09
morganfainbergayoung, ++16:09
morganfainbergayoung, *points to summit session*16:09
ayoungI'll have it available by then16:09
morganfainbergwhich reminds me. i need to send a followup to that thread saying we're having a session on it.16:10
openstackgerritLance Bragstad proposed a change to openstack/python-keystoneclient: Fix listing of endpoints for a token
*** lhcheng has joined #openstack-keystone16:14
*** lhcheng has quit IRC16:16
*** lhcheng has joined #openstack-keystone16:16
*** marcoemorais has joined #openstack-keystone16:17
*** marcoemorais has quit IRC16:17
*** marcoemorais has joined #openstack-keystone16:17
*** tellesnobrega has joined #openstack-keystone16:25
*** leonchio__ has joined #openstack-keystone16:27
*** leonchio_ has quit IRC16:28
morganfainbergraildo, i'm going to get breakfast (late because of multiple meetings i watch at this time) and then work on merging forward your topic branch16:35
*** tellesnobrega has quit IRC16:36
raildomorganfainberg, ok. thank you!16:37
morganfainbergraildo, my hope is we can have everything in place prior to the summit so post summit it's cleanup, merge -> master, and work on new stuff16:37
raildomorganfainberg, sounds good to me :)16:38
*** david-lyle has joined #openstack-keystone16:39
*** tellesnobrega has joined #openstack-keystone16:39
*** leonchio_ has joined #openstack-keystone16:45
*** leonchio__ has quit IRC16:45
*** leonchio_ has quit IRC16:45
*** gyee has joined #openstack-keystone16:50
*** richm1 has joined #openstack-keystone16:54
*** __TheDodd__ has quit IRC17:06
*** victsou is now known as vsilva17:12
*** vsilva is now known as victsou17:17
*** jogo is now known as flashgordon17:17
*** victsou is now known as vsilva17:22
*** vsilva is now known as victsou17:22
*** comstud is now known as bearhands17:23
*** amerine has joined #openstack-keystone17:24
*** amerine_ has quit IRC17:26
*** morganfainberg is now known as captainmorgan17:29
*** mikedillion has joined #openstack-keystone17:33
*** tellesnobrega has quit IRC17:34
*** tellesnobrega has joined #openstack-keystone17:39
openstackgerritRodrigo Duarte proposed a change to openstack/keystone: Add xmlsec1 dependency comments
rodrigodsmarekd, stevemar, ^17:40
rodrigodshad this problem while trying to setup the k2k env17:40
*** wwriverrat has left #openstack-keystone17:41
stevemarrodrigods, hmm, i thought we already doc'ed that, oh well, more docs the better17:46
*** saipandi has quit IRC17:46
ayoungThat is where we are today17:48
rodrigodsstevemar, ++17:48
*** harlowja_away is now known as harlowja17:49
ayoungdhellmann, question about common cli:
ayoungIs there some reason that the username etc is not pulled out of the token data?17:53
ayoungdhellmann, I'm not certain why, but even setting:  --os-username doesn't work in the Kerberos Plugin case17:54
*** toddnni has joined #openstack-keystone17:55
dtroyerayoung: first off,,unified might interest you in that specific instance…all of the client creation bits need updating with the arrival of sessions and suh plugins17:56
ayoungdtroyer, oh yes it does...let me  try that17:56
dtroyerayoung: in theory, we're giving the old client libs a token and telling them to 'trust us' but it hasn't always worked.  as they change to using the auth plugins that'll get much cleaner17:57
ayoungdtroyer, +2 trhat change!17:58
ayoungdtroyer, I just tested it out, and it cleans up the call significantly17:58
dtroyerit's been a day or two, stevemar? ^^^17:59
ayoungdtroyer, I'm using an out-of-tree plugin for kerberos, and with that, there is no explicit set of most data17:59
ayoungI still need to specify the domain for the project, but17:59
ayoung/usr/bin/openstack  --debug  --insecure --os-auth-plugin kerberos --os-username ayoung  --os-project-domain-name Default       hypervisor list17:59
ayoungjust worked for me17:59
ayoungOK,  next question:  --insecure should not be required...18:00
dtroyerayoung: cool.  I've been curious how many assumptions were left in the auth setup18:00
ayoungthink I'm messing up the cert18:00
ayounglemme see the CLI Param for that18:01
*** marcoemorais has quit IRC18:01
dtroyeryeah, that's all in your setup. if you have a ca cert available, use —os-cacert to point to it, or add it to … whatever requests wants for the ca bundle18:01
*** marcoemorais has joined #openstack-keystone18:01
ayoungI have a ca cert18:02
ayoungBundle...does that imply something other than pem?18:02
ayoungah,  wait, no I don't...duh18:02
dtroyerno, that is whatever requests (mayby python itself??) uses for the distributed ca list18:02
ayoungworks much better with the correct path18:03
*** radez is now known as radez_g0n318:04
ayoungdtroyer, so I suspect we are going to want to add OS_AUTH_PLUGIN as an accpetable env var18:06
*** radez_g0n3 is now known as radez18:07
ayoungdtroyer, wanna see something frightening?18:07
dtroyerayoung: possibly.  I think I'd rather leave off _PLUGIN.   nad it may change in other ways, I dont think that's the friendliest bit yet18:07
dtroyerayoung:  uh oh...18:07
ayoungdtroyer, just wondering if that diagram makes sense to anyone beyond me.18:08
dtroyerbesides being a search-n-replace of my old expense approval path at Perot?   lemme study a bit18:09
*** thedodd has joined #openstack-keystone18:09
dtroyerI wouldn't call it self-explanatory…but the whole policy thing is a black box to me atm too18:12
openstackgerritLance Bragstad proposed a change to openstack/keystone: Remove XML support
*** arborism has joined #openstack-keystone18:16
*** arborism is now known as amcrn18:17
stevemardtroyer, crashing -keystone again?18:22
ayoungdtroyer, this is just  together the classes from openstack/common/policy and the keystone side that builds a token18:22
ayoungthere really is nothing in policy persay that is RBAC beyond the "RoleCheck":18:22
*** ukalifon has joined #openstack-keystone18:24
*** marcoemorais has quit IRC18:26
*** marcoemorais has joined #openstack-keystone18:26
dtroyerayoung: ah, sure.  I got DB tables stuck in my head knowing that is not what that was, and it wouldn't leave…18:26
*** packet has quit IRC18:26
dtroyerstevemar: I'm like kibo, say the magic word and I appear...18:27
*** marcoemorais has quit IRC18:27
*** marcoemorais has joined #openstack-keystone18:28
*** thedodd has quit IRC18:28
stevemardtroyer, always with the obscure and random!18:29
dtroyerstevemar: when is jamie back?  looking at, we can make adjustments to the TokenEndpoint class if/when it moves to ksc18:29
dtroyerstevemar: no, just OLD18:29
stevemardtroyer, thats the question of the month, we have no idea18:29
stevemarsomething about getting married :P18:29
stevemarbut i think he's gone til conference?18:30
dtroyerwill he be in paris?  that's the honeymoon he needed to take…18:30
stevemarhe will be for sure18:30
dtroyerok, like sdad18:30
ayoungstevemar, dtroyer who else can +2 that patch?18:33
dtroyerit's us.  I'll +A it if stevemar is happy.18:34
ayoungdtroyer, I think I can vouch for the KC code being OK18:34
ayoungdtroyer, nothing I see locks us in to a bad design decision there: we are creating the nova client based on a session, which is proper.18:35
*** ukalifon has quit IRC18:42
ayoungstevemar, just checked nkinder's status (internal IRC) and it says PTO, so no discussion with him today18:43
openstackgerritAlexander Makarov proposed a change to openstack/keystone: Trust redelegation
*** amerine has quit IRC18:47
*** amerine has joined #openstack-keystone18:47
*** _cjones_ has quit IRC18:58
*** _cjones_ has joined #openstack-keystone18:58
ayoungamakarov_away, I think there is a pretty significant amount of work to do on trust delegations.19:02
*** _cjones_ has quit IRC19:03
*** tellesnobrega has quit IRC19:05
*** gordc has quit IRC19:11
captainmorganayoung, so that diagram?19:14
ayoungcaptainmorgan, yes19:14
captainmorganayoung is that just the different peices we need / steps / stuff?19:14
ayoungcaptainmorgan, actually, it is the current status19:14
captainmorganah ok19:15
captainmorganwasn't sure if you were looking at it from current view or future looking19:15
captainmorganmakes more sense :)19:15
ayoungcaptainmorgan, I would say that we use it as a starting point, and we can add in "if we do constraints it would look like this"19:15
captainmorgani like it19:15
ayoungcaptainmorgan, I think we want to go incremental on policy.  As tempting as it is to try and scrap and rewrite from scratch, I don't see anything fundamentally wrong in our current approach19:16
*** radez is now known as radez_g0n319:17
ayoungfor example, we are not locked in to RBAC, its just the best supported "check" type in common policy19:17
captainmorganayoung, the whole point for the summits session is to set the targets where we *need* to get to19:17
captainmorganbetween here and there is going to be quite the road19:17
*** radez_g0n3 is now known as radez19:18
ayoungcaptainmorgan  I've been on this road for a while.19:19
ayoungJane, get me off this crazy thing19:19
captainmorganayoung, i know. now it's just where the rest of OpenStack is catchingup19:19
ayoungcaptainmorgan, anyway, I'm starting to think along the lines of multiple Keystones working together.  Really, if you have admin access to the authorization service, you can do anything, so the logical way to break up delegation decisions is to say "run your own authorization service"19:22
ayoungMaybe policy shouldn't be served out of the same thing that issues tokens19:22
ayoungcaptainmorgan, if each endpoint has a single Keystone server which is the "authoritative" that issues out policy, and admin tokens, etc.  But then accepted tokens from a different one, based on limitations placed by the first, we'd have an interesting model for separate of concerns.19:26
captainmorganayoung, i know the congress folks are highly interested in this conversation19:26
captainmorgani specifically called out that policy may be centralized in KEystone *or* Congress *or* something else.19:27
ayoungI still don't like that the "authoritative" could override what the other keystones are doing.  I'd like to to be that the authoritative could say "you cant' do that" but then couldn't fake it itself19:27
*** _cjones_ has joined #openstack-keystone19:27
ayoung"they can't do that to our pledges"  "yeah, only we can do that to our pledges!"19:28
ayoungI like the idea of splitting up policy from tokens19:28
captainmorgani'm less worried about Cloud X issuing policy for Cloud Y.19:28
ayoungfrom a purely paranoia perspecive19:29
captainmorganheck i don't think that is the right choice.19:29
stevemardtroyer, ayoung which patch?19:29
captainmorganbut i'm not sure if a per-endpoint keystone would work.19:29
ayoungstevemar, for openstack client.  Session patch19:29
captainmorganayoung, i think there is a lot of conversation that is going to happen this cycle and it's time.19:29
stevemarayoung, checking now19:30
ayoungwould not want a light cigar inside my helmut visor19:31
dtroyerstevemar: too late…I'm bamking on your +1 as my sole defense19:31
stevemardtroyer, nooooo!19:31
stevemardtroyer, :P19:31
captainmorganayoung, one of the best video game cut scenes (the SC2 intro) - so enjoy that bit of work.19:31
ayoungI +1ed it as well19:32
stevemarsc2 intro is pretty badass captainmorgan19:32
captainmorganreminds me i need to install it and play it + HotS compaign19:35
captainmorganstevemar, i'm still sad SC Ghost was cancelled :(19:37
*** thedodd has joined #openstack-keystone19:40
captainmorganand i think that just failed.19:52
* captainmorgan just tried to merge the HM branch19:53
captainmorganand git didn't do what i wanted it to do...19:54
*** marcoemorais has quit IRC20:01
raildocaptainmorgan, how sad i'm for you :'(20:02
*** marcoemorais has joined #openstack-keystone20:02
*** Kui has joined #openstack-keystone20:04
rodrigodscaptainmorgan, \o/20:06
rodrigodscaptainmorgan, we need to wait for dolphm , right?20:07
captainmorganrodrigods, no we need to wait for jenkins20:07
captainmorgan*any* core can approve that change.20:07
rodrigodscaptainmorgan, true, first things first20:07
raildocaptainmorgan, In Paris, I'll buy you a beer as a reward \o20:07
captainmorgani have no problem with a single +2 for approval on it20:07
captainmorganso, once jenkins passes bug any of us.20:07
captainmorganyou can rebase on it and check test runs.20:08
captainmorganlocally that is20:08
captainmorganif it looks good go ahead and push the changes on top of it.20:08
* rodrigods already rebasing, captainmorgan too late20:08
richm1I think you should by captainmorgan a rum . . .20:08
captainmorganOH NO! ;)20:08
captainmorganrichm1, no :( sadly i'm not a rum person20:08
captainmorgannow.. brandy... cognac20:09
captainmorganscotch.. yes20:09
openstackgerritBrad Topol proposed a change to openstack/keystone-specs: Add a specification for revamping the documentation
richm1but - your namesake!!!20:09
captainmorgani snagged this for speak like a pirate day.20:09
captainmorganjust too good to not use every now and again20:09
captainmorganayoung, ok so i'm going to finish my BP cleanup this weekend. the only BPs i've mucked with (beside priority) that you posted were obvious duplicates20:11
richm1ok - then I suggest armagnac20:11
captainmorganrichm1, ++20:11
captainmorganayoung, any that i'm unsure about / know we might want I'm simply classifying as priority "not" and "pending approval"20:12
captainmorganso we know not to review them in the weekly meeting20:12
*** david-lyle has quit IRC20:24
-openstackstatus- NOTICE: Gerrit will be offline from 2100-2130 for project renames20:33
*** ChanServ changes topic to "Gerrit will be offline from 2100-2130 for project renames"20:33
ayoungcaptainmorgan, lets see20:40
ayoungdhellmann, captainmorgan, BTW,  I figured out part of the PBR issue.  When I changed the "name" value in setup.cfg from python-keystoneclient-kerberos to keystoneclient_kerberos, PBR (and entrypoints) worked20:41
ayoungI think having python-  in there is kinda dumb20:42
ayoungthat should be the RPM name, but for a python module it is redundant20:42
captainmorganayoung, yeah but we're already there with python-keystoneclient20:43
*** topol has quit IRC20:43
captainmorganso, lets stay consistent20:43
ayoungcaptainmorgan, nah20:44
ayounglets kill it for KC20:44
ayoungtis dumb20:44
* ayoung likes to break all the things20:44
*** zzzeek has joined #openstack-keystone20:47
*** miqui has quit IRC20:50
captainmorganayoung, we have bigger fish to fry than renaming packages.20:52
captainmorganlets not do busy work ;)20:52
ayoungThat she blows....tis the white whale, and the doubloon is mine!20:53
captainmorganayoung, we have this: don't we?20:54
captainmorganthat was henry-nash's thing20:55
ayoungyeah, mark that as done20:55
*** rwsu has quit IRC20:56
ayoung  really is not a Keystone BP20:57
captainmorganBPs are starting to look a lot better20:57
ayoungcaptainmorgan, you still don;t think keystone should generate html if you hit it from a browser?20:57
captainmorganayoung, i am torn. FreeIPAs interface makes me want it20:58
ayoungFreeIPA is actually all Javascript and JSON RPC20:58
*** jistr has quit IRC20:58
captainmorgani don't know if it's something i see as important enough this cycle, we have a lot of higher prio things20:58
captainmorganayoung, doesn't change my view on it :)20:58
captainmorganfreeipa's interface is pretty slick out of the box20:58
ayoungI still have the code...was done as an extension20:59
captainmorganif we could do it w/o needing to hook into the plumbing of keystone it would be awesome20:59
captainmorganbut then... wouldn't it just be "horizon"? :P20:59
*** lhcheng has quit IRC20:59
ayoungI still think that the JSON middleware needs to be fixed21:00
*** lhcheng has joined #openstack-keystone21:00
captainmorganso this is a glorified middleware?21:00
ayoungcaptainmorgan, no glory21:00
ayounginstead of stacking the content renderer, has one that switches based on the requests header21:01
*** radez is now known as radez_g0n321:01
ayoungif  accepts starts with HTML, select the HTML one21:01
captainmorganisn't this mostly solved if we moved to pcan/wsme?21:01
captainmorganand less code for us to maintain?21:01
ayoungI don't think so.  I mean, pecan has the concept, but I don't think it actually had the HTML renderer21:02
captainmorgani meant needing to "fix" the middleware just create a renderer for it21:02
-openstackstatus- NOTICE: Gerrit is offline from 2100-2130 for project renames21:02
*** ChanServ changes topic to "Gerrit is offline from 2100-2130 for project renames"21:02
captainmorganso we could have a JSON renderer / html one / etc21:02
ayoungcaptainmorgan, that is what I was told, but I did not really get deep enough into it to confirm21:02
ayoungthat is the right abstraction21:02
captainmorganif we can use that kind of abstraction and get it for free moving away from our *very* custom setup, i'd be good with that approach. otherwise making the rederer pluggable would be good21:03
ayoungJSON and XML, no HTML21:03
captainmorganand we just need to keep the interface super stable. then that html one could be out of tree / in tree, etc21:03
captainmorganwho cares where it is.21:03
captainmorganayoung, *doh*21:04
ayoungand the JSON was, IIRC not identical to what we are producing now21:04
captainmorgani'd rather get out of the business of writing our own json renderer if we can.21:04
captainmorganif it's something we could plug html rendering into as well, double win?21:04
ayoungyeah...pretty much I want to stop writing any custom code that is not fundamental to Authorization21:05
captainmorganayoung, so i think we need to change that conversation: fix the redering middleware/pipeline/stuff to be more sane21:05
ayounga dead simple HTML interface would make testing Keystone so much simpler.21:05
captainmorganthen we can easily handle <format> because it's pluggable.21:05
ayoungsince we are dreaming21:05
ayoungthe auth stuff should be in its own pipeline21:06
ayoungsplit   /auth  from identity, etc21:06
captainmorganayoung, hehe. something to talk about in the authorizaton session?21:06
captainmorgani think so :)21:06
* ayoung knew there was a reason...21:06
captainmorgani think this cycle is auth, policy, and "omg fix the ick in our backends so they aren't slow"21:07
ayoungcaptainmorgan, if auth were its own pipeline, it would make sense to then stack the pieces of the token pipeline as separate pipeline components21:07
ayoungv3 pipeline is all:21:08
ayoungpipeline = sizelimit url_normalize build_auth_context token_auth admin_token_auth xml_body_v3 json_body ec2_extension_v3 s3_extension simple_cert_extension revoke_extension service_v321:08
captainmorganor even if we didn't use paste, something were you could hook code in (via... i dunno... entry points *OMGOSH!*)21:08
ayoungis there a good tool for wiring together entrypoints?21:08
ayoungextensions should also be their own pipeline21:09
captainmorgannow you're talking nonsense :P21:09
captainmorgani mean..21:09
ayoungso we have21:09
captainmorgani think moving to that kind of distinction is a couple cycles out though21:09
ayounguse = egg:Paste#urlmap21:09
captainmorganbut we do have the *dep injection / life cycle* session21:10
ayoungthen things like /v2.0 = public_api21:10
captainmorganwhich does touch lightly on extensions (optional deps)21:10
ayoungthose really should be more like21:10
ayoung    /v3/auth = auth_v321:10
ayoungthen admin would have /user but not the one that you would hang out for the outside world (perhaps)21:11
captainmorgangyee, we're committed to filtering instead of pagination right?21:11
captainmorgancause i don't think we can make pagination work easily w/o a lot of ick.21:11
captainmorgangyee, re:
ayoungpagination dumb21:13
*** gyee has quit IRC21:14
captainmorganayoung, yeah i don't think we can do pagination.21:14
captainmorgangoing to nix that one.21:14
captainmorganwe should do filtering :)21:15
captainmorganunless the TC comes in and says "we support pagination like XXX"21:15
captainmorganwich case we try and convince them it's wrong... and then if still losing we implement pagination21:15
ayoungLDAP can't paginate21:18
captainmorganayoung, sure it can. it just sucks at it21:18
ayoungif it can't do it underload, then it really can't21:18
captainmorgani killed that BP21:18
ayoung  is basically done, isn't it?21:19
ayoungits a Horizon BP...21:19
captainmorganThis we have with regions... right: ?21:19
ayoungI have to ask mrunge21:19
ayoungcaptainmorgan, I'd say so.  Oh,  but there are other issues with how we use the catalog...basically,  there BP was neither necessary nor sufficient21:20
ayoungneed to ask the Nova folks if they would support something that allowed things like Glance image IDs and Neutron ports to be passed in as Full URLs instead of just IDs.  It would mean that the Service catalog would be kindof irrelvant21:21
ayoungit would certainly help disambiguate when there were two endpoints for the same services21:22
ayounger service21:22
ayoungcaptainmorgan, please approve this
captainmorgani can't21:23
captainmorganthats owned by horizon/david-lyle21:23
ayoungah, right21:23
captainmorganif i could approve it, so could you21:23
* ayoung needs reading glasses to see fine print21:24
ayoung  marked as *not*  thought that one was good-to-go21:24
*** ChanServ changes topic to "Now open for Kilo development! Blocking reviews: | Please review design session schedule and provide feedback:"21:25
-openstackstatus- NOTICE: Gerrit is back online21:25
ayoungah, needs spec url21:25
rodrigodscaptainmorgan, +1 from jenkings ^^21:25
captainmorganrodrigods, cool21:25
captainmorganayoung, mind tossing a +2/+A on this to keep multitenency work moving?21:26
captainmorganayoung, it's just a merge to pull the topic branch to current master21:26
ayoung*just* ?21:26
ayoungyou mean the other way round, don't you?21:27
*** gyee has joined #openstack-keystone21:27
ayoungMerge remote-tracking branch 'origin/master' into feature/hierarchical-multitenan ...21:27
ayoungcaptainmorgan, that is basically a "resync"  right?21:28
captainmorganit's a merge commit though, because we can't FF only it21:28
*** captainmorgan is now known as needscoffee21:29
*** needscoffee is now known as captainmorgan21:29
rodrigodsayoung, captainmorgan thanks!21:31
ayoungmy pleasure21:31
captainmorganayoung, side note: what do you think of gating on complexity?21:31
ayoungplease no more rules21:32
ayoungif it makes it harder to get code to pass tox -epep8 I'm against it21:32
captainmorganayoung, we have *no* code that exceeds complexity of 2421:32
ayoungI'll try harder21:32
captainmorganand that is a migrate script.21:32
captainmorgangenerally speaking our complexity is <1521:32
ayoungwhat does this buy us?21:32
captainmorganbut we're really picky about the code.21:32
captainmorganit's just a fence to help limit someone from creating crazy loop, loop, loop, loop constructs21:33
captainmorganw/o us seeing it because it's hard to read21:33
ayounghmmm,  so if we set complexity to, say 20,  what would that do with 'Auth._authenticate_token'21:33
captainmorganit would fail pep821:33
ayoungwould it help suggest ways to decomplixificate?21:34
captainmorganand tell you that the method is too complex21:34
captainmorganno it doesn't really have that smarts21:34
captainmorganit can't re-write the python21:34
ayoungall you want to do is say "no more complex than we have now"  for now?21:35
captainmorganpretty much21:35
captainmorgan24 is pretty good21:35
captainmorgannova is in the ~64 range at the top end for example21:35
ayounglets do it.  It lets the coder mess with the value, and maybe tox will provide some feedback to simplify in the future21:35
ayoungIf it gets painful we can always remove21:36
captainmorganthats my thought21:36
openstackgerritayoung proposed a change to openstack/python-keystoneclient-kerberos: kerberos client plugin
*** henrynash has quit IRC21:37
ayoungcaptainmorgan, so,  I think I want to break things on the 'der' vs 'pem' issue and compressed tokens.  Here's my logic:21:37
ayoungTHe 'right' thing to do would be to create a new token format21:38
ayounglets call it derz for now21:38
ayoungto differentiate from pkiz21:38
ayoungif we did that, any clients out there now would be broken if the keystone server started serving out 'derz_' tokens21:38
ayoungand would have no way to deal with it.21:38
captainmorganfwiw i already have internal people coding java validators to handle pkiz21:39
captainmorganso breaking it might be bad21:39
ayoungSo,its basically the same thing that would happen if we changed pkiz to doing der21:39
captainmorganwith a target of juno support (since juno is released)21:39
ayoungso, one thing to do is to publish something about the 'der' side of the issue:21:39
ayoungI have code in the current posting that would accept both pem and der21:39
captainmorgansadly i think we need to make it a config to switch to der - our code can be smart,but it needs tobe explicit for the server to issue der fmt21:40
rodrigodsbesides ayoung and jamielennox, who are other keystone bloggers?21:40
captainmorganin theory you coudl make STD PKI tokens also der fmt with a switch like that21:40
captainmorganrodrigods, dolphm21:40
rodrigodscaptainmorgan, ++21:41
captainmorganrodrigods, and i used to some till my blog died a horrible death21:41
captainmorganand i gave up21:41
captainmorgani should ressurect it.21:41
rodrigodscaptainmorgan, hehe21:41
rodrigodsI was posting a tutorial for k2k fed21:41
rodrigodscaptainmorgan, just need to figure out how to send the SAML assertion to the SP21:41
captainmorganrodrigods, hehe21:42
rodrigodsnot trivial task right now (not documented too)21:42
rodrigodswill submit other documentation improvements in this area21:42
captainmorganok i need to head out for a couple of hours.21:42
captainmorganbe back later on.21:42
rodrigodsjust have right now21:43
*** lhcheng has quit IRC21:43
rodrigodscaptainmorgan, o/21:43
*** lhcheng has joined #openstack-keystone21:44
*** lhcheng has quit IRC21:46
*** lhcheng has joined #openstack-keystone21:49
ayoungrodrigods, nkinder blogs too21:51
ayoung  rodrigods21:51
rodrigodsthanks ayoung21:52
rodrigodsadding to my feedly21:52
ayoungrodrigods,  ?21:53
ayoungPOK,  family time21:54
rodrigodsayoung, yep!21:54
*** ayoung has quit IRC21:54
*** zzzeek_ has joined #openstack-keystone21:54
*** zzzeek has quit IRC21:56
*** zzzeek_ is now known as zzzeek21:56
*** lhcheng_ has joined #openstack-keystone21:57
*** andreaf has quit IRC21:59
*** openstackgerrit has quit IRC22:03
*** openstackgerrit has joined #openstack-keystone22:04
*** lhcheng_ has quit IRC22:05
*** lhcheng has quit IRC22:05
*** lhcheng_ has joined #openstack-keystone22:05
*** lhcheng has joined #openstack-keystone22:05
*** lhcheng has quit IRC22:05
*** Tahmina has joined #openstack-keystone22:08
*** zzzeek_ has joined #openstack-keystone22:09
*** dimsum_ has quit IRC22:09
*** dimsum_ has joined #openstack-keystone22:09
*** zzzeek has quit IRC22:10
*** zzzeek_ is now known as zzzeek22:10
openstackgerritA change was merged to openstack/pycadf: Updated from global requirements
*** mikedillion has quit IRC22:12
*** r-daneel has quit IRC22:12
*** amerine has quit IRC22:12
*** tellesnobrega has joined #openstack-keystone22:14
*** dimsum_ has quit IRC22:14
*** _cjones_ has quit IRC22:16
*** _cjones_ has joined #openstack-keystone22:16
*** _cjones_ has quit IRC22:21
openstackgerritSteve Martinelli proposed a change to openstack/keystone-specs: add v3 API documentation
openstackgerritSteve Martinelli proposed a change to openstack/keystone-specs: Publish the Identity v3 API specs
*** henrynash has joined #openstack-keystone22:27
*** mikedillion has joined #openstack-keystone22:29
*** jorge_munoz has quit IRC22:33
*** pc-m has quit IRC22:34
*** thedodd has quit IRC22:35
*** sigmavirus24 is now known as sigmavirus24_awa22:36
*** andreaf has joined #openstack-keystone22:41
*** _cjones_ has joined #openstack-keystone22:46
*** arunkant has quit IRC22:49
*** rwsu has joined #openstack-keystone22:52
*** mikedillion has quit IRC22:58
openstackgerrithenry-nash proposed a change to openstack/keystone-specs: Make assignments pluggable.
openstackgerrithenry-nash proposed a change to openstack/keystone-specs: Add an extension to store domain specific configuration in SQL.
openstackgerrithenry-nash proposed a change to openstack/keystone-specs: Make assignments pluggable.
*** _cjones_ has quit IRC23:10
*** _cjones_ has joined #openstack-keystone23:11
*** tellesnobrega has quit IRC23:11
*** _cjones_ has quit IRC23:15
*** tellesnobrega has joined #openstack-keystone23:17
*** gyee has quit IRC23:30
*** _cjones_ has joined #openstack-keystone23:42
*** _cjones_ has quit IRC23:42
*** _cjones_ has joined #openstack-keystone23:42
*** dimsum_ has joined #openstack-keystone23:44
*** gyee has joined #openstack-keystone23:44
*** nellysmitt has quit IRC23:45
*** nellysmitt has joined #openstack-keystone23:45
*** henrynash has quit IRC23:45
*** dimsum_ has quit IRC23:46
*** dimsum_ has joined #openstack-keystone23:46
*** dimsum_ has quit IRC23:47
*** dimsum_ has joined #openstack-keystone23:48
*** nellysmitt has quit IRC23:50
*** david-lyle has joined #openstack-keystone23:52
*** dimsum_ has quit IRC23:52
*** david-lyle has quit IRC23:52
*** dimsum_ has joined #openstack-keystone23:55
*** dimsum_ has quit IRC23:59

Generated by 2.14.0 by Marius Gedminas - find it at!