| *** alex_xu has joined #openstack-keystone | 00:00 | |
| *** gokrokve has quit IRC | 00:04 | |
| *** gokrokve has joined #openstack-keystone | 00:04 | |
| *** cjellick_ has quit IRC | 00:08 | |
| *** cjellick has joined #openstack-keystone | 00:08 | |
| *** gokrokve has quit IRC | 00:09 | |
| *** stevemar has joined #openstack-keystone | 00:12 | |
| *** cjellick has quit IRC | 00:13 | |
| *** dims has joined #openstack-keystone | 00:14 | |
| *** dims has quit IRC | 00:19 | |
| *** marcoemorais has quit IRC | 00:28 | |
| *** ayoung has joined #openstack-keystone | 00:39 | |
| *** NM1 has joined #openstack-keystone | 00:42 | |
| openstackgerrit | Nathan Kinder proposed a change to openstack/keystone: Handle default string values when using user_enabled_invert https://review.openstack.org/125243 | 00:42 |
|---|---|---|
| nkinder | ...and with that, I'm out. | 00:42 |
| *** NM2 has joined #openstack-keystone | 00:44 | |
| *** NM3 has joined #openstack-keystone | 00:45 | |
| *** NM1 has quit IRC | 00:46 | |
| *** NM1 has joined #openstack-keystone | 00:46 | |
| *** NM1 has joined #openstack-keystone | 00:47 | |
| *** NM2 has quit IRC | 00:48 | |
| *** nkinder has quit IRC | 00:49 | |
| *** gyee has quit IRC | 00:49 | |
| *** NM3 has quit IRC | 00:50 | |
| *** stevemar has quit IRC | 00:57 | |
| *** gokrokve has joined #openstack-keystone | 01:03 | |
| *** r-daneel has quit IRC | 01:04 | |
| *** diegows has quit IRC | 01:05 | |
| *** NM1 has quit IRC | 01:08 | |
| *** openstackgerrit_ has joined #openstack-keystone | 01:19 | |
| *** HenryG_ has joined #openstack-keystone | 01:22 | |
| *** stevemar has joined #openstack-keystone | 01:24 | |
| *** HenryG has quit IRC | 01:24 | |
| *** ncoghlan has joined #openstack-keystone | 01:29 | |
| *** lcheng has quit IRC | 01:35 | |
| *** lcheng has joined #openstack-keystone | 01:35 | |
| *** dims has joined #openstack-keystone | 01:36 | |
| *** lcheng has quit IRC | 01:40 | |
| *** praneshp has quit IRC | 01:42 | |
| *** ncoghlan is now known as ncoghlan_afk | 01:43 | |
| *** gokrokve has quit IRC | 01:55 | |
| *** leonchio_ has quit IRC | 01:57 | |
| *** amcrn has quit IRC | 02:02 | |
| *** zzzeek has joined #openstack-keystone | 02:05 | |
| *** david-lyle has joined #openstack-keystone | 02:11 | |
| *** HenryG_ has quit IRC | 02:25 | |
| *** zzzeek has quit IRC | 02:34 | |
| *** r1chardj0n3s is now known as r1chardj0n3s_afk | 02:36 | |
| *** praneshp has joined #openstack-keystone | 02:37 | |
| *** jamielennox has quit IRC | 02:40 | |
| *** HenryG has joined #openstack-keystone | 02:41 | |
| *** praneshp_ has joined #openstack-keystone | 02:41 | |
| *** praneshp has quit IRC | 02:41 | |
| *** praneshp_ is now known as praneshp | 02:41 | |
| *** ncoghlan_afk is now known as ncoghlan | 02:41 | |
| *** harlowja is now known as harlowja_away | 02:42 | |
| *** swartulv has quit IRC | 02:42 | |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Ensure sql upgrade tests can run with non-sqlite databases. https://review.openstack.org/125228 | 02:44 |
| *** swartulv has joined #openstack-keystone | 02:44 | |
| *** david-lyle has quit IRC | 02:47 | |
| *** jamielennox has joined #openstack-keystone | 02:48 | |
| openstackgerrit | Nathan Kinder proposed a change to openstack/keystone: Handle default string values when using user_enabled_invert https://review.openstack.org/125243 | 02:49 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Handle default string values when using user_enabled_invert https://review.openstack.org/125243 | 02:52 |
| openstackgerrit | Nathan Kinder proposed a change to openstack/keystone: Handle default string values when using user_enabled_invert https://review.openstack.org/125243 | 02:53 |
| *** nkinder has joined #openstack-keystone | 02:54 | |
| morganfainberg | nkinder, you keep re-proposing the same fixes to master | 02:54 |
| nkinder | morganfainberg: yeah, I pushed to a branch from propsed/juno | 02:54 |
| nkinder | ...but it's going against master in gerrit. What gives? | 02:55 |
| morganfainberg | nkinder, you need to specify the branch with git review | 02:55 |
| morganfainberg | nkinder the .gitreview file says "master" | 02:55 |
| morganfainberg | so git reveiw <branch> | 02:55 |
| nkinder | bah, I don't have it set up to track properly. I must have fixed that for my local icehouse and havana and forget that step :( | 02:55 |
| *** NM1 has joined #openstack-keystone | 02:55 | |
| morganfainberg | nkinder, the .gitreview file wont get updated until stable/juno is cut | 02:55 |
| morganfainberg | nah, we update it for the stable branches | 02:55 |
| nkinder | ok, that makes sense then. Sorry for the noise on this one... | 02:56 |
| morganfainberg | https://github.com/openstack/keystone/blob/stable/havana/.gitreview#L5 | 02:56 |
| morganfainberg | nkinder, haha no worries, let me fix this one again and re-approve it :) | 02:56 |
| morganfainberg | nkinder i'm sure i've done the same thing a bunch :P | 02:56 |
| openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Handle default string values when using user_enabled_invert https://review.openstack.org/125243 | 02:57 |
| morganfainberg | nkinder, ok there ya go | 02:57 |
| morganfainberg | should be gating again | 02:57 |
| nkinder | morganfainberg: thanks! I'll propose it properly for proposed/juno now, cool? | 02:58 |
| morganfainberg | yeah | 02:58 |
| morganfainberg | just make sure you specify the branch you're proposing to. | 02:58 |
| nkinder | yeah, I've done that before for some of our internal git repos | 02:58 |
| nkinder | ok, that's better - https://review.openstack.org/#/c/125257/ | 03:04 |
| morganfainberg | way better | 03:05 |
| nkinder | morganfainberg: I'll NOT screw up when proposing the other 2 issues for proposed/juno :) | 03:05 |
| morganfainberg | hehehe | 03:05 |
| morganfainberg | it's ok, I'm just playing with the health kit stuff on my iphone, so nothing crazy going on here atm | 03:05 |
| *** lcheng has joined #openstack-keystone | 03:07 | |
| *** lcheng has quit IRC | 03:09 | |
| *** lcheng has joined #openstack-keystone | 03:09 | |
| nkinder | my other gating change is up for proposed/juno too now - https://review.openstack.org/#/c/125258/ | 03:10 |
| *** NM1 has quit IRC | 03:10 | |
| nkinder | that just leaves this one which still needs some review love - https://review.openstack.org/#/c/125097/ | 03:11 |
| *** jamielennox has quit IRC | 03:13 | |
| morganfainberg | yeah | 03:15 |
| morganfainberg | i'm looking at it | 03:15 |
| *** jamielenz has joined #openstack-keystone | 03:16 | |
| *** jamielenz is now known as jamielennox | 03:17 | |
| morganfainberg | bleh i don't like using coding utf8, :P | 03:17 |
| *** afaranha has quit IRC | 03:17 | |
| morganfainberg | +2 | 03:17 |
| *** tellesnobrega_ has quit IRC | 03:18 | |
| *** raildo has quit IRC | 03:18 | |
| *** thiagop has quit IRC | 03:18 | |
| *** samuelmz-awaw has quit IRC | 03:18 | |
| *** htruta has quit IRC | 03:18 | |
| *** gabriel-bezerra has quit IRC | 03:18 | |
| *** flwang has joined #openstack-keystone | 03:20 | |
| * morganfainberg sighs... fire alarm.. great... | 03:20 | |
| *** dims has quit IRC | 03:33 | |
| *** richm has quit IRC | 03:36 | |
| *** andreaf has quit IRC | 03:44 | |
| *** andreaf has joined #openstack-keystone | 03:45 | |
| *** amcrn has joined #openstack-keystone | 03:49 | |
| *** wwriverrat has joined #openstack-keystone | 03:56 | |
| stevemar | morganfainberg, both will need to be rechecked | 03:58 |
| stevemar | morganfainberg, the gate is on the floor | 03:59 |
| morganfainberg | aww | 03:59 |
| *** flwang has quit IRC | 04:02 | |
| *** r1chardj0n3s_afk is now known as r1chardj0n3s | 04:04 | |
| *** KanagarajM has joined #openstack-keystone | 04:22 | |
| *** gokrokve has joined #openstack-keystone | 04:38 | |
| *** dguitarbite has quit IRC | 04:55 | |
| *** ncoghlan is now known as ncoghlan_afk | 05:00 | |
| *** samuelmz has joined #openstack-keystone | 05:06 | |
| *** htruta has joined #openstack-keystone | 05:07 | |
| *** raildo has joined #openstack-keystone | 05:08 | |
| *** tellesnobrega has joined #openstack-keystone | 05:08 | |
| *** marcoemorais has joined #openstack-keystone | 05:14 | |
| *** afaranha has joined #openstack-keystone | 05:15 | |
| *** marcoemorais1 has joined #openstack-keystone | 05:15 | |
| *** alex_xu has quit IRC | 05:18 | |
| *** gabriel-bezerra has joined #openstack-keystone | 05:19 | |
| *** marcoemorais has quit IRC | 05:19 | |
| *** r1chardj0n3s is now known as r1chardj0n3s_afk | 05:24 | |
| *** amerine has joined #openstack-keystone | 05:24 | |
| *** NM1 has joined #openstack-keystone | 05:24 | |
| *** ncoghlan_afk is now known as ncoghlan | 05:26 | |
| *** ajayaa has joined #openstack-keystone | 05:27 | |
| *** NM2 has joined #openstack-keystone | 05:27 | |
| *** NM1 has quit IRC | 05:29 | |
| *** dguitarbite has joined #openstack-keystone | 05:32 | |
| *** ajayaa has quit IRC | 05:33 | |
| *** ncoghlan is now known as ncoghlan_afk | 05:36 | |
| *** ncoghlan_afk is now known as ncoghlan | 05:38 | |
| *** ajayaa has joined #openstack-keystone | 05:46 | |
| *** k4n0 has joined #openstack-keystone | 05:47 | |
| *** ukalifon has joined #openstack-keystone | 05:53 | |
| *** gokrokve_ has joined #openstack-keystone | 05:55 | |
| *** andreaf has quit IRC | 05:57 | |
| *** andreaf has joined #openstack-keystone | 05:57 | |
| *** gokrokve has quit IRC | 05:58 | |
| *** gokrokve_ has quit IRC | 05:59 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex https://review.openstack.org/124950 | 06:05 |
| *** r1chardj0n3s_afk is now known as r1chardj0n3s | 06:13 | |
| *** henrynash has joined #openstack-keystone | 06:15 | |
| *** openstackgerrit_ has joined #openstack-keystone | 06:19 | |
| *** gokrokve has joined #openstack-keystone | 06:25 | |
| *** gokrokve has quit IRC | 06:26 | |
| *** gokrokve has joined #openstack-keystone | 06:27 | |
| *** henrynash has quit IRC | 06:29 | |
| *** jedix has quit IRC | 06:30 | |
| *** gokrokve has quit IRC | 06:32 | |
| *** dims has joined #openstack-keystone | 06:33 | |
| *** dims has quit IRC | 06:38 | |
| *** mflobo__ has quit IRC | 06:44 | |
| *** mflobo has joined #openstack-keystone | 06:44 | |
| *** lcheng has quit IRC | 06:47 | |
| *** jedix has joined #openstack-keystone | 06:49 | |
| *** miqui has quit IRC | 06:52 | |
| *** marcoemorais1 has quit IRC | 07:01 | |
| *** Tahmina has joined #openstack-keystone | 07:03 | |
| *** NM1 has joined #openstack-keystone | 07:08 | |
| *** NM2 has quit IRC | 07:08 | |
| *** amcrn has quit IRC | 07:11 | |
| *** andreaf has quit IRC | 07:18 | |
| *** stevemar has quit IRC | 07:18 | |
| *** oomichi has joined #openstack-keystone | 07:18 | |
| *** KanagarajM has quit IRC | 07:25 | |
| *** KanagarajM has joined #openstack-keystone | 07:26 | |
| *** gokrokve has joined #openstack-keystone | 07:28 | |
| *** gokrokve has quit IRC | 07:32 | |
| marekd | mhu: hello | 07:32 |
| *** flwang has joined #openstack-keystone | 07:37 | |
| *** ajayaa has quit IRC | 07:43 | |
| *** NM1 has quit IRC | 07:48 | |
| openstackgerrit | Sergey Kraynev proposed a change to openstack/python-keystoneclient: Using correct keyword for region in v3 https://review.openstack.org/118383 | 07:55 |
| *** jistr has joined #openstack-keystone | 08:02 | |
| *** lsmola has joined #openstack-keystone | 08:04 | |
| *** ajayaa has joined #openstack-keystone | 08:04 | |
| *** ncoghlan has quit IRC | 08:07 | |
| *** bdossant has joined #openstack-keystone | 08:19 | |
| *** ayoung has quit IRC | 08:23 | |
| *** gokrokve has joined #openstack-keystone | 08:28 | |
| mhu | hey marekd | 08:28 |
| *** gokrokve has quit IRC | 08:33 | |
| *** henrynash has joined #openstack-keystone | 08:35 | |
| marekd | mhu: i have a question. | 08:35 |
| mhu | marekd, sure | 08:38 |
| marekd | mhu: (sorry, got distracted). So i want to play with my mapping patches in openstackclient, but even though the entries like mapping_create, mapping_list are in the setup.cfg, when I type openstack -h it doesnt list mapping options | 08:39 |
| marekd | mhu: do you know how to make it usable? | 08:40 |
| mhu | marekd, I actually have had the same problem, turns out the command is likely available, even though it is not listed in the help | 08:41 |
| marekd | mhu: how can i make it appear in that help list? | 08:42 |
| mhu | I need to figure out what's missing. I supposed -wrongly- that declaring the command in setup.cfg was enough | 08:42 |
| mhu | and adding a class docstring, since the help message is the docstring | 08:42 |
| marekd | mhu: L.O.L | 08:43 |
| marekd | mhu: ok i will try | 08:43 |
| mhu | marekd, first one to figure it out should tell the other ! :) | 08:43 |
| mhu | marekd, try to invoke the command, if you added it to setup.cfg it should be available even though the help doesn't show up | 08:45 |
| marekd | mhu: yep. | 08:45 |
| marekd | (osc)marek@cerntop:/srv/openstack/python-openstackclient$ openstack mapping create | 08:47 |
| marekd | ERROR: openstack Unknown command ['mapping', 'create'] | 08:47 |
| marekd | mhu: ^^ | 08:47 |
| marekd | desole | 08:47 |
| mhu | marekd: what does it say with --debug ? | 08:49 |
| marekd | oh, always foget about --debug. It simply raises ValueError from /srv/env/osc/local/lib/python2.7/site-packages/cliff/commandmanager.py find_command | 08:50 |
| marekd | ok, i will need to debug it. | 08:51 |
| mhu | marekd, it might be a long shot, it might be due to a missing dependency. Since the federation stuff is deemed "optional" in keystoneclient, some required libraries are declared in test-requirements (lxml being the culprit) | 08:52 |
| mhu | marekd, therefore they're not installed by default | 08:53 |
| *** NellyK has joined #openstack-keystone | 08:53 | |
| mhu | marekd, and thus the federation-related actions aren't available | 08:53 |
| marekd | hm, looks like osc is ignoring identity.v3 section from setup.cfg | 08:54 |
| marekd | (i tried to export OS_IDENTITY_API=3) | 08:54 |
| *** Daviey has quit IRC | 08:54 | |
| marekd | mhu: http://pasteraw.com/f5obb9uai5wzxg73jgmgml0qlm7y14o | 08:55 |
| marekd | mhu: for a future reference: I think the key is to choose proper identity api | 08:57 |
| marekd | but it still doesn't solve my problem :P | 08:57 |
| *** NellyK has quit IRC | 08:58 | |
| mhu | marekd, what does python -c 'from openstackclient.identity.v3.mapping import ListMapping' return ? | 08:58 |
| marekd | nothing, the class is there. | 08:59 |
| *** Daviey has joined #openstack-keystone | 09:06 | |
| marekd | mhu: to be honest it's even hard for me to imagine whether identity provider/protocols/mappings from keystoneclient will use sessions at the moment. | 09:11 |
| *** praneshp has quit IRC | 09:14 | |
| *** afazekas has joined #openstack-keystone | 09:17 | |
| *** oomichi has quit IRC | 09:20 | |
| openstackgerrit | henry-nash proposed a change to openstack/keystone: Ensure sql upgrade tests can run with non-sqlite databases. https://review.openstack.org/125228 | 09:20 |
| *** andreaf_ is now known as andreaf | 09:23 | |
| *** flwang has left #openstack-keystone | 09:23 | |
| mhu | marekd: how do you mean ? | 09:24 |
| *** gokrokve has joined #openstack-keystone | 09:26 | |
| marekd | mhu: well, it still uses some client classes that I am not sure atm if they use keystoneclient.Session | 09:30 |
| *** gokrokve has quit IRC | 09:31 | |
| *** nellysmitt has joined #openstack-keystone | 09:42 | |
| openstackgerrit | henry-nash proposed a change to openstack/keystone: Ensure sql upgrade tests can run with non-sqlite databases. https://review.openstack.org/125228 | 09:58 |
| *** amakarov has joined #openstack-keystone | 10:17 | |
| *** gokrokve has joined #openstack-keystone | 10:26 | |
| *** jaosorior has joined #openstack-keystone | 10:27 | |
| *** gokrokve has quit IRC | 10:30 | |
| *** KanagarajM has quit IRC | 10:40 | |
| *** diegows has joined #openstack-keystone | 10:51 | |
| *** aix has joined #openstack-keystone | 10:55 | |
| *** dims has joined #openstack-keystone | 11:12 | |
| *** henrynash has quit IRC | 11:24 | |
| *** henrynash has joined #openstack-keystone | 11:26 | |
| *** gokrokve has joined #openstack-keystone | 11:26 | |
| *** gokrokve has quit IRC | 11:31 | |
| *** ajayaa has quit IRC | 11:37 | |
| *** aix has quit IRC | 11:40 | |
| *** aix has joined #openstack-keystone | 11:41 | |
| *** ayoung has joined #openstack-keystone | 11:47 | |
| *** aix has quit IRC | 12:01 | |
| *** alex_xu has joined #openstack-keystone | 12:10 | |
| *** aix has joined #openstack-keystone | 12:14 | |
| *** dims has quit IRC | 12:21 | |
| *** dims has joined #openstack-keystone | 12:21 | |
| *** henrynash has quit IRC | 12:22 | |
| *** gokrokve has joined #openstack-keystone | 12:26 | |
| *** Gippa has joined #openstack-keystone | 12:28 | |
| *** gokrokve has quit IRC | 12:31 | |
| marekd | dolphm: easy review: https://review.openstack.org/#/c/124767/1, already got +2 from stevemar. | 12:44 |
| *** gordc has joined #openstack-keystone | 12:59 | |
| *** NM1 has joined #openstack-keystone | 13:05 | |
| *** richm has joined #openstack-keystone | 13:07 | |
| marekd | mhu: if you have time, can you take a look on this patch and check if mappings work on your env: https://review.openstack.org/#/c/86912/ | 13:09 |
| *** joesavak has joined #openstack-keystone | 13:15 | |
| *** NM1 has quit IRC | 13:19 | |
| amakarov | Greetings! Found this: https://wiki.openstack.org/wiki/Keystone/Trusts | 13:19 |
| amakarov | Does delegation chain actually works? | 13:20 |
| amakarov | >> A final parameter, delegation depth, says whether the delegation is recursive or not, and if recursive specifies the length of the delegation chain. | 13:20 |
| amakarov | In "create_trust" API call transitive delegation is blocked | 13:22 |
| amakarov | Is there any document about delegation chain internals? | 13:23 |
| *** Tahmina has quit IRC | 13:23 | |
| *** gokrokve has joined #openstack-keystone | 13:26 | |
| *** afazekas has quit IRC | 13:30 | |
| *** gokrokve has quit IRC | 13:31 | |
| mhu | marekd, sure | 13:33 |
| *** afazekas has joined #openstack-keystone | 13:33 | |
| *** nellysmitt has quit IRC | 13:36 | |
| Daviey | ayoung: Hey, just to check.. Did your p-k-k branch work with keystoneclient --os-auth-plugin / OS_AUTH_PLUGIN 'kerberos'? | 13:39 |
| Daviey | ayoung: I was reading http://www.jamielennox.net/blog/2014/09/15/how-to-use-keystoneclient-sessions/ , but that seemed to imply you need a separate wrapper.. but surely that can't be right? | 13:41 |
| *** topol has joined #openstack-keystone | 13:42 | |
| *** nellysmitt has joined #openstack-keystone | 13:47 | |
| *** gokrokve_ has joined #openstack-keystone | 13:48 | |
| *** gokrokve_ has quit IRC | 14:02 | |
| *** gokrokve has joined #openstack-keystone | 14:03 | |
| *** gokrokve_ has joined #openstack-keystone | 14:06 | |
| *** alex_xu has quit IRC | 14:07 | |
| *** gokrokve has quit IRC | 14:08 | |
| *** stevemar has joined #openstack-keystone | 14:10 | |
| *** sigmavirus24 has joined #openstack-keystone | 14:14 | |
| topol | Keystone cores, what is typical amount of time of warning given before a dperecated feature is pulled from the code base? | 14:15 |
| topol | two release cycles or one? | 14:15 |
| *** openstackgerrit has quit IRC | 14:18 | |
| *** openstackgerrit has joined #openstack-keystone | 14:18 | |
| *** bknudson has joined #openstack-keystone | 14:19 | |
| *** alex_xu has joined #openstack-keystone | 14:22 | |
| *** nellysmitt has quit IRC | 14:23 | |
| dstanek | topol: maybe marked as deprecated in one release and removed in the next. | 14:23 |
| topol | dstanek, THANKS!!! | 14:23 |
| dstanek | topol: i think oslo has a deprecate in N and remove in N+2 | 14:23 |
| dstanek | topol: what are you looking to deprecate? | 14:24 |
| topol | dstanek, I must say how keystone handles deprecation via decorator seems much better than another project I just looked at | 14:24 |
| dstanek | topol: also APIs may be longer? not sure | 14:25 |
| topol | dstanek, makes sense | 14:25 |
| topol | dstanek if you are curious: https://review.openstack.org/#/c/121824/ | 14:25 |
| *** henrynash has joined #openstack-keystone | 14:27 | |
| *** david-lyle_ has joined #openstack-keystone | 14:30 | |
| gordc | topol: there's a deprecated decorator in oslo... whether anyone uses it is another matter: https://github.com/openstack/oslo-incubator/blob/master/openstack/common/versionutils.py#L33 | 14:35 |
| bknudson | gordc: that's what we use. | 14:35 |
| gordc | bknudson: oh... well that answers that. :) | 14:35 |
| bknudson | I think we wrote it. | 14:36 |
| bknudson | I've got a question about some server behavior and a test... | 14:36 |
| gordc | bknudson: that'd explain it... i used it once. | 14:36 |
| bknudson | so the server generates a token and the response has a token in the body | 14:36 |
| gordc | thanks to keystone folks i guess. | 14:36 |
| bknudson | should I be able to take the body of the response, run cms_sign_token, and get the same token ID? | 14:37 |
| bknudson | the problem is, I think that json.dumps(token_dict) isn't going to always generate the same JSON | 14:37 |
| *** dhellmann has joined #openstack-keystone | 14:38 | |
| bknudson | I assume it can reorder the fields in the dict | 14:38 |
| *** dhellmann has quit IRC | 14:38 | |
| openstackgerrit | henry-nash proposed a change to openstack/keystone-specs: Add an extension to store domain specific configuration in SQL. https://review.openstack.org/123238 | 14:38 |
| bknudson | is there an application that would require being able to cms_sign_token the token body? | 14:40 |
| topol | Hey gordc, since you are around. I got some folks using ceilometer and after it runs for a month with little activity the database gets so big that the time it takes to run statistics queries is causing problems with actually triggering autoscaling behavior. | 14:40 |
| *** david-lyle_ is now known as david-lyle | 14:40 | |
| topol | gordc, have you heard of that happening? | 14:40 |
| *** YorikSar has quit IRC | 14:40 | |
| *** dhellmann has joined #openstack-keystone | 14:41 | |
| *** ukalifon has quit IRC | 14:42 | |
| ayoung | Daviey, I haven't tried yet. Let me see | 14:42 |
| gordc | topol: yeah, i've heard. would it be possible to get a sense of the data collected? ie size of sample/meter/resource tables? | 14:43 |
| gordc | topol: i'm not sure we have any formal advice on how to archive data but i think it's something we should add in ceilometer as we get more and more users playing with it. | 14:43 |
| ayoung | Daviey, I don't think the keystone client does that yet. I think you need the openstack common client...something I've managed to break on my test system | 14:44 |
| gordc | topol: i'm not sure any of the juno changes will improve the amount of data stored... it was improved for sql backends but i'm pretty sure mongodb will remain just as verbose in juno as in icehouse. | 14:44 |
| topol | gordc, I will have michael elder email you the details. Can you PM me your preferred email? | 14:44 |
| gordc | topol: sure. | 14:45 |
| topol | gordc THANKS | 14:45 |
| *** nellysmitt has joined #openstack-keystone | 14:45 | |
| ayoung | Daviey, and it does not look like that takes --os-auth-plugin yet | 14:45 |
| *** openstackgerrit has quit IRC | 14:47 | |
| *** openstackgerrit has joined #openstack-keystone | 14:48 | |
| *** dhellmann_ has quit IRC | 14:57 | |
| *** thedodd has joined #openstack-keystone | 14:57 | |
| *** dhellmann_ has joined #openstack-keystone | 15:01 | |
| *** openstackgerrit has quit IRC | 15:02 | |
| *** openstackgerrit has joined #openstack-keystone | 15:02 | |
| *** Gippa has quit IRC | 15:05 | |
| *** dhellmann_ has quit IRC | 15:05 | |
| *** henrynash has quit IRC | 15:06 | |
| *** dhellmann_ has joined #openstack-keystone | 15:06 | |
| amakarov | Who knows anything about delegation chain? | 15:06 |
| *** sigmavirus24 is now known as sigmavirus24_awa | 15:08 | |
| Daviey | ayoung: Okay, good.. Thanks | 15:08 |
| *** nellysmitt has quit IRC | 15:08 | |
| *** cjellick has joined #openstack-keystone | 15:09 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 15:10 | |
| *** andreaf_ has joined #openstack-keystone | 15:13 | |
| *** andreaf has quit IRC | 15:13 | |
| *** andreaf_ is now known as andreaf | 15:13 | |
| *** andreaf_ has joined #openstack-keystone | 15:13 | |
| ayoung | Daviey, I'm sure it is coming...jamielennox is off for another week or two, but I know its in his queue | 15:18 |
| *** mitz_ has quit IRC | 15:18 | |
| *** marekd is now known as marekd|away | 15:18 | |
| ayoung | bknudson, I would say "No" | 15:18 |
| ayoung | unless you had an algorithm that assured the text was identical, I would not expect to get an identical signature | 15:19 |
| *** alex_xu has quit IRC | 15:22 | |
| *** NM1 has joined #openstack-keystone | 15:23 | |
| *** mitz_ has joined #openstack-keystone | 15:23 | |
| *** dhellmann_ has quit IRC | 15:26 | |
| *** dhellmann_ has joined #openstack-keystone | 15:28 | |
| chmouel | keystonemiddleware tests get stucks when I run them, stracing the python process get me some "Too many open files" errors http://paste.openstack.org/raw/49asAlBw1i5l2rkIJDZ7/ | 15:29 |
| chmouel | the worrying part is testr looping forever and growing the cpu/memory | 15:29 |
| chmouel | waiting to get resource | 15:30 |
| chmouel | did anyone else experienced that? | 15:30 |
| chmouel | and control-c on tox is not killing it properly i have runaway testr which i have to kill with pkill -9 -f "subunit.run discover" | 15:32 |
| bknudson | ayoung: that sounds right to me, too. I'm going to see about changing the test... not sure what it should do instead just yet. | 15:33 |
| bknudson | or if I just remove the test | 15:33 |
| ayoung | which test? | 15:34 |
| *** dhellmann has quit IRC | 15:34 | |
| *** dhellmann_ is now known as dhellmann | 15:34 | |
| *** jasondotstar has joined #openstack-keystone | 15:34 | |
| bknudson | ayoung: see http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_v3_auth.py#n146 | 15:34 |
| bknudson | it's actually one you modified recently for pkiz support | 15:35 |
| bknudson | it does cms_sign_token on the response body and compares that to X-Subject-Token | 15:35 |
| bknudson | which usually works since the X-Subject-Token JSON is the same as the body JSON | 15:36 |
| bknudson | but will fail if they're not exactly the same. | 15:36 |
| ayoung | http://csrc.nist.gov/groups/SNS/rbac/documents/kuhn-coyne-weil-10.pdf Very interesting | 15:42 |
| *** mikedillion has joined #openstack-keystone | 15:42 | |
| ayoung | bknudson, yeah, I kindof wondered about that at the time...probably too strict a test | 15:43 |
| ayoung | self.assertEqual(expected_token_id, token_id) probably should be changed to something like: make sure we can validate the id | 15:43 |
| morganfainberg | chmouel, i've not experienced that. | 15:44 |
| bknudson | ayoung: that's what I was thinking... I'm also thinking there must be a test for that already. | 15:44 |
| ayoung | bknudson, is valid pki token? Hmmm | 15:45 |
| morganfainberg | chmouel, there was the buggy release of setuptools | 15:46 |
| ayoung | bknudson, I wasn't sure how to test it without basically making the code self referential | 15:46 |
| ayoung | that is why I cached one and test against the cached | 15:46 |
| morganfainberg | chmouel, that caused massive memory leaks, you didn't happen to snag that did you somehow? | 15:46 |
| bknudson | ayoung: I don't think there's anything that can be asserted about a relationship between the body and the PKI... maybe the token ID could be decoded and the dicts compared | 15:46 |
| ayoung | bknudson, yeah | 15:47 |
| bknudson | maybe the size of the dicts ... sorry, just making a dict joke. | 15:47 |
| morganfainberg | bknudson, heh | 15:47 |
| ayoung | bknudson, give it a whirl...I'd like it if other people were more comfortable with the openssl calling code | 15:47 |
| *** wwriverrat has quit IRC | 15:47 | |
| bknudson | I'll try decoding the PKI token and comparing. | 15:48 |
| ayoung | bknudson, you know what I learned recently? If you die in Canada, you die in real life. | 15:48 |
| ayoung | ++ | 15:48 |
| bknudson | ayoung: I'm surprised by that, but good to know. | 15:49 |
| *** lcheng has joined #openstack-keystone | 15:49 | |
| ayoung | yeah, important safety tip | 15:49 |
| *** jamielennox has quit IRC | 15:49 | |
| ayoung | bknudson, morganfainberg chmouel what do you guys think of standardizing the ids for Services? not endpoints, but "Keystone" "Neutron" all having fixed UUIDs for Ids? | 15:50 |
| ayoung | Not sure why they are dynamic, but it will make sharing data across keystones much harder | 15:50 |
| bknudson | ayoung: the user ID? | 15:51 |
| *** nellysmitt has joined #openstack-keystone | 15:54 | |
| ayoung | bknudson, no, the service id iteself | 15:56 |
| *** henrynash has joined #openstack-keystone | 15:56 | |
| ayoung | https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#services-v3services | 15:57 |
| ayoung | about one screen down | 15:57 |
| ayoung | Example entity: | 15:57 |
| ayoung | { | 15:57 |
| ayoung | "service": { | 15:57 |
| ayoung | "enabled": true, | 15:57 |
| ayoung | "id": "ee057c", | 15:57 |
| bknudson | yep... made me think about the templated backend and if services have IDs in there. | 15:58 |
| ayoung | why should "Keystone" for Rackspace have a different id than "Keystone" for IBM? | 15:58 |
| bknudson | if we're going to set the ID to a known value then seems like we could just use the type instead. | 15:59 |
| ayoung | yep | 15:59 |
| *** jamielenz has joined #openstack-keystone | 16:00 | |
| ayoung | I doubt anything is actually using the id | 16:00 |
| ayoung | its kindof meaningless | 16:00 |
| *** jamielenz is now known as jamielennox | 16:00 | |
| ayoung | joesavak, any idea why the "Service" entity has an id on it? | 16:00 |
| *** jsavak has joined #openstack-keystone | 16:03 | |
| *** afazekas has quit IRC | 16:04 | |
| *** joesavak has quit IRC | 16:04 | |
| *** k4n0 has quit IRC | 16:05 | |
| *** jamielennox has quit IRC | 16:08 | |
| *** alex_xu has joined #openstack-keystone | 16:15 | |
| *** raildo_ has joined #openstack-keystone | 16:16 | |
| *** jamielennox has joined #openstack-keystone | 16:16 | |
| *** colettecello has joined #openstack-keystone | 16:17 | |
| *** BAKfr has quit IRC | 16:17 | |
| *** gothicmindfood has quit IRC | 16:17 | |
| *** raildo has quit IRC | 16:17 | |
| *** harlowja_away has quit IRC | 16:17 | |
| *** rharwood has quit IRC | 16:17 | |
| *** ayoung has quit IRC | 16:17 | |
| *** openstackgerrit has quit IRC | 16:18 | |
| *** openstackgerrit has joined #openstack-keystone | 16:18 | |
| openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Fix tests comparing tokens https://review.openstack.org/125406 | 16:18 |
| *** ayoung has joined #openstack-keystone | 16:18 | |
| *** BAKfr has joined #openstack-keystone | 16:19 | |
| *** rharwood has joined #openstack-keystone | 16:19 | |
| *** samuelmz has quit IRC | 16:20 | |
| morgan_remote_ | ayoung: I actually like the concept of registered service ids. Similar to the IANA port assignments. | 16:23 |
| ayoung | morgan_remote_, I had made that connection, too | 16:24 |
| morgan_remote_ | We could publish the "known" services (this plays into the tc "big tent" conversation). Which also doesn't preclude deployers adding their own services. | 16:25 |
| openstackgerrit | David Stanek proposed a change to openstack/keystone: Middleware tests now run under Python3 https://review.openstack.org/99669 | 16:25 |
| openstackgerrit | David Stanek proposed a change to openstack/keystone: Adds a fork of python-ldap for Py3 testing https://review.openstack.org/95827 | 16:25 |
| openstackgerrit | David Stanek proposed a change to openstack/keystone: Mocks out the memcache library for tests https://review.openstack.org/125409 | 16:25 |
| openstackgerrit | David Stanek proposed a change to openstack/keystone: Fixes a type check to make it work in Python 3 https://review.openstack.org/125410 | 16:25 |
| *** gyee has joined #openstack-keystone | 16:25 | |
| *** diegows has quit IRC | 16:26 | |
| morgan_remote_ | This is definitely a case where random uuids do not make "sense" (though we need to handle transition to this model if we go there) | 16:26 |
| morgan_remote_ | Then again. We could just make service name == id. | 16:27 |
| *** Tahmina has joined #openstack-keystone | 16:27 | |
| *** marcoemorais has joined #openstack-keystone | 16:28 | |
| *** grantbow has quit IRC | 16:28 | |
| morgan_remote_ | And name == ID might be simpler (doe the uuids buy us anything besides fixed length, often longer than the name of the service) | 16:29 |
| * morgan_remote_ kicks autocorrect | 16:29 | |
| *** gokrokve_ has quit IRC | 16:31 | |
| *** colettecello is now known as gothicmindfood | 16:33 | |
| *** leonchio_ has joined #openstack-keystone | 16:35 | |
| *** grantbow has joined #openstack-keystone | 16:40 | |
| *** david-lyle has quit IRC | 16:43 | |
| *** grantbow has quit IRC | 16:44 | |
| morgan_remote_ | dolphm: gordc do we want to add keystone-core to pycadf-core? Not saying we won't have separate cores for pycadf. Just seeing what makes sense from a reviewer standpoint (cc topol ) | 16:44 |
| openstackgerrit | Chmouel Boudjnah proposed a change to openstack/keystonemiddleware: Encode middleware error message as bytes https://review.openstack.org/123451 | 16:45 |
| *** diegows has joined #openstack-keystone | 16:47 | |
| dolphm | morgan_remote_: no preference here - depends on who's interested in contributing IMO | 16:47 |
| *** david-lyle has joined #openstack-keystone | 16:49 | |
| *** wwriverrat has joined #openstack-keystone | 16:52 | |
| topol | who is morgan_remote_ ??? you should register a nickname :-) | 16:52 |
| *** jaosorior has quit IRC | 16:53 | |
| morgan_remote_ | topol: hah. I haven't gotten around to it since I use irccloud (little different workflow). | 16:53 |
| morgan_remote_ | dolphm: ++ makes sense. | 16:54 |
| topol | morgan_remote_, dolphm, seems like the pycadf cores and keystone cores have different expertises, no? | 16:54 |
| topol | although some folks like stevemar seem to know both | 16:55 |
| stevemar | what the who | 16:55 |
| dolphm | +1 for stevemar on pycadf-core | 16:56 |
| stevemar | dolphm, do i have a choice? (kidding!) | 16:56 |
| morgan_remote_ | I just want to ensure we have enough eyes on changes for pycadf to support reviewing the code since we (keystone) own it from a program sense | 16:56 |
| morgan_remote_ | stevemar: voluntold! | 16:56 |
| morgan_remote_ | Not that there is a lot of traffic to pycadf at the moment. | 16:57 |
| topol | I can start focusing more on pycadf too if that helps | 16:57 |
| morgan_remote_ | Sure. Let's just make sure it keeps getting appropriate amounts of love | 16:58 |
| morgan_remote_ | Also making sure the bugs get triaged as they are reported. | 16:59 |
| *** gyee has quit IRC | 16:59 | |
| *** thedodd has quit IRC | 17:00 | |
| dstanek | topol: i've been wanting to get more into CADF after that call with Matt | 17:01 |
| topol | dstanek, cool | 17:01 |
| topol | Im guessing dolphm will have a list of some refactorings that he wants to see happen in pycadf. That kind of low fruit is good for folks like me | 17:03 |
| topol | and morgan_remote_ may have some thoughts there too | 17:03 |
| morganfainberg | ok so... | 17:04 |
| morganfainberg | ok so stevemar, in all seriousness, you interested in helping more with pycadf? | 17:04 |
| topol | yes he is :-) | 17:04 |
| morganfainberg | i'll avoid adding all of keystone-core unless we *all* really want to keep eyes on it. | 17:04 |
| stevemar | morganfainberg, in all seriousness i can handle it, and am interested | 17:05 |
| morganfainberg | k | 17:05 |
| topol | stevemar has been doing a great job with it | 17:05 |
| morganfainberg | topol, i assume Matt Rutkowski is still working on it? | 17:05 |
| stevemar | he's working on the spec stuff | 17:05 |
| morganfainberg | ok i'm just looking at the pycadf core team | 17:06 |
| topol | yes, drives it from the stds side. and folks like stevemar and me will add to the code | 17:06 |
| morganfainberg | k | 17:06 |
| morganfainberg | stevemar, added you to pycadf core | 17:06 |
| stevemar | yay | 17:06 |
| morganfainberg | dhellmann, ping re: pycadf, do you have any interest in staying on as pycadf-core? [don't want to remove you if you are legitimately interested] | 17:06 |
| morganfainberg | dhellmann, same question about Julien Danjou if you know. | 17:07 |
| *** grantbow has joined #openstack-keystone | 17:08 | |
| morganfainberg | ok added topol as well, and added stevemar and topol to the drivers for the LP project | 17:09 |
| morganfainberg | so you guys can help triage the bugs etc | 17:09 |
| topol | k | 17:10 |
| *** radez_g0n3 is now known as radez | 17:10 | |
| morganfainberg | dstanek, obviously if you're interested as well i'm good with adding you, and i feel much more comfortable with a few more people looking at it for when issues do crop up | 17:10 |
| morganfainberg | topol, stevemar, thanks | 17:10 |
| dstanek | morganfainberg: that would be fine by me | 17:11 |
| morganfainberg | dstanek, ok i'll add you as well. | 17:11 |
| *** jistr has quit IRC | 17:13 | |
| *** joesavak has joined #openstack-keystone | 17:14 | |
| *** gyee has joined #openstack-keystone | 17:15 | |
| *** harlowja has joined #openstack-keystone | 17:15 | |
| *** jsavak has quit IRC | 17:16 | |
| *** praneshp has joined #openstack-keystone | 17:18 | |
| *** zzzeek has joined #openstack-keystone | 17:23 | |
| *** gokrokve has joined #openstack-keystone | 17:23 | |
| *** lsmola has quit IRC | 17:31 | |
| amakarov | morganfainberg, Hi! I'd like to develop a delegation(trust) chain according https://wiki.openstack.org/wiki/Keystone/Trusts | 17:37 |
| amakarov | I looked into the code and as far as I understand there is no way to delegate trusts | 17:37 |
| morganfainberg | amakarov, right now no, we've had discussion on this topic. though and there is definite interest in it | 17:38 |
| morganfainberg | amakarov, i *thought* we had a spec we had discussed for this... | 17:39 |
| morganfainberg | amakarov, https://github.com/openstack/keystone-specs/blob/master/specs/kilo/trusts-redelegation.rst | 17:39 |
| amakarov | morganfainberg, should I start with a blueprint? Oh, i'll see this spec, thanks | 17:39 |
| *** jaosorior has joined #openstack-keystone | 17:40 | |
| morganfainberg | amakarov, so definitely sync up with shardy (he's usually in #head if not here) and that is definitely something we want in Kilo! | 17:40 |
| morganfainberg | #heat | 17:40 |
| morganfainberg | sorry, typos abound today | 17:40 |
| ayoung | might want to include me on the discussion, too. I have a passing interest in trusts | 17:41 |
| morganfainberg | amakarov, i also know ayoung is a good resource for anything trust related, but don't hesitate to ask any of us here | 17:41 |
| amakarov | morganfainberg, my collegues also directed me to #heat channel and suggested to communicate with Steven Hardy there ) | 17:41 |
| morganfainberg | ayoung, haha, beat me to it | 17:41 |
| morganfainberg | amakarov, fantastic! it'll be nice to have the redelegation bits together this cycle. | 17:42 |
| morganfainberg | or subdelgation.. or chain-delegation (whatever we want to call it) | 17:42 |
| morganfainberg | amakarov, and the spec is already approved. | 17:43 |
| amakarov | morganfainberg, thanks for the tip ) | 17:43 |
| ayoung | amakarov, ok, here is the fundamental rule of trusts | 17:43 |
| ayoung | everything is checked to be valid when you execute the trust | 17:43 |
| morganfainberg | amakarov, i do recommend trying to work on/land the code as early as possible in the Kilo cycle. I am aiming to have new features land as early as possible, so we can ensure others can consume it and we get lots of drive time with it. | 17:44 |
| amakarov | ayoung, btw, I'd like to whine a little about my change proposal's review )) | 17:44 |
| ayoung | so, I create a trust for morganfainberg and he wants to redelegate to bknudson who redelegates to you, all those links in the chain need to be checked when you create a token using that trust | 17:44 |
| ayoung | amakarov, I like to call it whinging. Whinge away. | 17:45 |
| bknudson | I'll just get my own token | 17:45 |
| amakarov | some thoughts: https://docs.google.com/a/mirantis.com/drawings/d/1ZAA-9XydF_HjgbT7FSZ_ekfz7WjaF4MXYGW0awwKEcM/edit | 17:45 |
| *** wwriverrat has left #openstack-keystone | 17:46 | |
| amakarov | ayoung, whould you please look at that again? :) https://review.openstack.org/#/c/118590/ | 17:47 |
| morganfainberg | ayoung, also have some definite interest internal to HP (will have more info) on session/limited rescope [no scoped token rescope] implementations | 17:47 |
| morganfainberg | ayoung, i'll have more info after my trip next week | 17:47 |
| openstackgerrit | A change was merged to openstack/keystone: Fix parsing of emulated enabled DN https://review.openstack.org/125083 | 17:50 |
| *** thedodd has joined #openstack-keystone | 17:52 | |
| ayoung | amakarov, will do. Ask nkinder too, as he has established himself as our resident LDAP guru. a Decade working on a Directory server has taught him a thing or two about LDAP | 17:53 |
| *** henrynash has quit IRC | 17:54 | |
| ayoung | morganfainberg, cool on the rescope. I'm starting to think the only reason to have unscoped tokens is for Horizon. If we go with tokenless and the basic-auth approach, we can probably greatly simplify our story | 17:55 |
| * ayoung going to refresh the basic-auth patch and write a spec for it | 17:55 | |
| *** radez is now known as radez_g0n3 | 17:56 | |
| ayoung | jamielennox are you really around, or did you set your IRC client to start upon machine reboot? | 17:56 |
| ayoung | we really need some bench depth on client issues | 17:58 |
| openstackgerrit | ayoung proposed a change to openstack/keystone-specs: Token Constraints https://review.openstack.org/123726 | 17:59 |
| amakarov | nkinder, whould you kindly review my code again? https://review.openstack.org/#/c/118590/ | 18:00 |
| nkinder | amakarov: sure | 18:00 |
| nkinder | amakarov: ah, that one. | 18:00 |
| nkinder | So I'm still not sure it's really necessary. | 18:00 |
| ayoung | nkinder, thanks. I was looking at it, and it looked sane, but then, sane and LDAP are often seen together, but are not really a couple. | 18:00 |
| nkinder | Why do we need to validate/enforce that LDAP has the additional attributes when Keystone doesn't use them for anything? | 18:01 |
| ekarlso | hey nkinder, can I ask you what the reason is to remove the iidentity part of keystone ? | 18:01 |
| amakarov | nkinder, if so then it's a feathure to deprecate of remove for good | 18:01 |
| *** nellysmitt has quit IRC | 18:01 | |
| nkinder | Keystone only uses the additional mappings for create operations. | 18:01 |
| nkinder | amakarov: well, it's there for the purpose of doing a user create with read/write LDAP | 18:01 |
| ayoung | nkinder not just user | 18:02 |
| nkinder | amakarov: but we never expect to read those values back and use them for anything AFAIK | 18:02 |
| nkinder | ayoung: ok, any entry type | 18:02 |
| ayoung | it would allow you to write a different object class with required fields | 18:02 |
| ayoung | amakarov, do you need this feature? Did you trip up on it? | 18:02 |
| nkinder | ekarlso: I'll get back to that question once we finish this other conversation. | 18:02 |
| ekarlso | cool nkinder :) | 18:02 |
| dstanek | morganfainberg: i was trying to fix for keystone.tokens for Python 3 and maybe ran into an issue | 18:02 |
| *** aix has quit IRC | 18:03 | |
| amakarov | nkinder, I recall you told me about it, and right now it does not block anything, but in the future it could be handy | 18:03 |
| dstanek | morganfainberg: https://review.openstack.org/#/c/125410/ passes unit tests, but appears to fail on tempest tests | 18:03 |
| dstanek | morganfainberg: i have a few thoughts...let me know when you have a few minutes to discuss..thsi is not urgent at all | 18:03 |
| amakarov | ayoung, actually no, it was my exercise and first bug to fix in an opensource ) | 18:04 |
| nkinder | amakarov: so I didn't see anything wrong with the code, but my feeling is that we shouldn't add more validation code when we don't even need to request those attributes for a search. | 18:04 |
| nkinder | amakarov: It's just more code to trip up when retrieving users for no real benefit. | 18:05 |
| nkinder | amakarov: if we actually did something with those retrieved values, then I could see the benefit. | 18:05 |
| *** henrynash has joined #openstack-keystone | 18:06 | |
| ayoung | nkinder, so this would be a way to expose more LDAP attributes for a given entity. Right? | 18:06 |
| amakarov | nkinder, yes, it definitely does not speed anything up :) | 18:06 |
| nkinder | ayoung: in theory yes, but I think that's the wrong direction. | 18:06 |
| nkinder | ayoung: do we start allowing modification and display when doing a user-list of other attributes ? | 18:07 |
| ayoung | nkinder, it might also violate the spec | 18:07 |
| ayoung | we don't allow arbitrary values in the user object | 18:07 |
| amakarov | nkinder, but there was a buggy feature described in documentation, so I think it would be better to have it working ) | 18:07 |
| nkinder | ayoung: that just starts encouraging the use of keystone as an interface to LDAP writes for all sorts of stuff | 18:07 |
| nkinder | amakarov: which feature and doc? | 18:07 |
| amakarov | nkinder, 1 sec | 18:08 |
| nkinder | amakarov: it might be that the docs should be improved, but I'd need to see the reference | 18:08 |
| nkinder | amakarov: thx | 18:08 |
| ayoung | nkinder, it was my understanding when I ported this code that this was strictly for the "create a new valid object of type X" | 18:08 |
| ayoung | but that was before the v3 api had even been written | 18:08 |
| nkinder | ayoung: that is my understanding of it too | 18:08 |
| ayoung | nkinder, so I think that we want to say "nothing that is not in the spec can be in the user object" | 18:09 |
| ayoung | otherwise, we will have Horizon trying to store user preferences in there | 18:09 |
| ayoung | default projects, even | 18:09 |
| amakarov | nkinder, actually it's in /etc/keystone.conf | 18:09 |
| nkinder | ayoung: all sorts of stuff can be in th user object in LDAP, but keystone (and the rest of OpenStack) shouldn't ever need to know about it | 18:09 |
| nkinder | ayoung: entry creation is a special beast though, as we need to satisfy the objectclass requirements. | 18:10 |
| amakarov | nkinder, *_additional_attribute_mapping | 18:10 |
| ayoung | nkinder, can you imagine the mapping to try and create a valid IPA user? | 18:10 |
| ayoung | shuder | 18:10 |
| ayoung | shudderer | 18:10 |
| nkinder | ayoung: or posixAccount, etc. | 18:10 |
| *** amcrn has joined #openstack-keystone | 18:10 | |
| *** amcrn has quit IRC | 18:10 | |
| nkinder | amakarov: checking... | 18:10 |
| ayoung | nkinder, IPA user has like, 5 different object classes | 18:10 |
| ayoung | amakarov, what did I write there.... | 18:11 |
| nkinder | amakarov: yeah, so those comments in keystone.conf are way too vague | 18:11 |
| amakarov | nkinder, it must be several encounters | 18:11 |
| nkinder | amakarov: I can see how you would think "Oh, awesome! I can map all sorts of attributes from LDAP->Keystone." | 18:12 |
| ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/config.py#n604 | 18:12 |
| ayoung | never says that they are supposed to be returned | 18:12 |
| *** NM1 has quit IRC | 18:12 | |
| ayoung | OK, I lie | 18:12 |
| ayoung | user_attr is the Identity API attribute. | 18:12 |
| ayoung | I say we deprecate them, and see how long until Jose complains | 18:13 |
| nkinder | no, don't deprecate it | 18:13 |
| nkinder | it serves a purpose | 18:13 |
| nkinder | the comments just need to say what that purpose is | 18:13 |
| *** NM1 has joined #openstack-keystone | 18:13 | |
| nkinder | assume that "cn", "sn", and "uid" are required in LDAP | 18:14 |
| ayoung | nkinder, it maps them to keystone user attributes | 18:14 |
| nkinder | and my normal mappings in keystone are "id->uid", "name->cn" | 18:14 |
| *** henrynash has quit IRC | 18:14 | |
| ayoung | "user_attr is the Identity API attribute." | 18:14 |
| nkinder | ayoung: getting to that... | 18:14 |
| nkinder | so the above mappings are all well and good, but what about "sn"? | 18:15 |
| nkinder | If keystone tries to do an add, it needs to supply something for the sn | 18:15 |
| ayoung | ah...so dual mapping...yeah that could be clearer | 18:15 |
| ayoung | what about this language | 18:15 |
| nkinder | An additional mappings lets you do "id->uid", "name->cn", "id->sn" | 18:15 |
| *** radez_g0n3 is now known as radez | 18:15 | |
| nkinder | or "name->sn" | 18:15 |
| ayoung | List of additional LDAP attributes used for creating new entities | 18:15 |
| amakarov | problem was in mismatched mapping direction - I described it in comment to the bug https://bugs.launchpad.net/keystone/+bug/1336769/comments/2 | 18:16 |
| uvirtbot | Launchpad bug 1336769 in keystone "LDAP additional attribute mappings do not care about model attribute" [Low,In progress] | 18:16 |
| *** serverascode_ has quit IRC | 18:16 | |
| *** morgan_remote_ has quit IRC | 18:16 | |
| *** zhiyan has quit IRC | 18:16 | |
| *** gokrokve_ has joined #openstack-keystone | 18:16 | |
| *** morgan_remote_ has joined #openstack-keystone | 18:17 | |
| nkinder | amakarov: ok, so the order was swapped | 18:17 |
| amakarov | nkinder, right | 18:17 |
| *** zhiyan has joined #openstack-keystone | 18:17 | |
| ayoung | amakarov, its ok, this code actually predates Keystone. | 18:17 |
| nkinder | amakarov: I think we should just make the comments more clear for this | 18:18 |
| *** nellysmitt has joined #openstack-keystone | 18:18 | |
| ayoung | nkinder so do you agree I should change the language to make it clear that these are for creationg only? | 18:19 |
| ayoung | creation | 18:19 |
| nkinder | ayoung: yes please | 18:19 |
| *** serverascode_ has joined #openstack-keystone | 18:19 | |
| ayoung | or amakarov can make the change | 18:19 |
| *** gokrokve has quit IRC | 18:19 | |
| ayoung | I'll annotate in the bug to start | 18:19 |
| nkinder | ayoung++ | 18:19 |
| nkinder | ekarlso: ok, so back to your question... | 18:20 |
| amakarov | ayoung, ok, I'll just rollback changes and correct comments in conf? | 18:21 |
| nkinder | ekarlso: it's not so much removal of identity, but externalizing it | 18:21 |
| *** gokrokve_ has quit IRC | 18:21 | |
| nkinder | ekarlso: keystone should not be considered to be a centralized identity provider that other apps use as a user database | 18:22 |
| *** amcrn has joined #openstack-keystone | 18:22 | |
| ayoung | amakarov, bug is still assigned to you. Sorry it is not so much fun. | 18:23 |
| nkinder | ekarlso: keystone should be thought of as an application whose responsibility is handing out tokens. For users/groups, it should be using an external identity provider of some sort. | 18:23 |
| nkinder | ekarlso: this could be LDAP, a SAML IdP, etc. | 18:23 |
| morganfainberg | nkinder, ++ | 18:23 |
| nkinder | ekarlso: for LDAP, Keystone does way too much heavy lifting of it's own that it doesn't really need to do | 18:24 |
| nkinder | ekarlso: I would prefer for the LDAP functionality in the underlying operating system to provide user/group information to keystone. | 18:24 |
| *** henrynash has joined #openstack-keystone | 18:24 | |
| nkinder | ekarlso: you with me so far? | 18:25 |
| ekarlso | nkinder: yeah | 18:27 |
| ekarlso | so q is then, how you do make that identity thing pluggable ? | 18:28 |
| nkinder | ekarlso: ok, I'll get to that part, but first a bit about federation since it ties in | 18:28 |
| nkinder | ekarlso: the SAML federation functionality uses a model where the webserver in front of keystone (really an apache module) supplies the information about the user to Keystone | 18:29 |
| nkinder | ekarlso: this is a trusted source, so the authentication is already performed outside of keystone | 18:29 |
| ekarlso | nkinder: hmm k then | 18:30 |
| nkinder | ekarlso: keystone then performs some mapping of the user information that is supplied to determine what goes into the token (roles, etc.) | 18:30 |
| nkinder | ekarlso: I would like that same model to be used for LDAP or other mechanisms (OpenID connect, etc.) | 18:31 |
| nkinder | ekarlso: there is an apache module named mod_lookup_identity that helps with this | 18:31 |
| *** lcheng has quit IRC | 18:31 | |
| ekarlso | nkinder: how you federate towards ldap ? | 18:31 |
| ekarlso | k | 18:31 |
| nkinder | mod_lookup_identity calls into SSSD on the platform | 18:31 |
| *** henrynash has quit IRC | 18:31 | |
| nkinder | SSSD deals with talking to LDAP, AD, /etc/passwd, etc. | 18:32 |
| nkinder | so the same way that you can allow LDAP to be used for system login and user info is used for Keystone | 18:32 |
| nkinder | you can have separate domains of users though, so I'm not saying that system login is granted to keystone users | 18:33 |
| nkinder | think of it like different pam service files that applications use | 18:33 |
| nkinder | SSSD provides a lot of nice benefits too, such as caching of user/group data | 18:34 |
| *** lcheng has joined #openstack-keystone | 18:34 | |
| openstackgerrit | Alexander Makarov proposed a change to openstack/keystone: LDAP additional attribute mappings description https://review.openstack.org/118590 | 18:36 |
| amakarov | ayoung, nkinder, there is also minor nice-to-have improvement: https://review.openstack.org/#/c/120043/ | 18:38 |
| amakarov | will you look at it please? | 18:40 |
| *** gokrokve has joined #openstack-keystone | 18:41 | |
| *** lcheng has quit IRC | 18:42 | |
| openstackgerrit | ayoung proposed a change to openstack/keystone: Basic-Auth middleware https://review.openstack.org/92137 | 18:43 |
| *** lcheng has joined #openstack-keystone | 18:43 | |
| openstackgerrit | ayoung proposed a change to openstack/keystone-specs: Basic-Auth middleware https://review.openstack.org/125457 | 18:43 |
| nkinder | amakarov: I think that the sample config is generated from common/config.py IIRC | 18:44 |
| *** lcheng has quit IRC | 18:44 | |
| nkinder | amakarov: so you would need to update the comment strings there | 18:44 |
| *** lcheng has joined #openstack-keystone | 18:44 | |
| nkinder | morganfainberg: is tools/config/check_uptodate.sh supposed to be run manually after editing config.py? | 18:46 |
| amakarov | nkinder, thanks | 18:46 |
| nkinder | morganfainberg: or tools/config/generate_sample.sh I guess | 18:46 |
| nkinder | amakarov: I've done it before myself, but forgot the details :) | 18:47 |
| ayoung | bknudson, can I walk you through the kerberos plugin code review? I'd like you to beat the hell out of it for me. | 18:47 |
| ayoung | https://review.openstack.org/#/c/123614/ | 18:47 |
| *** ukalifon has joined #openstack-keystone | 18:50 | |
| ayoung | nkinder, its a tox job | 18:51 |
| ekarlso | nkinder: does it map diff domans to diff backends ? | 18:51 |
| ayoung | tox -e sample_config | 18:51 |
| openstackgerrit | Alexander Makarov proposed a change to openstack/keystone: LDAP additional attribute mappings description https://review.openstack.org/118590 | 18:51 |
| nkinder | ekarlso: domains is a bit of an overloaded term since SSSD has domains too | 18:52 |
| nkinder | ekarlso: so SSSD domans can map to separate backends | 18:52 |
| nkinder | ekarlso: keystone domains should be able to map to SSSD domains, though that hasn't been attempted yet | 18:52 |
| *** lcheng has quit IRC | 18:52 | |
| nkinder | ekarlso: ayound has set up mod_lookup_identity with keystone some time back, but it was before multi-LDAP backend support was in Keystone | 18:52 |
| ekarlso | nkinder: i'd be interested in looking at forgerock with this | 18:53 |
| *** lcheng has joined #openstack-keystone | 18:53 | |
| nkinder | ekarlso: there is likely some work to be done there to tie thing together nicely | 18:53 |
| nkinder | ekarlso: SSSD should work with forgerock, as it's just LDAP AFAIK | 18:53 |
| nkinder | ekarlso: SSSD has a concept of "providers", and there is a general LDAP one (in addition to AD, IPA, local, and maybe some others I'm forgetting) | 18:54 |
| *** thedodd has quit IRC | 18:54 | |
| nkinder | ayoung: ah, that's right. You do it via tox | 18:55 |
| ayoung | nkinder, right now, the keystoneclient doesn't really know about auth plugins, it only uses them via the session. But for Horizon, there is no real benefit to manipulating sessions. As I see it, the session really is there for sharing connection info between clients. It almost seems like a better approach is: | 18:55 |
| *** jaosorior has quit IRC | 18:55 | |
| ayoung | pass an auth plugin to client.Client and, if so, use that to instantiate a session | 18:56 |
| ayoung | this will insulate the Horizon code from the internals of the client | 18:56 |
| *** ukalifon has quit IRC | 18:56 | |
| ayoung | this is what it does now | 18:57 |
| ayoung | http://git.openstack.org/cgit/openstack/django_openstack_auth/tree/openstack_auth/backend.py#n86 | 18:57 |
| nkinder | amakarov: so did you generate keystone.conf.sample using 'tox -e sample_config' or the generate_sample.sh script directly? | 18:57 |
| ayoung | I'd like to see the code look something like this: | 18:57 |
| *** lcheng has quit IRC | 18:57 | |
| *** jaosorior has joined #openstack-keystone | 18:57 | |
| openstackgerrit | A change was merged to openstack/keystone: Convert unicode to UTF8 when calling ldap.str2dn() https://review.openstack.org/125097 | 18:58 |
| ayoung | http://paste.openstack.org/show/117558/ nkinder | 18:58 |
| ayoung | that is the minimal change that will keep everything working. But to do that requires yet another client change | 18:59 |
| nkinder | ayoung: so what needs to change for that? | 18:59 |
| ayoung | nkinder, the client creation code and authenticate calls | 19:00 |
| ayoung | I'll link | 19:00 |
| *** lcheng has joined #openstack-keystone | 19:00 | |
| ayoung | nkinder, this call is already horribly long: http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/v3/client.py#n44 | 19:01 |
| ayoung | and a comparable for V2 | 19:01 |
| zzzeek | heya morganfainberg : how attached is keystone to the fact that the DB-related methods in the various */backends/sql.py don’t accept a “context” argument, the way that is common in pretty much every other openstack project ? | 19:01 |
| ayoung | nkinder, and authenticate is session/auth plugin agnostic as well: http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/httpclient.py#n332 | 19:02 |
| ayoung | nkinder, I started a hack to deal with session...let me see if I posted it | 19:02 |
| ayoung | nkinder, https://review.openstack.org/#/c/122309/ | 19:03 |
| *** amerine_ has joined #openstack-keystone | 19:05 | |
| *** amerine has quit IRC | 19:05 | |
| *** radez is now known as radez_g0n3 | 19:07 | |
| ayoung | nkinder, It would also be good if the client could return the auth plugin from the entrypoints | 19:11 |
| ayoung | I'm starting to wonder if there should be a separate client creation function to handle all of this. | 19:11 |
| ayoung | What I would like is something like: client = client_factory(config) | 19:12 |
| ayoung | nkinder, jamie wrote this up on the 15th http://www.jamielennox.net/blog/2014/09/15/how-to-use-keystoneclient-sessions/ | 19:14 |
| ayoung | don't tell his wife | 19:14 |
| morganfainberg | zzzeek, hey | 19:16 |
| zzzeek | hey | 19:16 |
| morganfainberg | zzzeek, uhm, not that attached to that concept. | 19:16 |
| morganfainberg | oh wait | 19:16 |
| morganfainberg | context in one sense? like context from the controller layer down? | 19:16 |
| morganfainberg | or an SQLA context ? | 19:17 |
| zzzeek | a positioanl argument called “context” that is passed to a DB-based method, which you can say, “context.session” to get at the ORM | 19:17 |
| morganfainberg | or... some other type of context (wow, almost as overloaded a word as "project") | 19:17 |
| zzzeek | most similar woudl be what you see in neutron’s code | 19:17 |
| zzzeek | doesnt matter what kind of object “context” is | 19:17 |
| zzzeek | (thats why its usually called “context” ) | 19:17 |
| morganfainberg | ok so if it's isolated to the SQL backend for a given subsystem, zero attachment to not having a context | 19:17 |
| zzzeek | morganfainberg: for keystone, i might propose a decorator that actually adds “context” to the argument list | 19:18 |
| morganfainberg | if it was passing the user context down from the wsgi layer, i'd be very skeptical | 19:18 |
| ayoung | zzzeek, context is evil and leads to shoddy coding | 19:18 |
| openstackgerrit | Alexander Makarov proposed a change to openstack/keystone: LDAP additional attribute mappings description https://review.openstack.org/118590 | 19:18 |
| zzzeek | ayoung: OK can i show you the problem statement and you suggest your approach ? | 19:18 |
| ayoung | "lets just let everything talk to everything through a global dictionary" | 19:18 |
| amakarov | nkinder, fixed. I use tox | 19:18 |
| morganfainberg | but i'd prefer to have something a bit more specific (object wise) than an arbitrary "we shove things into this method and extract it" | 19:19 |
| morganfainberg | e.g. dict with "things" in it | 19:19 |
| zzzeek | ayoung: i dont really think that’s what im getting at, see this is why i have a very large blueprint in the works b.c. nobody seems to know what im talking about | 19:19 |
| ayoung | zzzeek, in python, context is usually kwargs | 19:19 |
| ayoung | and we do unspeakable things with them | 19:19 |
| zzzeek | ayoung: ok i think we are not on the same page here as I havent introduced this topic to you | 19:20 |
| ayoung | zzzeek, typically, context should be outside of objects | 19:20 |
| morganfainberg | zzzeek, what ayoung is getting at is people throw crap into the context dict and then assume they can grab that data vs a "real" argument | 19:20 |
| zzzeek | ayoung: OK less typing and more reading, here: https://review.openstack.org/#/c/125181/ | 19:20 |
| morganfainberg | that has a relatively known set of interfaces (duck type or not) | 19:20 |
| zzzeek | morganfainberg / ayoung : that blueprint has no “proposed solution” yet, just the problem. if you think what i describe there is not a problem, then maybe we’re done :) | 19:21 |
| *** henrynash has joined #openstack-keystone | 19:21 | |
| ayoung | looking | 19:21 |
| ayoung | a cloth bandaid on the thumb is incompatible with a thumb driven trackball | 19:21 |
| morganfainberg | zzzeek, ok so part of the issue is with nova they use the admin-level context deep down in the internals | 19:22 |
| morganfainberg | zzzeek, which is what the @require_context or @require_admin_context thing is | 19:22 |
| morganfainberg | iirc | 19:23 |
| ayoung | its cuz we don't split up object creation and object use. | 19:23 |
| zzzeek | morganfainberg / ayoung: OK forget about context for the moment, the point is you fokls need a database “thing” that you aren’t ad-hoc creating inside of methods | 19:23 |
| zzzeek | and you need to get rid of all that boilerplate as does everyone else | 19:23 |
| zzzeek | all other projects already have an argument called “context” that is sitting there already | 19:23 |
| morganfainberg | zzzeek, yes i'm fine with a way of passing a more unified facade *thing* into our SQL drivers that can handle re-use of sessions | 19:23 |
| ayoung | zzzeek, its called inversion of control, and if you have a solution for it, propose it. Otherwise, I move we steal dstanek 's | 19:23 |
| ayoung | anything is better than what we have now | 19:23 |
| morganfainberg | zzzeek, etc. | 19:24 |
| dstanek | ayoung: yay! | 19:24 |
| zzzeek | ayoung: anything…except an argument called “context” apparently :) | 19:24 |
| morganfainberg | zzzeek, if that is the answer you're looking for. | 19:24 |
| ayoung | dstanek, yours sucks, it just sucks less than everything else | 19:24 |
| morganfainberg | wait dstanek has something to steal? | 19:24 |
| * morganfainberg gets in line to steal it | 19:24 | |
| zzzeek | OK why dont i add you all to this and please let me know what solutions you are open to b.c. i dont really feel like spending two weeks defining something that youre all going to shoot down anyway | 19:24 |
| dstanek | ayoung: :-) this is a java problem and has a java solution | 19:24 |
| morganfainberg | zzzeek, fair enough. | 19:25 |
| ayoung | dstanek, no. IoC is a coding issue. | 19:25 |
| dstanek | ayoung: maybe i'll dust off my DI patch and re-apply | 19:25 |
| zzzeek | ayoung: yeah IoC is kind of “invisible-ish” in python :) | 19:25 |
| ayoung | dstanek, lets discuss at the summit. That would be a fantastic thing, but we need to play nice with stevedore | 19:25 |
| ayoung | zzzeek, that is the thing, not it is not | 19:25 |
| zzzeek | ayoung: compared to spring | 19:25 |
| morganfainberg | zzzeek, i think our only *real* concern was ensuring "context" wasn't equivalent to "kwargs" and just a bundle of "throw junk into this thing and extract it later" | 19:25 |
| ayoung | IofC is easier in strictly typed languages | 19:25 |
| dstanek | ayoung: i'll have something ready ahead of time for us to walk through | 19:26 |
| zzzeek | ayoung: which is like AH MY EYES | 19:26 |
| ayoung | zzzeek, let me burn your eyeballs for a moment | 19:26 |
| ayoung | http://sourceforge.net/p/cpp-resolver/svn/HEAD/tree/TRUNK/include/resolver.h | 19:26 |
| zzzeek | morganfainberg: i was going to have it just inject “session” directly, but ive seen most proj’s have “context” already and neutron says “context.session” | 19:26 |
| morganfainberg | ayoung, i know better than to click that link | 19:26 |
| dstanek | ayoung: my experience has been that it's been much easier in Python than in Java because of the dynamic typing | 19:27 |
| zzzeek | well all c++ burns my eyes | 19:27 |
| morganfainberg | zzzeek, sure, and that is clearly not a "bundle of whatever we felt like" | 19:27 |
| ayoung | zzzeek, so, yeah, I've thought about this for a while | 19:27 |
| ayoung | IofC in python needs a clean way to state what should fulfill a dependency | 19:27 |
| ayoung | in C++ and Java, you can use type info | 19:27 |
| ayoung | Python...not so much | 19:28 |
| ayoung | maybe there is something we could do with ABC? | 19:28 |
| morganfainberg | ayoung, DUCK! | 19:28 |
| morganfainberg | ayoung, yeah or another metaclass | 19:28 |
| zzzeek | ayoung: so, a simple decorator that just works and everythign is great, no good huh. | 19:28 |
| ayoung | morganfainberg, Duck typing is kindof "found out too late" | 19:28 |
| * morganfainberg is disappointed ABC can't do strict signature enforcement. | 19:28 | |
| ayoung | zzzeek, I want to be able to consume objects that don't have the decorator | 19:29 |
| ayoung | and I want the "wiriing up" to be outside the class definition file | 19:29 |
| zzzeek | ayoung: i dont understnad waht you mean. im talking only about methods taht right now say, “get_session()” all over the place inside of them | 19:29 |
| ayoung | something like stevedore | 19:29 |
| ayoung | zzzeek, OK, you are familiar with entrypoiunts? | 19:29 |
| zzzeek | ayoung: yes | 19:29 |
| ayoung | zzzeek, that is close | 19:29 |
| zzzeek | ayoung: sounds incredibly heavyhanded and magical for what is a simple problem | 19:30 |
| dstanek | ayoung: morganfainberg: the problem i ran into with IoC was that identity and assignment depend on each other | 19:30 |
| ayoung | zzzeek, so, lets say I have 2 different databases | 19:30 |
| zzzeek | ayoung: and for which the current approach is *horrible* | 19:30 |
| ayoung | lets use keystone as an example, and I have Identity in one, and Assignments in another | 19:30 |
| morganfainberg | dstanek, i *think* we can break that now.... or at least move the domain bit from Assignment around to help break that apart. | 19:30 |
| zzzeek | ayoung: im trying to *imrpve* the current situation, not build an amazing magic IoC system | 19:30 |
| dstanek | ayoung: morganfainberg: i never implemented that in my framework because it enables bad design :-( | 19:30 |
| ayoung | I want the python code that stoartes users to just say "I need a database" but not specify which one | 19:30 |
| dstanek | zzzeek: what review are we talking about here | 19:31 |
| dstanek | ? | 19:31 |
| zzzeek | dstanek: https://review.openstack.org/#/c/125181/4 | 19:31 |
| ayoung | zzzeek, I understand, but this is a recurring problem | 19:31 |
| ayoung | I don';t want another 0.5 glute solution | 19:31 |
| ayoung | zzzeek, for example, we now have code for multiple identity backends | 19:32 |
| ayoung | finding the right one is custome code. | 19:32 |
| zzzeek | ayoung: getting rid of get_session() everywhere is the first step to that | 19:32 |
| zzzeek | ayoung: you know how to do things “incrementally” right ? :) | 19:32 |
| ayoung | I want a solution that unifies that with the ability to split the Token Database from the identity database | 19:32 |
| morganfainberg | ayoung, sure. i think we can get there in steps | 19:33 |
| zzzeek | ayoung: i dont have that for you. I have fixes for excessive boilerplate and multiple transactions right now | 19:33 |
| ayoung | zzzeek, probably better than most, yet | 19:33 |
| ayoung | zzzeek, let me find the XKCD reference for you... | 19:33 |
| morganfainberg | part of that will be make it less "oh we implemented this thing ourselves different from everyone else, but only subtly so" | 19:33 |
| ayoung | http://xkcd.com/927/ | 19:33 |
| zzzeek | ayoung: wow youre really going to just link to that huh | 19:34 |
| ayoung | zzzeek, yep | 19:34 |
| ayoung | zzzeek, ok, so you touched on one of the issues that we have discussed in the past without resolving | 19:34 |
| zzzeek | ayoung: sure. guess ill just quit now, b.c if theres a problem, you’re done. it cant be solved b.c. XKCD somewhat tangentially can be applied. | 19:34 |
| ayoung | we have dependency resolution in keystone, and it is a one-off | 19:34 |
| * zzzeek takes his ball | 19:34 | |
| ayoung | zzzeek, oh no you don | 19:35 |
| ayoung | 't | 19:35 |
| ayoung | zzzeek, I think you are missing the point | 19:35 |
| ayoung | you are seeing one aspect of a larger problem, if only in Keystone | 19:35 |
| ayoung | Context is used to "create" objects, but should not be around after they are created | 19:35 |
| ayoung | and even context itself needs to be somewhat ordered | 19:35 |
| ayoung | context in the web means: | 19:36 |
| ayoung | conf file, global values, session values (not that we have sessions) and request values, in that order | 19:36 |
| *** radez_g0n3 is now known as radez | 19:36 | |
| ayoung | databases are often the worst offenders here, because people start with a simple app and write direct to the database...and then the app grows | 19:37 |
| ayoung | BTW, the XKCD reference was poking fun at my approach, not yours, in case it wasn't clear | 19:37 |
| zzzeek | ayoung: do me a favor. here’s a keystone method: http://paste.openstack.org/show/117568/ | 19:37 |
| *** swartulv has quit IRC | 19:37 | |
| zzzeek | ayoung: a. if you would make this method look like something else, what woudl it look like? | 19:37 |
| zzzeek | ayoung: or b. this method is perfect | 19:37 |
| ayoung | zzzeek, zzzeek the answer is not b, but the margin is too small.... | 19:38 |
| morganfainberg | ayoung, i'd argue you could make the whole object driver smarter in handling the db facade and sessions | 19:38 |
| zzzeek | ayoung: doesnt it concern you that a method that calls sql.transcation() which then calls another that calls get_session() ends up using nested transctions on two simultaneous connections? that shouldnt be solved ? | 19:38 |
| morganfainberg | rather than needing to context manager each step of the way here. | 19:38 |
| zzzeek | ayoung: i have a simple, tangible bug that is demonstratble. i dont know that we shoudl do nothing because XKCD has told us the perfect system is unattainable | 19:39 |
| ayoung | zzzeek, get_current_transaction().... | 19:39 |
| zzzeek | ayoung: oh! you have a solution! OK can I see it please, rewrite the fn for me | 19:39 |
| ayoung | zzzeek, actually, it was Godel that told us that | 19:39 |
| zzzeek | ayoung: im not very well educated | 19:39 |
| ayoung | zzzeek, do you know termie? | 19:39 |
| zzzeek | ayoung: nope | 19:40 |
| morganfainberg | ayoung, no he doesn't i'm sure. | 19:40 |
| ayoung | heh | 19:40 |
| dstanek | zzzeek: if you could make your decorator a context manager i'd be really happy | 19:40 |
| ayoung | morganfainberg, still not certain he isn't termie | 19:40 |
| zzzeek | dstanek: i planned for it to work in both ways | 19:40 |
| morganfainberg | ayoung, heh | 19:40 |
| zzzeek | dstanek: however. does keystone need transaction replaying for deadlocks? that’s somethuign you need the decorator version for | 19:41 |
| *** f13o_f13o has joined #openstack-keystone | 19:41 | |
| *** f13o_f13o has quit IRC | 19:41 | |
| morganfainberg | zzzeek, i hm, i don't think we have run into many deadlock issues actually. | 19:41 |
| dstanek | zzzeek: that's a really good question | 19:41 |
| bknudson | why would keystone have a deadlock? | 19:41 |
| zzzeek | bknudson: not sure, ive been looking at projects in the big picture and there;’s lots of retry_on_deadlock decorators | 19:42 |
| ayoung | zzzeek, OK, here's the deal, the code we have assumes a single instance for all of the objects. When you write that way, you need to externalized all of the state. If you don;t have magic methods that pull the state out of some global registry, you need to pass it in to the function call as a parameter | 19:42 |
| morganfainberg | zzzeek, we've largely written things to be isolated. we don't use that afaict | 19:42 |
| zzzeek | morganfainberg ok that is fine | 19:42 |
| ayoung | so instead of | 19:43 |
| *** swartulv has joined #openstack-keystone | 19:43 | |
| morganfainberg | zzzeek, it *does* result in some race-y-ness in some cases, and long term we need to fix that as well, but it's been of limited impact so far. | 19:43 |
| dstanek | morganfainberg: that's also helped by autocommit - so no chance of philosphers dining in our current implementation | 19:43 |
| morganfainberg | dstanek, ++ | 19:43 |
| ayoung | with sql.transaction() as session: creating a new transaction, under the covers it could join an existing transaction | 19:43 |
| ayoung | that would not require changes in this code, but rather in the sql.transaction() call | 19:44 |
| morganfainberg | ayoung, or a replacement of sql.transaction | 19:44 |
| morganfainberg | to something more universal across openstack | 19:44 |
| zzzeek | ayoung: that woudl require tons of cahgnes because most keystone calls do not use sql.transaction() | 19:44 |
| ayoung | morganfainberg, yep | 19:44 |
| zzzeek | ayoung: of course, sql.transaction() should be maintaining state across nesting | 19:44 |
| morganfainberg | zzzeek, for any writes we *should* use that, for anything that is read only, we've been more lax about that | 19:44 |
| zzzeek | morganfainberg: so i was thinking, sql.reader() vs. sql.writer() | 19:45 |
| morganfainberg | barring migrations... lets not even talk about those | 19:45 |
| ayoung | zzzeek, but the way our code is written also assumes a global database | 19:45 |
| zzzeek | anyway it sounds like ppl like context managers, sure that is not a problem | 19:45 |
| morganfainberg | zzzeek, sure. that makes logical sense (esp. if you want to fan out read-only replicas) | 19:45 |
| ayoung | which really is poor design as well | 19:46 |
| zzzeek | ayoung: that’s a different issue, by at least abstracting out how you get at the DB you provide a chance to work on that second | 19:46 |
| ayoung | for example, we need different semantics on, say, tokens, which are immutable versus trusts which require strict locking | 19:46 |
| morganfainberg | ayoung, i think if we had a smarter set of managers for this. we could move towards having multuple dbs. | 19:46 |
| morganfainberg | layer in something way better that knows DB db vs Identity vs Assignment vs credential | 19:46 |
| zzzeek | morganfainberg ayoung this spec is just the first step, *getting everyone to use a context manager* | 19:46 |
| zzzeek | that oslo.db defines and does the right thing | 19:47 |
| morganfainberg | zzzeek, and we do tend to like context managers. | 19:47 |
| zzzeek | morganfainberg: fine. other projects though really need the retry on deadlock part and that should be integrated | 19:47 |
| zzzeek | morganfainberg: itll work both ways, that was my plan anyway | 19:47 |
| morganfainberg | zzzeek, that is fine, if we're not using the retry_on_deadlock yet we might need it in the future this future proofs us | 19:47 |
| morganfainberg | zzzeek, i wouldn't complain if it worked both ways :) | 19:47 |
| zzzeek | morganfainberg: only if you used the decorator version :) deosnt matter. i just want to celan up this enginefacade junk | 19:48 |
| morganfainberg | right | 19:48 |
| *** crowell has joined #openstack-keystone | 19:48 | |
| zzzeek | morganfainberg: and if i can get it in keystone/nova/neutron then the rest of the projects can follow | 19:48 |
| openstackgerrit | A change was merged to openstack/pycadf: Stop using intersphinx https://review.openstack.org/124935 | 19:48 |
| ayoung | zzzeek, what would your version of list_projects_in_domain( look like? | 19:48 |
| ayoung | morganfainberg, actually, I know zzzeek isn't termie because termie hates sql | 19:49 |
| morganfainberg | ayoung, Hah! | 19:49 |
| zzzeek | ayoung: http://paste.openstack.org/show/117572/ | 19:49 |
| morganfainberg | dstanek, do you think we could revisit DI stuff at the summit and have a target/goal out of the session? | 19:50 |
| dstanek | morganfainberg: yes | 19:50 |
| morganfainberg | dstanek, mind giving a little thought to that on the etherpad? | 19:50 |
| ayoung | zzzeek, no problem with that | 19:50 |
| zzzeek | ayoung: by saying reader() you give a clue to clustering / HA systems what to do | 19:50 |
| ayoung | distinguishing between read and write locks is good | 19:51 |
| morganfainberg | zzzeek, how would the ._get_domain know the session? | 19:51 |
| dstanek | morganfainberg: sure, i'll do that now | 19:51 |
| zzzeek | morganfainberg: it would use the same decorator / contextmanager | 19:51 |
| morganfainberg | ok | 19:51 |
| morganfainberg | cool | 19:51 |
| dstanek | etherpad really needs a freaking search | 19:51 |
| morganfainberg | dstanek, haha yeah | 19:51 |
| morganfainberg | zzzeek, and yes read vs write would be great | 19:51 |
| zzzeek | morganfainberg: now what if a reader() called a writer(). probably raise an error | 19:51 |
| morganfainberg | zzzeek, yes that would be logical, if you expect to write always start with write | 19:52 |
| morganfainberg | zzzeek, but a writer *should* be able to call a reader | 19:52 |
| zzzeek | morganfainberg: in nova, they are passing the “session” along to methods trying to share the transaction, and they frequently forget to do it | 19:52 |
| zzzeek | morganfainberg: and in other cases they cant | 19:52 |
| zzzeek | morganfainberg: so it is a crapshow | 19:52 |
| morganfainberg | zzzeek, we do some of that. and do if not session: get_session | 19:52 |
| morganfainberg | we've been fairly good at it, but.. sometimes we miss | 19:52 |
| zzzeek | morganfainberg: yes that is just mistakes waiting to happen | 19:52 |
| zzzeek | morganfainberg: thats TMTOWTDI, to quote anoteher meme | 19:53 |
| morganfainberg | zzzeek, i think this is absolutely in the right direction, and helps makes things a bit more clear what is expected. | 19:53 |
| zzzeek | its in nova that its really serious | 19:53 |
| morganfainberg | ayoung, we might want to abstract this kind of concept out for LDAP as well. | 19:54 |
| *** crowell has left #openstack-keystone | 19:54 | |
| zzzeek | morganfainberg: so neutron already uses context.session. for them i might propose that these decorators are configured up front, as injecting an argument or patching it on an existing context argument | 19:54 |
| morganfainberg | zzzeek, i'd argue for the argument vs patching context. | 19:55 |
| morganfainberg | but that would just be my choice. i don't like "random budles of cruft" that people just extract things from and hope their right | 19:55 |
| zzzeek | morganfainberg: right but you can see if i go to neutron and say they ahve to chagne all def foo(context) into def foo(context, session), they’d not like that | 19:55 |
| zzzeek | morganfainberg: both have their place :) | 19:56 |
| morganfainberg | now, what might work for neutron is a wraper for the decorator, simple that says "context.session = my thing" | 19:56 |
| *** nellysmitt has quit IRC | 19:56 | |
| morganfainberg | or vice versa for us. | 19:56 |
| zzzeek | morganfainberg: in sqlalchemy, some of these events have huge piles of junk to send in , that can change across releases…so i just send the user event a context objecvt with a well defined interface | 19:56 |
| morganfainberg | mostly for ease of transition | 19:56 |
| *** nellysmitt has joined #openstack-keystone | 19:56 | |
| morganfainberg | zzzeek, yeah. and that is what i dislike about "context". summed up neatly | 19:57 |
| zzzeek | morganfainberg: i agree that an amorphous “context” sucks. but a well defined one can be appopriate when there is a really large and complex set of information to be made available. | 19:57 |
| morganfainberg | sure. | 19:57 |
| morganfainberg | we do that in keystoneclient somewhat | 19:57 |
| zzzeek | morganfainberg: but even then, yes the “context” should have something to do with the kinds of methods being called | 19:58 |
| morganfainberg | the problem is mostly it's amorphus context in openstack | 19:58 |
| zzzeek | morganfainberg: i wouldnt want to send the same “context” everywhere to everything | 19:58 |
| morganfainberg | vs. well defined | 19:58 |
| dstanek | morganfainberg: i'm going to leave it at that for now - if i think about it anymore i may dish out an ayoung style rant to etherpad :-) | 19:58 |
| morganfainberg | dstanek, thanks | 19:58 |
| zzzeek | thanks for the input dstanek | 19:58 |
| morganfainberg | dstanek, which etherpad? | 19:58 |
| morganfainberg | https://etherpad.openstack.org/p/kilo-keystone-summit-topics ? | 19:58 |
| dstanek | morganfainberg: yes, i expanded on the DI sectioin | 19:59 |
| morganfainberg | dstanek, ah wrong one, ok moving it over to the "right" one | 19:59 |
| ayoung | morganfainberg, there are no transaction in LDAP | 19:59 |
| ayoung | each call is atomitc | 19:59 |
| ayoung | atomic | 19:59 |
| dstanek | zzzeek: my OpenStack contribution for the day: *related* on line 16 of your spec | 20:00 |
| zzzeek | woop | 20:00 |
| dstanek | nap time! | 20:00 |
| dstanek | zzzeek: after talking to you the other day about SQA I started reading up on current patterns and practices | 20:01 |
| morganfainberg | dstanek, ok moved it over and zeroed out the old ether pad so no one uses it. | 20:01 |
| *** nellysmitt has quit IRC | 20:01 | |
| morganfainberg | ok i need to go .. lunch time | 20:01 |
| dstanek | morganfainberg: thx i didn't realize that was an older one | 20:01 |
| ayoung | morganfainberg, can we label this one as "no the otherone, dummy" | 20:02 |
| morganfainberg | https://etherpad.openstack.org/p/keystone-kilo-summit-sessions | 20:02 |
| morganfainberg | ayoung, fixed it | 20:02 |
| dstanek | how'd we get two? | 20:02 |
| morganfainberg | dstanek, my mistake, i picked the wrong name at one point | 20:03 |
| morganfainberg | :P | 20:03 |
| morganfainberg | the correct one was started by ttx | 20:03 |
| dstanek | ah | 20:03 |
| dstanek | morganfainberg: i found it in my chrome history since etherpad hasn't grown that feature yet | 20:03 |
| ayoung | dstanek, I guess my fundamental question is: how do I distinguish between what two registered objects provide if all I know is the string that they are named by | 20:04 |
| dstanek | ayoung: with snake-guice you can't have more than one thing registed to the same name unless they have different scope/annotations | 20:05 |
| ayoung | dstanek, so we have name, scope? | 20:05 |
| ayoung | I miss type safety | 20:05 |
| dstanek | scope is a concept from guice, nomal scope in created on demand, singleton only once (per thread), request is created once per request, etc. | 20:06 |
| dstanek | it's not about the type - it's about the lifecycle of an object | 20:06 |
| *** amakarov is now known as amakarov_away | 20:12 | |
| *** Gippa has joined #openstack-keystone | 20:17 | |
| ayoung | nkinder, OK, I think keystoneclient.client has some other code that DOA should be using instead. It looks like it handles creating a client of the right version already | 20:19 |
| ayoung | and, I think, it accepts an auth plugin. I'm going to test it out. | 20:19 |
| nkinder | ayoung: Cool. I haven't dove into a lot of the details you mentioned earlier. | 20:19 |
| nkinder | ayoung: my brain is melting trying to figure out setting up federation... :) | 20:19 |
| ayoung | nkinder, its ok, its mostly important that I get them clear in my own head | 20:20 |
| ayoung | nkinder, I'll avoid following up on that statement to avoid getting derailed myself | 20:21 |
| *** henrynash has quit IRC | 20:24 | |
| *** henrynash has joined #openstack-keystone | 20:25 | |
| *** nkinder has quit IRC | 20:29 | |
| rodrigods | stevemar, marekd|away ping | 20:36 |
| rodrigods | at metadata exchange step to configure k2k fed, where do I put the SP metadata? | 20:37 |
| stevemar | rodrigods, it should be at a location determined by shibboleth | 20:38 |
| rodrigods | stevemar, don't I need to put the SP information at the keystone IdP? | 20:39 |
| rodrigods | https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst#generate-metadata | 20:40 |
| stevemar | rodrigods, so keystoneIdP is generated using keystone-manage, and is placed at keystoneSP's shib directory | 20:42 |
| stevemar | ... wait now you've got me confused too | 20:42 |
| stevemar | both keystones (IdP and SP) need to have each other's metadata | 20:43 |
| rodrigods | stevemar, right, I've placed the IdP metadata at the SP. I thought I would need to do the same in the other way | 20:43 |
| rodrigods | exactly | 20:43 |
| *** dims_ has joined #openstack-keystone | 20:46 | |
| *** cjellick has quit IRC | 20:47 | |
| *** raildo_ is now known as raildo_away | 20:47 | |
| *** dims_ has quit IRC | 20:48 | |
| *** dims_ has joined #openstack-keystone | 20:48 | |
| *** dims_ has quit IRC | 20:49 | |
| *** dims_ has joined #openstack-keystone | 20:49 | |
| stevemar | rodrigods, i think you still specify it in shibboleth2.xml | 20:50 |
| *** dims has quit IRC | 20:50 | |
| *** mikedillion has quit IRC | 20:51 | |
| rodrigods | stevemar, so I need shibboleth for the IdP too? | 20:51 |
| stevemar | yep | 20:51 |
| *** nkinder has joined #openstack-keystone | 20:51 | |
| rodrigods | ok, will add some lines in the doc then =) | 20:52 |
| *** dims_ has quit IRC | 20:54 | |
| stevemar | rodrigods, thank you sir! | 20:57 |
| *** marcoemorais has quit IRC | 21:02 | |
| *** jasondotstar has quit IRC | 21:02 | |
| *** marcoemorais has joined #openstack-keystone | 21:02 | |
| *** marcoemorais has quit IRC | 21:03 | |
| *** marcoemorais has joined #openstack-keystone | 21:05 | |
| *** marcoemorais has quit IRC | 21:05 | |
| *** marcoemorais has joined #openstack-keystone | 21:05 | |
| *** marcoemorais has quit IRC | 21:06 | |
| *** marcoemorais has joined #openstack-keystone | 21:06 | |
| *** morgan_remote_ has quit IRC | 21:06 | |
| *** morgan_remote_ has joined #openstack-keystone | 21:09 | |
| *** radez is now known as radez_g0n3 | 21:10 | |
| *** joesavak has quit IRC | 21:10 | |
| openstackgerrit | Dolph Mathews proposed a change to openstack/keystone: revise docs on default _member_ role https://review.openstack.org/110803 | 21:19 |
| *** jaosorior has quit IRC | 21:33 | |
| *** jaosorior has joined #openstack-keystone | 21:34 | |
| nkinder | stevemar: none of the CLIs support creation of an IdP, protocol, or mappings for OS-FEDERATION, right? | 21:35 |
| nkinder | stevemar: just use curl for now? | 21:36 |
| stevemar | nkinder, OSC supports IdP | 21:36 |
| stevemar | and there is a patch for mapping | 21:36 |
| nkinder | stevemar: oh, cool. I suppose I'll try that way to test it out then | 21:36 |
| stevemar | nkinder, it's just been on the back burner is all | 21:36 |
| nkinder | stevemar: I'm using mod_auth_mellon and ipsilon, so that could turn into some doc updates to cover other cases than just shibboleth | 21:37 |
| stevemar | nkinder, sweet! | 21:38 |
| stevemar | nkinder, yeah adam had some of that on his blog, but if you could make legit docs, i'll be happy to review | 21:39 |
| *** andreaf has quit IRC | 21:41 | |
| *** andreaf has joined #openstack-keystone | 21:42 | |
| *** stevemar has quit IRC | 21:43 | |
| *** stevemar has joined #openstack-keystone | 21:44 | |
| *** joesavak has joined #openstack-keystone | 21:47 | |
| rm_work | stevemar: hey, you linked me to a thing yesterday about using Trusts with API v2 -- I was wondering if you could clear up some confusion i've been having about the Keystone versioning T_T | 21:52 |
| stevemar | rm_work, i'll gladly try to | 21:53 |
| rm_work | So, I have been told in the past "There is no Keystone v3 -- there is Identity API v2.0 and Identity API v3" | 21:54 |
| rm_work | is that accurate? | 21:54 |
| bknudson | rm_work: yes | 21:55 |
| rm_work | IE, the API versions are not tied to the Keystone version | 21:55 |
| bknudson | you can enable or disable either version support in keystone | 21:55 |
| rm_work | Ok, so Trusts are an Identity API v3 thing, but are doable in v2 -- how do I figure out what version of keystone is actually required for them to work? | 21:55 |
| rm_work | per https://bugs.launchpad.net/keystone/+bug/1331884 it looks like maybe they were backported into API v2? | 21:56 |
| uvirtbot | Launchpad bug 1331884 in keystone "A V2 token from trust cannot be generated with user/pass" [Wishlist,In progress] | 21:56 |
| bknudson | in v2 I think you can check for the extension... there's a v2.0/extensions | 21:56 |
| rm_work | or something like that | 21:56 |
| rm_work | so Trusts are an extension? | 21:56 |
| bknudson | kind of... you can disable trusts. | 21:56 |
| rm_work | Ok but... if someone only has Identity API v2 available, that could be either because they disabled v3, or because their version of Keystone was shipped before v3 EXISTED, right? | 21:57 |
| bknudson | sure | 21:57 |
| rm_work | and in the case of "they just disabled v3", then probably v2 supports Trusts still in the backend | 21:57 |
| rm_work | but possibly they have an older version of Keystone and trusts aren't supported at all? | 21:58 |
| *** thedodd has joined #openstack-keystone | 21:58 | |
| rm_work | so I'd have to do the /extension call you mentioned and see if it's there | 21:58 |
| bknudson | maybe they don't even run keystone and instead implement their own identity api | 21:58 |
| rm_work | lol yes, I definitely have that problem too <_< | 21:58 |
| rm_work | trying to keep to one huge cluster-f$#* at a time tho ;) | 21:58 |
| rm_work | So, what I *actually* need to say instead of "Keystone Identity API v3 is required for this to work" is "Keystone must have the Trusts extension installed for this to work" | 22:00 |
| bknudson | rm_work: that sounds right. for keystone it's not installed it's just enabled. | 22:00 |
| rm_work | well, it may or may not be there to BE enabled/disabled | 22:01 |
| rm_work | depending on how old the Keystone installation is | 22:01 |
| bknudson | sure | 22:01 |
| rm_work | ok | 22:01 |
| *** dims has joined #openstack-keystone | 22:02 | |
| *** rkofman has quit IRC | 22:03 | |
| *** joesavak has quit IRC | 22:03 | |
| stevemar | rm_work, that sounds super weird, i wonder why you aren't seeing v3 | 22:03 |
| *** rkofman has joined #openstack-keystone | 22:03 | |
| stevemar | rm_work, what do you get when you hit just '/' -> hostname:5000/ | 22:03 |
| stevemar | it should list all available versions | 22:03 |
| rm_work | stevemar: it's not that I don't see v3 in our install | 22:04 |
| rm_work | well, actually our install doesn't USE keystone, as bknudson hinted and I lamented :( | 22:04 |
| rm_work | but | 22:04 |
| *** lcheng has quit IRC | 22:04 | |
| *** lcheng has joined #openstack-keystone | 22:05 | |
| *** cjellick has joined #openstack-keystone | 22:05 | |
| *** marcoemorais has quit IRC | 22:05 | |
| rm_work | I need this to work across many cloud deployers (ie, anyone who runs Openstack) | 22:06 |
| *** marcoemorais has joined #openstack-keystone | 22:06 | |
| rm_work | and I am trying not to intruduce dependencies where I don't have to, and am currently surveying to see what versions of Keystone the major players involved in my project are running | 22:06 |
| *** marcoemorais has quit IRC | 22:06 | |
| *** marcoemorais has joined #openstack-keystone | 22:07 | |
| *** marcoemorais has quit IRC | 22:07 | |
| *** marcoemorais has joined #openstack-keystone | 22:07 | |
| *** henrynash has quit IRC | 22:08 | |
| *** lcheng has quit IRC | 22:09 | |
| *** lcheng has joined #openstack-keystone | 22:09 | |
| stevemar | rm_work, sounds like you have a headache to deal with | 22:10 |
| rm_work | indeed | 22:10 |
| *** mikedillion has joined #openstack-keystone | 22:10 | |
| *** henrynash has joined #openstack-keystone | 22:11 | |
| *** NM1 has quit IRC | 22:12 | |
| *** marcoemorais has quit IRC | 22:13 | |
| *** flwang1 has quit IRC | 22:13 | |
| *** marcoemorais has joined #openstack-keystone | 22:13 | |
| *** henrynash has quit IRC | 22:13 | |
| *** bknudson has quit IRC | 22:15 | |
| *** gordc has quit IRC | 22:17 | |
| *** Tahmina has quit IRC | 22:18 | |
| *** marcoemorais has quit IRC | 22:20 | |
| *** amcrn_ has joined #openstack-keystone | 22:26 | |
| *** topol has quit IRC | 22:27 | |
| *** amcrn has quit IRC | 22:30 | |
| *** marcoemorais has joined #openstack-keystone | 22:31 | |
| *** lcheng has quit IRC | 22:32 | |
| *** lcheng has joined #openstack-keystone | 22:33 | |
| *** marcoemorais has quit IRC | 22:33 | |
| *** zzzeek has quit IRC | 22:33 | |
| *** zzzeek has joined #openstack-keystone | 22:34 | |
| *** andreaf has quit IRC | 22:35 | |
| *** andreaf has joined #openstack-keystone | 22:36 | |
| *** lcheng has quit IRC | 22:37 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 22:37 | |
| *** shuffleb1t is now known as shufflebot | 22:37 | |
| *** shufflebot has joined #openstack-keystone | 22:38 | |
| *** zzzeek_ has joined #openstack-keystone | 22:47 | |
| *** zzzeek has quit IRC | 22:47 | |
| *** zzzeek_ is now known as zzzeek | 22:47 | |
| dstanek | dolphm: maybe you deserve more than a +2...but i had to correct all that crap! | 22:58 |
| openstackgerrit | Kui Shi proposed a change to openstack/keystone: Add memcached_backend configuration https://review.openstack.org/122037 | 23:00 |
| *** mikedillion has quit IRC | 23:09 | |
| *** lcheng has joined #openstack-keystone | 23:12 | |
| *** bknudson has joined #openstack-keystone | 23:17 | |
| *** thedodd has quit IRC | 23:32 | |
| *** Tahmina has joined #openstack-keystone | 23:44 | |
| openstackgerrit | A change was merged to openstack/keystone: Handle default string values when using user_enabled_invert https://review.openstack.org/125243 | 23:45 |
| openstackgerrit | A change was merged to openstack/keystone: Remove duplicated assertion https://review.openstack.org/123382 | 23:46 |
| *** david-lyle has quit IRC | 23:49 | |
| *** jaosorior has quit IRC | 23:53 | |
| *** mikedillion has joined #openstack-keystone | 23:55 | |
| openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Internal notifications for cleanup domain https://review.openstack.org/125521 | 23:55 |
| ayoung | morganfainberg, I think that endpoint constraints could replace the service catalog, and give us a way to get to an id only catalog | 23:58 |
| *** gokrokve has quit IRC | 23:58 | |
| *** bknudson has quit IRC | 23:58 | |
| *** bknudson has joined #openstack-keystone | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!