Tuesday, 2014-04-08

openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Collapse SQL Migrations  https://review.openstack.org/7816900:01
morganfainbergdstanek, +365, -475700:01
morganfainbergdstanek, ^00:01
morganfainbergdolphm, cc https://review.openstack.org/78169 no longer needs -200:03
*** derek_c has quit IRC00:05
dstanek-4757!00:09
morganfainbergdstanek, yesss! feels good00:09
dstanekmorganfainberg: let me know when you have a few mins - couple db questions for you00:10
morganfainbergdstanek, hmm. well somehow i caused a major failure with that change set :P00:10
morganfainbergdstanek, sure have time now00:10
morganfainbergooh lol00:10
dstanekmorganfainberg: i'm pretty sure that i won't need the _setup_database anymore because of line 46 here: https://review.openstack.org/#/c/85651/3/keystone/tests/ksfixtures/database.py00:11
dstanekmorganfainberg: what do you think of that? i'm basically making the sql tests more deterministic00:12
morganfainbergdstanek, hm... that seems sane00:12
dstanekright now if you ran some tests in isolation you will get different database schemas based on what was imported00:12
morganfainbergdstanek, i am curious if this impacts the live tests00:13
morganfainbergdstanek, well, except don't you auto import extensions00:13
dstanekmorganfainberg: i'm currently running on mysql with no _setup_database - after that i'll mess with the live tests00:13
morganfainbergdstanek, the idea was that we wouldn't migrate in the extension unless it was used.00:14
morganfainberghence the difference in schema00:14
morganfainbergproduction could see similar differences00:14
*** mgagne has joined #openstack-keystone00:15
dstanekmorganfainberg: i can try to make the migration test more controlled the problem is that we are not actually controlling this right now00:15
dstanekwhatever is imported is created00:15
morganfainbergdstanek, i guess for reflection creation purposes this actually makes more sense00:17
morganfainbergwe don't care if extra extensions are loaded00:17
morganfainbergdstanek, your impl. is better. keep it.00:17
morganfainbergdstanek, i'm crossing the upgrade tests vs the unit or restful tests.00:17
dstanekmorganfainberg: i'll make sure the upgrade tests are still controlled00:18
morganfainbergyeah00:18
morganfainbergdstanek, shouldn't be an issue because we don't use reflection for that set of tests00:19
*** ChanServ changes topic to "All of the project infrastructure hosts are being restarted for security updates."00:21
dstanekthat has been interesting because the backend kvs and ldap tests need sql configured00:22
dstaneki remember talking about that, but it's much different to have the explicit fixture closer to that code00:22
morganfainbergdstanek, yep00:23
morganfainbergnow... i'm trying to figure out why the check is failing my migrations when locally it works.00:23
dstanekmorganfainberg: is it failing? the only i'm looking at just needs to be rebased00:24
*** openstackgerrit has quit IRC00:24
morganfainbergdstanek, no mine00:24
morganfainbergdstanek, https://jenkins06.openstack.org/job/gate-keystone-python27/679/console00:25
morganfainbergi don't get the same failure.00:25
dstanekgotta wait for the reboot00:25
morganfainbergdstanek, ?00:29
dstanekthe just bounced the jenkins boxes - back now00:30
morganfainbergah00:30
morganfainbergi greatly dislike our git keystoneclient checks00:32
morganfainberg:(00:32
*** browne has quit IRC00:36
dstanekthat's a strange error00:37
dstanekis there maybe a different in migrate versions?00:37
dstanekmorganfainberg: ^00:37
morganfainbergdstanek, that is my thought. this means this is going to be a challenge to work around.00:37
dstanekmorganfainberg: what version are you using locally?00:38
morganfainbergdstanek, whatever tox installes00:38
morganfainbergso probably 0.9.x00:38
morganfainbergdstanek, oh interesting00:39
morganfainbergdstanek, got a failure locally. wow bad test isolation00:39
morganfainbergonly occurs in a full test run00:40
morganfainbergdoesn't occur running just the test_sql_upgrade tests00:40
ayoung_cookingdolphm, so...I realize that of the four patches to backport, we only really want the UTF-8 patch...but getting that without the other 3 seems like a lot of work...wouldn't it be better to just grab the series?00:40
dstanekha, that the kind of thing i'm trying to get rid of00:40
morganfainbergdstanek, and it didn't fail initially on a full run00:40
*** derek_c has joined #openstack-keystone01:00
*** gyee has quit IRC01:01
dstanekdolphm: jython is a no go; i can't event create a virtualenv up and running01:06
*** marcoemorais has quit IRC01:06
morganfainbergdstanek, aha, i think i found it01:07
dstanekmorganfainberg: what was it?01:07
morganfainbergdstanek, extension migration versions don't start with 35 :P01:07
morganfainbergdstanek, at least this should now pass unit tests *runs locally* now i do need to see why tempest is complaining01:08
morganfainbergand i wont know that until the test run completes01:10
*** richm has quit IRC01:17
*** ChanServ changes topic to "Open for Juno development; submit design summit session proposals ASAP (deadline: April 20th) http://summit.openstack.org/"01:32
*** openstack has joined #openstack-keystone01:48
*** askb_ has quit IRC01:57
*** david-lyle has joined #openstack-keystone02:02
*** mberlin1 has joined #openstack-keystone02:08
*** mberlin has quit IRC02:09
nkinderayoung_cooking: still cooking!?  You must be BBQ'ing brisket...02:19
nkinderjamielennox: ping02:19
jamielennoxnkinder: hey02:19
nkinderjamielennox: I was wondering if there's anything I missed on the client side for this - https://wiki.openstack.org/wiki/Security/Icehouse/Keystone02:20
jamielennoxnkinder: i can't think of anything02:21
jamielennoxthe only client side crypto should be decrypting PKI tokens02:21
jamielennoxand then encrypted caching to memcache02:21
nkinderjamielennox: well, also outgoing HTTPS (via requests), right?02:22
nkinderjamielennox: it's indirect of course...02:22
jamielennoxnkinder: oh, yea - as you say that's all handled by requests02:22
nkinderjamielennox: I wasn't sure what Requests uses underneath the covers.  I can dive into it, but do you know off hand?02:23
jamielennoxnkinder: it hands that off to urllib3, so whatever it uses02:23
nkinderjamielennox: ok02:23
jamielennoxi'm pretty sure the stuff like hostname matching is done by urllib3, i don't know what handles the crypto02:24
jamielennoxbut i would guess that it's all a wrapper around python's ssl02:24
nkinderjamielennox: yeah, I think that's likely the case as well02:26
jamielennoxmost of these http layers aren't doing actual work, they are mostly for usability02:26
nkinderjamielennox: yeah, I just want to know if they use PyCrypto, M2Crypto, etc.  I was pretty sure none of them are doing their own crypto (at least I hope not)02:28
jamielennoxi don't think i've drilled down that far - but i can't imagine it, they're fairly standard libraries (which doesn't preclude people doing stupid things, just that it should have been found)02:29
*** harlowja is now known as harlowja_away02:30
*** amcrn has joined #openstack-keystone02:32
*** Guest_ has joined #openstack-keystone02:33
*** harlowja_away is now known as harlowja02:40
*** topol has joined #openstack-keystone02:43
*** Chicago has joined #openstack-keystone02:53
*** Chicago has quit IRC02:53
*** Chicago has joined #openstack-keystone02:53
*** amcrn has quit IRC02:53
morganfainbergdstanek, ok finally solve (i think) most of my issues. the majority were that I didn't populate the default domain *doh* which we previously did in a migration02:56
morganfainbergdstanek, i think i have everything worked out now :) running tests then uploading.02:56
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Collapse SQL Migrations  https://review.openstack.org/7816903:06
dstanekmorganfainberg: very nice03:11
*** wchrisj has quit IRC03:29
*** wchrisj has joined #openstack-keystone03:29
morganfainbergdstanek, now just fighting with pgsql03:30
morganfainbergdstanek, something about how unique constraints are created with automagic names in sqla... i guess i need to let it auto name these? but the schema comes out different if i do (constraint naming that is)03:31
morganfainbergmaybe we should name these sanely going forward? maaaybe figure out if we can migrate these constraints and FKs to be all consistent across all dbs?03:32
dstanekmorganfainberg: so the names are different depending on the DB?03:36
morganfainbergdstanek, it appears so03:36
morganfainbergdstanek, also, our previous migrations just let SQLA define the constraints however it wanted03:37
morganfainbergdstanek, probably not "correct"03:37
morganfainbergit should probably be explicitly defined.03:37
morganfainbergand.. i think the tables we create with reflection do not really "mirror" actual tables since we don't name the constraints03:38
morganfainbergthough anyone who uses the reflection to make the schema in production is "doing it wrong"03:39
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Collapse SQL Migrations  https://review.openstack.org/7816903:39
morganfainbergdstanek, i'll think on it, but i think i'm going to propose a schema migration to "fix" all constraints to have clear naming.03:40
morganfainbergi also noticed we are using unique constraints in some places we're looking for unique_indexs03:42
* morganfainberg grumbles03:43
*** chandan_kumar has quit IRC03:44
morganfainbergthey should be the same thing (performance / effect wise) but they appear differently in the ORM03:47
*** amcrn has joined #openstack-keystone03:49
*** chandan_kumar has joined #openstack-keystone03:50
*** chandan_kumar has quit IRC03:56
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Collapse SQL Migrations  https://review.openstack.org/7816903:58
*** wchrisj has quit IRC03:59
*** chandan_kumar has joined #openstack-keystone04:14
*** wchrisj_ has joined #openstack-keystone04:15
*** wchrisj_ has quit IRC04:19
*** wchrisj_ has joined #openstack-keystone04:23
*** wchrisj_ has quit IRC04:33
*** wchrisj has joined #openstack-keystone04:39
*** wchrisj has quit IRC04:45
*** wchrisj has joined #openstack-keystone04:56
*** wchrisj has quit IRC05:00
*** Guest_ has quit IRC05:03
*** harlowja is now known as harlowja_away05:03
*** Guest_ has joined #openstack-keystone05:04
openstackgerritA change was merged to openstack/keystone: Add tests for user ID with comma  https://review.openstack.org/8547805:07
*** zhiyan_ is now known as zhiyan05:09
*** henrynash has joined #openstack-keystone05:11
*** RockKuo has joined #openstack-keystone05:20
*** saju_m has joined #openstack-keystone05:28
*** topol has quit IRC05:30
*** dolphm has quit IRC05:33
*** dolphm has joined #openstack-keystone05:34
*** dolphm has quit IRC05:38
*** dolphm has joined #openstack-keystone05:40
*** henrynash has quit IRC05:59
openstackgerritJenkins proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/8395506:00
*** Chicago has quit IRC06:09
*** Chicago has joined #openstack-keystone06:13
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Initial kerberos plugin implementation.  https://review.openstack.org/7497406:18
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Allow passing auth plugin as a parameter  https://review.openstack.org/8367306:18
*** jaosorior has joined #openstack-keystone06:21
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Initial kerberos plugin implementation.  https://review.openstack.org/7497406:25
*** Guest_ has quit IRC06:28
*** derek_c has quit IRC06:34
*** inc0 has joined #openstack-keystone06:37
*** jamielennox is now known as jamielennox|away06:48
*** derek_c has joined #openstack-keystone07:02
*** derek_c has quit IRC07:09
*** saju_m has quit IRC07:17
*** saju_m has joined #openstack-keystone07:25
*** saju_m has quit IRC07:32
*** morganfainberg is now known as morganfainberg_Z07:36
*** andreaf has joined #openstack-keystone07:56
*** saju_m has joined #openstack-keystone07:58
*** saju_m has quit IRC08:03
*** stevemar has quit IRC08:07
*** leseb has joined #openstack-keystone08:12
*** chandan_kumar has quit IRC08:15
*** saju_m has joined #openstack-keystone08:16
*** andreaf has quit IRC08:45
*** andreaf has joined #openstack-keystone09:13
*** henrynash has joined #openstack-keystone09:20
*** saju_m has quit IRC09:39
*** inc0 has quit IRC09:39
*** jaosorior has quit IRC09:39
*** dolphm has quit IRC09:39
*** RockKuo has quit IRC09:39
*** mgagne has quit IRC09:39
*** harlowja_away has quit IRC09:39
*** mhu has quit IRC09:39
*** ayoung_cooking has quit IRC09:39
*** bada has quit IRC09:39
*** mfisch has quit IRC09:39
*** dstanek has quit IRC09:39
*** d0ugal has quit IRC09:39
*** serverascode has quit IRC09:39
*** dtroyer has quit IRC09:39
*** jamiec has quit IRC09:39
*** uvirtbot has quit IRC09:39
*** ayoung_cooking has joined #openstack-keystone09:39
*** bada has joined #openstack-keystone09:39
*** inc0 has joined #openstack-keystone09:39
*** serverascode has joined #openstack-keystone09:39
*** RockKuo has joined #openstack-keystone09:39
*** serverascode has quit IRC09:39
*** serverascode has joined #openstack-keystone09:39
*** jaosorior has joined #openstack-keystone09:39
*** bada has quit IRC09:39
*** david-lyle has quit IRC09:39
*** openstackgerrit has quit IRC09:39
*** zhiyan has quit IRC09:39
*** Daviey has quit IRC09:39
*** huats has quit IRC09:39
*** openstack has joined #openstack-keystone09:49
*** koolhead17 has joined #openstack-keystone09:53
*** jaosorior has quit IRC09:56
*** jaosorior has joined #openstack-keystone09:56
*** serverascode has quit IRC09:57
*** serverascode has joined #openstack-keystone09:57
*** serverascode has quit IRC10:03
*** mfisch has quit IRC10:03
*** jaosorior has quit IRC10:03
*** Chicago has quit IRC10:03
*** zigo has quit IRC10:03
*** marekd|away has quit IRC10:03
*** bknudson has quit IRC10:03
*** sld has quit IRC10:03
*** sudorandom has quit IRC10:03
*** mfisch` has joined #openstack-keystone10:03
*** sld has joined #openstack-keystone10:03
*** zhiyan is now known as zhiyan_10:03
*** serverascode has joined #openstack-keystone10:04
*** jaosorior has joined #openstack-keystone10:04
*** zigo has joined #openstack-keystone10:04
*** afaranha has joined #openstack-keystone10:05
*** dolphm has quit IRC10:13
*** serverascode has quit IRC10:13
*** serverascode has joined #openstack-keystone10:13
*** mhu has quit IRC10:15
*** mfisch` has quit IRC10:15
*** jamiec has quit IRC10:15
*** mgagne has quit IRC10:16
*** sudorandom has joined #openstack-keystone10:17
*** mfisch has joined #openstack-keystone10:20
*** mfisch has quit IRC10:20
*** mfisch has joined #openstack-keystone10:20
*** huats has quit IRC10:26
*** uvirtbot has quit IRC10:26
*** zhiyan_ has quit IRC10:26
*** ayoung_cooking has quit IRC10:26
*** inc0 has quit IRC10:26
*** andreaf has quit IRC10:26
*** lbragstad has quit IRC10:26
*** jimbaker has quit IRC10:26
*** uvirtbot has joined #openstack-keystone10:27
*** jimbaker has joined #openstack-keystone10:27
*** huats has joined #openstack-keystone10:27
*** huats has quit IRC10:27
*** huats has joined #openstack-keystone10:27
*** andreaf has joined #openstack-keystone10:27
*** jimbaker has quit IRC10:27
*** jimbaker has joined #openstack-keystone10:27
*** inc0 has joined #openstack-keystone10:27
*** andreaf has quit IRC10:27
*** andreaf has joined #openstack-keystone10:27
*** zhiyan_ has joined #openstack-keystone10:28
*** ayoung_cooking has joined #openstack-keystone10:29
*** lbragstad has joined #openstack-keystone10:32
*** saju_m has quit IRC10:34
*** saju_m has joined #openstack-keystone10:35
*** lbragstad has quit IRC10:39
*** afaranha has quit IRC10:39
*** david-lyle has quit IRC10:39
*** mberlin1 has quit IRC10:39
*** lbragstad has joined #openstack-keystone10:40
*** david-lyle has joined #openstack-keystone10:40
*** afaranha has joined #openstack-keystone10:40
*** mberlin has joined #openstack-keystone10:40
*** chandan_kumar has joined #openstack-keystone11:03
*** RockKuo has quit IRC11:28
*** chandan_kumar has quit IRC11:44
*** mhu has joined #openstack-keystone11:44
*** dolphm has joined #openstack-keystone11:46
*** mgagne has joined #openstack-keystone11:48
*** ayoung_cooking has quit IRC12:00
*** chandan_kumar has joined #openstack-keystone12:02
*** serverascode has quit IRC12:16
*** serverascode has joined #openstack-keystone12:16
*** david-lyle has quit IRC12:17
*** zigo has quit IRC12:17
*** zigo has joined #openstack-keystone12:18
*** dolphm has quit IRC12:18
*** mhu has quit IRC12:18
*** mfisch has quit IRC12:18
*** sudorandom has quit IRC12:18
*** mgagne has quit IRC12:19
*** mhu has joined #openstack-keystone12:20
*** mgagne has joined #openstack-keystone12:21
*** mfisch has joined #openstack-keystone12:21
*** mfisch has joined #openstack-keystone12:21
*** dolphm has joined #openstack-keystone12:21
*** sudorandom has joined #openstack-keystone12:21
*** zhiyan_ is now known as zhiyan12:27
*** erecio has joined #openstack-keystone12:27
*** erecio has quit IRC12:36
*** bknudson has joined #openstack-keystone12:37
*** marekd has joined #openstack-keystone12:53
*** dstanek has quit IRC12:55
*** dstanek has joined #openstack-keystone12:56
*** erecio has joined #openstack-keystone12:59
erecioHi, everybody.  I was wondering if its possible that Keystone alert the users about this serious bug on OpenSSL http://heartbleed.com/ ?13:06
*** joesavak has joined #openstack-keystone13:21
*** openstackgerrit has joined #openstack-keystone13:23
*** openstackgerrit has quit IRC13:23
*** openstackgerrit has joined #openstack-keystone13:24
*** ayoung has joined #openstack-keystone13:30
*** jsavak has joined #openstack-keystone13:30
*** dims has joined #openstack-keystone13:33
*** joesavak has quit IRC13:34
*** Chicago has joined #openstack-keystone13:34
*** Chicago has joined #openstack-keystone13:34
*** flwang has joined #openstack-keystone13:37
flwanggreetings13:37
marekdjamielennox|away: ping me back when you are online.13:37
flwangI'd like to know is there any way to save a public key into Keystone for a specific user?13:37
flwangthanks13:38
openstackgerritPablo Fernando Cargnelutti proposed a change to openstack/keystone: Extracting get group roles for project logic to drivers.  https://review.openstack.org/8602513:39
bknudsonflwang: I don't think that we want to store user info in keystone, given the direction that we're going with federation13:41
*** nkinder has quit IRC13:41
bknudsonflwang: maybe barbican has a use case for it?13:41
openstackgerritayoung proposed a change to openstack/python-keystoneclient: revoke events  https://review.openstack.org/8116613:45
flwangbknudson: thanks, but IMHO, Barbican is used to store private key, so i'm not sure if it's a good place for public key13:48
flwangbknudson: or maybe we should not really care it13:48
*** vhoward- has left #openstack-keystone13:53
*** ChanServ sets mode: +o dolphm13:58
openstackgerritRaildo Mascena de Sousa Filho proposed a change to openstack/keystone: Filter User by project  https://review.openstack.org/8413614:04
*** chandan_kumar has quit IRC14:16
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Add CRUD operations for Identity Providers.  https://review.openstack.org/8333714:24
*** david-lyle has joined #openstack-keystone14:28
*** nkinder has joined #openstack-keystone14:30
*** derek_c has joined #openstack-keystone14:33
*** stevemar has joined #openstack-keystone14:37
*** saju_m has quit IRC14:41
ayoungdolphm, regarding jdennis' stack of patches for UTF-8:  I hear you on not backporting the refactoring for its own sake:  but we broke up the UTF-8 fix to make it more reviewable.   That should not block the patch series from being backported, especially to Icehouse, but even potentially to Havana.14:44
*** jamielennox|away has quit IRC14:45
*** jamielennox|away has joined #openstack-keystone14:49
*** jamielennox|away has quit IRC14:49
*** jamielennox|away has joined #openstack-keystone14:49
dolphmayoung: we don't backport refactors, they're too risky14:49
ayoungdolphm, even when the "refactor" in this case was to restructure the code in order to fix the bug?14:50
ayoungand...do we areally need to wait to Juno to get this bug fix?14:50
*** thedodd has joined #openstack-keystone14:51
ayoungI see Thierry agrees with you14:51
dolphmayoung: you can propose a clean fix to milestone-proposed or stable/ which must be aggressively reviewed -- but don't include a massive refactor, it's just not an option14:51
ayoungdolphm, I hear ya.  I just would feel better with the version of the code that actually landed in Master.  Not sure how easy this is going to be without the refactor.14:55
*** wchrisj has joined #openstack-keystone15:00
*** gokrokve has joined #openstack-keystone15:03
*** joesavak has joined #openstack-keystone15:04
*** jsavak has quit IRC15:06
*** wchrisj has quit IRC15:09
marekdstevemar: hello.15:13
stevemarmarekd, howdy15:13
marekdstevemar: https://review.openstack.org/#/c/83337/8/keystoneclient/v3/contrib/federation/identity_providers.py i am still wondering whether it would not be better to store all the attributes (like description, enabled etc) in Resource class. Isn't the class exactly for that?15:14
*** flwang has left #openstack-keystone15:17
*** Gu_______ has joined #openstack-keystone15:18
stevemarmarekd, you could, i don't know the other classes don't15:19
marekdstevemar: the other classes like class Project(base.CrudManager) etc?15:20
*** andreaf has quit IRC15:20
*** derek_c has quit IRC15:20
stevemaryeah, i don't think any actually store variables there right?15:20
marekdstevemar: lol, so why keep those clases? :D15:20
*** dstanek has quit IRC15:23
*** Gu_______ has quit IRC15:27
*** gyee has joined #openstack-keystone15:32
*** tomoiaga has joined #openstack-keystone15:38
*** bvandenh has joined #openstack-keystone15:44
*** Gu_______ has joined #openstack-keystone15:46
openstackgerritA change was merged to openstack/keystone: Fix response for missing attributes in trust  https://review.openstack.org/8532715:49
*** Gu_______ has quit IRC15:50
*** Guest____ has joined #openstack-keystone15:53
*** samuelmz_ has joined #openstack-keystone15:53
samuelmz_Hi, I'm trying to get nova working with keystone v3. I saw there is a bug to fix this https://bugs.launchpad.net/python-novaclient/+bug/126284315:58
uvirtbotLaunchpad bug 1262843 in python-novaclient "Nova and Cinder cannot be used with v3 authentication (dup-of: 1154809)" [Undecided,New]15:58
uvirtbotLaunchpad bug 1154809 in python-keystoneclient "Volume detach fails via OSAPI: AmbiguousEndpoints" [Wishlist,Confirmed]15:58
samuelmz_But I'd like to know if there is a workarround15:58
samuelmz_like Yaguang Tang's suggested at http://comments.gmane.org/gmane.comp.cloud.openstack.general/365715:59
samuelmz_s/Tang's/Tang16:02
*** marcoemorais has joined #openstack-keystone16:02
*** derek_c has joined #openstack-keystone16:09
*** browne has joined #openstack-keystone16:15
*** kun_huang has joined #openstack-keystone16:16
*** tomoiaga has quit IRC16:18
*** jsavak has joined #openstack-keystone16:19
*** derek_c has quit IRC16:20
bknudsonsamuelmz_: I think the issues that different projects are running into is that the service catalog in the v3 token is incompatible with v2 service catalog16:21
*** joesavak has quit IRC16:22
*** lbragstad has quit IRC16:23
openstackgerritA change was merged to openstack/python-keystoneclient: Reuse module `exceptions` from Oslo  https://review.openstack.org/6889716:25
samuelmz_bknudson, ok, so to get services working with keystone v3 is more than just adapting the services to accept token v3, as Yaguang Tang has proposed https://review.openstack.org/#/c/82149/216:31
samuelmz_bknudson, right?16:31
samuelmz_bknudson, in this case, he proposed to nova16:32
*** dstanek has joined #openstack-keystone16:34
*** saju_m has joined #openstack-keystone16:35
*** derek_c has joined #openstack-keystone16:36
dstanekstevemar / marekd : have you tried running any of the federation tests against mysql?16:39
marekddstanek: no.16:40
marekddstanek: this is a hypothetical question or you are having some troubles with that?16:40
dstanekmarekd: http://paste.openstack.org/show/75341/16:40
dstaneki've been hacking on how we use the database in our tests and i ran into that16:40
*** Guest____ has quit IRC16:41
marekddstanek: hmm, wait...devstack runs on mysql, right?16:41
dstanekmarekd: it does - i think it may be a difference in migrations -> models, but i wanted to see if anyone has already looked into it16:42
marekddstanek: ok, so i did play with keystone + federation + apache and used devstack as a base.16:43
marekddstanek: these are not tests themselves, but hey, eventually all the requests should look identically, right? :-)16:45
dstanekmarekd: :-)16:46
marekddstanek: I am not sure if I understood you correctly. So you think  that error is caused by bad migrations scripts?16:49
dstanekmarekd: no, i just rolled back my changes to see if it was me; i think it may be because i was loading the scheme using the model objects instead of the migrations16:50
marekddstanek: ok16:52
dstanekmarekd: i'm wondering if it's the extra unique constraint in the model16:57
*** joesavak has joined #openstack-keystone16:57
*** jsavak has quit IRC17:00
*** leseb has quit IRC17:00
marekddstanek: this?17:03
marekddstanek: https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/backends/sql.py#L3017:03
dstanekmarekd: yes17:03
*** henrynash has joined #openstack-keystone17:04
*** amcrn has quit IRC17:04
marekddstanek: hmm, i can see that identity and assignments also have 'combined' unique constraints..17:05
dstanekmarekd: ha! https://review.openstack.org/#/c/84447/17:05
dstanekmarekd: it's a primary key so it should already be unique unless sqlite is dumb (which is entirely possible)17:06
*** lbragstad has joined #openstack-keystone17:06
marekddstanek: aha.17:07
marekddstanek: so your suspection is mysql tries to apply this uniqueness constraint on already unique composite primary key (which implies it's unique)17:09
*** jaosorior has quit IRC17:10
ayoungmorganfainberg_Z, nkinder, intersting discussion here in meatspace:  what if we take the patch that allows attaching pydev etc to a Keystone  running in eventlet, and make it work for Apache based deploys.  Then, as part of keystone in httpd/devstack we connect to that via pdb or something?  I'm talking about this patch:    http://git.openstack.org/cgit/openstack/keystone/commit/?id=0f225743e8644416df2f200d710912c40b7acd4717:11
*** bvandenh has quit IRC17:12
*** jaosorior has joined #openstack-keystone17:15
*** harlowja has joined #openstack-keystone17:16
*** nlahouti_ has joined #openstack-keystone17:22
*** morganfainberg_Z is now known as morganfainberg17:22
nlahouti_Can someone please let me know how to enable notification in keystone when a tenat is create/deleted?17:23
dstanekmarekd: it appears that the extra constraint isn't the issue17:23
morganfainbergayoung, interesting17:23
ayoungmorganfainberg, I thought so17:23
morganfainbergayoung, I am a fan of pydevd debugging personally17:23
ayoungmorganfainberg, it doesn't let you restart keystone without restarting all of the httpd process though17:23
morganfainbergayoung, right17:24
ayoungmorganfainberg, and I am not certain that you could connect to the remote processes via some command line tool yet17:24
ayoungNeed to do more research17:24
morganfainbergayoung, might be able to, but you might need to do some wonky stuff such as limit to a single wsgi process so you can actually debug17:24
morganfainbergayoung, might be very hard to debug with all the workers grabbing whatever requests they get17:25
ayoungmorganfainberg, yeah17:25
morganfainbergayoung, but in premise i like the concept a lot17:25
marekddstanek: and it's still federation only?17:26
marekddstanek: https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L560 -> ok, here its not unique on two PKs, but I think you have just eliminated that as a possibility?17:27
dstanekayoung: can't that be done in middleware instead of in keystone itself?17:27
dstanekmarekd: no, there are lots of things that fail17:27
dstanekthe unicode tests all seemt to fail17:28
dolphmcan someone respond to the "event notifications issue" thread on openstack-dev? the config there looks fine to me, i'm not sure what the issue is17:28
*** tomoiaga has joined #openstack-keystone17:29
dolphmit sounds like there might be a regression from oslo between havana and icehouse17:29
nlahouti_dolpahm: thaks for your reply. It was okay before till I sync'd up with the master17:29
morganfainbergdolphm, hm..17:31
morganfainbergdolphm, that config looks sane....17:31
dstanekdolphm, morganfainberg: can the -2 be removed on https://review.openstack.org/#/c/78169/17:31
dolphmyes!17:31
dolphmdone17:31
morganfainbergdolphm, dstanek, look at the comment about the fk, ix, and ixu constraints/indexes17:32
nlahouti_dolphm: keystone/keystone/openstack/common/rpc does not exist in the latest code anymore17:32
morganfainbergnot sure if that is sufficient, but i'm thinking we should outline a specific convention so if we decide to use relfection at any point we can.17:33
dstanekdolphm: thx17:33
*** tomoiaga has quit IRC17:33
dstanekmorganfainberg: so does that mean we'll have to explicitly list our indexes in the model?17:33
morganfainbergnlahouti_, oh oooooh this is an oslo.messaging change cc dolphm my guess17:33
dolphmnlahouti_: ah, that makes sense... hmm17:33
bknudsonsamuelmz_: https://review.openstack.org/#/c/82149/ is the client side (getting a token via v3 api)... jamielennox|away is working on changes to support that.17:33
morganfainbergdstanek, we should. we should also do some work to make a factory for user_id fields etc, so we don't need to change multiple places if we want to update the models.17:34
dolphmnlahouti_: morganfainberg: do we need to restore it, even though we're not explicitly using it? (and open an rc3?)17:34
morganfainbergdolphm, well, oslo.messaging supposedly supersedes it afaik, but we might need to restore that for Icehouse and rip it out in Juno? This is another reason oslo-incubator is a pita17:35
*** amcrn has joined #openstack-keystone17:35
nlahouti_dolphm: have parameters setting changed for the new code?17:35
nlahouti_dolphm: I meand setting it in keystone.conf file17:35
dolphmnlahouti_: i think you might just be able to specify 'rabbit' for that option?17:35
morganfainbergdolphm, or do we need to keep things like this for 2 releases (ugh, can i vote we stop using incubator code that connect into the keystone.conf if so..)17:35
nlahouti_I did17:35
dolphmnlahouti_: or let it default17:35
dolphmmorganfainberg: :-/17:35
nlahouti_but  where does the message go?17:36
dolphmnlahouti_: oh, is that your thread on openstack-dev?17:36
nlahouti_it used to be in notification.info17:36
*** elmiko has joined #openstack-keystone17:36
nlahouti_or anything that I set as notification topic in the keystone.conf17:36
morganfainbergdolphm, nlahouti_ would be the name i'd expect on IRC :)17:36
dolphmnlahouti_: "The rpc_backend option is not required as long as RabbitMQ is the default messaging system." - http://docs.openstack.org/trunk/config-reference/content/configuring-rpc.html17:37
elmikohey all, i started up my stack today and i'm getting errors in /var/log/keystone/keystone.log when i attempt to authenticate. has anyone encountered this before "ERROR keystone.common.wsgi [-] (OperationalError) (1054, "Unknown column 'endpoint.enabled' in 'field list'")" ?17:38
nlahouti_dolphm: the problem is rpc_backend=nova.openstack.common.rpc.impl_kombu  does not exist anymore17:38
dolphmnlahouti_: have you tried not setting that option at all, though?17:38
nlahouti_dolphm: is it the latest doc that I can follow for the config17:38
morganfainbergnlahouti_, rpc_backend should be set to "rabbit" now17:39
nlahouti_dolphm: yes and the problem wan that _notifier was None17:39
morganfainbergnlahouti_, for keystone, which would just put it on the bus directly17:39
dstanekwhat actually uses the rpc_backend setting?17:39
morganfainbergdstanek, that is provided by oslo.messaging, that should be "qpid" "zmq" or "rabbit"17:39
morganfainberghttps://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L30417:40
morganfainbergjust based on sample config17:40
dstanekmorganfainberg: ah, that's why i don't see it in our code17:40
morganfainbergyeah17:40
morganfainbergthis is the move to oslo.messaging17:40
nlahouti_dstanek: Now I set it to rpc_backend=rabbit17:40
morganfainbergdolphm, restoring the openstack.common rpc stuff would be bad.17:40
morganfainbergdolphm, possible conflicts with oslo.messaging17:40
dolphmmorganfainberg: oh, true. crap17:40
morganfainbergs/would/could17:41
dolphmmorganfainberg: i guess we need to figure this out and provide upgrade notes17:41
samuelmz_bknudson, cool.. thanks for ur help17:41
dolphmdstanek: just CRUD notifications at the moment17:41
nlahouti_morganfainberg: did it work or was it tested with the oslo.messaging17:41
morganfainbergnlahouti_, it should work with oslo.messaging (assuming icehouse code?)17:42
nlahouti_morganfainberg: I checkout the master17:42
morganfainbergnlahouti_, ok17:43
morganfainbergnlahouti_, should work with oslo.messaging17:43
morganfainberglooking at the notification driver setting17:43
nlahouti_morganfainberg: but I need to know the correct format  of parameter that works17:43
morganfainbergnlahouti_, yep, give me a second to chase this down for ya :)17:44
nlahouti_morganfainberg: thx a lot17:44
morganfainbergnlahouti_, ok still looking but you might be able to set it to "rabbit" or "kombu" (yes the string)17:50
morganfainbergnlahouti_, this seems wrong though. hold on17:50
*** henrynash has quit IRC17:51
dstanekmorganfainberg, nlahouti_: there is an answer on the list17:52
morganfainbergdstanek, ah *looks*17:53
nlahouti_morganfainberg: what list?17:53
morganfainbergnlahouti_, the mailing list17:53
morganfainbergnlahouti_, in response to your email (solly ross responded)17:53
nlahouti_morganfainberg: ok ;) i'll check17:53
morganfainbergnlahouti_, looks like "messaging" is the right answer17:53
morganfainbergdstanek, the fact that the documentation for oslo.messaging doesn't make this easy is ugly17:54
nlahouti_morganfainberg: and how about the notification_topics, control_exchange, and notification_driver17:54
morganfainbergnlahouti_, ok if you read the email, the rpc_backend should be "rabbit" and the notification_driver "messaging"17:54
morganfainbergnlahouti_, i believe the other options don't really change17:55
nlahouti_morganfainberg: ok. let me read and try the recommendation.17:55
morganfainbergnlahouti_, of course you'll need to configure the options to point at the correct rabbit server, etc17:55
*** gokrokve has quit IRC17:55
morganfainbergnlahouti_, but again those should be mostly the same if not identical17:56
*** anteaya has quit IRC17:56
dolphmbottom section of http://docs.openstack.org/trunk/config-reference/content/configuring-rpc.html is relevant17:56
marekddolphm: Hi, could you please remind me what was the proper way to work with dependencies in gerrit? Say I have review X and said X is a dependency for Y (well, Y is built on top of X). So it's git review -d X, later git review -x Y and next...git commit --amend?17:56
dolphmnlahouti_: notifications_topics and control_exchange are your preference, you just need to be consistent about them17:56
nlahouti_dolphm: thx for the doc17:57
*** jamielennox|away is now known as jamielennox17:58
dolphmmarekd: git review -d X would checkout the first commit, git review -x Y would cherry-pick the second commit onto whatever branch you're on (if you already have the first commit checked out, then it's basically a rebase on top of the latest X)17:58
dolphmmarekd: git commit --amend would then rewrite the second commit; a subsequent git-review would submit everything on the current branch not-in-gerrit to gerrit17:59
* dolphm meeting time!17:59
marekddolphm: so, let's say i had to update X, and now want to bring those changes to Y so I have a new 'base'17:59
dstanekmarekd: when i have patchsets like X->Y->Z i'll git review Z and modify the X, Y or Z commit before running git review18:00
dstaneki never 'git review -d' commits other than the top one in the dep list18:00
*** topol has joined #openstack-keystone18:01
*** tjones has joined #openstack-keystone18:01
*** diegows has joined #openstack-keystone18:02
diegowshi18:02
diegows:)18:02
diegowsWhat do you think about a PAM authentication module for keystone?18:02
diegowsI'd like to implement LDAP auth, but there is no backend for that (I don't need identity management, just auth)18:02
diegowsand may be a implementation with PAM could open the game to other auth methods easily18:02
*** thedodd has quit IRC18:03
*** tjones has left #openstack-keystone18:04
morganfainbergdiegows, we're in a meeting now, but we had one and it wasn't used (it had been broken since before grizzly)18:04
brownediegows: i'm not a fan of the PAM driver.18:05
morganfainbergdiegows, my guess is that a new one will see similar use, PAM is not well suited for providing the information needed for a user for keystone.18:05
*** joesavak has quit IRC18:05
morganfainbergdiegows, feel free to propose it, but i'm concerned about maintaining it and functionality18:05
diegowsmorganfainberg, I don't need to provide information,  just authentication18:05
diegowslike the other authentication modules18:06
dstanekdiegows: this is what morganfainberg was talking about http://git.openstack.org/cgit/openstack/keystone/commit/?id=6bd230718:06
diegowsAFAIK, they only very user/pass18:06
*** richm has joined #openstack-keystone18:06
brownecouldn't the remote_user auth with httpd be used for diegows?18:06
*** thedodd has joined #openstack-keystone18:06
diegowsbut that require may be a more complex config, something simple like PAM or just LDAP directly would be better I think18:07
brownediegows: you can use LDAP for auth/user/groups and SQL for assignments18:07
diegowsLDAP Identify module, right?18:09
*** wchrisj has joined #openstack-keystone18:10
morganfainbergdiegows, you could also just write an auth_plugin that does pam auth.18:11
brownediegows: yes, you can configure keystone to use LDAP for identity driver and SQL for assignment.  I like this setup18:11
diegowsmorganfainberg, I was talking about that :), may be I wasn't clear18:11
diegowsbrowne, I'm setting up OpenStack in a company where we have an AD that we can't touch18:12
brownediegows: yep, that's typical18:12
diegowsthe schema is weird, not very friendly with Keystone18:12
*** kun_huang has quit IRC18:12
nlahouti_morganfainberg: thx guys, I tried it and it worked!18:12
diegowsThat's why I mention that I need something simple, really simple, just authentication18:12
brownediegows: well, you'll have to construct proper search queries.  schema is what always gets tricky with hooking in ldap18:13
nlahouti_dolphm: morganfainberg: thx for the help. rpc_backend=rabbit and notification_driver=messaging were the correct setting.18:14
diegowsdstanek,  I was reading the commit that you mention and I don't want PAM identity mgmt, I want PAM authentication   auth /plugins/pam.py :)18:15
morganfainbergnlahouti_, ++ glad we could help (though give credit to the mailing list for the right answerts, solly helped a lot there)18:16
nlahouti_dolphm: morganfainberg: I just did and reply to the email :)18:16
morganfainbergnlahouti_, cheers18:16
*** samuelmz_ has quit IRC18:16
brownedstanek: nice that the pam driver was finally removed.  i always wondered why it remained and if anyone actually used it18:17
diegowsand a short question about how auth plugins, they are tried in order, right?18:17
morganfainbergbrowne, it was removed because i noticed it was really borken when i tried to refactor stuff around it18:19
morganfainbergdiegows, need to finish the meeting and we can talk about it, should be done in ~40min (max)18:20
diegowsPAM identity mgmt doesn't make sense I think, broken by definition :)18:20
diegowsok morganfainberg18:20
*** leseb has joined #openstack-keystone18:33
dolphmdiegows: ++18:34
diegowsdolphm, that "++" was about my last question or about the PAM module ? :)18:35
dolphmdiegows: uhh, PAM18:38
diegows:)18:38
dolphmdiegows: not sure which order you're referring to, though? plugins are executed in the order that the client identifies them18:39
dolphmdiegows: the service won't try multiple plugins for the same authentication method18:39
diegowshmm18:40
diegowssuppose that I have methods = external,password,token,oauth118:41
diegowsif external founds REMOTE_USER, will return OK and the process finish, right?18:41
*** leseb_ has joined #openstack-keystone18:42
ayoungyou diegows there is a Keystone meeting going on in #openstack-meeting right now...you will get more coherent answers in...17 minutes18:43
diegowsok, I know... but dolphm was answering :)18:44
*** saju_m has quit IRC18:44
*** leseb has quit IRC18:44
dolphmi was trying to jump in and out in a conversation lull :)18:46
dolphmdiegows: yes, to your last question18:46
*** thedodd has quit IRC18:50
*** thedodd has joined #openstack-keystone18:52
*** stevemar has quit IRC18:55
*** stevemar has joined #openstack-keystone18:55
*** inc0 has quit IRC18:55
nkindergyee: yeah, not much else we can do if it's just the hash string we're dealing with18:59
nkindergyee: what about prefixing the hash string with an identifier (like LDAP password hashes)?19:00
gyeeright, but embedding the algorithm would make it unambiguous19:00
bknudsonI'm trying to figure out where auth_token would use the hash algorithm in the token?19:00
gyeenkinder, yes, prefixing would work too19:00
*** Guest_ has joined #openstack-keystone19:00
dstanekayoung: i was hoping to test the db fixtures patch against a real database so i may just need to figure this out today too19:00
nkinder{SHA-256}blahblahblah19:00
gyee++19:00
gyeebknudson, two places, 1) revocation check, 2) online validatoin19:01
ayoungnkinder, not sure what that would solve19:01
bknudsongyee: the revocation list has the hash algorithm ...19:01
ayoungwe need to look up tokens by ID...ID is generated from the hash, but you would need to know tha algroithm a-priori19:01
bknudsongyee: we could reject tokens that don't have the same hash algorithm?19:01
nkinderayoung: ID is the hash, right?19:02
ayoungthis is a waste of efforts.  We just stop hashing the tokens all together19:02
ayoungnkinder, yep.  And only really needed for online validation.19:02
ayoungEphemeral is the way to solve it19:02
ayoungif you cahnge the hash algorthim for your server, all previous tokens get revoked.  Period19:03
nkinderI was looking for more info on ephemeral.  The blueprint didn't really go into the detail of what I was looking for.19:03
gyeebknudson, that's fine for revocation list then, we only need to worry about online validation19:03
nkinderWith ephemeral tokens, what is stored in the token database exactly?19:03
bknudsongyee: so in that case we get a hash on the request, then we send the hash to the server for confirmation.19:03
morganfainbergnkinder, just the revocation events19:03
bknudsongyee: I don't see where the hash algorithm comes in?19:03
nkindermorganfainberg gave me some details on IRC, which were helpful, but I'm wondering exactly what we would see.19:04
morganfainbergnkinder, token data wouldn't be stored in the DB at all19:04
nkindermorganfainberg: so no active tokens?19:04
morganfainbergnkinder, correct19:04
ayoungnkinder, the short version is this:  only cryptographic validation of tokens is ever performed.19:04
ayoungSo if a remote process askes keystone "is this token valid"  two things happend19:04
morganfainbergnkinder, ^ what ayoung said.19:04
nkinderand how does revocation reference a token?19:04
ayoungone19:04
ayoungthe token i verified  via cms19:04
bknudsongyee: unless you want the server to reject tokens that have the wrong algorithm?19:04
nkinderI need to read the token revocation events bp...19:04
ayoungtwo the token is convfrimed to not be revoked against the revocation events19:04
morganfainbergayoung, btw, that is next on my list of "todo" since SQL collapse is posted. (tangentially related)19:05
ayoungID becomes irrelevant19:05
dolphmtoken_backend = network19:05
gyeebknudson, but aren't we hash the PKI token for online validation?19:05
nkinderok, so when I want to revoke a token, it's simply done by referring to the user/group/whatever metadata instead of a token id?19:05
morganfainbergnkinder, correct.19:05
nkinderI guess date is in there as well?19:05
bknudsongyee: is online validation sending the token to the server?19:05
morganfainbergnkinder, yes19:05
nkinder...so I could say "revoke all of nkinder's tokens older then yesterday"19:06
ayoungnkinder, yes19:06
bknudsongyee: I just want to make sure I understand what's meant by "online validation"19:06
gyeebknudson, for PKI token, the token ID basically the hash of the PKI token19:06
ayoungnkinder, specifically:  user_id and issued_at time19:06
nkindercool19:06
bknudsongyee: that would be the client that's talking to auth_token that does the hash19:06
nkindergyee: signature verification from the signing cert19:06
gyeebknudson, you can validate a PKI token over the wire as oppose locally19:06
ayoungnkinder, it was going to do "expires_at" as well, but that revokes all tokens, and we are negotiating with Horizon, since that breaks the Horizon approach19:06
bknudsongyee: so you're more worried about the other clients and not auth_token?19:07
nkinderayoung: so the client has to look at what is in the token to see if a revocation event affects it, right?19:07
bknudsonI don't know if we provide a library for hashing a token... not sure how apps know how to do it.19:07
dolphmbknudson: with PKI / offline validation, you need the network at startup, but theoretically you can validate tokens while keystone is down, for example19:07
ayoungnkinder, correct.  The code to do that is going into a library, but non-python clients are going to need an impl as well19:07
ayoungthe clien piece is held up by python33 nastiness19:08
ayounghttps://review.openstack.org/#/c/81166/19:08
nkinderayoung, morganfainberg: I like it19:08
morganfainbergayoung, still fighting that?19:08
morganfainbergnkinder, yeah i liked it a lot when ayoung proposed it.19:08
gyeebknudson, revocation list is fetch at an interval, for those prefer real-time, they can do it over the wire19:08
ayoungmorganfainberg, no, I'm fighting my boss who wants me to pick uop the UTF8 fix.19:08
ayoungDid I mention nkinder is my boss?19:08
nkinderlooking at the contents of the token database scared me19:08
morganfainbergayoung, ah.19:09
ayoungHeh19:09
bknudsongyee: are you ok with auth_token not caring about the hash algorithm in the token?19:09
dolphmnkinder: as it should!19:09
morganfainbergnkinder, yeah i want that db table to die.19:09
morganfainbergnkinder, it's horribad (but we what we have for right now)19:09
dolphmDROP TABLE `token`; #juno19:09
morganfainbergdolphm, +++++++++++++++19:09
gyeebknudson, no, auth_token should carry the hash algorithm19:09
morganfainbergdolphm, waiiit are you using postgres!? :P19:09
bknudsongyee: where is it going to use it?19:09
stevemardid we end up deciding that the security docs should live in tree?19:09
gyeebknudson, sorry19:10
nkinderI had a question about some of the LDAP code too (which I mentioned in the "potential improvements" section of the security doc)19:10
morganfainbergstevemar, i think initialluy19:10
stevemarmorganfainberg, cool19:10
gyeebknudson, I mean auth_token middleware should not care about the configurable hash algorithm19:10
nkinderwhy do we have code that hashes passwords for LDAP users?19:10
ayoungnkinder, only for adding them in the backend19:10
ayoungI don't think it is called anywhere else19:11
nkinderI can't think of any reason why we would need to do that, so I'd like to see if it's safe to rip out19:11
dolphmstevemar: nkinder is going to poke other projects for ideas, but i think we're all happy to have them in-tree19:11
gyeeayoung, but LDAP itself hash the passwords19:11
nkindergyee: +119:11
ayounggyee, I needed it at one point19:11
stevemardolphm, okay, i might post a quick copy/paste of the wiki content (in rst format)19:11
bknudsongyee: ok, we hash a token for checking against the the cache ... but this happens before we've decoded the cms.19:11
dolphmstevemar: to gerrit?19:12
bknudsongyee: so we don't have the token hash at that point.19:12
nkinderthat's an old (bad) approach that things like pam_ldap used to take long ago.  The client would hash the password, then read the hash from LDAP and compare it!19:12
stevemardolphm, yes19:12
dstanekhas anyone seen this DB error before? http://paste.openstack.org/show/75341/19:12
bknudsongyee: do you think auth_token should decode the cms before hashing?19:12
morganfainbergnkinder, seems kinda icky19:12
ayoungkeystone/identity/backends/ldap.py:19:12
nkinderwe should just use the provided password and perform a bind with it19:12
morganfainbergnkinder, ++ i like that better19:13
dstaneki can't tell why it's choking other than a FK to a field that is part of a composit index19:13
ayoungnkinder, so we do it to check that the password matches, too19:13
dolphmstevemar: --author="Nathan Kinder <somethingsomething>"19:13
nkinderayoung: that's what a bind is for19:13
morganfainbergdstanek, yes i have seen that.19:13
ayoungnkinder, we don't make changes as the user19:13
ayoungthe bind is doen by the admin usder19:13
ayounguser19:13
stevemarcool19:13
*** gokrokve has joined #openstack-keystone19:13
dstanekmorganfainberg: were you able to solve it?19:13
nkinderayoung: bind isn't making changes19:13
gyeebknudson, that's fine, we can invalidate the cache for hash mismatch, something we can afford doing19:13
morganfainbergdstanek, ... it's (i want to say) invalid FK constraint / non-synced column types19:14
morganfainbergdstanek, either the refrenced column is busted, or the data types in the referenced column doesn't match the local column.19:14
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/identity/backends/ldap.py#n10219:14
nkinderayoung: so we require binding as an admin user who can read the userPassword attribute?19:14
dolphmstevemar: --author="Nathan Kinder <nkinder@redhat.com>" and then put yourself as Co-Authored-By in the commit message19:14
morganfainbergdstanek, varchar(255) vs int19:14
ayoungnkinder, I think it can die19:14
morganfainbergdstanek, or even more subtle19:14
dstanekmorganfainberg: the types are the same19:14
bknudsongyee: ok, I'll look into it.19:14
morganfainbergdstanek, exactly the same?19:15
ayoungnkinder, if the user submits the password in plaintext, we hash it upon update.  I'm guessing that No one in their right mind wants that19:15
morganfainbergdstanek, down to the null / not null / default /etc19:15
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/identity/backends/ldap.py#n22719:15
stevemardolphm, hmm, how to translate these tables to rst19:15
morganfainbergdstanek, i assume mysql because of the error code19:15
bknudsonstevemar: http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables19:15
nkinderayoung: yeah, it needs to die.  It will require binding as the users though (which is fine, but we just need to see how invasive of a change that is)19:16
morganfainbergdstanek, and it gets cranky about even minor differences19:16
dstanekmorganfainberg: yep19:16
morganfainbergdstanek, you could also see this on innodb vs non-innodb tables19:16
dolphmstevemar: maybe tables isn't the best option lol: http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables19:16
ayoungnkinder, I think for R/W LDAP binding as the user should be the default.  And for Read Only, it should not be.19:16
morganfainbergdstanek, and charset differences (e.g. utf8 vs latin1)19:16
dolphmstevemar: that looks like a nightmare for people to maintain in RST19:16
ayoungnkinder, so a config option "ldap_operations_as_user" =True  or  something19:16
morganfainbergdstanek, is the db engine inno and the charset utf8 by default?19:17
nkinderayoung: why are you considering a bind as a write?19:17
gyeenkinder, ayoung, need to be careful with LDAP bind, I run into a case with OpenLDAP when bind failed, it fall back to anonymous bind19:17
ayoungRIght now, I am guessing most people leave the LDAP user blank, and do anonymous19:17
gyeescary stuff :)19:17
morganfainbergdstanek, ran into a bunch of these recently actually, it's super sucky to debug.19:17
dolphmgyee: it's a feature?19:17
nkindergyee: yes, that is normal.  You need to check the result code19:17
gyeedolphm, yeah, in OpenLDAP19:17
nkinderYou can connect without binding, and your identity is "anonymous"19:17
* stevemar shudders!19:17
nkindergyee: it's standard for LDAP19:17
gyeeits a server-side configuration19:18
stevemarso tables is a no19:18
dstanekmorganfainberg: http://paste.openstack.org/show/75355/ :-(19:18
ayounggyee, Anonymous is fine, so long as anonymous has no write access.  You a, though, are referring to the bug for the authenticate path, and yes, we don't want to re-introduce that19:18
gyeeayoung, for LDAP authentication, you don't want anonymous bind fallback at all19:18
ayoungnkinder, yes, but it was being used on the authenitcate call19:18
morganfainbergdstanek, show create table identity_provider19:18
nkindergyee: are you talking about "unauthenticated binds", or failed binds?19:18
ayounggyee, I remember well.19:18
nkinder"unauthenticated" is when you send a bind DN without a password19:18
ayoungAs I recall, that patch slipped in at the end of the review cycle as I was telling people "please no LDAP changes without notifying me"19:19
nkinderthat falls through to anonymous, and it's bad.  The RFC discourages it19:19
ayoungand I was not notified, and I was not pleased19:19
nkinderand servers often reject that with an error now.19:19
gyeenkinder, no, I mean  anonymous bind fall back19:19
ayoungnkinder, authenticate is the only place the simple_bind is used as the user.  otherwise it is the admin user for all LDAP operations19:19
morganfainbergdstanek, and show full columns identity_provider19:19
gyeeyou send DN/password and bind failed, you don't get an error19:19
nkindergyee, ayoung: Yes, that is normal.  You need to check if you get an err=4919:19
gyeeyou just get an anonymous context I think19:19
gyeeI remember seeing this with OpenLDAP awhile back19:20
nkinderthere is also a "whoami" extended operation19:20
morganfainbergdstanek, and SHOW CHARACTER SET FOR keystone;19:20
ayoungnkinder, so if an update comes in, shouldn't that update be performed as the user requesting the Update so the proper ACLs get exercised?19:20
nkinderthe issue with binds is that you can bind multiple times on a single connection19:20
ayoungand, if the directory does not have Anonymous access, shouldn't you bind as the user, not as an admin?19:21
nkinderayoung: yes, that is the normal way (though there are more advanced proxy operations too)19:21
morganfainbergdstanek, and one last one: select `ENGINE` from `information_schema`.`TABLES` where `TABLE_SCHEMA`='keystone';19:21
nkinderayoung: yes, as the user19:21
dstanekmorganfainberg: started running the tests again - it looks like devstack setup my mysql to default to latin119:21
dstanekmorganfainberg: hopefully this will fix it19:21
ayoungnkinder, and...if we do Kerberos, we can do S4U@Proxy as the user, and then we've basically reimplemented the Auth mechanism in FreeIPA19:21
nkinderayoung: we just need to bind as the user, then check the result code.  If it's 0, the bind was successful.19:21
morganfainbergdstanek, yeah. that is normal. in our migrations we explicitly change the default to utf819:22
morganfainbergdstanek, 004 iirc19:22
morganfainbergdstanek, and my collapse does the same on 03619:22
ayoungnkinder, so we hash for password update.  What should Keystone do there (other than get out of the writable LDAP business)?19:23
dstanekmorganfainberg: that would definitely explain why the unicode tests where failing, but not why a foreign key would fail19:23
morganfainbergdstanek, yeaaah. collation issues.19:24
nkinderayoung: how can we do a password update if we're read-only?19:24
morganfainbergdstanek, my guess is one table ended up utf8 and the other was latin119:24
morganfainbergdstanek, i know it's stupid.19:24
nkinderayoung: we would just have to reject password changes19:24
ayoungnkinder, heh...We can't  BUt Keystone was not originally Read only for LDAP, and removing that requires a deliberate decision19:24
dstanekmorganfainberg: so far so good - but the run will take a little bit19:25
morganfainbergdstanek, ++ sounds good, let me know if you need anything else19:25
ayoungdolphm, for Juno, can we deprecate "Writable LDAP Identity backend?"  My guess is that CERN would be OK with that.19:25
nkinderayoung: yeah, seems like a configurable option would be ideal there19:25
*** david_lyle_ has joined #openstack-keystone19:26
ayoungnkinder, I'm actually leaning toward removing write access for users, but we need to make sure that we are not breaking things for people if we do.  Everytime I look at something and go "That is so crazy, no one would ever do that"  someone does it.19:27
dstanekmorganfainberg: thanks for your help - now i just have to figure out these integrity errors19:27
ayoungnkinder, binding as the user to create the entries might also break things.  For example, creating a new project might be allowed as the admin Directory user, but not as the end user.   We might want to do this on a "per backend  basis"19:28
*** gyee has quit IRC19:28
ayoungdstanek, once you get it working, the real fun begins:  we need Mysql unit test runs as part of gate19:28
*** dklyle has joined #openstack-keystone19:28
ayoungAnd postgresql really19:29
dolphmayoung: we've tried in the past, and it keeps getting maintained, so i'd say no19:30
*** david-lyle has quit IRC19:30
ayounghuh?19:30
dolphmayoung: to deprecate writable LDAP19:31
ayoungdolphm, ah.  OK. I thought you meant the SQL Unit test gate thing19:31
*** dklyle has quit IRC19:31
dolphmayoung: remember, essex was implemented as read-only, and then people came out of the woodwork to make it writable19:31
ayoungdolphm, I suspect you are right.19:31
*** dklyle has joined #openstack-keystone19:31
dolphmit'd be nice if it was a separate driver, i suppose19:31
ayoungdolphm, but with split Identity, I think that it is the assignment side that people really need writable19:31
dolphmthe read-only implementation being the base class for a read/write one19:32
dolphmayoung: maybe people are just using keystone to manage LDAP19:32
*** david_lyle_ has quit IRC19:32
ayoungdolphm, perhaps19:32
dolphmbecause keystone is the *best* HTTP API for your LDAP server19:32
bknudsonhttp://marginnotes2.wordpress.com/2013/03/04/opendj-rest-to-ldap-gateway/19:33
dstanekayoung: is the thought then to add a few new builder to run against mysql and postres?19:35
ayoungdstanek, there were two possibile approaches:  one was that it was a separate builder, and one that it would ride the coattails for the postgres and mysql tempest runs19:36
ayoungjust in a separate database.  hence keystone_test vs keystone as the DB name19:36
dstanekayoung: interesting...ok. i'll ping you when i unwind all of this and we can talk a little more about that19:36
*** thedodd has quit IRC19:37
ayoungdstanek, that would be most excellent19:37
ayoungand with that...if you will excuse me...I need to change offices19:37
*** ayoung has quit IRC19:37
*** thedodd has joined #openstack-keystone19:38
*** dklyle is now known as david-lyle19:40
*** thedodd has quit IRC19:43
jamielennoxfor the ibmers or others: does anyone understand what this is: http://softlayer.github.io/jumpgate/?19:47
bknudsontopol: you know? ^19:48
topolbknudson, yes I know about jumpgate19:49
lbragstadjamielennox: I'm not entirely sure, but *think* it is a translation layer19:49
lbragstadbetween the softlayer and openstack apis19:49
jamielennoxlbragstad: yea, that was my guess - but it's a new server not a client layer19:49
*** joesavak has joined #openstack-keystone19:49
lbragstadI've never played with it19:50
topollbragstad is pretty much correct.  Its SoftLayers's first step towards providing OpenStack.19:50
topolI have19:50
topolSoftLayer current support OpenStack in a few different ways19:50
*** mjfork has joined #openstack-keystone19:51
lbragstadmjfork: Hi!19:51
topolYou can get baremetal machines and provision and manage your own.  They also already have Swift hosted and will provision Swift object storages for 10 cents a gigabyte storage per month. And for now they have Jumpgate to provide OpenStack support19:51
jamielennoxfor context i found it and with it talking to all different services i though it would be a client layer and that i might be able to get some ideas for client or SDK19:51
topolvia API translation19:51
topolYes, it talks to some native SoftLayer services19:52
jamielennoxah, ok - so they have an existing cloud product and they are wanting to make it work with openstack apis19:52
topoljamielennox, yes that is there first step19:52
topoltowards greater OpenStack support19:53
jamielennoxtopol: ok, cool - i hadn't heard of them before so coming out with an abstraction service just seemed like a weird starting point19:53
topolso funny story. One of my folks was doing an internal Project and we needed a Swift.  at 10 cents a gigabyte we did the whole project on an account provisioned on my personal Visa.  So that project cost me way less than when I have tobuy you guys beers 1st night of the summit19:54
jamielennoxyea, it's getting so cheap19:55
topolfor 10 cents I brag and tell folks I "co-funded" the project :-)19:55
lbragstadlol19:55
*** jaosorior has quit IRC20:00
dolphmbug 1285833 got re-opened over the weekend, but i'm not sure if it's a new issue or not...20:01
uvirtbotLaunchpad bug 1285833 in python-keystoneclient "Keystone client racing on certificate lookups causing 401 Unauthorized on API calls" [Critical,Confirmed] https://launchpad.net/bugs/128583320:01
dolphmit's the same stack trace, but i can't imagine it's still a race condition20:01
*** nlahouti_ has quit IRC20:03
bknudsondolphm: I think morganfainberg added some more logging for it.20:03
marekdjamielennox: I was wondering what you meant in your comment in line 56 https://review.openstack.org/#/c/83337/7/keystoneclient/v3/contrib/federation/identity_providers.py20:04
marekdjamielennox: or if I understood it correctly.20:04
jamielennoxmarekd: the enabled=True one?20:05
marekdjamielennox: yep20:05
jamielennoxso when you do an update it should just provide the information you want to actually change in the object20:06
jamielennoxso you can change eg name without changing all the other details20:06
marekdjamielennox: ah, this. ok20:06
marekdjamielennox: got it.20:06
jamielennoxok20:06
jamielennoxyep, so if you always set enabled=True that will always be part of the update call20:07
marekdjamielennox: true.20:07
*** topol has quit IRC20:08
marekdjamielennox: i will be sitting here for a while so if you could take a look again at the commit (I addressed your comments) and something new came up we could discuss it and afterwards I just could apply similar patterns on mapping rules and protocols.20:10
jamielennoxmarekd: sure, i'm here other than for a few meetings now as well - where are you located? our TZs are way off20:10
jamielennoxmarekd: is there a reason for having enabled be a required argument on update?20:11
marekdjamielennox: Switzerland, it's 22:10 here.20:12
marekdjamielennox: ah, forgot about that.20:12
jamielennoxutils.positional.method doesn't always need an arg20:13
marekdjamielennox: I changed the signatures so the significant attributes (like id, enabled, description) are positional arguments. Otherwise I feel like you loose control on what will be passed as an arg.20:13
jamielennoxif you leave it empty it will just enforce that anything with a default value is going to be passed as a kwarg20:13
jamielennoxmarekd: true - do identity providers allow that 'extra' unspecified attributes?20:14
marekdjamielennox: 'extra' -> those in kwargs?20:15
jamielennoxmarekd: yea, the stupid thing we do where we save any extra arguments to the db for later20:15
marekdi know the 'extra' mechanism in keystone :-) But, basically here, when it comes to IdP CRUD operations you basically play with it's id(name), descrption and enabled switch.20:16
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Add security details to keysone docs  https://review.openstack.org/8614020:17
*** erecio has quit IRC20:19
jamielennoxmarekd: i don't mind if you do it explicitly - i was just wondering20:19
jamielennoxmarekd: commented20:20
jamielennoxmarekd: most are nits20:20
derek_cis the master branch of openstackclient using the master branch of keystoneclient?20:21
jamielennoxderek_c: it should be tested that way in the gate, but not in reality20:22
jamielennoxthat was confusing, it is tested that way in the gate. If you install OSC manually though it will pull in from pypi20:23
derek_cjamielennox: ok, I see20:23
derek_cthanks20:23
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Add security details to keysone docs  https://review.openstack.org/8614020:23
marekdjamielennox: jamielennox thanks20:25
*** ayoung has joined #openstack-keystone20:27
*** Guest_ has quit IRC20:29
*** Guest_ has joined #openstack-keystone20:30
marekdjamielennox: so the identity_provider id is a string, defined by a user.20:35
marekdjamielennox: no uuids in this case.20:35
jamielennoxok20:35
marekdjamielennox: and it must be provided.20:35
jamielennoxso you dont want base.getid then20:35
marekdnot at all20:36
dstanekbarf...the tables are not getting dropped at the end of the test20:37
marekdaand in methods like get,update,create this idp's id is used to build dynamic URL.20:37
*** Guest_ has quit IRC20:38
*** Guest_ has joined #openstack-keystone20:38
*** vhoward has joined #openstack-keystone20:39
*** gyee has joined #openstack-keystone20:41
marekdjamielennox: "In this case you should probably call the param id and it should be positional.method(0)" -> you want me to store idp's id in kwargs?20:43
stevemarnkinder, ping -> https://review.openstack.org/#/c/86140/20:44
jamielennoxyea, everything that is a parameter of the object should be a kwarg20:44
marekdjamielennox: so why not put description,enabled in the kwargs - because they have default values?20:45
lbragstadstevemar: nkinder took a quick pass https://review.openstack.org/#/c/86140/20:45
stevemarlbragstad, thanks boss!20:46
lbragstadstevemar: thanks for pushing that up!20:46
nkinderstevemar: awesome, I'll take a look20:46
jamielennoxmarekd: its moreabout how it is passed, if you wwant to have them handled by  **kwargs then you can, @positional is there so that you can make them explicit but still have them be passed via keyword20:47
marekdjamielennox: i think i start understand people who complain about Python's  dynamic typing and all that stuff :-)20:48
jamielennoxmarekd: :) its better in py3, this is a nice hack in the mean time20:49
derek_cI'm creating a new contrib module. do I need to somehow register it?20:57
*** david-lyle is now known as david-lyle_afk20:57
derek_ci'm talking about /keystone/contrib20:59
dolphmnkinder: around for #openstack-meeting?21:03
nkinderdolphm: yep, I'm there21:04
*** marcoemorais has quit IRC21:12
*** marcoemorais has joined #openstack-keystone21:13
dolphmstevemar: did you propose the RST version of the security notes?21:14
stevemardolphm, yessem21:15
stevemarhttps://review.openstack.org/#/c/86140/2/doc/source/security_details.rst21:15
marekdjamielennox: i don't know whether you planned that, but probably probably session proposal to rewrite managers and enforce some stable interface could be not that bad idea :-)21:22
dolphmstevemar: thanks! but it sounds like the cross-project desire is for this to live in the wiki :-/21:22
stevemarnooooo21:23
lbragstadwell, it sounds like people are behind it, that's a good thing21:23
stevemartrue true21:24
stevemargotta bail, see ya folks21:24
jamielennoxmarekd: i hadnt, there's only so much im willing to try to force through review at any one time21:26
jamielennoxi was hoping to address something like that in python-openstacksdk and then if it proved useful we could look at it for a 1.021:26
jamielennoxbut the backwards compatability would just be a nightmare to transfer the current stuff21:26
derek_cwhy would I get this error when running devstack?21:27
derek_c/home/vagrant/devstack/lib/keystone:376 keystone did not start21:27
*** Guest_ has quit IRC21:27
marekdjamielennox: ;/21:28
derek_ca more complete log is here: http://upl.io/wnnlr521:28
derek_cseems like keystone timed out for some reason21:28
*** stevemar has quit IRC21:28
openstackgerritA change was merged to openstack/python-keystoneclient: Allow passing auth plugin as a parameter  https://review.openstack.org/8367321:29
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Add CRUD operations for Identity Providers.  https://review.openstack.org/8333721:43
*** david_lyle_ has joined #openstack-keystone21:44
*** david_lyle_ is now known as david-lyle21:44
*** david-lyle is now known as david_lyle21:44
*** leseb_ has quit IRC21:45
*** david_lyle_ has joined #openstack-keystone21:46
*** david-lyle_afk has quit IRC21:47
*** elmiko is now known as elmiko_afk21:48
*** Gu_______ has joined #openstack-keystone21:49
*** d0ugal has quit IRC21:50
*** d0ugal has joined #openstack-keystone21:50
*** david_lyle has quit IRC21:50
derek_crunning the command used to start keystone manually results in the following log: http://upl.io/l65by621:51
derek_c2014-04-08 21:49:56,478 CRITICAL log logging_excepthook cannot import name exception21:51
derek_canyone has any clue what problem this might be?21:51
*** marcoemorais has quit IRC22:01
*** marcoemorais has joined #openstack-keystone22:01
*** marcoemorais has quit IRC22:03
*** marcoemorais has joined #openstack-keystone22:03
*** gokrokve_ has joined #openstack-keystone22:04
*** marcoemorais has quit IRC22:06
*** marcoemorais has joined #openstack-keystone22:06
dolphmderek_c: the did not start could be caused by a port conflict on 35357 https://bugs.launchpad.net/devstack/+bug/125348222:07
uvirtbotLaunchpad bug 1253482 in devstack "Keystone's IANA-assigned default port in linux local ephemeral port range" [Undecided,In progress]22:07
*** dtroyer has quit IRC22:07
openstackgerritPriti Desai proposed a change to openstack/keystone: Adding one more check on project_id  https://review.openstack.org/8519922:07
dolphmderek_c: i have no idea what the except hook one would be caused by - that's new to me22:07
*** gokrokve has quit IRC22:07
dolphmjamielennox: ayoung: subscribed you both to https://bugs.launchpad.net/cinder/+bug/128583322:08
uvirtbotLaunchpad bug 1285833 in python-keystoneclient "Keystone client racing on certificate lookups causing 401 Unauthorized on API calls" [Critical,Confirmed]22:09
*** henrynash has joined #openstack-keystone22:09
ayoungdolphm, yeah, I've been trying to think what we did to cause that22:09
jamielennoxdolphm: your patch didnt fix it then?22:09
*** lbragstad has quit IRC22:10
ayoungjamielennox, I think we fixed and rebroke that22:10
*** dtroyer has joined #openstack-keystone22:10
jamielennoxmaybe we need to extract it out to an object and put explicit locks around the fetching?22:12
ayoungjamielennox, we could fetch the certificates upon initial startup22:12
ayoungjamielennox, there are two reasons I wasn't recommending do that when I first wrote it:22:13
*** andreaf has joined #openstack-keystone22:13
*** dstanek has quit IRC22:13
ayoung1.  order of bringing up the servcies22:13
ayoung2.  PKI tokens were not default22:14
ayoung2 has gone away, and 1 is not an issue in devstack22:14
*** marcoemorais has quit IRC22:16
*** marcoemorais has joined #openstack-keystone22:17
jamielennoxmarekd: mind if i push an update fixing the positional stuff?22:19
jamielennoxad the getid()22:19
marekdjamielennox: go ahead.22:19
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Add CRUD operations for Identity Providers.  https://review.openstack.org/8333722:30
*** marcoemorais has quit IRC22:32
*** marcoemorais has joined #openstack-keystone22:32
*** d0ugal has quit IRC22:32
jamielennoxmarekd: ^^22:34
marekdjamielennox: yep, saw it, thanks.22:34
marekdjamielennox:  i will apply similar changes to rules and protocols, tomorrow morning.22:37
*** marekd is now known as marekd|away22:37
*** gokrokve_ has quit IRC22:38
*** nkinder has quit IRC22:40
*** gokrokve has joined #openstack-keystone22:43
*** browne has quit IRC22:43
*** andreaf has quit IRC22:46
*** andreaf has joined #openstack-keystone22:47
*** browne has joined #openstack-keystone22:47
*** d0ugal has joined #openstack-keystone22:47
*** d0ugal has quit IRC22:47
*** d0ugal has joined #openstack-keystone22:47
*** henrynash has quit IRC22:49
*** dims has quit IRC22:49
*** diegows has quit IRC22:53
*** Gu_______ has quit IRC22:54
*** david_lyle_ has quit IRC22:55
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Convert auth_token to use session  https://review.openstack.org/7490822:56
*** Guest___ has joined #openstack-keystone22:56
*** Guest___ has quit IRC22:59
openstackgerritPriti Desai proposed a change to openstack/keystone: Adding more descriptive error message  https://review.openstack.org/8618723:08
morganfainbergdolphm, http://pasteraw.com/h23zhdanw3pg67gfks2av5pqg6ry96m mysql schema diff23:09
derek_cdolphm: thanks for looking into it.  doesn't look like I have other stuff running on 35357 though23:09
morganfainbergdolphm, looks like i need to insert the _member_ role as well, appears to be missing. *doh*23:10
derek_ca bit of googling resulting in this: http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2013-09-23.log23:11
derek_ccould that be a sqlalchemy error?23:11
dolphmmorganfainberg: _member_ is inserted at runtime as needed23:25
morganfainbergdolphm ok23:25
dolphmmorganfainberg: repository_path text vs medium_text is weird23:26
morganfainbergthat is something we don't control23:26
dolphmmorganfainberg: yeah23:27
morganfainbergnot sure why sqla-migrate is doing that differently23:27
dolphmmorganfainberg: that diff looks like a +2 to me23:27
morganfainberglet me finish the pgsql first though23:27
morganfainbergwant to make sure it looks good on that front too23:27
dolphmmorganfainberg: who was worried about the index names, and why?23:27
morganfainbergthough pg is a bit more work since i don't know it as well :P23:27
morganfainbergi am worried about index names personally23:27
morganfainbergi want to make sure no one has issues with being explicit on them23:28
dolphmmorganfainberg: can't we use sqlalchemy to manipulate them without knowing the name? (/me runs off to read docs)23:28
morganfainbergand if we like this naming convention, i'll propose a migration to make current deployments23:28
morganfainbergwe can. but matching is no fun23:28
morganfainbergwell as long as they have a name we can manipulate them23:28
morganfainbergafaict23:28
morganfainbergif they are anonymous we can't, but via reflection the name doesn't really matter23:29
dolphmmorganfainberg: i'd rather not use names at all, but we're past that i suppose23:30
morganfainbergwell, the automagic naming does strange things sometimes23:31
dolphmmorganfainberg: ?23:31
dolphmmorganfainberg: things we have reason to care about?23:31
morganfainbergi've saw postgres complain about adding the constraints23:31
morganfainbergbecause there was some kind of name conflict in the constraint23:31
morganfainbergbut mysql didn't complain23:32
morganfainbergand sqlite...is sqlite23:32
morganfainbergmy gut says the safest bet is name the constraints consistently23:32
morganfainbergthen we don't get odd side effects23:32
dolphmmorganfainberg: that just sounds like the constraint already existed on that system :P23:32
morganfainbergwas a clean db and it complained23:32
morganfainbergso, somehow it automatically added a constraint mysql didn't ?23:33
dolphmmorganfainberg: maybe they both added the same logical constraint, but the migration was trying to re-use the same name on postgres, but either wasn't recreating the constraint on mysql, or mysql allowed a duplicate logical constraint with a different name?23:35
dolphmmorganfainberg: or maybe postgres was balking at the duplicate logical constraint, even if the name was different?23:36
morganfainbergdolphm, yeah not sure, it was gate failing not something i could duplicate locally23:36
dolphmi'm just making stuff up here23:36
*** nkinder has joined #openstack-keystone23:36
morganfainbergdolphm, http://pasteraw.com/bl8gqt1pwvvzfie84x23dikyncp8xhy23:39
morganfainbergdolphm, pgsql diff23:39
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: Support token hash algorithm  https://review.openstack.org/8039823:40
morganfainbergshould prob get bknudson to checkout db2 (or i could try if i can install db2)23:41
*** dstanek has joined #openstack-keystone23:44
dolphmmorganfainberg: "projects" aren't technically part of v2 ;)23:45
morganfainbergdolphm, i can revert that if you want.23:45
morganfainbergdolphm, easy enough.23:45
morganfainbergdolphm, and fair point23:45
dolphmmorganfainberg: i'm just saying there's a reason it was worded that - i'm not sure we can pretend tenants aren't a thing until v2 is totally gone23:46
morganfainbergdolphm, sure. and i'm happy to keep that if needed.23:46
dolphmmorganfainberg: ALTER TABLE ONLY domain ADD CONSTRAINT domain_name_key UNIQUE (name); is missing post-squash in pg?23:46
morganfainbergdolphm, a bit further down i see23:47
morganfainberg--- Name: migrate_version_pkey; Type: CONSTRAINT; Schema: public; Owner: root; Tablespace:23:47
morganfainberg+-- Name: ixu_domain_name; Type: CONSTRAINT; Schema: public; Owner: root; Tablespace:23:47
*** d0ugal has quit IRC23:47
bknudsondolphm: is the preferred hash a new config option?23:48
morganfainbergit looks like there a bit more re-ordering in the pg_sql model.23:48
bknudsonotherwise we could only support sha256 or a specific algorithm.23:48
*** d0ugal has joined #openstack-keystone23:49
openstackgerritBrant Knudson proposed a change to openstack/keystone: Configurable token hash algorithm  https://review.openstack.org/8040123:50
*** joesavak has quit IRC23:52
*** gokrokve has quit IRC23:52
dolphmbknudson: it could be, but if it's already sha256 i doubt many people would change it23:53
dolphmbknudson: but, sure23:53
bknudsondolphm: ok, I'll give it a try... I'll start with sha256 and can make it configurable later.23:54
bknudsondolphm: so tokens shouldn't have a hash_algorithm?23:55
dolphmbknudson: i really don't think so - it's not at all relevant to the token itself23:55
bknudsonok, that makes it easier23:56
derek_chow do you register a contrib module?23:58
derek_cI have a routers.py file23:58
derek_cbut how do I actually make it work?23:59
derek_cI assume I need to somehow tell keystone I have defined a new module23:59
dolphmderek_c: i assume you mean an API extension with it's own router?23:59
derek_cdolphm: yes23:59
derek_cunder keystone/contrib23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!