Monday, 2014-10-06

*** andreaf has quit IRC00:15
*** andreaf has joined #openstack-keystone00:16
*** shakamunyi has joined #openstack-keystone00:22
*** cjellick has joined #openstack-keystone00:25
*** shakamunyi has quit IRC00:29
*** cjellick has quit IRC00:29
*** shakamunyi has joined #openstack-keystone00:29
*** shakamunyi has quit IRC00:39
*** shakamunyi has joined #openstack-keystone01:04
*** henrynash has quit IRC01:12
*** shakamunyi has quit IRC01:14
*** andreaf has quit IRC01:19
*** andreaf has joined #openstack-keystone01:20
*** cjellick has joined #openstack-keystone01:26
*** andreaf has quit IRC01:30
*** andreaf has joined #openstack-keystone01:30
*** cjellick has quit IRC01:31
*** shakamunyi has joined #openstack-keystone01:39
*** dguitarbite has joined #openstack-keystone01:42
*** andreaf has quit IRC01:44
*** andreaf has joined #openstack-keystone01:45
*** dimsum_ has quit IRC01:47
*** diegows has quit IRC01:49
*** shakamunyi has quit IRC01:54
*** vsilva is now known as victsou01:55
*** dimsum_ has joined #openstack-keystone01:58
*** dimsum_ has quit IRC02:00
*** dguitarbite has quit IRC02:02
*** dimsum_ has joined #openstack-keystone02:10
*** Sunny__ has quit IRC02:14
*** shakamunyi has joined #openstack-keystone02:20
*** cjellick has joined #openstack-keystone02:27
*** cjellick has quit IRC02:32
*** andreaf has quit IRC02:34
*** andreaf has joined #openstack-keystone02:34
*** shakamunyi has quit IRC02:36
*** dimsum_ has quit IRC02:38
*** stevemar has joined #openstack-keystone02:43
*** shakamunyi has joined #openstack-keystone03:03
*** r1chardj0n3s is now known as r1chardj0n3s_afk03:11
*** shakamunyi has quit IRC03:11
*** dimsum_ has joined #openstack-keystone03:16
*** dguitarbite has joined #openstack-keystone03:19
*** cjellick has joined #openstack-keystone03:28
*** dimsum_ has quit IRC03:30
*** cjellick has quit IRC03:32
*** gokrokve has joined #openstack-keystone03:51
*** gokrokve has quit IRC03:53
*** gokrokve has joined #openstack-keystone03:53
*** gokrokve has quit IRC03:53
*** shakamunyi has joined #openstack-keystone04:08
*** andreaf has quit IRC04:12
*** andreaf has joined #openstack-keystone04:12
*** shakamunyi has quit IRC04:20
*** fifieldt has joined #openstack-keystone04:25
*** gokrokve has joined #openstack-keystone04:25
*** gokrokve has quit IRC04:25
*** andreaf has quit IRC04:28
*** cjellick has joined #openstack-keystone04:29
*** andreaf has joined #openstack-keystone04:29
*** cjellick has quit IRC04:33
*** lcheng has joined #openstack-keystone04:57
*** lcheng has quit IRC04:58
*** r1chardj0n3s_afk is now known as r1chardj0n3s04:58
*** lcheng has joined #openstack-keystone04:58
*** lcheng has quit IRC05:03
*** lcheng has joined #openstack-keystone05:06
*** shakamunyi has joined #openstack-keystone05:08
*** lcheng has quit IRC05:09
*** lcheng has joined #openstack-keystone05:10
*** ajayaa has joined #openstack-keystone05:13
*** jaosorior has joined #openstack-keystone05:22
*** shakamunyi has quit IRC05:24
*** ajayaa has quit IRC05:24
*** cjellick has joined #openstack-keystone05:29
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Use jsonutils from oslo.serialization
*** cjellick has quit IRC05:34
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Use importutils from oslo.utils
openstackgerritHaneef Ali proposed a change to openstack/keystone: Allow v3 policy file
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Use importutils from oslo.utils
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Replace an instance of keystone/openstack/common/timeutils
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Remove XML support
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Update docs to no longer show XML support
*** ajayaa has joined #openstack-keystone05:43
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Update the CLI examples to also use openstackclient
*** k4n0 has joined #openstack-keystone05:44
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Add v3 openstackclient CLI examples
*** ukalifon has joined #openstack-keystone05:49
*** shakamunyi has joined #openstack-keystone05:50
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Add v3 openstackclient CLI examples
*** shakamunyi has quit IRC05:57
*** andreaf has quit IRC05:57
*** andreaf has joined #openstack-keystone05:58
*** dguitarbite has quit IRC06:02
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex
*** cjellick has joined #openstack-keystone06:30
*** cjellick has quit IRC06:35
*** lufix has joined #openstack-keystone06:36
*** miqui has quit IRC06:38
*** shakamunyi has joined #openstack-keystone06:53
*** afazekas has joined #openstack-keystone06:53
*** lcheng has quit IRC06:56
*** andreaf has quit IRC07:02
*** shakamunyi has quit IRC07:19
*** jistr has joined #openstack-keystone07:23
*** cjellick has joined #openstack-keystone07:31
*** cjellick has quit IRC07:36
*** shakamunyi has joined #openstack-keystone07:40
*** stevemar has quit IRC07:44
*** shakamunyi has quit IRC07:55
marekdnkinder: thanks for uploading openstack auth plugins patch!08:11
*** nellysmitt has joined #openstack-keystone08:15
*** Dafna has joined #openstack-keystone08:22
*** cjellick has joined #openstack-keystone08:32
*** cjellick has quit IRC08:36
*** lsmola has joined #openstack-keystone08:37
*** oomichi has joined #openstack-keystone08:37
*** k4n0 has quit IRC08:46
openstackgerritChristian Berendt proposed a change to openstack/keystone: Change all used passwords/secrets to 'secretsecret' and 'secrete_token' to 'secret_token'
*** dguitarbite has joined #openstack-keystone08:49
*** Clabbe has quit IRC08:52
*** k4n0 has joined #openstack-keystone09:00
*** aix has joined #openstack-keystone09:07
*** cjellick has joined #openstack-keystone09:33
*** cjellick has quit IRC09:37
*** shakamunyi has joined #openstack-keystone09:41
*** k4n0 has quit IRC09:41
*** shakamunyi has quit IRC09:45
*** amakarov has joined #openstack-keystone09:47
*** k4n0 has joined #openstack-keystone09:57
*** andreaf_ is now known as andreaf10:32
*** cjellick has joined #openstack-keystone10:34
*** kragniz has joined #openstack-keystone10:39
*** cjellick has quit IRC10:39
*** harlowja_away has quit IRC10:47
*** Kui has quit IRC10:50
*** diegows has joined #openstack-keystone10:53
*** nellysmitt has quit IRC10:58
*** shakamunyi has joined #openstack-keystone11:03
*** shakamunyi has quit IRC11:12
*** Tahmina has joined #openstack-keystone11:14
*** dimsum_ has joined #openstack-keystone11:19
*** nellysmitt has joined #openstack-keystone11:33
*** cjellick has joined #openstack-keystone11:34
*** mflobo has joined #openstack-keystone11:36
*** cjellick has quit IRC11:39
*** shakamunyi has joined #openstack-keystone12:26
*** cjellick has joined #openstack-keystone12:35
*** cjellick has quit IRC12:40
*** shakamunyi has quit IRC12:40
*** ayoung-ZzzZzzZzz is now known as ayoung12:44
*** dimsum_ has quit IRC12:45
*** dimsum_ has joined #openstack-keystone12:45
*** dimsum_ is now known as dims12:58
*** aix has quit IRC12:58
*** ukalifon3 has joined #openstack-keystone12:59
*** ukalifon has quit IRC12:59
*** aix has joined #openstack-keystone12:59
*** raildo_away has quit IRC13:02
*** vhoward has joined #openstack-keystone13:06
*** samuelmz has joined #openstack-keystone13:08
*** jdennis has joined #openstack-keystone13:11
*** amakarov has quit IRC13:12
*** gordc has joined #openstack-keystone13:13
*** mikedillion has joined #openstack-keystone13:26
*** sigmavirus24_awa is now known as sigmavirus2413:30
*** amakarov has joined #openstack-keystone13:33
*** oomichi has quit IRC13:34
*** richm has joined #openstack-keystone13:36
*** cjellick has joined #openstack-keystone13:36
*** shakamunyi has joined #openstack-keystone13:37
*** thedodd has joined #openstack-keystone13:40
*** cjellick has quit IRC13:40
*** dhellmann is now known as dhellmann_13:43
*** dhellmann_ is now known as dhellmann13:44
*** r-daneel has joined #openstack-keystone13:45
*** andreaf is now known as andreaf_13:45
*** thedodd has quit IRC13:46
*** achampion has joined #openstack-keystone13:48
achampionquick question, is there an easy way through the keystoneclient to get from username/password to a userid?13:49
amakarovachampion, m.b. custom script?13:52
*** shakamunyi has quit IRC13:53
achampionamkarov: m.b.?13:53
amakarovachampion, "may be" :)13:56
amakarovachampion, keystone api has no much porcelain actually13:58
achampionamakarov: :$, I was surprised, that I couldn't get access to the token details, just the token id.13:59
amakarovachampion, X-Subject-Token can be usable here14:00
amakarovTry base64decode on it14:01
amakarovif you use PKI, it holds everything you need14:01
*** ukalifon3 has quit IRC14:02
tellesnobregahey morganfainberg, i'm starting to work on this bug , the idea is to revoke all tokens from an idp, when this idp is deleted14:06
uvirtbotLaunchpad bug 1291157 in python-keystoneclient "idp deletion should trigger token revocation" [High,Triaged]14:06
tellesnobregamy question here is, is there an way to list all tokens from an idp?14:07
*** shakamunyi has joined #openstack-keystone14:07
tellesnobreganevermind, i saw dolph's comment in the bug and the approach is the other way around14:10
marekdtellesnobrega: there was a guy working on that. You may want to contact him. Besides, I'd suggest syncing whether this bug should be fixed for UUIDs or PKI tokens (then revocation events are to be used).14:12
*** amakarov has quit IRC14:12
*** amakarov has joined #openstack-keystone14:13
*** shakamunyi has quit IRC14:21
rodrigodslbragstad, went through your comments at the HM patch, you can continue your review =)14:21
lbragstadrodrigods: sure thing, I'll add it to my queue14:22
tellesnobregamarekd, i see. Who should I talk to about this bug?14:22
marekdtellesnobrega: both bugs are assigned to Navid Putschi.14:24
tellesnobregai'll try to contact him14:25
marekdtellesnobrega: speaking about UUID/PKI -i suggest talking with ayoung14:25
marekdand morganfainberg14:25
marekdotherwise you may waste your time14:26
*** david-lyle has joined #openstack-keystone14:28
*** jistr has quit IRC14:28
*** gokrokve has joined #openstack-keystone14:28
*** jistr has joined #openstack-keystone14:30
dolphmmorganfainberg: clean backports to juno/proposed
*** radez_g0n3 is now known as radez14:34
dstanekdolphm: nice14:35
dolphmanyone free to review this? i'd like to get it into juno as well
dolphmdstanek: oh, just read your concern there .. ^14:36
dstanekdolphm: yeah, like morganfainberg said it's probably fine for RC since we won't be adding new tables and relationships there, but for Kilo it would introduce a maint burdon14:37
dolphmdstanek: and agree, but it does work as-is14:37
*** cjellick has joined #openstack-keystone14:37
dolphmdstanek: ++14:37
dstanekdolphm: if need be we can just replace it later after the merge14:37
dstanekdolphm: do you think it's worth fixing now or merging and fixing later14:41
*** stevemar has joined #openstack-keystone14:41
*** cjellick has quit IRC14:41
*** topol has joined #openstack-keystone14:42
dolphmdstanek: both? :) i'd like to get a fix into juno/proposed today so we can cut rc2 within the next 24 hours with it, but the fast we can get a better solution into master, the more happiness14:42
remote_morgan_ Hm. Let's merge it now so we can get it for rc fix as a following for better14:42
*** raildo has joined #openstack-keystone14:42
remote_morgan_Yeah. Rc2 in 24hr would be nice.14:43
dstanekthe code looks ok - i have not tried it out14:43
remote_morgan_ dolphm looking at those reviews while on the ground14:47
dolphmremote_morgan_: thanks14:47
*** diegows has quit IRC14:47
*** achampion has quit IRC14:47
tellesnobregaayoung, morganfainberg do you guys have any considerations about the bug regarding if this should be done for UUID or PKI tokens or both?14:47
uvirtbotLaunchpad bug 1291157 in python-keystoneclient "idp deletion should trigger token revocation" [High,Triaged]14:47
*** aix has quit IRC14:48
*** achampion has joined #openstack-keystone14:48
ayoungtellesnobrega, needs to be done for both14:49
tellesnobregaayoung, thanks14:50
remote_morgan_dolphm: +2 on both of those. (Backports)14:52
dolphmtellesnobrega: if it's achieved with a token revocation event, then it covers both14:52
dolphmremote_morgan_: thank you, sir!14:52
*** joesavak has joined #openstack-keystone14:53
remote_morgan_ayoung: I think it only is needed for events not revoke by id.14:55
ayoungremote_morgan_, it is needed for both14:55
ayoungrevocation events are not used yet14:56
remote_morgan_Is it? I thought we determined at the summit/meetup we'd make it event only.14:56
remote_morgan_And events work for uuid tokens now. Just not consumed by middleware *yet*14:56
tellesnobregadolphm, from your comment in the bug, the idea is to check the token by getting the idps. is this the better approach or should it be revoke tokens when deleting idps?14:57
remote_morgan_I'm fine with doing it for both. But just checking if we really needed.14:58
*** aix has joined #openstack-keystone15:00
remote_morgan_Anything else that I anyone needs me to look at before next flight?15:00
dolphmremote_morgan_: WIP backport for henry's patch
dstanekdolphm: does that DB patch work for you? i'm getting lots of DatabaseAlreadyControlledErrors15:01
dolphmdstanek: i haven't run it! let me try15:01
dstanekdolphm: does that DB patch work for you? i'm getting lots of DatabaseAlreadyControlledErrors15:02
dstanekhaha ignore that15:02
*** jistr has quit IRC15:02
remote_morgan_dstanek: had your work layered on top of it?15:02
ayoungremote_morgan_, I guess that means that we can still make the DB backend ephemeral.  I didn't enable it by default.  Has anyone else done so?15:02
*** jistr has joined #openstack-keystone15:02
dstanekremote_morgan_: nope, just did a 'git review -d' and reconfigured the DB settings15:03
*** richm has quit IRC15:03
remote_morgan_Ayoung: I thought we did make it on by default for Juno15:03
*** diegows has joined #openstack-keystone15:03
remote_morgan_Or did we just migrate it by default?15:03
remote_morgan_dstanek: ah.15:04
ayoungcfg.BoolOpt('revoke_by_id', default=True,15:04 in sqlite15:04
ayoungwell would you look at that15:04
remote_morgan_ayoung: ah right.15:04
*** gokrokve_ has joined #openstack-keystone15:05
*** ajayaa has quit IRC15:05
ayoungremote_morgan_, are we going to switch it now, post RC1?15:05
dstanekmorganfainberg: this is very similar to the error i was asking zzzeek about - he though it was some assumption SQA made about sqlite15:05
remote_morgan_ayoung: no let's not change it now.15:06
ayoungremote_morgan_, ok,  lets switch it now for Kilo15:06
ayoungget the early breakage reports15:06
remote_morgan_ayoung: I think we need middleware to consume events first.15:06
remote_morgan_For he PKI case.15:06
remote_morgan_Right?  Revoke by id is the old "revocation " list15:07
ayoungremote_morgan_, feh15:07
ayoungyeah, or we need to link PKI to revoke by id...yuk15:07
ayoungI really think I want to torch the whole concept of revocations15:08
remote_morgan_Yeah. Which would likely break the contract (I'd like revoke by id to be audit ids, but I don't think we can)15:08
ayoungI think we need to move to 5 minute tokens and no revocations15:08
*** gokrokve has quit IRC15:08
remote_morgan_We will have an authz session at the summit to discuss just that. Tokens, fixing them, etx15:08
remote_morgan_Revocations as well15:08
ayoungotherwise it will be bandaid after bandaid15:08
*** Tahmina has quit IRC15:09
remote_morgan_That one and the client one are pretty much guaranteed. The others aren't really set. (CI we'll do as pod / meetup day)15:10
*** henrynash has joined #openstack-keystone15:10
ayoungremote_morgan_, do the other services actually consume the service catalog that is in the Keystone token?15:11
ayoungCuz, if they don't...I have some work to do15:11
ayoungwell, me and lots of other people15:11
remote_morgan_dolphm datanek: henrynash's fix looks good to me, but I can't test it till I'm setup once I land.15:11
remote_morgan_ayoung: some of them, I think, use it (eg nova to cinder). But not 100% sure15:12
dolphmremote_morgan_: i'm testing it now, and running into the problem it's fixing. investigating now15:12
dolphmdstanek: i never got a db already controlled error though15:12
ayoungremote_morgan_, the endpoint part of constraints would get you your ID-only service catalog.15:12
remote_morgan_ayoung: right. And if we can make the full catalog a separate data bit (not in the signed part of the token) it should ease up token size issues significantly (improvement for both uuid and PKI)15:13
dolphmdstanek: this is my test run
dolphmhenrynash: ^15:16
dolphmhenrynash: this is running with your patch against mysql15:16
henrynashdolphm: hmmm15:16
remote_morgan_dstanek: prob need to also drop the migrate_version table. Why you're getting already controlled issues15:16
remote_morgan_dolphm: henrynash ^^15:17
dstanekremote_morgan_: it was a brand new database :-)15:17
henrynashremote_morgan: than is dropped in teardown15:17
remote_morgan_dstanek: right if that table isn't dropped int he cleanup it'll still fail since we re_init the db15:17
remote_morgan_henrynash: ah ok.15:18
remote_morgan_dstanek: between the migrate tests15:18
dstanekremote_morgan_: but doens't that mean that the tests are broken?15:18
remote_morgan_SQLite uses a new (uncontrolled) schema each test.15:18
dstanekit runs fine in sqlite - i'm having the issue with mysql15:19
remote_morgan_And in MySQL we didn't migrate down to 0 when we collapsed the migrates.15:19
dstanekhenrynash's patch that is...15:19
remote_morgan_dstanek: right. SQLite always worked, since it had no state between tests.15:19
dolphmremote_morgan_: why would i not have dstanek's issue then?15:20
remote_morgan_dolphm: looking at your paste. But about to take off so ...15:20
remote_morgan_Back in an hour or so.15:20
dolphmhenrynash: oh your patch is at least missing the region table15:21
remote_morgan_Ok I think the solution here is turning off FK constraints before dropping and turning hem back on at the tests15:21
remote_morgan_Gotta go15:21
dolphmremote_morgan_: ++15:21
*** david-lyle has quit IRC15:22
dstanekdolphm: jas, i'll paste my output15:22
*** david-lyle has joined #openstack-keystone15:22
henrynashdolphm: region table is not part of the initial table set….(the downgrades should delete it)..and if not I drop it anywya in the first part of teardown15:22
dolphmhenrynash: all tests pass for me if you just add 'region' before 'service'15:22
henrynashdolphm: sorry, on another call at the moment, so not quite abelt o gve this my fill attention15:23
dolphmhenrynash: ack15:23
*** arunkant has quit IRC15:24
dolphmdstanek: are you running test_sq_upgrade roughly the same way i iam?15:24
dstaneki'm using - tox -e py27 -- test_sql_upgrade15:24
dstanekdolphm: hmmm different errors now15:29
dolphmdstanek: more or less like mine?15:29
dolphmdstanek: and what changed?15:29
dstaneki'm getting the same errors you have - the relationships won't let the table be removed15:29
dstanekdolphm: no idea, i dropped the table and recreated and it no longer fails that way15:30
dolphmdstanek: the migrate table?15:30
dolphmdstanek: or you mean the whole db?15:30
*** portante_ is now known as portante15:31
dstanekdolphm: yeah, i mean the whole db15:31
dolphmdstanek: i just got a DatabaseAlreadyControlled :) using the same db i was using with nosetests15:31
dstaneki guess it would be a transient issue, but i've tried a dozen time and i can't get it anymore15:31
dstanekwhat was the first error that made removing the tables fail?15:32
dolphmdstanek: keystone.tests.test_sql_upgrade.VersionTests.test_initial_with_extension_version_None failed with DBError: (IntegrityError) (1217, 'Cannot delete or update a parent row: a foreign key constraint fails') '\nDROP TABLE region' ()15:33
*** lufix has quit IRC15:33
*** thedodd has joined #openstack-keystone15:34
dolphmdstanek: i don't understand the db already controlled thing, because between runs the db is empty15:34
dolphmdstanek: oooh, is that a multithreading thing, maybe?15:35
dstanekdolphm: in my case it failed to remove the tables so every test after that failed with a already controlled error15:35
dstanekdolphm: i have the env set to only run one process15:35
*** lcheng has joined #openstack-keystone15:36
dolphmif i set --concurrency=1 then the tests pass15:36
dolphmdstanek: ^15:36
*** sigmavirus24 has left #openstack-keystone15:38
*** cjellick has joined #openstack-keystone15:38
dstanekdolphm: it still fails for me15:40
*** gokrokve_ has quit IRC15:40
*** cjellick has quit IRC15:42
*** lcheng has quit IRC15:43
*** virmitio has joined #openstack-keystone15:44
dstanekdolphm: the only way i get it to work it to replace the table dropping logic15:46
henrynashdstanek: with the oslo-based cleanup?15:50
dstanekhenrynash: yes15:50
dstanekhenrynash, dolphm: do you guys still get errors or is it just me?15:50
*** lcheng has joined #openstack-keystone15:51
*** lcheng has quit IRC15:52
*** cjellick has joined #openstack-keystone15:55
*** cjellick_ has joined #openstack-keystone15:57
*** lcheng_ has joined #openstack-keystone15:58
henrynashdstanek: I’m fine with switching this to the “belt and braces” approach that oslo used....15:58
henrynashdstanek: it shouldn’t be the job of teardown to spot, for instance, that we can’t remove a table if some downgrade method has left an FK hanging around15:59
henrynashdstanek: we just want to blow it out of the water15:59
*** cjellick has quit IRC15:59
*** cjellick has joined #openstack-keystone16:00
*** cjellick_ has quit IRC16:00
henrynashdstanek: do have that implemented locally?  if so, do you want to update the patch with it, or should I ?16:00
dstanekhenrynash: yeah, i have it applied - jas i'll push it16:02
*** jistr has quit IRC16:02
henrynashdtsaneK: cool!  And I assume you dumped the INITIAL_DROP_TABLE_SEQUENCE or whatever I called it?16:02
*** cjellick has quit IRC16:04
*** sigmavirus24 has joined #openstack-keystone16:04
*** cjellick has joined #openstack-keystone16:05
dstanekhenrynash: yes, i'm running the tests now16:06
henrynashdstanek: I’ll give it a whirl as well once you post16:06
*** _cjones_ has joined #openstack-keystone16:07
henrynashdstanek: as an aside, by means of light relief, the spec for deprecation in Kilo is probably ready to +A….I didn’t do it ‘cause otherwise it would be an all IBM approval16:08
henrynashdstanek: we can than at least start pulling the ones that are ready, out16:09
*** jaosorior has quit IRC16:13
*** lcheng_ has quit IRC16:14
*** lhcheng has joined #openstack-keystone16:14
openstackgerritDavid Stanek proposed a change to openstack/keystone: Ensure sql upgrade tests can run with non-sqlite databases.
dstanekhenrynash: ^16:15
dstanekhenrynash: ugg...i didn't change the commit message to match reality16:16
henrynashdstaneK; great, I’ll check it out16:16
dolphmdstanek: have an alternative patch?16:21
openstackgerritA change was merged to openstack/keystone-specs: Remove deprecated items from the Kilo release
dstanekdolphm: no, i just updated it to use oslo's approach16:22
dstaneknow it always works for me on mysql and sqlite16:22
dolphmdstanek: alright, i'll test it16:24
*** wwriverrat has joined #openstack-keystone16:26
*** nellysmitt has quit IRC16:26
dolphmdstanek: awesome, passes with nosetests & tox, with and without concurrency, on mysql16:27
*** nellysmitt has joined #openstack-keystone16:28
dstanekdolphm: with concurrency is probably a fluke - i have a few other patches where i'm working on fixing all of that16:29
dolphmdstanek: it was pretty consistent16:29
*** Guest84187 is now known as mfisch16:30
henrynashdtsanek: I’ve tested it with sqlite, mysql and postgresql and they all seem to work (mind you, they did too with my version :-) )16:30
*** gokrokve has joined #openstack-keystone16:30
*** mfisch is now known as Guest996216:30
henrynashdtsanek: for me, at least - but I prefer your version16:31
dstanekdolphm: henrynash: i have few things baking in my checkouts, but once done i just want to update that commit message16:31
* dolphm is thinking about setting up a CI job for mysql & postgresql16:31
henrynashdolphm: ++16:31
henrynashdolphm: we’ve clearly not been testing the migrations for a while, since I found so many errors that meant the test_sql_upgrade could not have been run with them since16:32
henrynashdolphm: that couldn’t have passed when we release IceHouse16:33
henrynashdolphm: let alone now16:33
dolphmdstanek: i wonder if it would be easier to do that on my own, or to coerce jenkins to run limited tox jobs against mysql & postgres?16:34
dstanekdolphm: that would be great - i have a few fixes that will make the tests run on all non-sqlite databases16:34
*** wwriverrat has left #openstack-keystone16:34
dstanekdolphm: i'm hoping to get them all working on mysql/postgres/etc soon16:34
dstanekdolphm: i've been doing some experimenting and i've started to write a few specs about this later today16:35
*** marcoemorais has joined #openstack-keystone16:36
*** _cjones_ has quit IRC16:36
*** _cjones_ has joined #openstack-keystone16:36
henrynashdolphm: do you want to do the honors for:, the spec has now been approved16:37
henrynashdolphm: I want to hear the sounds of those kvs bits dropping on the floor….16:37
dolphmhenrynash: done!16:38
henrynashdstanek: I think a spec of dos and don’t would be great….there are too many ways of doing things with SQA, that it’s esay to get yourself into trouble16:38
henrynashdolphm: crash, tinkle, crunch….16:39
*** _cjones_ has quit IRC16:41
*** arunkant has joined #openstack-keystone16:42
marekdstevemar: thanks for +2 on osc-mapping16:43
stevemarmarekd, np, thanks for running it :P16:43
marekdstevemar: LOL.16:44
marekdstevemar: anyway, we are *that* close to be able to configure federation with osc only16:44
stevemarmarekd, 1 sec16:44
stevemarmarekd, found 1 error i think16:44
dstanekdolphm: question on catalog substitution when yo have a sec16:44
*** rwsu has joined #openstack-keystone16:44
marekdstevemar: namely?16:44
stevemarmarekd, commented16:45
marekdstevemar: ++++++++++16:46
marekdstevemar: gonna fix it in a sec16:46
marekdi was thinking - do you think enforcing files with rules is a good idea?16:46
*** afazekas has quit IRC16:48
stevemarmarekd, i think that's fine16:48
stevemarwe do that with policy16:48
marekdin osc?16:48
*** aix has quit IRC16:49
marekdstevemar: uploaded new ver.16:49
nkindermarekd: so there are proposed changes to use osc for federation protocol and mapping calls?16:51
marekdnkinder: yes.16:51
marekdnkinder: 1 sec16:51
nkindermarekd: I'd be happy to review and test those16:51
marekdnkinder: and
*** zzzeek has joined #openstack-keystone16:52
*** jorge_munoz has joined #openstack-keystone16:52
nkindermarekd: thanks!16:52
*** gokrokve has quit IRC16:52
marekdnkinder: you welcome! :-)16:52
*** gokrokve has joined #openstack-keystone16:52
nkindermarekd: what's going on around federation support in the CLI?  Is there an auth plug-in that uses ECP in the works?16:54
*** sigmavirus24 is now known as sigmavirus24_awa16:55
marekdnkinder: well, to CRUD idps/protocols/mappings you simply need admin privileges. To authenticate and get unscoped federated token (and later scope it) there are plugins in keystoneclient:
nkindermarekd: yes, I meant actually using SAML federation to get a token16:56
marekdnkinder: so, ECP in general and saml2 plugin from keystoneclient.16:56
nkindermarekd: I didn't realize that was already there16:56
*** _cjones_ has joined #openstack-keystone16:57
nkindermarekd: so as long as the apache module and IdP support ECP, we should be good from the CLI side?16:57
marekdnkinder: correct16:57
nkindermarekd: ok, great.  I will have to see if mod_auth_mellon and Ipsilon have ECP support16:58
nkinderThey both use lasso, and it appears to support ECP16:58
nkinderI haven't really looked into it any further than that though16:58
*** _cjones_ has quit IRC16:58
marekdunfortunately I don't know if mod_mellon has ECP built in.16:59
*** _cjones_ has joined #openstack-keystone16:59
nkindermarekd: simo might know.  I'll check with him.16:59
*** _cjones_ has quit IRC16:59
marekdnkinder: ah, right16:59
*** _cjones_ has joined #openstack-keystone16:59
dolphmdstanek: o/17:00
stevemarnkinder, i think most saml idp plugins has ecp support17:00
marekdstevemar: ++17:01
dolphmdstanek: ooh, we didn't drop that for juno, did we?17:01
*** marcoemorais has quit IRC17:01
dolphmdstanek: looking to drop it for kilo?17:01
marekdnkinder: i think this is becoming kind of standard, just like websso17:01
dstanekdolphm: yes, in kilo - i have a patch somewhere that just removed the abiltity completely17:01
*** bknudson has joined #openstack-keystone17:01
*** marcoemorais has joined #openstack-keystone17:02
*** marcoemorais has quit IRC17:02
dstanekdolphm: do we need to deprecate that functionality or can we just say that they we no longer do any substitution on urls?17:02
remote_morgan_Ok on the ground now...17:02
remote_morgan_dstanek: didn't we deprecate it already?17:02
*** marcoemorais has joined #openstack-keystone17:02
dstanekremote_morgan_: i don't think so - pretty sure we just added the whitelisting17:03
dstaneki could create a deprecation patch for rc if we want that in there17:03
dstanekit would be very noisey because of how may times we generate the catalog17:04
remote_morgan_Well, it *should* only fire once per instantistion right?17:05
remote_morgan_We could formally deprecate in K if it's a hassle.17:06
*** _cjones_ has quit IRC17:06
dstanekremote_morgan_: i can probably do once per catalog request, which could be a lot still17:06
*** _cjones_ has joined #openstack-keystone17:06
dstanekremote_morgan_: i would proabably implement this by cecking if the resulting url and endpoint['url'] are different here
*** _cjones_ has quit IRC17:09
dstanekremote_morgan_: if any are different at all in the 'for' loop i would fire off a deprecation warning17:09
*** _cjones_ has joined #openstack-keystone17:09
remote_morgan_Let's formally deprecate in K then vs squeezing into RC unless you think we *really* need this gone.17:10
remote_morgan_That implementation sounds sane.17:10
dstanekremote_morgan_: now that the hole is closed it's just some code to maintain - deprecate in K and remove in +1?17:11
dolphmdstanek: we need to keep doing tenant_id and user_id for now17:11
dolphmdstanek: for as long as swift depends on it17:11
dolphmdstanek: and whatever other api's have tenant_id in their endpoints17:11
remote_morgan_dstanek: sounds good.17:12
dstanekdolphm: hmmm...ok, that'll make it a bit messy, but doable17:12
dolphmdstanek: yeah -- can we only raise a deprecation when there's something besides tenant_id / user_id in an endpoint?17:12
remote_morgan_dolphm: ah. Good point.17:12
dolphmdstanek: not sure that should go into rc at this point though17:12
dstanekdolphm: i don't know how i would do that exactly, but i'm sure i can come up with something that is somewhat performant17:13
dolphmdstanek: maybe try a hardcoded whitelist of tenant_id / user_id, catch a keyerror, and then fallback on the whitelist with a deprecation warning?17:14
dstanekdolphm: similar to what i was thinking, but i'm going to try not to have a deprecation warning for each url17:15
dstanekfor a catalog that does this in every url it would be super noisy17:15
dolphmdstanek: ah ++17:15
*** lufix has joined #openstack-keystone17:16
dstaneki think i'm going to call format_url twice (or something similar)17:16
remote_morgan_bknudson: you going to continue as he oslo liaison for Keystone? / want to?17:19
bknudsonmorganfainberg: I can continue with it.17:20
bknudsonmorganfainberg: shouldn't be as much to do.17:21
remote_morgan_bknudson: if you're not opposed to continuing, IMO you've done a great job and would def appreciate you continuing.17:22
remote_morgan_Agreed shouldn't be as much as Juno17:22
ayoungdolphm, is there backport potential on PKIZ whitespace patch?
dolphmayoung: it's a performance tune, so i don't think so17:24
dolphmayoung: why should it be in juno?17:24
ayoungdolphm, just the whole "tokens are too big" thing17:24
ayoungI guess its too little of a benefit to backport though17:24
ayoungremote_morgan_, BTW, formal congrats on select for PTL17:25
*** richm has joined #openstack-keystone17:25
remote_morgan_ayoung: thnx17:25
* ayoung still catching up on email17:25
dolphmayoung: if it was major benefit with no risk, i might argue for it, but it's quite late, and there could be a funky json parser out there or whatever17:26
remote_morgan_dolphm: probably some Java implementation.17:27
ayoungI wonder why  SAML doesn't have the size problem?  It must be a full body post of the SAML assertion17:27
*** nellysmitt has quit IRC17:27
remote_morgan_Yeah SAML doesn't go in a header.17:28
marekdremote_morgan_: ++17:28
marekdremote_morgan_: SAML, at least ECP is wrapped with SOAP17:29
remote_morgan_dolphm: we had a dedicated "ops" keystone session outside of the ops track in ATL right?17:30
ayoungSAML sucks,  but Keystpone sucks...differently?  I was going to say more, but I'm not sure that is true17:31
marekdayoung: SAML sucks.17:31
ayoungeverything sucks, just in different ways17:32
*** marekd is now known as marekd|away17:32
stevemarayoung, that's some philosophical stuff right there17:33
*** harlowja has joined #openstack-keystone17:34
*** mewald has joined #openstack-keystone17:35
*** richm has quit IRC17:37
mewaldwhen talks about the "policy service", does this refer to the local policy.json file that dictates permissions within this keystone instance or something else?17:37
*** marcoemorais has quit IRC17:37
*** marcoemorais has joined #openstack-keystone17:38
openstackgerritDavid Stanek proposed a change to openstack/keystone-specs: Enable tests on non-SQLite database
*** diegows has quit IRC17:42
openstackgerritA change was merged to openstack/keystone: Remove identity and assignment kvs backends
mewaldwhat does KVS stand for?17:44
dstanekmewald: key value store17:45
mewaldstevemar: thx, but cannot SQL be a KVS, too, then?17:46
mewaldits a very generic term17:46
mewaldthe document lists KVS next to SQL as a backend service - that's confusing me a bit17:46
dstanekmewald: we mean it more like a dictionary - actually our specific implementation17:46
openstackgerritDavid Stanek proposed a change to openstack/keystone-specs: Enable tests on non-SQLite database
*** amakarov is now known as amakarov_away17:47
mewaldahh so KVS is more like an interface than an actual backend and - given I wanted to - I could implement this interface with a SQL backend (which would be of no point at all as SQL backend already exists) - correct?17:47
dstanekmewald: no it's a backend - if you used it your data would not be in a SQL database17:48
*** amcrn has joined #openstack-keystone17:48
mewaldahh damn I read "your" when you wrote "our"17:49
mewaldgot it - th17:49
dstanekmewald: beside the token backend the rest of them are really for tests17:49
dstanekthere is a review to delete most of the KVS backends this cycle17:49
mewaldtoken backend? I thought there was a token service which could use the KVS backend - confusing is coming back riiiihgght NOW :D17:51
*** david-lyle has quit IRC17:51
dstanekmewald: keystone is divided into subsystems like identity, catalog, token, etc.17:52
dstanekmewald: each of those can be configured to use different backends17:52
dstanekmewald: for example, you could use ldap for identity and sql for everything else17:53
mewaldcan every subsystem use any of the backends?17:53
dstanekno, each subsystem has a different interface for the backend17:54
*** Guest9962 is now known as mfisch17:54
*** lhcheng has quit IRC17:54
*** lhcheng has joined #openstack-keystone17:55
*** mfisch is now known as Guest3382117:55
dstanekmewald: interface definition for catalogs
dstanekmewald: backend implementations
openstackgerritHaneef Ali proposed a change to openstack/keystone: Migrate keystone to use  v3 policy file
mewalddstanek: I see, now I know how to find out the rest :) Would you mind taking care of my first question from before what KVS stands for?17:57
*** diegows has joined #openstack-keystone17:59
dstanekmewald: jas...let me find it17:59
dstanekmewald: me guess it this
mewaldyeah this is what I am talking about18:00
mewalddoesnt sound like local policy.json stuff18:00
*** marcoemorais has quit IRC18:03
*** marcoemorais has joined #openstack-keystone18:03
*** sigmavirus24_awa is now known as sigmavirus2418:04
*** marcoemorais has quit IRC18:04
*** marcoemorais has joined #openstack-keystone18:04
mewalddstanek: this reads more like a central repository for all policy.json files throughout the environment18:05
mewalddoest that cut it?18:05
*** marcoemorais has quit IRC18:05
*** marcoemorais has joined #openstack-keystone18:06
*** dguitarbite has quit IRC18:07
*** amakarov_away has quit IRC18:10
*** amakarov_away has joined #openstack-keystone18:10
*** ayoung has quit IRC18:11
dstanekmewald: i think all of that predates me by a lot - i'm not sure what the intent was18:14
mewaldyou think we're going to see this in the next release?18:15
*** marcoemorais has quit IRC18:17
dstaneksee the policy stuff i linked to?18:19
*** ayoung has joined #openstack-keystone18:20
*** amcrn has quit IRC18:20
mewald ? yeah18:20
dolphmremote_morgan_: yes, regarding ops session18:20
dstanekmewald: that should already be release18:20
dolphmremote_morgan_: ours was apparently one of the few productive out-of-ops-track ops sessions though18:20
dstanekdolphm: mewald brought up a good question...what is keystone.policy used for?18:21
remote_morgan_dolphm: I'll plan to have another one then. I liked it.18:21
dolphmdstanek: as a potential/future HTTP backend to oslo.policy18:21
dstanekdolphm: so it can't be used right now?18:22
dolphmdstanek: no, there's no oslo.policy driver to pull policy blobs from keystone18:22
dolphmdstanek: instead of from local disk (service's policy.json)18:22
dstanekdolphm: since it's in the API doc i would have thought it was usable18:22
dolphmdstanek: the API on keystone's side is certainly useable18:23
dolphmdstanek: it's just nothing is utilizing it18:23
dolphmremote_morgan_: if you're up for a code review, this is dstanek's oslo-based revision of henrynash's patch
*** arborism has joined #openstack-keystone18:24
openstackgerritDavid Stanek proposed a change to openstack/keystone-specs: Enable tests on non-SQLite databases
*** lufix has quit IRC18:28
openstackgerritDavid Stanek proposed a change to openstack/keystone-specs: Enable tests on non-SQLite databases
*** mikedillion has quit IRC18:29
*** mikedillion has joined #openstack-keystone18:30
*** marcoemorais has joined #openstack-keystone18:33
mewaldI just had  a look at the backend-folders in the keystone source code and found that PAM is not listed anywhere. But several documents state is as a backend to the identity subsystem - what's the truth?18:36
*** gyee has joined #openstack-keystone18:37
*** victsou is now known as vsilva18:42
*** david-lyle has joined #openstack-keystone18:46
dstanekmewald: PAM is gone - it was removed a while ago18:46
mewaldaha - where would I be able to track that kind of stuff?18:46
dstanekmewald: where did you see a reference to it?18:47
*** david-lyle_ has joined #openstack-keystone18:47
remote_morgan_dolphm: will look at it post lunch.18:49
mewaldvery good question .. can't find it adhoc18:49
*** david-lyle has quit IRC18:50
dstanekmewald: the functionality was removed in March, but the last bits of code docs where updated to remove it only a few weeks ago18:51
mewaldah probably that's why18:51
mewaldagain: where do you check this kind of thing? (X was removed Y weeks ago)18:51
dstaneki got that from the git history, but there was probably a bug or blueprint18:52
dstanekmewald: or not -
mewaldok thx18:56
mewaldthink I got most of what makes Keystone now :)18:56
*** _cjones_ has quit IRC19:04
*** _cjones_ has joined #openstack-keystone19:05
*** marcoemorais has quit IRC19:05
*** marcoemorais has joined #openstack-keystone19:06
*** marcoemorais has quit IRC19:06
*** marcoemorais has joined #openstack-keystone19:06
*** marcoemorais has quit IRC19:07
dstanekmewald: or not -
*** marcoemorais has joined #openstack-keystone19:07
dstanekmewald: you're welcome - ignore that last link19:07
mewalddone :)19:08
*** _cjones_ has quit IRC19:09
henrynashremote_morgan: are you au fait with the revoke by ID token mechanism?19:15
*** gabriel-bezerra has quit IRC19:15
henrynash(just getting ready for Paris….)19:15
*** lufix has joined #openstack-keystone19:16
mewaldwhich are the supported databases with Keystone? I have learned it uses the ORM SQLAlchemy. Does Keystone generally support all the databases SQLAlchemy supports?19:17
henrynashmewald: yes19:18
*** andreaf has joined #openstack-keystone19:19
henrynashmewald: but the onse we test with are MySQL, DB2, Postgresql19:19
henrynashmewald: I don’t know of anyone trying anything else19:19
mewaldok :)19:19
*** gabriel-bezerra has joined #openstack-keystone19:22
*** lufix has quit IRC19:26
ayoungnkinder, what is the right way to use ldapmodify to add a new memberPrincipal  value?19:27
ayoungI have two machines already set for s4u2proxy dlegation, but I need to add a third19:27
*** andreaf has quit IRC19:27
ayoungmewald, you want the new SSSD goodness!19:27
nkinderayoung: do you have an example of the entry you want to modify?19:28
ayoungnkinder, yep19:28
mewaldhenrynash: how can you guys test with DB2 while SQLAlchemy doesnt list it at all?19:28
ayoung  nkinder   the ldif at the  bottom19:28
henrynashmewald: we have magic pixie-dust19:28
mewaldayoung: what's SSSD?19:28
ayoungmewald, System Services Security Daemon19:28
henrynashmewald: …and also IBM provides a driver to make it work :-)19:29
mewaldsorry my non-native english stops here :D can't follow neither of you19:29
mewaldayoung: already found this but thx :)19:29
ayoungnkinder, right now my ldif is19:29
ayoungchangetype: add19:30
ayoungwould it just be modify?19:30
mewaldhenrynash: so IBM provides a driver that has to be plugged into SQLAlchemy?19:30
nkinderit's still a modify operation, not an add, so changetype is "modify"19:31
henrynashmewald: yes, see “external Dialects” in
mewaldahh nice19:32
ayoungnkinder, I'm so steeeeenkin close on the Kerberos plugin....19:32
nkinderayoung: let me know when there's a new version to try19:32
ayoungnkinder, I;m talking about Horizon19:33
nkinderayoung: ah, cool19:33
ayoungI have not hacked on the RPM yet19:33
nkinderayoung: ok, I can't get back to that until tomorrow at the earliest myself19:33
ayoungnkinder, I need to go back through the #openstakc-keystone logs and find out who I was talking to...the debian mainter for the Keystone packages was the one that said they used the env var approach19:33
* ayoung has no medium term memory for names19:34
ayoungnkinder, but I suspect I missed one of the steps that  Debian uses when dealing with PBR19:34
*** _cjones_ has joined #openstack-keystone19:35
*** nellysmitt has joined #openstack-keystone19:40
*** marcoemorais has quit IRC19:41
ayoungzigo, hey, when you have a moment:  the RPM I built using PBR_VERSION still kciks off a the 'sdist tarball' message at run time...what did I forget or do wrong? Are you building off an sdist tarball?19:41
ayoungzigo, I thought you were building out of git...19:41
*** andreaf has joined #openstack-keystone19:41
ayoungnkinder, discussion re packaging was here:   grep for zigo for the start of it19:42
henrynashayoung: do you know much about the revoke_by_id config setting in token?19:43
ayounghenrynash, nope never heard of it.  Let me see who wrote it....git blame...oh, I did.  Yeah, I know about it19:43
henrynashayoung: :-)19:43
ayounghenrynash, it is the way of saying "do what we've always done"19:43
henrynashayoung: if it is set to True19:43
ayoungie,  revoke by the token id19:44
ayoungand we leave it as true thus far19:44
henrynashayoung: so the comment in the config imples that if the revoke backend is not KVS we should set it to flase19:44
henrynashfalse, even19:44
ayoungshould -> could19:45
ayoungbut the middleware is not able to use it yet19:45
ayoungthat patch died in subcommittee19:45
henrynashayoung: Ok, so since I am just deprecating the revoke kvs backend…I’ll reword the comment for revoke_by_id19:45
ayounghenrynash, ^^ probably needs to be refreshed, as I suspect that some of the changes in keystone server are not yet reflected there19:46
henrynashayoung: ok, thx19:46
ayoungrevoke by ID in KVS...ah, the non-persisted version?19:47
henrynashayoung: I’m not deprecateing the token kvs backend….19:50
henrynashayoung: only the revoke one19:50
ayoung henrynash why?19:50
henrynashayoung: I think the token kvs backend is too valuable19:50
ayounghenrynash, I think you are confusing things19:51
henrynashayoung: wouldn;t be the first time19:51
ayoungthe KVS backend there is for all KVS backends, to include the persisted ones19:51
henrynashayoung: when you say “the KVS backend”, you mean token.backends.kvs yes?19:52
ayoung_KVS_BACKEND = 'openstack.kvs.Memory'  is not a good option19:52
ayoungsomeone deprecated it...19:52
ayoungNot I, said the cat19:52
ayounghenrynash, I think it might have gotten tarred with the "stop unit testing against KVS" brush19:53
henrynashayoung: well, I did….at the request I think of morgan (taking his name in vain)19:53
henrynashayoung: we can, of course, not deprecate it….I suspect the thought was sql was OK for revoke19:54
mewaldis there any site that explains keystone trusts properly? I found this: but for someone who knows nothing about it, it's completely useless19:54
ayounghenrynash, um,  lets not19:54
ayoungI mean, I want to throw out the entire concept of revocations, but that is a different conversation19:54
henrynashOK, suggest you raise an update to:
ayounghenrynash, does this mean we are not going to have any KVS backends at all?  That will make some people sad19:55
morganfainbergdolphm, dstanek, henrynash, theSQL fix is lloking good19:55
dolphmmorganfainberg: woot19:55
dolphmmorganfainberg: i couldn't fault it19:56
morganfainbergdolphm, +319:56
*** jorge_munoz has quit IRC19:56
dolphmmorganfainberg: danke!19:56
henrynashayoung: so tokens, catalog I think survive19:56
henrynashdolphm: yep, it looks good19:57
ayounghenrynash, leave KVS for the time being19:57
dolphmmorganfainberg: unblocked backport henrynash dstanek19:57
*** jorge_munoz has joined #openstack-keystone19:57
henrynashayoung: OK….I’ll leave it for now…19:57
ayounghenrynash, until I have a clear view of what we are doing with revocation events, I don't know if I can get behind removing the KVS backend. It might be the right backend for someone19:58
morganfainbergdolphm, nice19:58
henrynashayoung: ok19:58
ayounghenrynash, I really want to go to 5 minute tokens with no revocations19:58
ayoungreally really19:58
henrynashayoung: understand why19:58
henrynashayoung: I do really19:58
ayoungin which case this whole extension goes away19:58
morganfainbergdolphm, ok +2ing that one as well (backport)19:59
ayoungbut if we are not, and someone is using a memcached backend for tokens, and have worked to replicate it, then the revocation events maybe should piggyback on that work19:59
*** mewald has left #openstack-keystone20:02
*** marcoemorais has joined #openstack-keystone20:05
*** Kui has joined #openstack-keystone20:07
*** dguitarbite has joined #openstack-keystone20:08
*** lhcheng has quit IRC20:08
*** lhcheng has joined #openstack-keystone20:08
*** sigmavirus24 has left #openstack-keystone20:11
*** _cjones_ has quit IRC20:12
*** _cjones_ has joined #openstack-keystone20:12
raildohenrynash, ping20:17
*** gabriel-bezerra has quit IRC20:22
*** virmitio has quit IRC20:25
rm_workHey guys, I have some questions about python-keystoneclient and sessions, regarding using Trusts and Composite auth (scanning through now and it is not clear to me immediately how I would utilize a Trust this way)20:31
dolphmayoung: morganfainberg: ^20:33
ayoungrm_work, what are you trying to do?20:33
rm_workayoung: do you remember the discussions I've had re: Neutron - > Barbican via Trusts and Composite Token auth?20:33
rm_workfor reference:
dolphm(when do mr & mrs jamielennox return?)20:34
*** nellysmitt has quit IRC20:35
rm_workI'm now at a point where I think we have the logistics nailed down -- so I was going to actually implement the basic workflow, but I need to get the Trust Token and then somehow send it through as an auth_plugin to the Barbican Client20:35
rm_workthe Keystone session stuff looks like it all requires a user/pass for auth20:35
*** gabriel-bezerra has joined #openstack-keystone20:36
ayoungrm_work, so when the user first calls LBaaS, you need to establish the trust there and then20:36
rm_workobviously the user/pass I have won't actually work directly for communication with Barbican, because that'll just lead to the generation of our service user's token20:36
rm_workayoung: we have decided to force the user to establish the Trust beforehand20:36
ayoungrm_work, OK,  so the user is required to pass the trustid  in the requst20:36
rm_workthey give us the TrustID, so we have that stored in our DB20:37
* ayoung reads a little closer20:37
ayoungrm_work, OK,  so you want to  know how to execute the trust?20:37
rm_workerr well20:38
rm_workI know how to execute the trust using the keystone client20:38
rm_workbut that gives me a Trust Token20:38
ayoungfor the composite auth, you would pass both tokens20:38
rm_workright, and I know how I would do that if I were just using curl / etc20:38
rm_workbut I am now using python-barbicanclient20:38
ayoungthe trust token goes in  -X-Auth_Token and the service users token goes in -X-Service-TOken or something20:39
rm_workwhich will (soon) be using keystone session as an auth_plugin20:39
rm_workas per
rm_workbut I don't see a way to create a keystone-session using the Trust Token by itself even20:39
rm_worknot to mention the Composite thing20:39
ayoungrm_work, you need jamielennox .  I'm a poor facimile of him20:39
rm_workheh, k20:39
ayoungok...I know some of this20:39
ayoungwe don't a have a trust auth plugin20:40
ayoungyou use the token plugin20:40
ayoungand pass the trust_id along with the token-id20:41
ayoungits one of the base parameters for the auth plugin20:41
rm_workso like20:41
*** david-lyle_ is now known as david-lyle20:42
rm_workv3.Token(token_id= ... , trust_id = ... )20:42
rm_workbut for composite...20:42
ayoungthat is for creating the token itself20:42
ayoungnot sure if we have an abstraction for the composite20:42
rm_workkk I will read more on that section20:42
ayoungI think you might need to explicitly set the second header20:43
rm_workI think I was in the wrong section anyway20:43
ayoungrm_work, I'm not even certain that the composite token work has merged20:44
vsilvahey ayoung, I heard you're the guy for PKI tokens. I'm working on this bug:, and still haven't figured out how dolph's suggestion applies for these newer tokens.20:44
uvirtbotLaunchpad bug 1291157 in python-keystoneclient "idp deletion should trigger token revocation" [High,Triaged]20:44
* ayoung looking in wrong repo...20:44
rm_workI *think* it has20:44
vsilvaHis words: "As discussed in today's keystone meeting, keystoneclient.middleware.auth_token can track valid IdPs on GET /v3/OS-FEDERATION/identity_providers and compare them to tokens to test for validity."20:44
ayoungrm_work, I see it...20:45
rm_workhmm looks like even v2 accepts trust_id=20:45
vsilvaI don't quite have experience with keystone so I might be saying silly stuff here, but I thought PKI tokens didn't go back to keystone - how are we going to get the valid IdPs back from keystone?20:46
rm_workok cool20:46
rm_workthanks ayoung this will definitely do me for now, I was dumb and looking in the wrong spot :)20:46
ayoungrm so I think you need to set -X-SERVICE-TOKEN explicitly20:46
rm_workalright, will look into that20:46
ayoungrm_work, thanks for doing this.20:46
rm_work... or submitting a bug/CR for adding it to the client somehow :)20:46
rm_workwill see what my motivation / sprint manager will allow :)20:47
ayoungrm_work, we def need client support for that20:48
ayoungrm_work, it is possible jamielennox has already submitted it for review20:49
*** junhongl has quit IRC20:49
*** junhongl has joined #openstack-keystone20:49
rm_workI've got a while before we need to really USE this anyway, probably late-kilo20:50
rm_workso i'm not worried yet20:50
rm_workwe'll see20:50
ayoungvsilva, looking20:50
ayoungrm_work, so,  for UUID tokens you need to be able to go from the token, to the userid (in all its forms, trusts and oauth included)  and then for a federated token, you would follow that to the id_mapping table.  At which point I think you would lose the trail, end up hungry and cold in the forest, and get eaten by a grue20:52
ayoungvsilva, you need to figure out what the connection is between IdP and domains.  At this point, I become a smarty pants and say "I told you so" to some of the other devs.  I think we have lost that link20:53
ayoungwell...not is in the mapping tables.20:54
ayoungand when I say tables, I meant the JSON documents for the mapping20:58
rodrigodsayoung, vsilva , let's see if I understood it correctly. Since an IdP is related to a domain, when I delete an IdP I can figure out it's domain (via mappings), look what tokens are related to this domain and them to the revoked list? (PKI tokens)20:58
rodrigodsfor UUID tokens I would delete them from the tokens backend...20:59
ayoungrodrigods, that is the short of it yep20:59
ayoungrodrigods, deal with that first20:59
ayoungrodrigods, for PKI, it will also work20:59
ayoungits the revocation events that are not yet covered, and those would require probably revoking all by domain id21:00
ayoungrodrigods, so IdP -> domain_ids would still come out of the mapping21:00
rodrigodsayoung, nice21:02
vsilvathanks ayoung21:02
rodrigodsayoung, this revoking by domain_id has an bug that we can attack first?21:02
*** marcoemorais has quit IRC21:03
ayoungrodrigods, vsilva oy vey, is it going to be messy21:03
*** marcoemorais has joined #openstack-keystone21:03
ayoungrodrigods, vsilva OK,  I just ran the db sync for the federation extension,  and there is no clear way to map IdP to domain base on the database21:04
ayoungI think we need an explicit rule for that, but I've been overrulled in the past21:04
ayoungvsilva, this is what you get:21:05
ayoungidp_id  to mapping_id21:05
ayoungand in the mapping table21:05
ayoungid  to rules, which are text21:05
lbragstadrodrigods: is h-m not going to be implemented for ldap backends?21:05
raildolbragstad, nope21:05
ayoungand I shall cut short my rant about serializing objects into the database as opposed to normalizing them21:06
ayoungand just state that we need to put an external constraint on what IdP can map to what domain21:06
rodrigodslbragstad, we thought that would be unnecessary pain for now =)21:06
ayoungI think that is the context behind:21:06
ayoungbut even then, I think it misses this point21:07
*** ayoung is now known as ayoung-afk21:07
ayoung-afkGotta go pickup the kids21:07
rodrigodsayoung-afk, ok, we can chat about it latter =)21:07
*** _cjones_ has quit IRC21:08
*** _cjones_ has joined #openstack-keystone21:08
*** raildo is now known as raildo-zzz21:08
*** _cjones_ has quit IRC21:11
*** _cjones_ has joined #openstack-keystone21:11
*** fifieldt_ has joined #openstack-keystone21:14
*** diegows has quit IRC21:15
rodrigodslbragstad, thanks for the review, btw21:17
lbragstadrodrigods: no problem, trying to work through the rest of the series21:17
*** fifieldt has quit IRC21:18
rodrigodslbragstad, ++21:19
openstackgerritRodrigo Duarte proposed a change to openstack/keystone: Improve list role assignments filters performance
*** gyee has quit IRC21:22
rodrigods^ for the brave21:24
*** david-lyle has quit IRC21:27
*** joesavak has quit IRC21:42
*** gordc has quit IRC21:43
*** diegows has joined #openstack-keystone21:45
*** _cjones_ has quit IRC21:56
*** _cjones_ has joined #openstack-keystone21:57
*** _cjones_ has quit IRC21:59
*** _cjones_ has joined #openstack-keystone21:59
*** radez is now known as radez_g0n322:00
*** rkofman has quit IRC22:09
*** rkofman has joined #openstack-keystone22:10
*** vsilva is now known as victsou22:10
*** bknudson has quit IRC22:20
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Add an example of an audit event for a federated user
*** david-lyle has joined #openstack-keystone22:29
*** gyee has joined #openstack-keystone22:32
*** david-lyle_ has joined #openstack-keystone22:35
*** dims has quit IRC22:36
*** dims has joined #openstack-keystone22:37
*** david-lyle has quit IRC22:39
*** dims has quit IRC22:41
*** Dafna has quit IRC22:49
*** henrynash has quit IRC22:49
*** rwsu has quit IRC22:51
*** david-lyle has joined #openstack-keystone22:53
*** dims has joined #openstack-keystone22:56
*** dims has quit IRC22:56
*** david-lyle_ has quit IRC22:56
*** dims has joined #openstack-keystone22:57
*** rwsu has joined #openstack-keystone23:04
*** mikedillion has quit IRC23:11
*** david-lyle has quit IRC23:22
*** david-lyle has joined #openstack-keystone23:23
*** topol has quit IRC23:24
*** thedodd has quit IRC23:30
openstackgerritA change was merged to openstack/keystone: Ensure sql upgrade tests can run with non-sqlite databases.
*** dims has quit IRC23:31
*** dims has joined #openstack-keystone23:31
*** david-lyle has quit IRC23:34
*** dims has quit IRC23:36
*** bknudson has joined #openstack-keystone23:37
*** _cjones_ has quit IRC23:38
*** _cjones_ has joined #openstack-keystone23:39
*** dims has joined #openstack-keystone23:40
*** bknudson has quit IRC23:41
*** _cjones_ has quit IRC23:44
*** _cjones_ has joined #openstack-keystone23:45
*** zzzeek has quit IRC23:49

Generated by 2.14.0 by Marius Gedminas - find it at!