openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Collapse SQL Migrations https://review.openstack.org/78169 | 00:01 |
---|---|---|
morganfainberg | dstanek, +365, -4757 | 00:01 |
morganfainberg | dstanek, ^ | 00:01 |
morganfainberg | dolphm, cc https://review.openstack.org/78169 no longer needs -2 | 00:03 |
*** derek_c has quit IRC | 00:05 | |
dstanek | -4757! | 00:09 |
morganfainberg | dstanek, yesss! feels good | 00:09 |
dstanek | morganfainberg: let me know when you have a few mins - couple db questions for you | 00:10 |
morganfainberg | dstanek, hmm. well somehow i caused a major failure with that change set :P | 00:10 |
morganfainberg | dstanek, sure have time now | 00:10 |
morganfainberg | ooh lol | 00:10 |
dstanek | morganfainberg: 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.py | 00:11 |
dstanek | morganfainberg: what do you think of that? i'm basically making the sql tests more deterministic | 00:12 |
morganfainberg | dstanek, hm... that seems sane | 00:12 |
dstanek | right now if you ran some tests in isolation you will get different database schemas based on what was imported | 00:12 |
morganfainberg | dstanek, i am curious if this impacts the live tests | 00:13 |
morganfainberg | dstanek, well, except don't you auto import extensions | 00:13 |
dstanek | morganfainberg: i'm currently running on mysql with no _setup_database - after that i'll mess with the live tests | 00:13 |
morganfainberg | dstanek, the idea was that we wouldn't migrate in the extension unless it was used. | 00:14 |
morganfainberg | hence the difference in schema | 00:14 |
morganfainberg | production could see similar differences | 00:14 |
*** mgagne has joined #openstack-keystone | 00:15 | |
dstanek | morganfainberg: i can try to make the migration test more controlled the problem is that we are not actually controlling this right now | 00:15 |
dstanek | whatever is imported is created | 00:15 |
morganfainberg | dstanek, i guess for reflection creation purposes this actually makes more sense | 00:17 |
morganfainberg | we don't care if extra extensions are loaded | 00:17 |
morganfainberg | dstanek, your impl. is better. keep it. | 00:17 |
morganfainberg | dstanek, i'm crossing the upgrade tests vs the unit or restful tests. | 00:17 |
dstanek | morganfainberg: i'll make sure the upgrade tests are still controlled | 00:18 |
morganfainberg | yeah | 00:18 |
morganfainberg | dstanek, shouldn't be an issue because we don't use reflection for that set of tests | 00:19 |
*** ChanServ changes topic to "All of the project infrastructure hosts are being restarted for security updates." | 00:21 | |
dstanek | that has been interesting because the backend kvs and ldap tests need sql configured | 00:22 |
dstanek | i remember talking about that, but it's much different to have the explicit fixture closer to that code | 00:22 |
morganfainberg | dstanek, yep | 00:23 |
morganfainberg | now... i'm trying to figure out why the check is failing my migrations when locally it works. | 00:23 |
dstanek | morganfainberg: is it failing? the only i'm looking at just needs to be rebased | 00:24 |
*** openstackgerrit has quit IRC | 00:24 | |
morganfainberg | dstanek, no mine | 00:24 |
morganfainberg | dstanek, https://jenkins06.openstack.org/job/gate-keystone-python27/679/console | 00:25 |
morganfainberg | i don't get the same failure. | 00:25 |
dstanek | gotta wait for the reboot | 00:25 |
morganfainberg | dstanek, ? | 00:29 |
dstanek | the just bounced the jenkins boxes - back now | 00:30 |
morganfainberg | ah | 00:30 |
morganfainberg | i greatly dislike our git keystoneclient checks | 00:32 |
morganfainberg | :( | 00:32 |
*** browne has quit IRC | 00:36 | |
dstanek | that's a strange error | 00:37 |
dstanek | is there maybe a different in migrate versions? | 00:37 |
dstanek | morganfainberg: ^ | 00:37 |
morganfainberg | dstanek, that is my thought. this means this is going to be a challenge to work around. | 00:37 |
dstanek | morganfainberg: what version are you using locally? | 00:38 |
morganfainberg | dstanek, whatever tox installes | 00:38 |
morganfainberg | so probably 0.9.x | 00:38 |
morganfainberg | dstanek, oh interesting | 00:39 |
morganfainberg | dstanek, got a failure locally. wow bad test isolation | 00:39 |
morganfainberg | only occurs in a full test run | 00:40 |
morganfainberg | doesn't occur running just the test_sql_upgrade tests | 00:40 |
ayoung_cooking | dolphm, 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 |
dstanek | ha, that the kind of thing i'm trying to get rid of | 00:40 |
morganfainberg | dstanek, and it didn't fail initially on a full run | 00:40 |
*** derek_c has joined #openstack-keystone | 01:00 | |
*** gyee has quit IRC | 01:01 | |
dstanek | dolphm: jython is a no go; i can't event create a virtualenv up and running | 01:06 |
*** marcoemorais has quit IRC | 01:06 | |
morganfainberg | dstanek, aha, i think i found it | 01:07 |
dstanek | morganfainberg: what was it? | 01:07 |
morganfainberg | dstanek, extension migration versions don't start with 35 :P | 01:07 |
morganfainberg | dstanek, at least this should now pass unit tests *runs locally* now i do need to see why tempest is complaining | 01:08 |
morganfainberg | and i wont know that until the test run completes | 01:10 |
*** richm has quit IRC | 01: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-keystone | 01:48 | |
*** askb_ has quit IRC | 01:57 | |
*** david-lyle has joined #openstack-keystone | 02:02 | |
*** mberlin1 has joined #openstack-keystone | 02:08 | |
*** mberlin has quit IRC | 02:09 | |
nkinder | ayoung_cooking: still cooking!? You must be BBQ'ing brisket... | 02:19 |
nkinder | jamielennox: ping | 02:19 |
jamielennox | nkinder: hey | 02:19 |
nkinder | jamielennox: I was wondering if there's anything I missed on the client side for this - https://wiki.openstack.org/wiki/Security/Icehouse/Keystone | 02:20 |
jamielennox | nkinder: i can't think of anything | 02:21 |
jamielennox | the only client side crypto should be decrypting PKI tokens | 02:21 |
jamielennox | and then encrypted caching to memcache | 02:21 |
nkinder | jamielennox: well, also outgoing HTTPS (via requests), right? | 02:22 |
nkinder | jamielennox: it's indirect of course... | 02:22 |
jamielennox | nkinder: oh, yea - as you say that's all handled by requests | 02:22 |
nkinder | jamielennox: I wasn't sure what Requests uses underneath the covers. I can dive into it, but do you know off hand? | 02:23 |
jamielennox | nkinder: it hands that off to urllib3, so whatever it uses | 02:23 |
nkinder | jamielennox: ok | 02:23 |
jamielennox | i'm pretty sure the stuff like hostname matching is done by urllib3, i don't know what handles the crypto | 02:24 |
jamielennox | but i would guess that it's all a wrapper around python's ssl | 02:24 |
nkinder | jamielennox: yeah, I think that's likely the case as well | 02:26 |
jamielennox | most of these http layers aren't doing actual work, they are mostly for usability | 02:26 |
nkinder | jamielennox: 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 |
jamielennox | i 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_away | 02:30 | |
*** amcrn has joined #openstack-keystone | 02:32 | |
*** Guest_ has joined #openstack-keystone | 02:33 | |
*** harlowja_away is now known as harlowja | 02:40 | |
*** topol has joined #openstack-keystone | 02:43 | |
*** Chicago has joined #openstack-keystone | 02:53 | |
*** Chicago has quit IRC | 02:53 | |
*** Chicago has joined #openstack-keystone | 02:53 | |
*** amcrn has quit IRC | 02:53 | |
morganfainberg | dstanek, 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 migration | 02:56 |
morganfainberg | dstanek, i think i have everything worked out now :) running tests then uploading. | 02:56 |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Collapse SQL Migrations https://review.openstack.org/78169 | 03:06 |
dstanek | morganfainberg: very nice | 03:11 |
*** wchrisj has quit IRC | 03:29 | |
*** wchrisj has joined #openstack-keystone | 03:29 | |
morganfainberg | dstanek, now just fighting with pgsql | 03:30 |
morganfainberg | dstanek, 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 |
morganfainberg | maybe 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 |
dstanek | morganfainberg: so the names are different depending on the DB? | 03:36 |
morganfainberg | dstanek, it appears so | 03:36 |
morganfainberg | dstanek, also, our previous migrations just let SQLA define the constraints however it wanted | 03:37 |
morganfainberg | dstanek, probably not "correct" | 03:37 |
morganfainberg | it should probably be explicitly defined. | 03:37 |
morganfainberg | and.. i think the tables we create with reflection do not really "mirror" actual tables since we don't name the constraints | 03:38 |
morganfainberg | though anyone who uses the reflection to make the schema in production is "doing it wrong" | 03:39 |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Collapse SQL Migrations https://review.openstack.org/78169 | 03:39 |
morganfainberg | dstanek, 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 |
morganfainberg | i also noticed we are using unique constraints in some places we're looking for unique_indexs | 03:42 |
* morganfainberg grumbles | 03:43 | |
*** chandan_kumar has quit IRC | 03:44 | |
morganfainberg | they should be the same thing (performance / effect wise) but they appear differently in the ORM | 03:47 |
*** amcrn has joined #openstack-keystone | 03:49 | |
*** chandan_kumar has joined #openstack-keystone | 03:50 | |
*** chandan_kumar has quit IRC | 03:56 | |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Collapse SQL Migrations https://review.openstack.org/78169 | 03:58 |
*** wchrisj has quit IRC | 03:59 | |
*** chandan_kumar has joined #openstack-keystone | 04:14 | |
*** wchrisj_ has joined #openstack-keystone | 04:15 | |
*** wchrisj_ has quit IRC | 04:19 | |
*** wchrisj_ has joined #openstack-keystone | 04:23 | |
*** wchrisj_ has quit IRC | 04:33 | |
*** wchrisj has joined #openstack-keystone | 04:39 | |
*** wchrisj has quit IRC | 04:45 | |
*** wchrisj has joined #openstack-keystone | 04:56 | |
*** wchrisj has quit IRC | 05:00 | |
*** Guest_ has quit IRC | 05:03 | |
*** harlowja is now known as harlowja_away | 05:03 | |
*** Guest_ has joined #openstack-keystone | 05:04 | |
openstackgerrit | A change was merged to openstack/keystone: Add tests for user ID with comma https://review.openstack.org/85478 | 05:07 |
*** zhiyan_ is now known as zhiyan | 05:09 | |
*** henrynash has joined #openstack-keystone | 05:11 | |
*** RockKuo has joined #openstack-keystone | 05:20 | |
*** saju_m has joined #openstack-keystone | 05:28 | |
*** topol has quit IRC | 05:30 | |
*** dolphm has quit IRC | 05:33 | |
*** dolphm has joined #openstack-keystone | 05:34 | |
*** dolphm has quit IRC | 05:38 | |
*** dolphm has joined #openstack-keystone | 05:40 | |
*** henrynash has quit IRC | 05:59 | |
openstackgerrit | Jenkins proposed a change to openstack/keystone: Imported Translations from Transifex https://review.openstack.org/83955 | 06:00 |
*** Chicago has quit IRC | 06:09 | |
*** Chicago has joined #openstack-keystone | 06:13 | |
openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Initial kerberos plugin implementation. https://review.openstack.org/74974 | 06:18 |
openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Allow passing auth plugin as a parameter https://review.openstack.org/83673 | 06:18 |
*** jaosorior has joined #openstack-keystone | 06:21 | |
openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Initial kerberos plugin implementation. https://review.openstack.org/74974 | 06:25 |
*** Guest_ has quit IRC | 06:28 | |
*** derek_c has quit IRC | 06:34 | |
*** inc0 has joined #openstack-keystone | 06:37 | |
*** jamielennox is now known as jamielennox|away | 06:48 | |
*** derek_c has joined #openstack-keystone | 07:02 | |
*** derek_c has quit IRC | 07:09 | |
*** saju_m has quit IRC | 07:17 | |
*** saju_m has joined #openstack-keystone | 07:25 | |
*** saju_m has quit IRC | 07:32 | |
*** morganfainberg is now known as morganfainberg_Z | 07:36 | |
*** andreaf has joined #openstack-keystone | 07:56 | |
*** saju_m has joined #openstack-keystone | 07:58 | |
*** saju_m has quit IRC | 08:03 | |
*** stevemar has quit IRC | 08:07 | |
*** leseb has joined #openstack-keystone | 08:12 | |
*** chandan_kumar has quit IRC | 08:15 | |
*** saju_m has joined #openstack-keystone | 08:16 | |
*** andreaf has quit IRC | 08:45 | |
*** andreaf has joined #openstack-keystone | 09:13 | |
*** henrynash has joined #openstack-keystone | 09:20 | |
*** saju_m has quit IRC | 09:39 | |
*** inc0 has quit IRC | 09:39 | |
*** jaosorior has quit IRC | 09:39 | |
*** dolphm has quit IRC | 09:39 | |
*** RockKuo has quit IRC | 09:39 | |
*** mgagne has quit IRC | 09:39 | |
*** harlowja_away has quit IRC | 09:39 | |
*** mhu has quit IRC | 09:39 | |
*** ayoung_cooking has quit IRC | 09:39 | |
*** bada has quit IRC | 09:39 | |
*** mfisch has quit IRC | 09:39 | |
*** dstanek has quit IRC | 09:39 | |
*** d0ugal has quit IRC | 09:39 | |
*** serverascode has quit IRC | 09:39 | |
*** dtroyer has quit IRC | 09:39 | |
*** jamiec has quit IRC | 09:39 | |
*** uvirtbot has quit IRC | 09:39 | |
*** ayoung_cooking has joined #openstack-keystone | 09:39 | |
*** bada has joined #openstack-keystone | 09:39 | |
*** inc0 has joined #openstack-keystone | 09:39 | |
*** serverascode has joined #openstack-keystone | 09:39 | |
*** RockKuo has joined #openstack-keystone | 09:39 | |
*** serverascode has quit IRC | 09:39 | |
*** serverascode has joined #openstack-keystone | 09:39 | |
*** jaosorior has joined #openstack-keystone | 09:39 | |
*** bada has quit IRC | 09:39 | |
*** david-lyle has quit IRC | 09:39 | |
*** openstackgerrit has quit IRC | 09:39 | |
*** zhiyan has quit IRC | 09:39 | |
*** Daviey has quit IRC | 09:39 | |
*** huats has quit IRC | 09:39 | |
*** openstack has joined #openstack-keystone | 09:49 | |
*** koolhead17 has joined #openstack-keystone | 09:53 | |
*** jaosorior has quit IRC | 09:56 | |
*** jaosorior has joined #openstack-keystone | 09:56 | |
*** serverascode has quit IRC | 09:57 | |
*** serverascode has joined #openstack-keystone | 09:57 | |
*** serverascode has quit IRC | 10:03 | |
*** mfisch has quit IRC | 10:03 | |
*** jaosorior has quit IRC | 10:03 | |
*** Chicago has quit IRC | 10:03 | |
*** zigo has quit IRC | 10:03 | |
*** marekd|away has quit IRC | 10:03 | |
*** bknudson has quit IRC | 10:03 | |
*** sld has quit IRC | 10:03 | |
*** sudorandom has quit IRC | 10:03 | |
*** mfisch` has joined #openstack-keystone | 10:03 | |
*** sld has joined #openstack-keystone | 10:03 | |
*** zhiyan is now known as zhiyan_ | 10:03 | |
*** serverascode has joined #openstack-keystone | 10:04 | |
*** jaosorior has joined #openstack-keystone | 10:04 | |
*** zigo has joined #openstack-keystone | 10:04 | |
*** afaranha has joined #openstack-keystone | 10:05 | |
*** dolphm has quit IRC | 10:13 | |
*** serverascode has quit IRC | 10:13 | |
*** serverascode has joined #openstack-keystone | 10:13 | |
*** mhu has quit IRC | 10:15 | |
*** mfisch` has quit IRC | 10:15 | |
*** jamiec has quit IRC | 10:15 | |
*** mgagne has quit IRC | 10:16 | |
*** sudorandom has joined #openstack-keystone | 10:17 | |
*** mfisch has joined #openstack-keystone | 10:20 | |
*** mfisch has quit IRC | 10:20 | |
*** mfisch has joined #openstack-keystone | 10:20 | |
*** huats has quit IRC | 10:26 | |
*** uvirtbot has quit IRC | 10:26 | |
*** zhiyan_ has quit IRC | 10:26 | |
*** ayoung_cooking has quit IRC | 10:26 | |
*** inc0 has quit IRC | 10:26 | |
*** andreaf has quit IRC | 10:26 | |
*** lbragstad has quit IRC | 10:26 | |
*** jimbaker has quit IRC | 10:26 | |
*** uvirtbot has joined #openstack-keystone | 10:27 | |
*** jimbaker has joined #openstack-keystone | 10:27 | |
*** huats has joined #openstack-keystone | 10:27 | |
*** huats has quit IRC | 10:27 | |
*** huats has joined #openstack-keystone | 10:27 | |
*** andreaf has joined #openstack-keystone | 10:27 | |
*** jimbaker has quit IRC | 10:27 | |
*** jimbaker has joined #openstack-keystone | 10:27 | |
*** inc0 has joined #openstack-keystone | 10:27 | |
*** andreaf has quit IRC | 10:27 | |
*** andreaf has joined #openstack-keystone | 10:27 | |
*** zhiyan_ has joined #openstack-keystone | 10:28 | |
*** ayoung_cooking has joined #openstack-keystone | 10:29 | |
*** lbragstad has joined #openstack-keystone | 10:32 | |
*** saju_m has quit IRC | 10:34 | |
*** saju_m has joined #openstack-keystone | 10:35 | |
*** lbragstad has quit IRC | 10:39 | |
*** afaranha has quit IRC | 10:39 | |
*** david-lyle has quit IRC | 10:39 | |
*** mberlin1 has quit IRC | 10:39 | |
*** lbragstad has joined #openstack-keystone | 10:40 | |
*** david-lyle has joined #openstack-keystone | 10:40 | |
*** afaranha has joined #openstack-keystone | 10:40 | |
*** mberlin has joined #openstack-keystone | 10:40 | |
*** chandan_kumar has joined #openstack-keystone | 11:03 | |
*** RockKuo has quit IRC | 11:28 | |
*** chandan_kumar has quit IRC | 11:44 | |
*** mhu has joined #openstack-keystone | 11:44 | |
*** dolphm has joined #openstack-keystone | 11:46 | |
*** mgagne has joined #openstack-keystone | 11:48 | |
*** ayoung_cooking has quit IRC | 12:00 | |
*** chandan_kumar has joined #openstack-keystone | 12:02 | |
*** serverascode has quit IRC | 12:16 | |
*** serverascode has joined #openstack-keystone | 12:16 | |
*** david-lyle has quit IRC | 12:17 | |
*** zigo has quit IRC | 12:17 | |
*** zigo has joined #openstack-keystone | 12:18 | |
*** dolphm has quit IRC | 12:18 | |
*** mhu has quit IRC | 12:18 | |
*** mfisch has quit IRC | 12:18 | |
*** sudorandom has quit IRC | 12:18 | |
*** mgagne has quit IRC | 12:19 | |
*** mhu has joined #openstack-keystone | 12:20 | |
*** mgagne has joined #openstack-keystone | 12:21 | |
*** mfisch has joined #openstack-keystone | 12:21 | |
*** mfisch has joined #openstack-keystone | 12:21 | |
*** dolphm has joined #openstack-keystone | 12:21 | |
*** sudorandom has joined #openstack-keystone | 12:21 | |
*** zhiyan_ is now known as zhiyan | 12:27 | |
*** erecio has joined #openstack-keystone | 12:27 | |
*** erecio has quit IRC | 12:36 | |
*** bknudson has joined #openstack-keystone | 12:37 | |
*** marekd has joined #openstack-keystone | 12:53 | |
*** dstanek has quit IRC | 12:55 | |
*** dstanek has joined #openstack-keystone | 12:56 | |
*** erecio has joined #openstack-keystone | 12:59 | |
erecio | Hi, 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-keystone | 13:21 | |
*** openstackgerrit has joined #openstack-keystone | 13:23 | |
*** openstackgerrit has quit IRC | 13:23 | |
*** openstackgerrit has joined #openstack-keystone | 13:24 | |
*** ayoung has joined #openstack-keystone | 13:30 | |
*** jsavak has joined #openstack-keystone | 13:30 | |
*** dims has joined #openstack-keystone | 13:33 | |
*** joesavak has quit IRC | 13:34 | |
*** Chicago has joined #openstack-keystone | 13:34 | |
*** Chicago has joined #openstack-keystone | 13:34 | |
*** flwang has joined #openstack-keystone | 13:37 | |
flwang | greetings | 13:37 |
marekd | jamielennox|away: ping me back when you are online. | 13:37 |
flwang | I'd like to know is there any way to save a public key into Keystone for a specific user? | 13:37 |
flwang | thanks | 13:38 |
openstackgerrit | Pablo Fernando Cargnelutti proposed a change to openstack/keystone: Extracting get group roles for project logic to drivers. https://review.openstack.org/86025 | 13:39 |
bknudson | flwang: I don't think that we want to store user info in keystone, given the direction that we're going with federation | 13:41 |
*** nkinder has quit IRC | 13:41 | |
bknudson | flwang: maybe barbican has a use case for it? | 13:41 |
openstackgerrit | ayoung proposed a change to openstack/python-keystoneclient: revoke events https://review.openstack.org/81166 | 13:45 |
flwang | bknudson: thanks, but IMHO, Barbican is used to store private key, so i'm not sure if it's a good place for public key | 13:48 |
flwang | bknudson: or maybe we should not really care it | 13:48 |
*** vhoward- has left #openstack-keystone | 13:53 | |
*** ChanServ sets mode: +o dolphm | 13:58 | |
openstackgerrit | Raildo Mascena de Sousa Filho proposed a change to openstack/keystone: Filter User by project https://review.openstack.org/84136 | 14:04 |
*** chandan_kumar has quit IRC | 14:16 | |
openstackgerrit | Marek Denis proposed a change to openstack/python-keystoneclient: Add CRUD operations for Identity Providers. https://review.openstack.org/83337 | 14:24 |
*** david-lyle has joined #openstack-keystone | 14:28 | |
*** nkinder has joined #openstack-keystone | 14:30 | |
*** derek_c has joined #openstack-keystone | 14:33 | |
*** stevemar has joined #openstack-keystone | 14:37 | |
*** saju_m has quit IRC | 14:41 | |
ayoung | dolphm, 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 IRC | 14:45 | |
*** jamielennox|away has joined #openstack-keystone | 14:49 | |
*** jamielennox|away has quit IRC | 14:49 | |
*** jamielennox|away has joined #openstack-keystone | 14:49 | |
dolphm | ayoung: we don't backport refactors, they're too risky | 14:49 |
ayoung | dolphm, even when the "refactor" in this case was to restructure the code in order to fix the bug? | 14:50 |
ayoung | and...do we areally need to wait to Juno to get this bug fix? | 14:50 |
*** thedodd has joined #openstack-keystone | 14:51 | |
ayoung | I see Thierry agrees with you | 14:51 |
dolphm | ayoung: 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 option | 14:51 |
ayoung | dolphm, 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-keystone | 15:00 | |
*** gokrokve has joined #openstack-keystone | 15:03 | |
*** joesavak has joined #openstack-keystone | 15:04 | |
*** jsavak has quit IRC | 15:06 | |
*** wchrisj has quit IRC | 15:09 | |
marekd | stevemar: hello. | 15:13 |
stevemar | marekd, howdy | 15:13 |
marekd | stevemar: 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-keystone | 15:17 | |
*** Gu_______ has joined #openstack-keystone | 15:18 | |
stevemar | marekd, you could, i don't know the other classes don't | 15:19 |
marekd | stevemar: the other classes like class Project(base.CrudManager) etc? | 15:20 |
*** andreaf has quit IRC | 15:20 | |
*** derek_c has quit IRC | 15:20 | |
stevemar | yeah, i don't think any actually store variables there right? | 15:20 |
marekd | stevemar: lol, so why keep those clases? :D | 15:20 |
*** dstanek has quit IRC | 15:23 | |
*** Gu_______ has quit IRC | 15:27 | |
*** gyee has joined #openstack-keystone | 15:32 | |
*** tomoiaga has joined #openstack-keystone | 15:38 | |
*** bvandenh has joined #openstack-keystone | 15:44 | |
*** Gu_______ has joined #openstack-keystone | 15:46 | |
openstackgerrit | A change was merged to openstack/keystone: Fix response for missing attributes in trust https://review.openstack.org/85327 | 15:49 |
*** Gu_______ has quit IRC | 15:50 | |
*** Guest____ has joined #openstack-keystone | 15:53 | |
*** samuelmz_ has joined #openstack-keystone | 15: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/1262843 | 15:58 |
uvirtbot | Launchpad bug 1262843 in python-novaclient "Nova and Cinder cannot be used with v3 authentication (dup-of: 1154809)" [Undecided,New] | 15:58 |
uvirtbot | Launchpad 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 workarround | 15:58 |
samuelmz_ | like Yaguang Tang's suggested at http://comments.gmane.org/gmane.comp.cloud.openstack.general/3657 | 15:59 |
samuelmz_ | s/Tang's/Tang | 16:02 |
*** marcoemorais has joined #openstack-keystone | 16:02 | |
*** derek_c has joined #openstack-keystone | 16:09 | |
*** browne has joined #openstack-keystone | 16:15 | |
*** kun_huang has joined #openstack-keystone | 16:16 | |
*** tomoiaga has quit IRC | 16:18 | |
*** jsavak has joined #openstack-keystone | 16:19 | |
*** derek_c has quit IRC | 16:20 | |
bknudson | samuelmz_: I think the issues that different projects are running into is that the service catalog in the v3 token is incompatible with v2 service catalog | 16:21 |
*** joesavak has quit IRC | 16:22 | |
*** lbragstad has quit IRC | 16:23 | |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Reuse module `exceptions` from Oslo https://review.openstack.org/68897 | 16: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/2 | 16:31 |
samuelmz_ | bknudson, right? | 16:31 |
samuelmz_ | bknudson, in this case, he proposed to nova | 16:32 |
*** dstanek has joined #openstack-keystone | 16:34 | |
*** saju_m has joined #openstack-keystone | 16:35 | |
*** derek_c has joined #openstack-keystone | 16:36 | |
dstanek | stevemar / marekd : have you tried running any of the federation tests against mysql? | 16:39 |
marekd | dstanek: no. | 16:40 |
marekd | dstanek: this is a hypothetical question or you are having some troubles with that? | 16:40 |
dstanek | marekd: http://paste.openstack.org/show/75341/ | 16:40 |
dstanek | i've been hacking on how we use the database in our tests and i ran into that | 16:40 |
*** Guest____ has quit IRC | 16:41 | |
marekd | dstanek: hmm, wait...devstack runs on mysql, right? | 16:41 |
dstanek | marekd: it does - i think it may be a difference in migrations -> models, but i wanted to see if anyone has already looked into it | 16:42 |
marekd | dstanek: ok, so i did play with keystone + federation + apache and used devstack as a base. | 16:43 |
marekd | dstanek: these are not tests themselves, but hey, eventually all the requests should look identically, right? :-) | 16:45 |
dstanek | marekd: :-) | 16:46 |
marekd | dstanek: I am not sure if I understood you correctly. So you think that error is caused by bad migrations scripts? | 16:49 |
dstanek | marekd: 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 migrations | 16:50 |
marekd | dstanek: ok | 16:52 |
dstanek | marekd: i'm wondering if it's the extra unique constraint in the model | 16:57 |
*** joesavak has joined #openstack-keystone | 16:57 | |
*** jsavak has quit IRC | 17:00 | |
*** leseb has quit IRC | 17:00 | |
marekd | dstanek: this? | 17:03 |
marekd | dstanek: https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/backends/sql.py#L30 | 17:03 |
dstanek | marekd: yes | 17:03 |
*** henrynash has joined #openstack-keystone | 17:04 | |
*** amcrn has quit IRC | 17:04 | |
marekd | dstanek: hmm, i can see that identity and assignments also have 'combined' unique constraints.. | 17:05 |
dstanek | marekd: ha! https://review.openstack.org/#/c/84447/ | 17:05 |
dstanek | marekd: 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-keystone | 17:06 | |
marekd | dstanek: aha. | 17:07 |
marekd | dstanek: 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 IRC | 17:10 | |
ayoung | morganfainberg_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=0f225743e8644416df2f200d710912c40b7acd47 | 17:11 |
*** bvandenh has quit IRC | 17:12 | |
*** jaosorior has joined #openstack-keystone | 17:15 | |
*** harlowja has joined #openstack-keystone | 17:16 | |
*** nlahouti_ has joined #openstack-keystone | 17:22 | |
*** morganfainberg_Z is now known as morganfainberg | 17:22 | |
nlahouti_ | Can someone please let me know how to enable notification in keystone when a tenat is create/deleted? | 17:23 |
dstanek | marekd: it appears that the extra constraint isn't the issue | 17:23 |
morganfainberg | ayoung, interesting | 17:23 |
ayoung | morganfainberg, I thought so | 17:23 |
morganfainberg | ayoung, I am a fan of pydevd debugging personally | 17:23 |
ayoung | morganfainberg, it doesn't let you restart keystone without restarting all of the httpd process though | 17:23 |
morganfainberg | ayoung, right | 17:24 |
ayoung | morganfainberg, and I am not certain that you could connect to the remote processes via some command line tool yet | 17:24 |
ayoung | Need to do more research | 17:24 |
morganfainberg | ayoung, 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 debug | 17:24 |
morganfainberg | ayoung, might be very hard to debug with all the workers grabbing whatever requests they get | 17:25 |
ayoung | morganfainberg, yeah | 17:25 |
morganfainberg | ayoung, but in premise i like the concept a lot | 17:25 |
marekd | dstanek: and it's still federation only? | 17:26 |
marekd | dstanek: 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 |
dstanek | ayoung: can't that be done in middleware instead of in keystone itself? | 17:27 |
dstanek | marekd: no, there are lots of things that fail | 17:27 |
dstanek | the unicode tests all seemt to fail | 17:28 |
dolphm | can 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 is | 17:28 |
*** tomoiaga has joined #openstack-keystone | 17:29 | |
dolphm | it sounds like there might be a regression from oslo between havana and icehouse | 17:29 |
nlahouti_ | dolpahm: thaks for your reply. It was okay before till I sync'd up with the master | 17:29 |
morganfainberg | dolphm, hm.. | 17:31 |
morganfainberg | dolphm, that config looks sane.... | 17:31 |
dstanek | dolphm, morganfainberg: can the -2 be removed on https://review.openstack.org/#/c/78169/ | 17:31 |
dolphm | yes! | 17:31 |
dolphm | done | 17:31 |
morganfainberg | dolphm, dstanek, look at the comment about the fk, ix, and ixu constraints/indexes | 17:32 |
nlahouti_ | dolphm: keystone/keystone/openstack/common/rpc does not exist in the latest code anymore | 17:32 |
morganfainberg | not 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 |
dstanek | dolphm: thx | 17:33 |
*** tomoiaga has quit IRC | 17:33 | |
dstanek | morganfainberg: so does that mean we'll have to explicitly list our indexes in the model? | 17:33 |
morganfainberg | nlahouti_, oh oooooh this is an oslo.messaging change cc dolphm my guess | 17:33 |
dolphm | nlahouti_: ah, that makes sense... hmm | 17:33 |
bknudson | samuelmz_: 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 |
morganfainberg | dstanek, 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 |
dolphm | nlahouti_: morganfainberg: do we need to restore it, even though we're not explicitly using it? (and open an rc3?) | 17:34 |
morganfainberg | dolphm, 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 pita | 17:35 |
*** amcrn has joined #openstack-keystone | 17:35 | |
nlahouti_ | dolphm: have parameters setting changed for the new code? | 17:35 |
nlahouti_ | dolphm: I meand setting it in keystone.conf file | 17:35 |
dolphm | nlahouti_: i think you might just be able to specify 'rabbit' for that option? | 17:35 |
morganfainberg | dolphm, 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 did | 17:35 |
dolphm | nlahouti_: or let it default | 17:35 |
dolphm | morganfainberg: :-/ | 17:35 |
nlahouti_ | but where does the message go? | 17:36 |
dolphm | nlahouti_: oh, is that your thread on openstack-dev? | 17:36 |
nlahouti_ | it used to be in notification.info | 17:36 |
*** elmiko has joined #openstack-keystone | 17:36 | |
nlahouti_ | or anything that I set as notification topic in the keystone.conf | 17:36 |
morganfainberg | dolphm, nlahouti_ would be the name i'd expect on IRC :) | 17:36 |
dolphm | nlahouti_: "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.html | 17:37 |
elmiko | hey 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 anymore | 17:38 |
dolphm | nlahouti_: 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 config | 17:38 |
morganfainberg | nlahouti_, rpc_backend should be set to "rabbit" now | 17:39 |
nlahouti_ | dolphm: yes and the problem wan that _notifier was None | 17:39 |
morganfainberg | nlahouti_, for keystone, which would just put it on the bus directly | 17:39 |
dstanek | what actually uses the rpc_backend setting? | 17:39 |
morganfainberg | dstanek, that is provided by oslo.messaging, that should be "qpid" "zmq" or "rabbit" | 17:39 |
morganfainberg | https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L304 | 17:40 |
morganfainberg | just based on sample config | 17:40 |
dstanek | morganfainberg: ah, that's why i don't see it in our code | 17:40 |
morganfainberg | yeah | 17:40 |
morganfainberg | this is the move to oslo.messaging | 17:40 |
nlahouti_ | dstanek: Now I set it to rpc_backend=rabbit | 17:40 |
morganfainberg | dolphm, restoring the openstack.common rpc stuff would be bad. | 17:40 |
morganfainberg | dolphm, possible conflicts with oslo.messaging | 17:40 |
dolphm | morganfainberg: oh, true. crap | 17:40 |
morganfainberg | s/would/could | 17:41 |
dolphm | morganfainberg: i guess we need to figure this out and provide upgrade notes | 17:41 |
samuelmz_ | bknudson, cool.. thanks for ur help | 17:41 |
dolphm | dstanek: just CRUD notifications at the moment | 17:41 |
nlahouti_ | morganfainberg: did it work or was it tested with the oslo.messaging | 17:41 |
morganfainberg | nlahouti_, it should work with oslo.messaging (assuming icehouse code?) | 17:42 |
nlahouti_ | morganfainberg: I checkout the master | 17:42 |
morganfainberg | nlahouti_, ok | 17:43 |
morganfainberg | nlahouti_, should work with oslo.messaging | 17:43 |
morganfainberg | looking at the notification driver setting | 17:43 |
nlahouti_ | morganfainberg: but I need to know the correct format of parameter that works | 17:43 |
morganfainberg | nlahouti_, yep, give me a second to chase this down for ya :) | 17:44 |
nlahouti_ | morganfainberg: thx a lot | 17:44 |
morganfainberg | nlahouti_, ok still looking but you might be able to set it to "rabbit" or "kombu" (yes the string) | 17:50 |
morganfainberg | nlahouti_, this seems wrong though. hold on | 17:50 |
*** henrynash has quit IRC | 17:51 | |
dstanek | morganfainberg, nlahouti_: there is an answer on the list | 17:52 |
morganfainberg | dstanek, ah *looks* | 17:53 |
nlahouti_ | morganfainberg: what list? | 17:53 |
morganfainberg | nlahouti_, the mailing list | 17:53 |
morganfainberg | nlahouti_, in response to your email (solly ross responded) | 17:53 |
nlahouti_ | morganfainberg: ok ;) i'll check | 17:53 |
morganfainberg | nlahouti_, looks like "messaging" is the right answer | 17:53 |
morganfainberg | dstanek, the fact that the documentation for oslo.messaging doesn't make this easy is ugly | 17:54 |
nlahouti_ | morganfainberg: and how about the notification_topics, control_exchange, and notification_driver | 17:54 |
morganfainberg | nlahouti_, ok if you read the email, the rpc_backend should be "rabbit" and the notification_driver "messaging" | 17:54 |
morganfainberg | nlahouti_, i believe the other options don't really change | 17:55 |
nlahouti_ | morganfainberg: ok. let me read and try the recommendation. | 17:55 |
morganfainberg | nlahouti_, of course you'll need to configure the options to point at the correct rabbit server, etc | 17:55 |
*** gokrokve has quit IRC | 17:55 | |
morganfainberg | nlahouti_, but again those should be mostly the same if not identical | 17:56 |
*** anteaya has quit IRC | 17:56 | |
dolphm | bottom section of http://docs.openstack.org/trunk/config-reference/content/configuring-rpc.html is relevant | 17:56 |
marekd | dolphm: 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 |
dolphm | nlahouti_: notifications_topics and control_exchange are your preference, you just need to be consistent about them | 17:56 |
nlahouti_ | dolphm: thx for the doc | 17:57 |
*** jamielennox|away is now known as jamielennox | 17:58 | |
dolphm | marekd: 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 |
dolphm | marekd: git commit --amend would then rewrite the second commit; a subsequent git-review would submit everything on the current branch not-in-gerrit to gerrit | 17:59 |
* dolphm meeting time! | 17:59 | |
marekd | dolphm: 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 |
dstanek | marekd: when i have patchsets like X->Y->Z i'll git review Z and modify the X, Y or Z commit before running git review | 18:00 |
dstanek | i never 'git review -d' commits other than the top one in the dep list | 18:00 |
*** topol has joined #openstack-keystone | 18:01 | |
*** tjones has joined #openstack-keystone | 18:01 | |
*** diegows has joined #openstack-keystone | 18:02 | |
diegows | hi | 18:02 |
diegows | :) | 18:02 |
diegows | What do you think about a PAM authentication module for keystone? | 18:02 |
diegows | I'd like to implement LDAP auth, but there is no backend for that (I don't need identity management, just auth) | 18:02 |
diegows | and may be a implementation with PAM could open the game to other auth methods easily | 18:02 |
*** thedodd has quit IRC | 18:03 | |
*** tjones has left #openstack-keystone | 18:04 | |
morganfainberg | diegows, we're in a meeting now, but we had one and it wasn't used (it had been broken since before grizzly) | 18:04 |
browne | diegows: i'm not a fan of the PAM driver. | 18:05 |
morganfainberg | diegows, 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 IRC | 18:05 | |
morganfainberg | diegows, feel free to propose it, but i'm concerned about maintaining it and functionality | 18:05 |
diegows | morganfainberg, I don't need to provide information, just authentication | 18:05 |
diegows | like the other authentication modules | 18:06 |
dstanek | diegows: this is what morganfainberg was talking about http://git.openstack.org/cgit/openstack/keystone/commit/?id=6bd2307 | 18:06 |
diegows | AFAIK, they only very user/pass | 18:06 |
*** richm has joined #openstack-keystone | 18:06 | |
browne | couldn't the remote_user auth with httpd be used for diegows? | 18:06 |
*** thedodd has joined #openstack-keystone | 18:06 | |
diegows | but that require may be a more complex config, something simple like PAM or just LDAP directly would be better I think | 18:07 |
browne | diegows: you can use LDAP for auth/user/groups and SQL for assignments | 18:07 |
diegows | LDAP Identify module, right? | 18:09 |
*** wchrisj has joined #openstack-keystone | 18:10 | |
morganfainberg | diegows, you could also just write an auth_plugin that does pam auth. | 18:11 |
browne | diegows: yes, you can configure keystone to use LDAP for identity driver and SQL for assignment. I like this setup | 18:11 |
diegows | morganfainberg, I was talking about that :), may be I wasn't clear | 18:11 |
diegows | browne, I'm setting up OpenStack in a company where we have an AD that we can't touch | 18:12 |
browne | diegows: yep, that's typical | 18:12 |
diegows | the schema is weird, not very friendly with Keystone | 18:12 |
*** kun_huang has quit IRC | 18:12 | |
nlahouti_ | morganfainberg: thx guys, I tried it and it worked! | 18:12 |
diegows | That's why I mention that I need something simple, really simple, just authentication | 18:12 |
browne | diegows: well, you'll have to construct proper search queries. schema is what always gets tricky with hooking in ldap | 18:13 |
nlahouti_ | dolphm: morganfainberg: thx for the help. rpc_backend=rabbit and notification_driver=messaging were the correct setting. | 18:14 |
diegows | dstanek, 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 |
morganfainberg | nlahouti_, ++ 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 |
morganfainberg | nlahouti_, cheers | 18:16 |
*** samuelmz_ has quit IRC | 18:16 | |
browne | dstanek: nice that the pam driver was finally removed. i always wondered why it remained and if anyone actually used it | 18:17 |
diegows | and a short question about how auth plugins, they are tried in order, right? | 18:17 |
morganfainberg | browne, it was removed because i noticed it was really borken when i tried to refactor stuff around it | 18:19 |
morganfainberg | diegows, need to finish the meeting and we can talk about it, should be done in ~40min (max) | 18:20 |
diegows | PAM identity mgmt doesn't make sense I think, broken by definition :) | 18:20 |
diegows | ok morganfainberg | 18:20 |
*** leseb has joined #openstack-keystone | 18:33 | |
dolphm | diegows: ++ | 18:34 |
diegows | dolphm, that "++" was about my last question or about the PAM module ? :) | 18:35 |
dolphm | diegows: uhh, PAM | 18:38 |
diegows | :) | 18:38 |
dolphm | diegows: not sure which order you're referring to, though? plugins are executed in the order that the client identifies them | 18:39 |
dolphm | diegows: the service won't try multiple plugins for the same authentication method | 18:39 |
diegows | hmm | 18:40 |
diegows | suppose that I have methods = external,password,token,oauth1 | 18:41 |
diegows | if external founds REMOTE_USER, will return OK and the process finish, right? | 18:41 |
*** leseb_ has joined #openstack-keystone | 18:42 | |
ayoung | you diegows there is a Keystone meeting going on in #openstack-meeting right now...you will get more coherent answers in...17 minutes | 18:43 |
diegows | ok, I know... but dolphm was answering :) | 18:44 |
*** saju_m has quit IRC | 18:44 | |
*** leseb has quit IRC | 18:44 | |
dolphm | i was trying to jump in and out in a conversation lull :) | 18:46 |
dolphm | diegows: yes, to your last question | 18:46 |
*** thedodd has quit IRC | 18:50 | |
*** thedodd has joined #openstack-keystone | 18:52 | |
*** stevemar has quit IRC | 18:55 | |
*** stevemar has joined #openstack-keystone | 18:55 | |
*** inc0 has quit IRC | 18:55 | |
nkinder | gyee: yeah, not much else we can do if it's just the hash string we're dealing with | 18:59 |
nkinder | gyee: what about prefixing the hash string with an identifier (like LDAP password hashes)? | 19:00 |
gyee | right, but embedding the algorithm would make it unambiguous | 19:00 |
bknudson | I'm trying to figure out where auth_token would use the hash algorithm in the token? | 19:00 |
gyee | nkinder, yes, prefixing would work too | 19:00 |
*** Guest_ has joined #openstack-keystone | 19:00 | |
dstanek | ayoung: i was hoping to test the db fixtures patch against a real database so i may just need to figure this out today too | 19:00 |
nkinder | {SHA-256}blahblahblah | 19:00 |
gyee | ++ | 19:00 |
gyee | bknudson, two places, 1) revocation check, 2) online validatoin | 19:01 |
ayoung | nkinder, not sure what that would solve | 19:01 |
bknudson | gyee: the revocation list has the hash algorithm ... | 19:01 |
ayoung | we need to look up tokens by ID...ID is generated from the hash, but you would need to know tha algroithm a-priori | 19:01 |
bknudson | gyee: we could reject tokens that don't have the same hash algorithm? | 19:01 |
nkinder | ayoung: ID is the hash, right? | 19:02 |
ayoung | this is a waste of efforts. We just stop hashing the tokens all together | 19:02 |
ayoung | nkinder, yep. And only really needed for online validation. | 19:02 |
ayoung | Ephemeral is the way to solve it | 19:02 |
ayoung | if you cahnge the hash algorthim for your server, all previous tokens get revoked. Period | 19:03 |
nkinder | I was looking for more info on ephemeral. The blueprint didn't really go into the detail of what I was looking for. | 19:03 |
gyee | bknudson, that's fine for revocation list then, we only need to worry about online validation | 19:03 |
nkinder | With ephemeral tokens, what is stored in the token database exactly? | 19:03 |
bknudson | gyee: so in that case we get a hash on the request, then we send the hash to the server for confirmation. | 19:03 |
morganfainberg | nkinder, just the revocation events | 19:03 |
bknudson | gyee: I don't see where the hash algorithm comes in? | 19:03 |
nkinder | morganfainberg gave me some details on IRC, which were helpful, but I'm wondering exactly what we would see. | 19:04 |
morganfainberg | nkinder, token data wouldn't be stored in the DB at all | 19:04 |
nkinder | morganfainberg: so no active tokens? | 19:04 |
morganfainberg | nkinder, correct | 19:04 |
ayoung | nkinder, the short version is this: only cryptographic validation of tokens is ever performed. | 19:04 |
ayoung | So if a remote process askes keystone "is this token valid" two things happend | 19:04 |
morganfainberg | nkinder, ^ what ayoung said. | 19:04 |
nkinder | and how does revocation reference a token? | 19:04 |
ayoung | one | 19:04 |
ayoung | the token i verified via cms | 19:04 |
bknudson | gyee: unless you want the server to reject tokens that have the wrong algorithm? | 19:04 |
nkinder | I need to read the token revocation events bp... | 19:04 |
ayoung | two the token is convfrimed to not be revoked against the revocation events | 19:04 |
morganfainberg | ayoung, btw, that is next on my list of "todo" since SQL collapse is posted. (tangentially related) | 19:05 |
ayoung | ID becomes irrelevant | 19:05 |
dolphm | token_backend = network | 19:05 |
gyee | bknudson, but aren't we hash the PKI token for online validation? | 19:05 |
nkinder | ok, 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 |
morganfainberg | nkinder, correct. | 19:05 |
nkinder | I guess date is in there as well? | 19:05 |
bknudson | gyee: is online validation sending the token to the server? | 19:05 |
morganfainberg | nkinder, yes | 19:05 |
nkinder | ...so I could say "revoke all of nkinder's tokens older then yesterday" | 19:06 |
ayoung | nkinder, yes | 19:06 |
bknudson | gyee: I just want to make sure I understand what's meant by "online validation" | 19:06 |
gyee | bknudson, for PKI token, the token ID basically the hash of the PKI token | 19:06 |
ayoung | nkinder, specifically: user_id and issued_at time | 19:06 |
nkinder | cool | 19:06 |
bknudson | gyee: that would be the client that's talking to auth_token that does the hash | 19:06 |
nkinder | gyee: signature verification from the signing cert | 19:06 |
gyee | bknudson, you can validate a PKI token over the wire as oppose locally | 19:06 |
ayoung | nkinder, 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 approach | 19:06 |
bknudson | gyee: so you're more worried about the other clients and not auth_token? | 19:07 |
nkinder | ayoung: so the client has to look at what is in the token to see if a revocation event affects it, right? | 19:07 |
bknudson | I don't know if we provide a library for hashing a token... not sure how apps know how to do it. | 19:07 |
dolphm | bknudson: with PKI / offline validation, you need the network at startup, but theoretically you can validate tokens while keystone is down, for example | 19:07 |
ayoung | nkinder, correct. The code to do that is going into a library, but non-python clients are going to need an impl as well | 19:07 |
ayoung | the clien piece is held up by python33 nastiness | 19:08 |
ayoung | https://review.openstack.org/#/c/81166/ | 19:08 |
nkinder | ayoung, morganfainberg: I like it | 19:08 |
morganfainberg | ayoung, still fighting that? | 19:08 |
morganfainberg | nkinder, yeah i liked it a lot when ayoung proposed it. | 19:08 |
gyee | bknudson, revocation list is fetch at an interval, for those prefer real-time, they can do it over the wire | 19:08 |
ayoung | morganfainberg, no, I'm fighting my boss who wants me to pick uop the UTF8 fix. | 19:08 |
ayoung | Did I mention nkinder is my boss? | 19:08 |
nkinder | looking at the contents of the token database scared me | 19:08 |
morganfainberg | ayoung, ah. | 19:09 |
ayoung | Heh | 19:09 |
bknudson | gyee: are you ok with auth_token not caring about the hash algorithm in the token? | 19:09 |
dolphm | nkinder: as it should! | 19:09 |
morganfainberg | nkinder, yeah i want that db table to die. | 19:09 |
morganfainberg | nkinder, it's horribad (but we what we have for right now) | 19:09 |
dolphm | DROP TABLE `token`; #juno | 19:09 |
morganfainberg | dolphm, +++++++++++++++ | 19:09 |
gyee | bknudson, no, auth_token should carry the hash algorithm | 19:09 |
morganfainberg | dolphm, waiiit are you using postgres!? :P | 19:09 |
bknudson | gyee: where is it going to use it? | 19:09 |
stevemar | did we end up deciding that the security docs should live in tree? | 19:09 |
gyee | bknudson, sorry | 19:10 |
nkinder | I had a question about some of the LDAP code too (which I mentioned in the "potential improvements" section of the security doc) | 19:10 |
morganfainberg | stevemar, i think initialluy | 19:10 |
stevemar | morganfainberg, cool | 19:10 |
gyee | bknudson, I mean auth_token middleware should not care about the configurable hash algorithm | 19:10 |
nkinder | why do we have code that hashes passwords for LDAP users? | 19:10 |
ayoung | nkinder, only for adding them in the backend | 19:10 |
ayoung | I don't think it is called anywhere else | 19:11 |
nkinder | I 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 out | 19:11 |
dolphm | stevemar: nkinder is going to poke other projects for ideas, but i think we're all happy to have them in-tree | 19:11 |
gyee | ayoung, but LDAP itself hash the passwords | 19:11 |
nkinder | gyee: +1 | 19:11 |
ayoung | gyee, I needed it at one point | 19:11 |
stevemar | dolphm, okay, i might post a quick copy/paste of the wiki content (in rst format) | 19:11 |
bknudson | gyee: ok, we hash a token for checking against the the cache ... but this happens before we've decoded the cms. | 19:11 |
dolphm | stevemar: to gerrit? | 19:12 |
bknudson | gyee: so we don't have the token hash at that point. | 19:12 |
nkinder | that'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 |
stevemar | dolphm, yes | 19:12 |
dstanek | has anyone seen this DB error before? http://paste.openstack.org/show/75341/ | 19:12 |
bknudson | gyee: do you think auth_token should decode the cms before hashing? | 19:12 |
morganfainberg | nkinder, seems kinda icky | 19:12 |
ayoung | keystone/identity/backends/ldap.py: | 19:12 |
nkinder | we should just use the provided password and perform a bind with it | 19:12 |
morganfainberg | nkinder, ++ i like that better | 19:13 |
dstanek | i can't tell why it's choking other than a FK to a field that is part of a composit index | 19:13 |
ayoung | nkinder, so we do it to check that the password matches, too | 19:13 |
dolphm | stevemar: --author="Nathan Kinder <somethingsomething>" | 19:13 |
nkinder | ayoung: that's what a bind is for | 19:13 |
morganfainberg | dstanek, yes i have seen that. | 19:13 |
ayoung | nkinder, we don't make changes as the user | 19:13 |
ayoung | the bind is doen by the admin usder | 19:13 |
ayoung | user | 19:13 |
stevemar | cool | 19:13 |
*** gokrokve has joined #openstack-keystone | 19:13 | |
dstanek | morganfainberg: were you able to solve it? | 19:13 |
nkinder | ayoung: bind isn't making changes | 19:13 |
gyee | bknudson, that's fine, we can invalidate the cache for hash mismatch, something we can afford doing | 19:13 |
morganfainberg | dstanek, ... it's (i want to say) invalid FK constraint / non-synced column types | 19:14 |
morganfainberg | dstanek, either the refrenced column is busted, or the data types in the referenced column doesn't match the local column. | 19:14 |
ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/identity/backends/ldap.py#n102 | 19:14 |
nkinder | ayoung: so we require binding as an admin user who can read the userPassword attribute? | 19:14 |
dolphm | stevemar: --author="Nathan Kinder <nkinder@redhat.com>" and then put yourself as Co-Authored-By in the commit message | 19:14 |
morganfainberg | dstanek, varchar(255) vs int | 19:14 |
ayoung | nkinder, I think it can die | 19:14 |
morganfainberg | dstanek, or even more subtle | 19:14 |
dstanek | morganfainberg: the types are the same | 19:14 |
bknudson | gyee: ok, I'll look into it. | 19:14 |
morganfainberg | dstanek, exactly the same? | 19:15 |
ayoung | nkinder, if the user submits the password in plaintext, we hash it upon update. I'm guessing that No one in their right mind wants that | 19:15 |
morganfainberg | dstanek, down to the null / not null / default /etc | 19:15 |
ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/identity/backends/ldap.py#n227 | 19:15 |
stevemar | dolphm, hmm, how to translate these tables to rst | 19:15 |
morganfainberg | dstanek, i assume mysql because of the error code | 19:15 |
bknudson | stevemar: http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables | 19:15 |
nkinder | ayoung: 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 |
morganfainberg | dstanek, and it gets cranky about even minor differences | 19:16 |
dstanek | morganfainberg: yep | 19:16 |
morganfainberg | dstanek, you could also see this on innodb vs non-innodb tables | 19:16 |
dolphm | stevemar: maybe tables isn't the best option lol: http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables | 19:16 |
ayoung | nkinder, I think for R/W LDAP binding as the user should be the default. And for Read Only, it should not be. | 19:16 |
morganfainberg | dstanek, and charset differences (e.g. utf8 vs latin1) | 19:16 |
dolphm | stevemar: that looks like a nightmare for people to maintain in RST | 19:16 |
ayoung | nkinder, so a config option "ldap_operations_as_user" =True or something | 19:16 |
morganfainberg | dstanek, is the db engine inno and the charset utf8 by default? | 19:17 |
nkinder | ayoung: why are you considering a bind as a write? | 19:17 |
gyee | nkinder, ayoung, need to be careful with LDAP bind, I run into a case with OpenLDAP when bind failed, it fall back to anonymous bind | 19:17 |
ayoung | RIght now, I am guessing most people leave the LDAP user blank, and do anonymous | 19:17 |
gyee | scary stuff :) | 19:17 |
morganfainberg | dstanek, ran into a bunch of these recently actually, it's super sucky to debug. | 19:17 |
dolphm | gyee: it's a feature? | 19:17 |
nkinder | gyee: yes, that is normal. You need to check the result code | 19:17 |
gyee | dolphm, yeah, in OpenLDAP | 19:17 |
nkinder | You can connect without binding, and your identity is "anonymous" | 19:17 |
* stevemar shudders! | 19:17 | |
nkinder | gyee: it's standard for LDAP | 19:17 |
gyee | its a server-side configuration | 19:18 |
stevemar | so tables is a no | 19:18 |
dstanek | morganfainberg: http://paste.openstack.org/show/75355/ :-( | 19:18 |
ayoung | gyee, 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 that | 19:18 |
gyee | ayoung, for LDAP authentication, you don't want anonymous bind fallback at all | 19:18 |
ayoung | nkinder, yes, but it was being used on the authenitcate call | 19:18 |
morganfainberg | dstanek, show create table identity_provider | 19:18 |
nkinder | gyee: are you talking about "unauthenticated binds", or failed binds? | 19:18 |
ayoung | gyee, I remember well. | 19:18 |
nkinder | "unauthenticated" is when you send a bind DN without a password | 19:18 |
ayoung | As 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 |
nkinder | that falls through to anonymous, and it's bad. The RFC discourages it | 19:19 |
ayoung | and I was not notified, and I was not pleased | 19:19 |
nkinder | and servers often reject that with an error now. | 19:19 |
gyee | nkinder, no, I mean anonymous bind fall back | 19:19 |
ayoung | nkinder, authenticate is the only place the simple_bind is used as the user. otherwise it is the admin user for all LDAP operations | 19:19 |
morganfainberg | dstanek, and show full columns identity_provider | 19:19 |
gyee | you send DN/password and bind failed, you don't get an error | 19:19 |
nkinder | gyee, ayoung: Yes, that is normal. You need to check if you get an err=49 | 19:19 |
gyee | you just get an anonymous context I think | 19:19 |
gyee | I remember seeing this with OpenLDAP awhile back | 19:20 |
nkinder | there is also a "whoami" extended operation | 19:20 |
morganfainberg | dstanek, and SHOW CHARACTER SET FOR keystone; | 19:20 |
ayoung | nkinder, 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 |
nkinder | the issue with binds is that you can bind multiple times on a single connection | 19:20 |
ayoung | and, if the directory does not have Anonymous access, shouldn't you bind as the user, not as an admin? | 19:21 |
nkinder | ayoung: yes, that is the normal way (though there are more advanced proxy operations too) | 19:21 |
morganfainberg | dstanek, and one last one: select `ENGINE` from `information_schema`.`TABLES` where `TABLE_SCHEMA`='keystone'; | 19:21 |
nkinder | ayoung: yes, as the user | 19:21 |
dstanek | morganfainberg: started running the tests again - it looks like devstack setup my mysql to default to latin1 | 19:21 |
dstanek | morganfainberg: hopefully this will fix it | 19:21 |
ayoung | nkinder, and...if we do Kerberos, we can do S4U@Proxy as the user, and then we've basically reimplemented the Auth mechanism in FreeIPA | 19:21 |
nkinder | ayoung: we just need to bind as the user, then check the result code. If it's 0, the bind was successful. | 19:21 |
morganfainberg | dstanek, yeah. that is normal. in our migrations we explicitly change the default to utf8 | 19:22 |
morganfainberg | dstanek, 004 iirc | 19:22 |
morganfainberg | dstanek, and my collapse does the same on 036 | 19:22 |
ayoung | nkinder, so we hash for password update. What should Keystone do there (other than get out of the writable LDAP business)? | 19:23 |
dstanek | morganfainberg: that would definitely explain why the unicode tests where failing, but not why a foreign key would fail | 19:23 |
morganfainberg | dstanek, yeaaah. collation issues. | 19:24 |
nkinder | ayoung: how can we do a password update if we're read-only? | 19:24 |
morganfainberg | dstanek, my guess is one table ended up utf8 and the other was latin1 | 19:24 |
morganfainberg | dstanek, i know it's stupid. | 19:24 |
nkinder | ayoung: we would just have to reject password changes | 19:24 |
ayoung | nkinder, heh...We can't BUt Keystone was not originally Read only for LDAP, and removing that requires a deliberate decision | 19:24 |
dstanek | morganfainberg: so far so good - but the run will take a little bit | 19:25 |
morganfainberg | dstanek, ++ sounds good, let me know if you need anything else | 19:25 |
ayoung | dolphm, for Juno, can we deprecate "Writable LDAP Identity backend?" My guess is that CERN would be OK with that. | 19:25 |
nkinder | ayoung: yeah, seems like a configurable option would be ideal there | 19:25 |
*** david_lyle_ has joined #openstack-keystone | 19:26 | |
ayoung | nkinder, 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 |
dstanek | morganfainberg: thanks for your help - now i just have to figure out these integrity errors | 19:27 |
ayoung | nkinder, 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 IRC | 19:28 | |
ayoung | dstanek, once you get it working, the real fun begins: we need Mysql unit test runs as part of gate | 19:28 |
*** dklyle has joined #openstack-keystone | 19:28 | |
ayoung | And postgresql really | 19:29 |
dolphm | ayoung: we've tried in the past, and it keeps getting maintained, so i'd say no | 19:30 |
*** david-lyle has quit IRC | 19:30 | |
ayoung | huh? | 19:30 |
dolphm | ayoung: to deprecate writable LDAP | 19:31 |
ayoung | dolphm, ah. OK. I thought you meant the SQL Unit test gate thing | 19:31 |
*** dklyle has quit IRC | 19:31 | |
dolphm | ayoung: remember, essex was implemented as read-only, and then people came out of the woodwork to make it writable | 19:31 |
ayoung | dolphm, I suspect you are right. | 19:31 |
*** dklyle has joined #openstack-keystone | 19:31 | |
dolphm | it'd be nice if it was a separate driver, i suppose | 19:31 |
ayoung | dolphm, but with split Identity, I think that it is the assignment side that people really need writable | 19:31 |
dolphm | the read-only implementation being the base class for a read/write one | 19:32 |
dolphm | ayoung: maybe people are just using keystone to manage LDAP | 19:32 |
*** david_lyle_ has quit IRC | 19:32 | |
ayoung | dolphm, perhaps | 19:32 |
dolphm | because keystone is the *best* HTTP API for your LDAP server | 19:32 |
bknudson | http://marginnotes2.wordpress.com/2013/03/04/opendj-rest-to-ldap-gateway/ | 19:33 |
dstanek | ayoung: is the thought then to add a few new builder to run against mysql and postres? | 19:35 |
ayoung | dstanek, 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 runs | 19:36 |
ayoung | just in a separate database. hence keystone_test vs keystone as the DB name | 19:36 |
dstanek | ayoung: interesting...ok. i'll ping you when i unwind all of this and we can talk a little more about that | 19:36 |
*** thedodd has quit IRC | 19:37 | |
ayoung | dstanek, that would be most excellent | 19:37 |
ayoung | and with that...if you will excuse me...I need to change offices | 19:37 |
*** ayoung has quit IRC | 19:37 | |
*** thedodd has joined #openstack-keystone | 19:38 | |
*** dklyle is now known as david-lyle | 19:40 | |
*** thedodd has quit IRC | 19:43 | |
jamielennox | for the ibmers or others: does anyone understand what this is: http://softlayer.github.io/jumpgate/? | 19:47 |
bknudson | topol: you know? ^ | 19:48 |
topol | bknudson, yes I know about jumpgate | 19:49 |
lbragstad | jamielennox: I'm not entirely sure, but *think* it is a translation layer | 19:49 |
lbragstad | between the softlayer and openstack apis | 19:49 |
jamielennox | lbragstad: yea, that was my guess - but it's a new server not a client layer | 19:49 |
*** joesavak has joined #openstack-keystone | 19:49 | |
lbragstad | I've never played with it | 19:50 |
topol | lbragstad is pretty much correct. Its SoftLayers's first step towards providing OpenStack. | 19:50 |
topol | I have | 19:50 |
topol | SoftLayer current support OpenStack in a few different ways | 19:50 |
*** mjfork has joined #openstack-keystone | 19:51 | |
lbragstad | mjfork: Hi! | 19:51 |
topol | You 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 support | 19:51 |
jamielennox | for 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 SDK | 19:51 |
topol | via API translation | 19:51 |
topol | Yes, it talks to some native SoftLayer services | 19:52 |
jamielennox | ah, ok - so they have an existing cloud product and they are wanting to make it work with openstack apis | 19:52 |
topol | jamielennox, yes that is there first step | 19:52 |
topol | towards greater OpenStack support | 19:53 |
jamielennox | topol: ok, cool - i hadn't heard of them before so coming out with an abstraction service just seemed like a weird starting point | 19:53 |
topol | so 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 summit | 19:54 |
jamielennox | yea, it's getting so cheap | 19:55 |
topol | for 10 cents I brag and tell folks I "co-funded" the project :-) | 19:55 |
lbragstad | lol | 19:55 |
*** jaosorior has quit IRC | 20:00 | |
dolphm | bug 1285833 got re-opened over the weekend, but i'm not sure if it's a new issue or not... | 20:01 |
uvirtbot | Launchpad bug 1285833 in python-keystoneclient "Keystone client racing on certificate lookups causing 401 Unauthorized on API calls" [Critical,Confirmed] https://launchpad.net/bugs/1285833 | 20:01 |
dolphm | it's the same stack trace, but i can't imagine it's still a race condition | 20:01 |
*** nlahouti_ has quit IRC | 20:03 | |
bknudson | dolphm: I think morganfainberg added some more logging for it. | 20:03 |
marekd | jamielennox: 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.py | 20:04 |
marekd | jamielennox: or if I understood it correctly. | 20:04 |
jamielennox | marekd: the enabled=True one? | 20:05 |
marekd | jamielennox: yep | 20:05 |
jamielennox | so when you do an update it should just provide the information you want to actually change in the object | 20:06 |
jamielennox | so you can change eg name without changing all the other details | 20:06 |
marekd | jamielennox: ah, this. ok | 20:06 |
marekd | jamielennox: got it. | 20:06 |
jamielennox | ok | 20:06 |
jamielennox | yep, so if you always set enabled=True that will always be part of the update call | 20:07 |
marekd | jamielennox: true. | 20:07 |
*** topol has quit IRC | 20:08 | |
marekd | jamielennox: 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 |
jamielennox | marekd: sure, i'm here other than for a few meetings now as well - where are you located? our TZs are way off | 20:10 |
jamielennox | marekd: is there a reason for having enabled be a required argument on update? | 20:11 |
marekd | jamielennox: Switzerland, it's 22:10 here. | 20:12 |
marekd | jamielennox: ah, forgot about that. | 20:12 |
jamielennox | utils.positional.method doesn't always need an arg | 20:13 |
marekd | jamielennox: 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 |
jamielennox | if you leave it empty it will just enforce that anything with a default value is going to be passed as a kwarg | 20:13 |
jamielennox | marekd: true - do identity providers allow that 'extra' unspecified attributes? | 20:14 |
marekd | jamielennox: 'extra' -> those in kwargs? | 20:15 |
jamielennox | marekd: yea, the stupid thing we do where we save any extra arguments to the db for later | 20:15 |
marekd | i 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 |
openstackgerrit | Steve Martinelli proposed a change to openstack/keystone: Add security details to keysone docs https://review.openstack.org/86140 | 20:17 |
*** erecio has quit IRC | 20:19 | |
jamielennox | marekd: i don't mind if you do it explicitly - i was just wondering | 20:19 |
jamielennox | marekd: commented | 20:20 |
jamielennox | marekd: most are nits | 20:20 |
derek_c | is the master branch of openstackclient using the master branch of keystoneclient? | 20:21 |
jamielennox | derek_c: it should be tested that way in the gate, but not in reality | 20:22 |
jamielennox | that was confusing, it is tested that way in the gate. If you install OSC manually though it will pull in from pypi | 20:23 |
derek_c | jamielennox: ok, I see | 20:23 |
derek_c | thanks | 20:23 |
openstackgerrit | Steve Martinelli proposed a change to openstack/keystone: Add security details to keysone docs https://review.openstack.org/86140 | 20:23 |
marekd | jamielennox: jamielennox thanks | 20:25 |
*** ayoung has joined #openstack-keystone | 20:27 | |
*** Guest_ has quit IRC | 20:29 | |
*** Guest_ has joined #openstack-keystone | 20:30 | |
marekd | jamielennox: so the identity_provider id is a string, defined by a user. | 20:35 |
marekd | jamielennox: no uuids in this case. | 20:35 |
jamielennox | ok | 20:35 |
marekd | jamielennox: and it must be provided. | 20:35 |
jamielennox | so you dont want base.getid then | 20:35 |
marekd | not at all | 20:36 |
dstanek | barf...the tables are not getting dropped at the end of the test | 20:37 |
marekd | aand in methods like get,update,create this idp's id is used to build dynamic URL. | 20:37 |
*** Guest_ has quit IRC | 20:38 | |
*** Guest_ has joined #openstack-keystone | 20:38 | |
*** vhoward has joined #openstack-keystone | 20:39 | |
*** gyee has joined #openstack-keystone | 20:41 | |
marekd | jamielennox: "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 |
stevemar | nkinder, ping -> https://review.openstack.org/#/c/86140/ | 20:44 |
jamielennox | yea, everything that is a parameter of the object should be a kwarg | 20:44 |
marekd | jamielennox: so why not put description,enabled in the kwargs - because they have default values? | 20:45 |
lbragstad | stevemar: nkinder took a quick pass https://review.openstack.org/#/c/86140/ | 20:45 |
stevemar | lbragstad, thanks boss! | 20:46 |
lbragstad | stevemar: thanks for pushing that up! | 20:46 |
nkinder | stevemar: awesome, I'll take a look | 20:46 |
jamielennox | marekd: 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 keyword | 20:47 |
marekd | jamielennox: i think i start understand people who complain about Python's dynamic typing and all that stuff :-) | 20:48 |
jamielennox | marekd: :) its better in py3, this is a nice hack in the mean time | 20:49 |
derek_c | I'm creating a new contrib module. do I need to somehow register it? | 20:57 |
*** david-lyle is now known as david-lyle_afk | 20:57 | |
derek_c | i'm talking about /keystone/contrib | 20:59 |
dolphm | nkinder: around for #openstack-meeting? | 21:03 |
nkinder | dolphm: yep, I'm there | 21:04 |
*** marcoemorais has quit IRC | 21:12 | |
*** marcoemorais has joined #openstack-keystone | 21:13 | |
dolphm | stevemar: did you propose the RST version of the security notes? | 21:14 |
stevemar | dolphm, yessem | 21:15 |
stevemar | https://review.openstack.org/#/c/86140/2/doc/source/security_details.rst | 21:15 |
marekd | jamielennox: 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 |
dolphm | stevemar: thanks! but it sounds like the cross-project desire is for this to live in the wiki :-/ | 21:22 |
stevemar | nooooo | 21:23 |
lbragstad | well, it sounds like people are behind it, that's a good thing | 21:23 |
stevemar | true true | 21:24 |
stevemar | gotta bail, see ya folks | 21:24 |
jamielennox | marekd: i hadnt, there's only so much im willing to try to force through review at any one time | 21:26 |
jamielennox | i was hoping to address something like that in python-openstacksdk and then if it proved useful we could look at it for a 1.0 | 21:26 |
jamielennox | but the backwards compatability would just be a nightmare to transfer the current stuff | 21:26 |
derek_c | why would I get this error when running devstack? | 21:27 |
derek_c | /home/vagrant/devstack/lib/keystone:376 keystone did not start | 21:27 |
*** Guest_ has quit IRC | 21:27 | |
marekd | jamielennox: ;/ | 21:28 |
derek_c | a more complete log is here: http://upl.io/wnnlr5 | 21:28 |
derek_c | seems like keystone timed out for some reason | 21:28 |
*** stevemar has quit IRC | 21:28 | |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Allow passing auth plugin as a parameter https://review.openstack.org/83673 | 21:29 |
openstackgerrit | Marek Denis proposed a change to openstack/python-keystoneclient: Add CRUD operations for Identity Providers. https://review.openstack.org/83337 | 21:43 |
*** david_lyle_ has joined #openstack-keystone | 21:44 | |
*** david_lyle_ is now known as david-lyle | 21:44 | |
*** david-lyle is now known as david_lyle | 21:44 | |
*** leseb_ has quit IRC | 21:45 | |
*** david_lyle_ has joined #openstack-keystone | 21:46 | |
*** david-lyle_afk has quit IRC | 21:47 | |
*** elmiko is now known as elmiko_afk | 21:48 | |
*** Gu_______ has joined #openstack-keystone | 21:49 | |
*** d0ugal has quit IRC | 21:50 | |
*** d0ugal has joined #openstack-keystone | 21:50 | |
*** david_lyle has quit IRC | 21:50 | |
derek_c | running the command used to start keystone manually results in the following log: http://upl.io/l65by6 | 21:51 |
derek_c | 2014-04-08 21:49:56,478 CRITICAL log logging_excepthook cannot import name exception | 21:51 |
derek_c | anyone has any clue what problem this might be? | 21:51 |
*** marcoemorais has quit IRC | 22:01 | |
*** marcoemorais has joined #openstack-keystone | 22:01 | |
*** marcoemorais has quit IRC | 22:03 | |
*** marcoemorais has joined #openstack-keystone | 22:03 | |
*** gokrokve_ has joined #openstack-keystone | 22:04 | |
*** marcoemorais has quit IRC | 22:06 | |
*** marcoemorais has joined #openstack-keystone | 22:06 | |
dolphm | derek_c: the did not start could be caused by a port conflict on 35357 https://bugs.launchpad.net/devstack/+bug/1253482 | 22:07 |
uvirtbot | Launchpad bug 1253482 in devstack "Keystone's IANA-assigned default port in linux local ephemeral port range" [Undecided,In progress] | 22:07 |
*** dtroyer has quit IRC | 22:07 | |
openstackgerrit | Priti Desai proposed a change to openstack/keystone: Adding one more check on project_id https://review.openstack.org/85199 | 22:07 |
dolphm | derek_c: i have no idea what the except hook one would be caused by - that's new to me | 22:07 |
*** gokrokve has quit IRC | 22:07 | |
dolphm | jamielennox: ayoung: subscribed you both to https://bugs.launchpad.net/cinder/+bug/1285833 | 22:08 |
uvirtbot | Launchpad 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-keystone | 22:09 | |
ayoung | dolphm, yeah, I've been trying to think what we did to cause that | 22:09 |
jamielennox | dolphm: your patch didnt fix it then? | 22:09 |
*** lbragstad has quit IRC | 22:10 | |
ayoung | jamielennox, I think we fixed and rebroke that | 22:10 |
*** dtroyer has joined #openstack-keystone | 22:10 | |
jamielennox | maybe we need to extract it out to an object and put explicit locks around the fetching? | 22:12 |
ayoung | jamielennox, we could fetch the certificates upon initial startup | 22:12 |
ayoung | jamielennox, there are two reasons I wasn't recommending do that when I first wrote it: | 22:13 |
*** andreaf has joined #openstack-keystone | 22:13 | |
*** dstanek has quit IRC | 22:13 | |
ayoung | 1. order of bringing up the servcies | 22:13 |
ayoung | 2. PKI tokens were not default | 22:14 |
ayoung | 2 has gone away, and 1 is not an issue in devstack | 22:14 |
*** marcoemorais has quit IRC | 22:16 | |
*** marcoemorais has joined #openstack-keystone | 22:17 | |
jamielennox | marekd: mind if i push an update fixing the positional stuff? | 22:19 |
jamielennox | ad the getid() | 22:19 |
marekd | jamielennox: go ahead. | 22:19 |
openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Add CRUD operations for Identity Providers. https://review.openstack.org/83337 | 22:30 |
*** marcoemorais has quit IRC | 22:32 | |
*** marcoemorais has joined #openstack-keystone | 22:32 | |
*** d0ugal has quit IRC | 22:32 | |
jamielennox | marekd: ^^ | 22:34 |
marekd | jamielennox: yep, saw it, thanks. | 22:34 |
marekd | jamielennox: i will apply similar changes to rules and protocols, tomorrow morning. | 22:37 |
*** marekd is now known as marekd|away | 22:37 | |
*** gokrokve_ has quit IRC | 22:38 | |
*** nkinder has quit IRC | 22:40 | |
*** gokrokve has joined #openstack-keystone | 22:43 | |
*** browne has quit IRC | 22:43 | |
*** andreaf has quit IRC | 22:46 | |
*** andreaf has joined #openstack-keystone | 22:47 | |
*** browne has joined #openstack-keystone | 22:47 | |
*** d0ugal has joined #openstack-keystone | 22:47 | |
*** d0ugal has quit IRC | 22:47 | |
*** d0ugal has joined #openstack-keystone | 22:47 | |
*** henrynash has quit IRC | 22:49 | |
*** dims has quit IRC | 22:49 | |
*** diegows has quit IRC | 22:53 | |
*** Gu_______ has quit IRC | 22:54 | |
*** david_lyle_ has quit IRC | 22:55 | |
openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Convert auth_token to use session https://review.openstack.org/74908 | 22:56 |
*** Guest___ has joined #openstack-keystone | 22:56 | |
*** Guest___ has quit IRC | 22:59 | |
openstackgerrit | Priti Desai proposed a change to openstack/keystone: Adding more descriptive error message https://review.openstack.org/86187 | 23:08 |
morganfainberg | dolphm, http://pasteraw.com/h23zhdanw3pg67gfks2av5pqg6ry96m mysql schema diff | 23:09 |
derek_c | dolphm: thanks for looking into it. doesn't look like I have other stuff running on 35357 though | 23:09 |
morganfainberg | dolphm, looks like i need to insert the _member_ role as well, appears to be missing. *doh* | 23:10 |
derek_c | a bit of googling resulting in this: http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2013-09-23.log | 23:11 |
derek_c | could that be a sqlalchemy error? | 23:11 |
dolphm | morganfainberg: _member_ is inserted at runtime as needed | 23:25 |
morganfainberg | dolphm ok | 23:25 |
dolphm | morganfainberg: repository_path text vs medium_text is weird | 23:26 |
morganfainberg | that is something we don't control | 23:26 |
dolphm | morganfainberg: yeah | 23:27 |
morganfainberg | not sure why sqla-migrate is doing that differently | 23:27 |
dolphm | morganfainberg: that diff looks like a +2 to me | 23:27 |
morganfainberg | let me finish the pgsql first though | 23:27 |
morganfainberg | want to make sure it looks good on that front too | 23:27 |
dolphm | morganfainberg: who was worried about the index names, and why? | 23:27 |
morganfainberg | though pg is a bit more work since i don't know it as well :P | 23:27 |
morganfainberg | i am worried about index names personally | 23:27 |
morganfainberg | i want to make sure no one has issues with being explicit on them | 23:28 |
dolphm | morganfainberg: can't we use sqlalchemy to manipulate them without knowing the name? (/me runs off to read docs) | 23:28 |
morganfainberg | and if we like this naming convention, i'll propose a migration to make current deployments | 23:28 |
morganfainberg | we can. but matching is no fun | 23:28 |
morganfainberg | well as long as they have a name we can manipulate them | 23:28 |
morganfainberg | afaict | 23:28 |
morganfainberg | if they are anonymous we can't, but via reflection the name doesn't really matter | 23:29 |
dolphm | morganfainberg: i'd rather not use names at all, but we're past that i suppose | 23:30 |
morganfainberg | well, the automagic naming does strange things sometimes | 23:31 |
dolphm | morganfainberg: ? | 23:31 |
dolphm | morganfainberg: things we have reason to care about? | 23:31 |
morganfainberg | i've saw postgres complain about adding the constraints | 23:31 |
morganfainberg | because there was some kind of name conflict in the constraint | 23:31 |
morganfainberg | but mysql didn't complain | 23:32 |
morganfainberg | and sqlite...is sqlite | 23:32 |
morganfainberg | my gut says the safest bet is name the constraints consistently | 23:32 |
morganfainberg | then we don't get odd side effects | 23:32 |
dolphm | morganfainberg: that just sounds like the constraint already existed on that system :P | 23:32 |
morganfainberg | was a clean db and it complained | 23:32 |
morganfainberg | so, somehow it automatically added a constraint mysql didn't ? | 23:33 |
dolphm | morganfainberg: 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 |
dolphm | morganfainberg: or maybe postgres was balking at the duplicate logical constraint, even if the name was different? | 23:36 |
morganfainberg | dolphm, yeah not sure, it was gate failing not something i could duplicate locally | 23:36 |
dolphm | i'm just making stuff up here | 23:36 |
*** nkinder has joined #openstack-keystone | 23:36 | |
morganfainberg | dolphm, http://pasteraw.com/bl8gqt1pwvvzfie84x23dikyncp8xhy | 23:39 |
morganfainberg | dolphm, pgsql diff | 23:39 |
openstackgerrit | Brant Knudson proposed a change to openstack/python-keystoneclient: Support token hash algorithm https://review.openstack.org/80398 | 23:40 |
morganfainberg | should prob get bknudson to checkout db2 (or i could try if i can install db2) | 23:41 |
*** dstanek has joined #openstack-keystone | 23:44 | |
dolphm | morganfainberg: "projects" aren't technically part of v2 ;) | 23:45 |
morganfainberg | dolphm, i can revert that if you want. | 23:45 |
morganfainberg | dolphm, easy enough. | 23:45 |
morganfainberg | dolphm, and fair point | 23:45 |
dolphm | morganfainberg: 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 gone | 23:46 |
morganfainberg | dolphm, sure. and i'm happy to keep that if needed. | 23:46 |
dolphm | morganfainberg: ALTER TABLE ONLY domain ADD CONSTRAINT domain_name_key UNIQUE (name); is missing post-squash in pg? | 23:46 |
morganfainberg | dolphm, a bit further down i see | 23: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 IRC | 23:47 | |
bknudson | dolphm: is the preferred hash a new config option? | 23:48 |
morganfainberg | it looks like there a bit more re-ordering in the pg_sql model. | 23:48 |
bknudson | otherwise we could only support sha256 or a specific algorithm. | 23:48 |
*** d0ugal has joined #openstack-keystone | 23:49 | |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Configurable token hash algorithm https://review.openstack.org/80401 | 23:50 |
*** joesavak has quit IRC | 23:52 | |
*** gokrokve has quit IRC | 23:52 | |
dolphm | bknudson: it could be, but if it's already sha256 i doubt many people would change it | 23:53 |
dolphm | bknudson: but, sure | 23:53 |
bknudson | dolphm: ok, I'll give it a try... I'll start with sha256 and can make it configurable later. | 23:54 |
bknudson | dolphm: so tokens shouldn't have a hash_algorithm? | 23:55 |
dolphm | bknudson: i really don't think so - it's not at all relevant to the token itself | 23:55 |
bknudson | ok, that makes it easier | 23:56 |
derek_c | how do you register a contrib module? | 23:58 |
derek_c | I have a routers.py file | 23:58 |
derek_c | but how do I actually make it work? | 23:59 |
derek_c | I assume I need to somehow tell keystone I have defined a new module | 23:59 |
dolphm | derek_c: i assume you mean an API extension with it's own router? | 23:59 |
derek_c | dolphm: yes | 23:59 |
derek_c | under keystone/contrib | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!