Monday, 2014-09-29

*** openstack has joined #openstack-keystone12:40
*** alex_xu has joined #openstack-keystone12:41
*** ayoung has joined #openstack-keystone12:50
*** saipandi has joined #openstack-keystone12:52
*** saipandi has quit IRC12:55
*** saipandi has joined #openstack-keystone12:56
*** nkinder has quit IRC13:12
*** joesavak has joined #openstack-keystone13:17
openstackgerritgordon chung proposed a change to openstack/keystonemiddleware: Adding audit middleware to keystonemiddleware  https://review.openstack.org/10295813:18
*** samuelmz has joined #openstack-keystone13:21
*** alex_xu has quit IRC13:22
*** richm has joined #openstack-keystone13:26
*** andreaf is now known as andreaf_13:26
*** joesavak has quit IRC13:28
*** bdossant has quit IRC13:28
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/endpoint_policy/routers.py#n34    this is the API I call to get policy for a given endpoint, right?13:28
Davieyayoung: Can you give me a hand getting the kerberos plugin to work?  I might be missunderstanding how stevedore works.13:30
ayoungDaviey, server side or client?13:31
Davieyclient13:31
ayoungDaviey, you have the server working?13:31
DavieyYes13:31
ayoungCool13:31
Davieyayoung: --os-auth-plugin $PLUGINNAME13:31
ayoungI've got a meeting/call supposed to start now,  but I'll help you until Iget dragged away13:31
DavieyI thought that was all i needed to do13:32
ayoungDaviey, hmmm....maybe13:32
DavieyGreat13:32
ayoungDaviey, lets start with Python code13:32
Davieypython-keystoneclient-kerberos is in my pythonpath13:32
DavieyOK13:32
*** gokrokve has joined #openstack-keystone13:32
ayoungI wasn't using stevedore, though,  sooo13:32
ayoungDaviey, http://paste.openstack.org/show/116709/13:34
ayoungwhich should basically be the code in the scripts directory13:34
DavieyOkay, let me try that13:34
ayoungDaviey, hmmm, meant to leave that code in the commit.  I might make that a follow up commit.13:35
*** bknudson has joined #openstack-keystone13:35
ayoungDaviey, wanna know a secret?13:36
ayoungI don't understand Stevedor myself13:36
*** gokrokve has quit IRC13:36
Davieyayoung: hah :)13:38
Davieyayoung: So, I am seeing the sort of issue i'd expect..13:38
DavieyFailing to import keystoneclient.contrib.auth.v3 import kerberos13:38
DavieyAre you putting the plugin directly in keystoneclient contrib/ ?13:38
ayoungDaviey, er...let me see, that might be older code13:40
ayoungDaviey, sorry, that was pre-split code13:41
ayoungedit the import to be13:41
ayoungfrom import keystoneclient_kerberos import kerberos13:41
Davieyright13:42
gordcDaviey: we use stevedore quite extensively in ceilometer if you want examples.13:42
*** sigmavirus24 has joined #openstack-keystone13:43
ayounggordc, no, I want someone to hold my hand and show me how I should be doing it in the kerberos plugin13:44
ayounggordc, and that way someone else reviews it, too  :)13:44
Davieygordc / ayoung: Well the thing that is confusing me, is that i expected it to provide runtime plugin infra.. right?13:44
ayounghttps://review.openstack.org/#/c/123614/13:44
gordcayoung: lol you on your own then. enjoy your lonely walk13:44
DavieyBut what i am currently seeing is a custom glue client?13:44
ayoungDaviey, baby steps13:44
Davieyayoung: That is fair, i just assumed i was doing it wrong :)13:45
ayoungDaviey, but I is entirely likely I messed up the Stevedore setup13:45
ayoungDaviey, better to assume I am just faking it13:45
Daviey:)13:45
ayoungyou'll have better odds than at the Roulette table, that is for certain13:45
DavieyThe House always wins.13:46
ayoungDaviey, I think I might have dropped the entry points registration when I merged the code with the new repo project structure13:46
*** radez_g0n3 is now known as radez13:46
DavieyAh13:46
ayoungthey were in setup.cfg13:46
ayoung[entry_points]13:47
ayoungkeystoneclient.auth.plugin =13:47
gordcat a highlevel, add an entry_point to a specific namespace13:47
gordchttps://github.com/openstack/ceilometer/blob/master/setup.cfg#L231-L23813:47
ayoungand then we need the updated path13:47
ayoungDaviey, I don't think we ever had them set up right13:48
gordcand then load driver when needed: https://github.com/openstack/ceilometer/blob/master/ceilometer/publisher/__init__.py#L27-L3513:48
ayounggordc, lets assume I already have keystoneclient.auth.plugin =  defeinid from the core keystone client13:49
ayounghow do I add the kerberos plugin to it?13:49
ayoungif I do13:49
ayoungkeystoneclient.auth.plugin = [newline] kerberos =  keystoneclient-kerberos.kerberos13:49
ayoungwill that append, or overwrite the old dictionary?13:50
gordcayoung: you want to load a driver defined in another library?13:50
ayounggordc, we have the stevedore infrastructure  in Keystone client13:50
morganfainbergdolphm, https://bugs.launchpad.net/keystone/+bug/1375139 is the only bug i can see as potentially a blocker.13:50
uvirtbotLaunchpad bug 1375139 in keystone "LDAP, non ascii characters in CN field couse error while switching projects" [Undecided,New]13:50
ayounggordc, yes13:50
morganfainbergdolphm, of the four that are "new" state.13:51
ayounggordc, we want to be able to add additional plugins from third party libraries13:51
morganfainbergdolphm, it also clearly shows me we need to get to a "real" ldap test so we can definitely rule some of these out/catch them.13:52
*** joesavak has joined #openstack-keystone13:53
*** Dafna has joined #openstack-keystone13:53
gordcayoung: i assume you'd need to do something similar.13:53
morganfainbergdolphm, also, i put a +1 on https://review.openstack.org/#/c/124692/ consider that a +2 if all bugs look in order.13:54
dolphmmorganfainberg: ++13:54
gordcayoung: we technically load in drivers from oslo.messaging in ceilometer: https://github.com/openstack/ceilometer/blob/master/setup.cfg#L290-L29513:54
ayounggordc, in the same namespace?13:54
ayounggordc, the namespace is oslo.messaging.notify.drivers13:54
ayoungbut you don't add any drivers to that13:54
morganfainbergdolphm, only a +1 so no one else feels the need to approve too quickly (not that I think they would, but it's early, pre-coffee, you know)13:55
dolphmmorganfainberg: also, congratulations, sir!13:56
morganfainbergdolphm, hehe thanks. time for you to get a break from some of the craziness huh? :)13:56
dolphmmorganfainberg: https://bugs.launchpad.net/keystone/+bug/1363047 ?13:57
uvirtbotLaunchpad bug 1363047 in keystone "test_sql_upgrade and live_test not working for non-sqllite DBs" [High,In progress]13:57
ayoungmorganfainberg, dolphm does that mean it is official?13:58
*** topol has joined #openstack-keystone13:58
*** gokrokve has joined #openstack-keystone13:58
*** topol is now known as Guest2639113:58
dolphmayoung: pretty much! technically we have a lame duck period where i finish juno, and morgan is free to start on kilo - but finger is on the button to open kilo already :)13:58
*** Guest26391 has quit IRC13:59
ayoungdolphm, is your day job changing?13:59
dolphmayoung: PTL has been my day job, so i suppose yes :)13:59
morganfainbergdolphm, that one we need to fix, but it like is something we'll want to backport to juno. It requires knowing how to tear down the schema. I have two ideas on how to fix it, either drop tables (programatically) or redo the upgrade tests to not need a fullt downgrade (my preference)14:00
dolphmayoung: i'll still try to help out in the same manner though14:00
gordcayoung: hmm... do you have the patch/code where you're actually using stevedore? i'm not quite sure what you mean.14:00
ayounggordc, nope, not yet.14:00
*** nkinder has joined #openstack-keystone14:00
ayoungDaviey was the one who made me realize I had not yet supported it in the Kerberos plugin14:00
gordcayoung: ah i see... i'll try to take a look again later. got to run to a meeting14:01
ayoungNP14:01
ayoungthanks gordc14:01
morganfainbergdolphm, i think nova has the "right" approach for it, where you do each migrationa dn look for a pre/post migration check script instead of recreate, check, recreate. it's a large test restructure though. if we want to get that in we can try but not sure how long it'll take.14:02
dolphmmorganfainberg: and the dev that wrote that for nova wrote it *twice* for keystone :(14:02
dolphmmorganfainberg: we never merged it, mostly because it was a huge set of giant patches, and timing was poor for those kind of reviews14:02
morganfainbergayoung, I'm *hoping* we get to keep dolphm doing lots of stuff, but freeing him up from some of the daily PTL tasks.14:02
morganfainbergdolphm, i think we can probably land it K1 here and have it ready for Juno-stable right away, which *should* be sufficient for most cases.14:03
morganfainbergdolphm, and K1 is kind of the time for that type of stuff.14:03
ayoungmorganfainberg, he needs to break the "I'm free, time to disappear"  tradition of former Keystone PTLs, but he's been pretty good at breaking tradition so far14:03
dolphmmorganfainberg: yeah, this was H3, i think14:03
dolphmayoung: ++14:04
morganfainbergayoung, ++14:04
ayoungthere was some talk of replacing SQLite with MySQL  running on a memory based backing store14:04
*** vhoward has joined #openstack-keystone14:06
*** lbragstad has joined #openstack-keystone14:06
morganfainbergayoung, i would like SQLite to go away as a valid target14:06
ayoungmorganfainberg, yeah, that was part of the rational14:06
ayounge14:07
ayoungmorganfainberg, I think there is a way to run MySQL like that now...maybe a different backend, though14:07
ayoung"MEMORY tables are stored differently than InnoDB,"14:08
morganfainbergayoung, there are a few ways to do it with MySQL, but not sure how well they'd work for keystone.  though with no tokens in the DB, they might be a good target in general (NDB can be cool).14:08
morganfainbergayoung, and could be very fast compared to innodb.14:08
ayoungmorganfainberg, only if it doesn't add yet another variable, like the isam/innodb split14:09
morganfainbergmight need a lot of schema massaging though14:09
ayoungnot worth it14:09
ayoungmorganfainberg, I think I would rather create a shared memory file system and run the existing Mysql code on top of that14:09
morganfainbergthe schema massaging to get there is (in my experience) generall good practice anyway14:09
morganfainbergbut that work in itself might be enough14:10
ayoungs/shared memory/in memory/14:10
dolphmayoung: yeah, there was some odd behavior of mysql that made using MEMORY tables almost as undesirable as sqlite itself14:10
morganfainbergayoung, though if we fix our tests to not require a full clean schema everytime a lot of the benefit of sqlite goes away14:11
dolphmwonder if postgres or someone else does it right14:11
ayoungdolphm, probably not.  postgres et alles is more concerned with actually doing database stuff right14:11
ayoungmore so than MySQL even14:11
ayoungbut...let me look14:11
dolphmmorganfainberg: given that https://bugs.launchpad.net/keystone/+bug/1375139 was in icehouse, and it feels like Medium impact to me, i don't think it should block rc114:12
uvirtbotLaunchpad bug 1375139 in keystone "LDAP, non ascii characters in CN field couse error while switching projects" [Undecided,New]14:12
dolphmmorganfainberg: i also went through our last 20 bugs or so, and nothing stood out14:12
morganfainbergdolphm, ++ works for me, i'm testing it now14:12
dolphmmorganfainberg: testing what?14:13
morganfainbergdolphm, the LDAP one.14:13
dolphmmorganfainberg: oh, you have a fix already?14:13
morganfainbergdolphm, but i agree that it is medium + non blocker14:13
morganfainbergdolphm, nah, confirming when/if/how it breaks14:13
morganfainbergin juno14:13
dolphmmorganfainberg: ah14:13
morganfainbergdolphm, doesn't change my agreement with medium + non-blocker14:14
dolphmmorganfainberg: well i was going to say, if you have a quick fix, we can get it in14:14
ayoungdolphm, morganfainberg, but http://stackoverflow.com/questions/9407442/optimise-postgresql-for-fast-testing looks like good reading14:15
dolphmayoung: ooo14:15
ayoungdolphm, yeah.14:15
ayounghttp://www.postgresql.org/docs/current/static/non-durability.html14:15
*** doug-fish has joined #openstack-keystone14:16
ayoungdolphm, so on my system, postgres data gets written to:14:16
morganfainbergayoung, dolphm, i'm also *trying* to convince my buddy who is DB engineer extrodinaire to join OpenStack and help out (initially helping us get our schemas "better"14:16
ayoung++14:16
morganfainbergand by join openstack.. i do mean find a place on monty's team :)14:16
ayoungmorganfainberg, I'm a Postgresql fan.  Have been for a long while14:17
dolphmmorganfainberg: :)14:17
dolphmi wish i was a db engineer extrodinaire14:18
morganfainbergdolphm, so do i!14:18
dolphmmorganfainberg: db's are fun!14:18
ayoungdolphm, its a thankless job14:18
ayoungyeah, but DB mgmt jobs are not fun14:18
dolphmayoung: i know, but i'd get a ton of satisfaction out of it, regardless14:18
morganfainbergugh.14:19
morganfainberghaha wow, braaaaavo... http://paste.openstack.org/show/116722/14:19
morganfainberghttps://github.com/openstack-dev/devstack/blob/master/lib/ldap#L115-L119 yeah... thats ... special14:20
ayoungmorganfainberg, did topol write that?14:20
morganfainbergwe *really* don't ever test that do we.14:20
*** foo_topol has joined #openstack-keystone14:20
ayoungmorganfainberg, is that devstacl?14:20
morganfainbergyes that is *actually* in devstack14:20
ayoungmorganfainberg, foo_topol wrote that , at my instigation14:20
ayounghe got the LDAP code into devstack, but, no, we don't run it on install14:21
morganfainbergbeen broken since https://github.com/openstack-dev/devstack/commit/b9e25135c51ee29edbdf48d41e1cb637188cc35814:21
morganfainbergwow. such broken14:21
morganfainbergso amaze14:21
ayoungmorganfainberg, which was it broken on, Ubuntu?14:21
morganfainbergor longer.14:21
morganfainbergyeah ubuntu14:21
morganfainbergwe just never instlal ldap in ubuntu14:21
ayoungDoes that mean everyone is running Fedora that actually cares about LDAP?14:21
morganfainbergit's not possible14:21
*** dolphm changes topic to "Currently gating to open development for Kilo https://review.openstack.org/#/c/124692/ | Release blockers https://gist.github.com/dolph/651c6a1748f69637abd0"14:22
*** stevemar has joined #openstack-keystone14:22
morganfainbergayoung, for devstack14:22
dolphmmorganfainberg: ^14:22
morganfainbergdolphm, woot!14:22
morganfainbergdolphm, so i put up the *wrong* link for the session proposals *doh*, will migrate stuff over to the correct one from ttx14:22
morganfainbergetherpad.14:22
ayoungmorganfainberg, dolphm has left you some mighty big shoes to fill.  I'd recommend wearing 2 sets of socks.14:22
morganfainbergayoung, i bought 15 pairs extra, was figuring I'd wear all 15 to start and see how many i need tot ake off before they fit.14:23
ayoungNice14:23
ayoungGood think wool ski socks, I'm sure14:23
*** zzzeek has joined #openstack-keystone14:24
ayoungOK,  postgresql puts its data in   /var/lib/pgsql/data14:24
ayoungOn a new install I have nothing there14:24
*** foo_topol is now known as topol_14:24
ayoungI'll mess around with the Postgresql tests and see if I can get it to work in memory14:24
ayoungand non-durable14:24
morganfainbergayoung, cool14:25
morganfainbergayoung, whatever we plan on doing, we'll do it for our conversion to the functional tests if possible (that is to say, for ditching SqlIte)14:25
ayoungmorganfainberg, I think we might be able to start the postgresql one this way14:25
ayoungand then later switch the unit tests to do the same thing14:25
*** topol_ is now known as topol14:26
topolomg I had to work so hard to be known as topol14:26
*** dstanek has joined #openstack-keystone14:26
morganfainbergayoung, well we don't test *anything* against postgres except in tempest right now14:26
doug-fishHi keystone friends.14:27
doug-fishI'm harassing/helping sambetts in Horizon.  He'd like to make some of our user settings actually persist on a per user basis.14:27
doug-fishI'm afraid his current approach might cause problems https://review.openstack.org/#/c/118334/14:27
doug-fishDoes keystone have any support for unstructured metadata on the user that could store this sort of thing? something like glace image properties except for users?14:27
lbragstaddoug-fish: some of the Keystone resources allow for additional attributes to be passed on creation14:28
*** sigmavirus24 has left #openstack-keystone14:28
ayounglbragstad, don't encourage that!14:29
lbragstadand if you're using an SQL backend driver for identity, those additional attributes would be stored in an 'extras' column14:29
doug-fishlbragstad: cool!  I couldn't figure out which API14:29
ayoungdoug-fish, no...its impossible14:29
ayoungdon't even ask!14:29
lbragstaddoug-fish: but forget I said that14:29
doug-fishlol14:29
ayoungheh14:29
lbragstadwe want that to go away14:29
doug-fishwell if its a bad idea I don't want to14:29
ayoungdoug-fish, seriously, Horizon<->keystone is a tricky relationship14:29
doug-fishAre you suggesting I shouldn't call you "friends"?14:30
ayoungdoug-fish, I would not actually assume that Horizon has write access to the user data14:30
doug-fishah sure14:30
ayoungif it is in LDAP, which is the norm, you will not14:30
doug-fishthat's reasonable14:30
doug-fishso using keystone to store this really isn't viable... at least not if its going to be updated from Horizon.14:30
ayoungdoug-fish, it puts Horizon in a tricky position14:30
ayoungyou have no guaranteed datastore per users14:31
*** aix has quit IRC14:31
ayoungcookies are your best bet, but those are not shared across users14:31
ayounger devices14:31
morganfainbergdoug-fish, correct, it is more or less not guaranteed nor guaranteed to be available for write.14:31
doug-fishayoung: right,a nd they are shared across users in shared computer scenarios14:31
morganfainbergayoung, doug-fish, sadly this is why most "web apps" use DBs for user prefs.14:31
ayoungdoug-fish, if Horizon wants this data, Horizon needs a Database14:31
ayoungyou really can't offload that requirement any more14:32
doug-fishawww14:32
ayoungI would not say that you should have a database, though14:32
doug-fishunderstood14:32
ayoungbut, maybe we could work out something with swift?14:32
doug-fishoh that's an interesting idea14:32
ayoungdoug-fish, understand, I want Horizon to become completely stateless anyway14:32
morganfainbergooh swift is a cool idea.14:32
ayoungnothing more than static HTML and javascript, so fetching preferences from a web url makes sense14:33
*** rwsu has joined #openstack-keystone14:33
ayoungand then the user would need to be able to store their preferences themself anyway14:33
ayoungdoug-fish, lets assume all preferences could be of the form of css.14:33
*** k4n0 has quit IRC14:34
morganfainbergdoug-fish, ayoung, i think it makes the most sense to just have a *way* (generic) in horizon to store user pref(s). Could be cookies, swift, db, etc. let the deployer pick the mechanism.14:34
ayoungThen  in horizon's startup, you include the users custom css14:34
ayoungmorganfainberg, needs to be Web accessable14:34
*** sambetts has joined #openstack-keystone14:34
ayoungDB is a deployment option, but not end user14:34
doug-fishright - I think we are talking about a pluggable user prefs backend14:35
*** gokrokve_ has joined #openstack-keystone14:35
ayoungdoug-fish, I'd start by prototyping something with swift14:35
doug-fishayoung:  that's an interesting approach; it seems workable (custom js I think though, not css)14:35
morganfainbergayoung, doug-fish, correct i'm saying make a pluggable backend that does $stuff$ in a generic way (i think django has a framework for that already)14:35
ayoungmorganfainberg, NO...lets not do anything more that is Django specific14:36
doug-fishayoung:  I'm getting the impression you aren't a django fan?14:36
ayoungdoug-fish, I like Django well enough14:36
ayoungI am not a server-side-scripting fan14:36
*** gokrokve_ has quit IRC14:37
morganfainbergayoung, also weigh the benefit of not re-implementing.14:37
*** gokrokve_ has joined #openstack-keystone14:37
ayoungdoug-fish, does it need to be full javascript?14:37
doug-fishayoung:morganfainberg:  I appreciate your thoughts on this.  Certainly the swift approach is something to consider.14:37
ayoungCSS is a muchj safer option14:37
*** afazekas has quit IRC14:37
ayoungdoug-fish, the stateless Horizon is coming14:37
doug-fishfull javascript?  no. I was actually thinking JSON.14:37
ayoungdoug-fish, shoot for CSS14:37
ayoungah, but you want stuff like14:38
ayoungdefault project?14:38
*** topol is now known as topol_14:38
doug-fishmaybe one day:  right now preferences are only language, rows per page and time zone.14:38
ayoungOpenStack specific data, not just visual elements14:38
*** topol_ is now known as topol14:38
doug-fishright14:38
*** gokrokve has quit IRC14:38
ayoungdoug-fish, language should come from the browser14:38
ayoungrows per page...ok14:38
ayoungtime zone comes from the browser14:39
*** saipandi has quit IRC14:39
*** john-davidge has joined #openstack-keystone14:39
doug-fishayoung:   rather the timezone and langauge _could_ come from the browser.14:39
doug-fishbut they don't today14:39
ayoungdoug-fish, as I said *should*14:40
ayoungdon't fight the standards14:40
doug-fishI overlooked that word14:40
doug-fishyep14:40
*** topol has quit IRC14:40
ayoung"I fought the standards and the standards won."14:40
doug-fishThe Clash?14:40
*** topol has joined #openstack-keystone14:40
ayoungI thought is was Johnny Cash14:40
doug-fishhey you have your music and I have mine14:41
doug-fishI'm hearing the clash sing it.14:41
ayoung"Sonny Curtis of the Crickets "14:41
ayoungBut I knew Cash had to have covered that one14:41
* ayoung on youtube listening now14:41
sambettsthe user should be able to override the default language setting though, without changing their entire browser14:41
ayoungAh  Bobby Fuller version14:42
sambettsshouldn't they14:42
sambetts?14:42
doug-fishsambetts:  why?14:42
ayoungsambetts, hells no!14:42
*** bradjones has joined #openstack-keystone14:43
ayoungOK,  the Clash Version is better14:43
morganfainbergsambetts, doug-fish, ayoung, the default should *absolutely* come from the browser. But it is largely valuable to allow users to select any language they want.14:44
sambettsmorganfainberg: ++14:44
morganfainbergsambetts, doug-fish, ayoung, just based on every web app / ux out there these days.14:44
john-davidgemorganfainberg: That approach sounds sensible to me14:45
ayoungmorganfainberg, if all your friends were jumping off a bridge...oh, wait, XKCD ruined that expression14:45
morganfainbergsambetts, doug-fish, ayoung, same thing with the TZ.14:45
morganfainbergi'd say even mor so TZ14:45
ayounghttp://xkcd.com/1170/14:46
morganfainbergwhy do i need to change my system timezone (if thats where the browser is getting data from) if all my work is in UTC, therefore i want horizon to show me stuff in UTC14:46
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Use openstackclient examples in configuration documentation  https://review.openstack.org/12427014:46
doug-fishmorganfainberg:  generally Horizon converts from the local TZ to UTC14:46
morganfainbergdoug-fish, sure i mean from a display perspective.14:47
morganfainbergif everything i run is specific to a timezone, let me pick the timezone.14:47
doug-fishoh okay14:47
doug-fishgot it14:47
morganfainbergboth of these are pretty far down the list of things i'd worry about implementing14:47
morganfainberggeneral user prefs (rows displayed, columns, etc) are more important14:48
ayoungmorganfainberg, and if each Datacenter is in a different timezone?14:48
ayoungand different countires, and you routinely get on an airplane and visually inspect them?14:48
ayoungYeah, lets customize the UI for that guy14:48
doug-fishwow the keystone channel is really lively!14:49
morganfainbergayoung, i'd like you to meet the strawman argument14:49
morganfainbergayoung, :)14:49
dolphmayoung: doug-fish: it's actually by Sonny Curtis of the Crickets (?!) http://en.wikipedia.org/wiki/I_Fought_the_Law14:49
ayoungmorganfainberg, I thought we burnt him in the middle of the desert?14:49
ayoungwas that a different burnable man?14:49
morganfainbergayoung, might have been14:49
ayoungdolphm, I can't believe Johnny Cash didn't cover that one14:50
doug-fishdolphm:  I'm still trying to find the Johnny Cash ramake14:50
doug-fishooh14:50
doug-fishthat's why I can't find it14:50
morganfainbergayoung, my point is we *can* support that stuff and should open the doors for that... but other ux/usability stuff is far more important first which requires generic pref store first.14:50
dolphmdoug-fish: lol i was trying to do the same14:50
morganfainbergdolphm, ayoung, you mean Green Day didn't originally make that song /s14:50
ayoungmorganfainberg, listening to the Green Day version now.  Not  bad14:51
dolphmmorganfainberg: no no, kanye invented it14:51
nkinderI was thinking of the Dead Kennedy's version14:51
ayounghttps://www.youtube.com/watch?v=YDVCMHX9r0k  I think is what I must have been thinking of14:51
sambettsyes, generic prefs store please :-)14:51
morganfainbergdolphm, ++ I KNEW IT, was he in his zone when he did it?14:51
lbragstadmorganfainberg: ++ clearly14:52
doug-fishsambetts: not sure when you joined the channel, but there was a suggestion to consider using swift to store these prefs14:52
*** andreaf has joined #openstack-keystone14:52
sambettsI hit the tail end of it, wouldn't that be dependant on the openstack supporting Swift?14:53
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Update the CLI examples to also use openstackclient  https://review.openstack.org/12409514:53
ayoungsambetts, doug-fish I was hoping for straight CSS, but JSON would work.14:53
doug-fishayoung:   I'm still struggling to see how CSS does the job14:53
morganfainbergsambetts, it's worth supporting swift as a target if it exists, you'd need something more pluggable to handle cases where swift is not a viable (valid/available) target14:53
ayoungdoug-fish, I've seen  some truely amzing things with just CSS14:54
ayoungand for custome theming, it is the right starting point14:54
doug-fishsure, no doubt its powerful, but things like TZ, language, preferred projects don't seem to be a good fit14:54
sambettsI dont think we want to make Horizon dependant on any more components, swift could be a possiblity in the future, but we need a solution that works with the bare minimum openstack14:56
sambettsswift support could be an extension of that14:57
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Add v3 openstackclient CLI examples  https://review.openstack.org/12448914:57
morganfainbergsambetts, so, make it a pluggable backend, allow for "cookies" to be one, db to be another, swift a third. let the deployers pick which one they want14:57
ayoungsambetts, then Horizon should run its own database cuz there aint' nothing guaranteed to work14:58
*** ajayaa has quit IRC14:58
ayoungsambetts, the way most people run Keystone is with Users in LDAP14:58
ayoungLDAP is read only as far as OpenStack is concerned14:58
stevemarlbragstad, why can't i add you to any reviews14:59
ayoungmorganfainberg, why not let the user pick?14:59
ayoungdon't run it through the Horizon server at all14:59
morganfainbergayoung, it's not a user choice where the prefs get stored.14:59
ayoungwhy not14:59
stevemarwhenever i add "Lance Bragstad <lbragstad@gmail.com>" gerrit says "does not identify a registered user or group"14:59
doug-fishI agree with morganfainberg on the storage14:59
ayoungdoug-fish, Horizon is going stateles14:59
morganfainbergayoung, because users are dumb :P14:59
doug-fishI don't think that's user configurable14:59
sambettsmorganfainberg: the cookie idea is whats implemented right now, but that means that every user that uses the browser gets the same prefs14:59
lbragstadstevemar: use ldbragst14:59
ayoungmorganfainberg, make it a service, register it as an endpoint15:00
lbragstadGerrit has my lbragstad account messed up15:00
stevemarlbragstad, it worked - what magick is that15:00
morganfainbergayoung, more tot he point the user usually doesn't know enough about the system to make a smart choice about that15:00
lbragstadstevemar: I'm not sure, it's weird...15:00
doug-fishayoung:  you've mentioned that a couple of times... is there a prototype of what you have in mind with that statement?15:00
ayoungdoug-fish, Horizon going stateless?15:00
morganfainbergayoung, the deployer will know if swift is a good option, or a DB is available, or if *only* cookies are15:00
doug-fish"stateless" is a pretty strong word.  A browser page has a state.15:00
ayoungdoug-fish, let me see ...15:01
morganfainbergdoug-fish, sambetts, you can have per-user cookie data but it gets wonky iirc.15:01
doug-fishmorganfainberg: yeah that's what sambetts did initially15:01
ayoungdoug-fish, hmmmm I thought I had written it up.  I do have an ugly-as-sin prototype15:01
*** andreaf has quit IRC15:01
ayoungdoug-fish, ah, its on the mailing list...one second15:02
*** Daviey has quit IRC15:02
sambettsthis is the fix I proposed -> https://review.openstack.org/#/c/118334/15:02
morganfainbergayoung, the other concern about "user picking" becomes XSS issues, if you load data from an untrusted source (argument against non-signed cookies) it's bad.15:02
ayoungCORS15:02
morganfainbergayoung, i think my only point is you're assuming the user has a place to store these prefs15:03
morganfainbergayoung, and that it would be considered secure from a CORS standpoint15:03
ayoungmorganfainberg, make it a service and get it from the service catalog15:03
ayoungmorganfainberg, ugh...I cleanup up my mail and now I can't find it15:04
ayounghttp://openstack.10931.n7.nabble.com/Keystone-Horizon-CORS-and-Federation-td52693.html15:04
morganfainbergayoung, i think the pluggable generic store would allow a deployer to set that then. it's still a deployer selection in this case.15:04
ayoungok, that was one part15:04
morganfainbergthe deployer needs to provide that service then, right?15:05
morganfainbergand add it to the catalog15:05
ayoungmorganfainberg, yes15:06
*** Daviey has joined #openstack-keystone15:06
ayoungmorganfainberg, It would probably be like Glance:15:06
morganfainbergok, so i don't argue that its a good approach to have said service.15:06
ayoungcould be backed to Swift, but doesn't have to be15:07
morganfainbergayoung, but if a deployer wanted something that wrote to a DB, would that be an awful mode (no it shouldn't be the default) to support?15:07
ayoungmorganfainberg, nope,  would not be bad at all15:08
ayoungjust like Glance can store to multiple backends15:08
morganfainbergi think it still comes down to providing a framework to do this and let the deployer pick the way they want users to store the prefs. - we obviously pick the winner for devstack as the default, and encourage people going that way.15:08
*** ukalifon has quit IRC15:08
morganfainbergand it might be the default is "load JSON from location and use that"15:09
ayoungmorganfainberg, works for me15:10
doug-fishsambetts: are you up for this?   It seems a more significant effort that just creating a user-per-cookie.15:11
ayoungdoug-fish, it bascially is another way of saying:15:11
doug-fishayoung: morganfainberg: lbragstad:  I do appreciate you guys exploring/sharing these ideas.15:11
ayoungHorizon needs its own damn database15:12
doug-fishlol15:12
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Change saml2.ADFSUnscopedToken method signature.  https://review.openstack.org/12476715:12
doug-fishayoung:  I'm not sure we ready for that kind of responsibility yet.15:12
doug-fish:-)15:12
ayoungdoug-fish, no,  you aren't15:12
ayoungthen again, none of us are15:12
sambettsdoug-fish: So we're going with the write a file approach? Maybe a Sqlite backend then??15:13
ayoungfake it until you make it15:13
ayoungsambetts, start with dogpile15:13
ayounguse morganfainberg 's approach to the KVS backend in Keystone15:13
doug-fishsambetts:  I think the solution has to be configurable15:13
doug-fishand a chief option is keep it the way it is (one cookie per browser)15:13
ayoungmorganfainberg, might be time to think about making your Dogpile code an Oslo utility15:13
morganfainbergayoung, it's on the list of things to do this cycle actually15:14
morganfainbergayoung, had a spec for last cycle that ended up pushing too late to get accepted15:14
morganfainbergayoung, the plan is to replace memorycache in oslo + add memoization decorators15:14
ayoungmorganfainberg, http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/cache  right?15:14
morganfainbergayoung, that isn't useful in it's current state, but yes that is where it will go15:15
ayoungmorganfainberg, so a related but different problem is caching data from Keystone  in the endpoints.  middleware.auth_token and also....policy15:15
morganfainberghttps://review.openstack.org/#/c/97155/15:15
*** andreaf has joined #openstack-keystone15:15
morganfainbergayoung, i'll be resubmitting in a day or so for kilo acceptance15:16
ayoungpolicy keeps coming up in this context15:16
morganfainbergayoung, and a lot of it is scraping keystone code + cleanup and making it oslo.15:16
ayoung++15:16
morganfainbergayoung, and then auth_token etc becomes able to use it as we see fit15:16
ayoungmorganfainberg, the one issue is that openssl will need access to the data from a file;  I don't think we can abstract that away yet15:17
morganfainbergayoung, i also have some folks who've said they are *very* interested in making that happen.15:17
ayoungso the certs etc...15:17
ayoungpromises promises...15:17
morganfainbergayoung, metacloud^wmetacisco? has implemented largely what i did for keystone in the nova metadata service15:18
morganfainbergthey'd love to have it as a library for both internal / non-keystone stuff15:18
lbragstaddoug-fish: no problem15:23
*** zeus has joined #openstack-keystone15:24
morganfainbergdoug-fish, sambetts, happy to help15:24
zeushi all15:26
dolphmpotentially less than 10 minutes from kilo...15:27
*** cjellick has joined #openstack-keystone15:27
sambettsmorganfainberg: Thanks so much!15:28
*** Guest73730 is now known as mgagne15:29
*** mgagne has quit IRC15:29
*** mgagne has joined #openstack-keystone15:29
morganfainbergayoung, https://review.openstack.org/#/c/124776/15:29
ayoungmorganfainberg, really should keep the original change id.  I know you were told to abandon it, but all the history is gone15:29
morganfainbergayoung, it was explicitly abandoned15:30
ayoungyep,  I know15:30
morganfainbergayoung, so i'm going with that15:30
ayounglink to the abandoned one, so people can see this is a well beaten up concept15:30
morganfainbergwill do.15:30
ayoungmorganfainberg, http://adam.younglogic.com/2014/09/multiple-signers/15:31
ayoungdolphm  ^^15:32
ayoungmorganfainberg, dolphm read it when you get a chance15:32
morganfainbergayoung, oh a new take on the multiple signers.15:32
ayoungmorganfainberg, yeah15:32
morganfainbergayoung, yeah will try and read it today15:32
ayoungmorganfainberg, the biggest realization was that one Keystone is still considered authoritative15:33
morganfainbergdolphm, annnd gate reset! 1h and counting15:33
ayoungok...back to stevedore15:33
morganfainbergdolphm, ~1h15:33
*** thedodd has joined #openstack-keystone15:34
ayoungmorganfainberg, so, would you be infavor/opposed to Keystone-team managed repos for maintain RPM spec file and Debian Package data?15:35
dolphmayoung: the TC is opposed to that -- we tried once15:36
dolphmayoung: packagers weren't happy15:36
morganfainbergayoung, i'd rather not have to manage those directly. I also think that would be a question for the packagers (e.g. zigo, and whoever is managing the RPM side). I think it's not the right place for it.15:36
ayoungdolphm, maybe we should float it again15:36
*** shakamunyi has joined #openstack-keystone15:36
ayoungmorganfainberg, nah,  packagers are dumb15:36
ayoungmorganfainberg, heh15:36
zigomorganfainberg: ayoung: May I help?15:36
*** radez is now known as radez_g0n315:36
ayoungactually, packagers are wikked smart15:36
zigoayoung: Thanks !15:36
ayoungthey just have to answer to different masters15:37
morganfainbergif the packagers legitimately liked it / wanted it, it would be worth floating15:37
*** jorge_munoz has joined #openstack-keystone15:37
morganfainbergif they would rather not, i don't see how providing it will help anyone15:37
ayounghaving a standard packaging repo  would make the packaging process more visible15:37
morganfainbergsince the authoriatative packagers wont use it anyway15:37
ayoungI'd almost want to put both the RPM and the Debian packaging into the same repo, so peope would be able to view them side  by side15:37
*** gokrokve has joined #openstack-keystone15:38
zigoayoung: We have different policies, in Debian, upstream should *not* include a debian folder. In RedHat stuff, it's fine (and desirable) to have the .spec file upstreamed.15:38
*** Guest68643 is now known as redrobot15:38
ayoungzigo, not in keystone repo15:39
ayoungzigo, have a new repo:15:39
ayoungkeystone-packages15:39
ayoungor keystonepackaging15:39
*** hockeynut has quit IRC15:39
*** cjellick has quit IRC15:40
morganfainbergzigo, i can tell you it's def. not going into keystone's tree directly ;)15:40
*** cjellick_ has joined #openstack-keystone15:40
morganfainbergzigo, in either case.15:40
zigoayoung: Everthing that I do is easilly accessible using Git. I'd be happy (and asked already) to have this happen directly within the OpenStack infra.15:40
ayoungzigo, https://bugzilla.redhat.com/show_bug.cgi?id=114708415:40
uvirtbotayoung: Error: Could not parse XML returned by bugzilla.redhat.com: HTTP Error 404: Not Found15:40
*** hockeynut has joined #openstack-keystone15:40
zigoThough currently it's only hosted on alioth.debian.org.15:40
morganfainberguvirtbot, nice try, maybe next time.15:40
uvirtbotmorganfainberg: Error: "nice" is not a valid command.15:40
ayoungzigo, let me take a look at what you are doing15:41
ayoungzigo, link to your repo?15:41
zigoayoung: https://qa.debian.org/developer.php?login=openstack-devel@lists.alioth.debian.org15:41
zigoThat's the list of packages I maintain.15:41
zigoPlus some more within the Debian Python Module Team (DPMT).15:41
*** Sharath_ has joined #openstack-keystone15:42
zigoEverything is like: git://anonscm.debian.org/openstack/<project>.git15:42
ayoungPTS? Is that like a TPS report?15:42
*** lufix has quit IRC15:42
zigoSo for keystone, that'd be: git://anonscm.debian.org/openstack/keystone.git15:42
*** gokrokve_ has quit IRC15:42
ayoungpacakge testing summary15:42
*** gokrokve has quit IRC15:42
*** radez_g0n3 is now known as radez15:42
zigoA clone will get you the Icehouse branch currently, though there's debian/juno branches for core packages, and some in debian/experimental (for libs).15:42
Sharath_Hi , am new to openstack started with keystone understanding , am unable to get the flow , from where it will start and how it generate key , can any one tell me the flow. Thank you15:43
*** cjellick has joined #openstack-keystone15:44
ayoungzigo, lets see if we can reduce this list of custom patches  http://anonscm.debian.org/cgit/openstack/keystone.git/tree/debian/patches15:44
*** gyee has joined #openstack-keystone15:44
ayoungPretty sure we dealt with http://anonscm.debian.org/cgit/openstack/keystone.git/tree/debian/patches/fix-missing-gettextutil.py-import.patch15:44
ayoungbut maybe you need that for backports15:44
zigoThat'd be very much appreciated !15:45
ayoung http://anonscm.debian.org/cgit/openstack/keystone.git/tree/debian/patches/fixes-default-connection.patch  looks just plain evil15:45
Sharath_hi ayong , i gone through the code as per ur instructions15:45
ayoungbut only cuz it says "sqlite"15:45
ayoungSharath_, you will never be able to make my IRC client flash until you get my name right15:45
Sharath_but still i didnt get the flow ayong , can u help to find out ?15:45
dolphmSharath_: there are several authentication code paths, but you might try looking at keystone.auth.controllers.Auth:authenticate()15:45
zigoayoung: I default to sqlite because it's usefull for doing automated install/upgrades without prompting for a MySQL password.15:46
ayoungzigo, you have the requirement that, once the package is installed you have a working system, right>15:46
ayoung?15:46
zigoRight.15:46
ayoungmodifying the default conf file is not really the right way to go about that, as it is an autogenerated, document file15:47
zigoBasically, in Debian, you just do "apt-get install keystone", and there's nothing more to configure by hand.15:47
ayoungbut not a cardinal sin15:47
*** cjellick_ has quit IRC15:47
ayoungzigo, I thought Debian had a way of managing config files across updates/upgrades15:47
zigoWell, in more recent versions, I just do a sed when building the package, that works better (no need to rebase).15:47
ayoungzigo, what about the issues with PBR?15:48
zigoayoung: We do, but not when upstream decides every week, to rename and move accross sections every directive.15:48
ayoungapt and rpm both want to manage the package versions.15:48
zigoayoung: Do you mean about the export OSLO_PACKAGE_VERSION=$(VERSION)?15:48
ayoungyeah...where is that done?15:49
zigoWell, I do that in every package, since I'm using a Git based workflow.15:49
zigoThat tells PBR to use whatever I put on top of debian/changelog.15:49
Sharath_not really like that ayong ,15:50
*** ayoung is now known as ayong15:50
ayongSharath_, I give up15:50
ayongyou win15:50
Sharath_ok , thank you dolphm15:50
zigoIf I don't do that, then PBR doesn't know what version I'm using.15:50
zigoWe went through *many* iteration before having this system, and I'm very happy with it.15:50
ayongzigo, where is that done?15:51
lbragstadstevemar: what review did you add me to?15:51
zigoayong: PBR has that feature to look at OSLO_PACKAGE_VERSION env, and use that ...15:52
ayongzigo, yes, but where is it called?  assu,me I know nothing about debian package build process15:52
zigoLet me explain quickly.15:52
zigoI use Git for packaging, eg *not* the release tarballs.15:52
zigoMeaning that I don't have the egg-info, PKG-INFO, and so on.15:53
zigoBut when I do "git-buildpackage" it's not using Git anymore, it's pushing stuff into a chroot for building.15:53
zigoThen there would be no way for PBR to know the version number without the OSLO_PACKAGE_VERSION.15:53
* stevemar shrugs at lbragstad 15:56
stevemarlbragstad, this one i think https://review.openstack.org/#/c/122989/15:56
stevemarlbragstad, then this chain: https://review.openstack.org/#/c/124270/415:56
lbragstadstevemar: sweet, thanks15:57
*** thedodd has quit IRC16:00
ayongzigo, OK,  I think that is pretty much what I proposed with my RPM patches16:03
ayongzigo, is OSLO_PACKAGE_VERSION  set anywhere in your build files linked above?16:04
*** ayong is now known as ayoung16:04
zigoayong: I just put it in debian/rules, but $(VERSION) is populated thanks to what lives in /usr/share/openstack/pkgos.make (which is in openstack-pkg-tools).16:05
zigoBasically, it's a couple of dpkg-parsechangelog plus grep/sed calls to get the version number.16:06
ayoungzigo, so an env var  set in debian/rules is in effect for the whole build process?16:06
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Use openstackclient examples in configuration documentation  https://review.openstack.org/12427016:06
zigoayoung: Yes.16:06
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Update the CLI examples to also use openstackclient  https://review.openstack.org/12409516:07
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Add v3 openstackclient CLI examples  https://review.openstack.org/12448916:07
ayoungzigo, in the RPM version, we build using the released tarball, and the versions need to match16:07
ayoungso the RPM spec file has the version numbers in it,  but I don't really like it;16:07
ayoungI want it to be something an end devloper can use without having to modify the rpm spec file16:08
ayoungunfortunately, all of the projects I've seen have had to modify that file, using a template or something16:08
ayoungwhich makes sense, since the build needs to be reproducible16:08
*** thedodd has joined #openstack-keystone16:09
ayoungzigo, what if the PBR code did not assume git, but only did the rebuild of PKG-INFO  if it was inside a git repo and if a flag was left unset?16:10
zigoayoung: We went through many kinds of changes in PBR to try to make it double-guess, but it never worked out. The env var works best, and I don't want this to change again.16:11
zigoI think we had about 5 different systems ...16:11
zigoOver probably a period of more than a year.16:12
ayoungzigo, and I assume this was across all of the projects, not just Keystone16:12
zigoayoung: In PBR itself.16:12
zigo(so yes, all the projects)16:13
ayoungzigo, I guess in general I am OK with the approach, just that it seems a little strange to release the tarball with a version string in it, and then to rewrite that data16:13
openstackgerritJulien Danjou proposed a change to openstack/keystonemiddleware: Switch to oslo.utils  https://review.openstack.org/12443516:13
ayoungits not in git, so maybe it should not be in the tarball16:13
openstackgerritJulien Danjou proposed a change to openstack/keystonemiddleware: Update oslo-incubator  https://review.openstack.org/12472616:13
openstackgerritJulien Danjou proposed a change to openstack/keystonemiddleware: Switch to oslo.serialization  https://review.openstack.org/12443616:13
zigoayoung: Again, I do *not* use the release tarballs, I use the upstream git from github directly.16:13
ayoungbut then  there is no way to map from the tarball back to the git commit16:13
ayoungzigo, does the .deb contain the git hash somehow?16:14
zigoThe release tarballs are using a 20 years old compression (.gz instead of .xz), and do not have pgp signed tags ...16:14
*** rm_work is now known as rm_work|away16:14
*** marcoemorais has joined #openstack-keystone16:14
zigoayoung: It's based on a release *tag*.16:15
zigogit archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz16:15
zigoI also prefer this way because it's much much more efficient.16:15
zigoBasically, I do: edition of debian/changelog, then ./debian/rules fetch-upstream-remote, then git merge -X theirs <version>16:16
zigoThat's it ...16:16
zigoNo need to download a huge tarball, just the incremental commits.16:17
*** praneshp has joined #openstack-keystone16:17
zigoNo need to bother storing the tarballs in Git using something like pristine-tar.16:17
zigoEverything is self-contained in a single packaging branch.16:17
zigoAlso, I don't want the release artifacts like changelog (which is too big, and which the Debian FTP masters wined about), or the AUTHORS file, which gives a wrong idea of who's the copyright holder, I don't want either the egg-info files, which are anyway generated at build time.16:19
ayoungzigo, yep16:19
stevemartopol, ping test16:19
zigoBTW, didn't we suppose to have rc at this time?16:20
ayoungzigo, incipient16:20
topolthanks stevemar. and yes its me.16:20
zigoDuring the Juno summit, the plan was to have rc on the 25th of October.16:20
*** rm_work|away is now known as rm_work16:20
zigoYet, I haven't found any project releasing RC yet...16:20
ayoungzigo, Keystone is ready16:20
zigoayoung: But there's no rc tags, is there?16:21
morganfainbergzigo, we're merging the change that RC will be tagged from16:21
zigoOk.16:21
morganfainbergzigo, https://review.openstack.org/#/c/124692/16:21
zigoGood to know.16:21
ayoung"STAND IN THE DOOR!"16:22
*** __TheDodd__ has joined #openstack-keystone16:22
*** thedodd has quit IRC16:22
*** hockeynut has quit IRC16:22
*** hockeynut has joined #openstack-keystone16:23
*** dimsum_ is now known as dims16:23
ayounghttp://www.youtube.com/watch?v=tHLgC6Ioyf416:24
*** wwriverrat has joined #openstack-keystone16:24
ayoungThe most beautiful sight I ever did see/ was my fully inflated canopy.16:25
*** __TheDodd__ has quit IRC16:25
dimsayoung: awesome!16:26
*** thedodd has joined #openstack-keystone16:26
*** radez is now known as radez_g0n316:27
ayoungchmouel, you need to use a fragment of ^^ for openstack reactions16:27
ayoung"How I feel when waiting for rc tag to get cut"16:28
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: SAML2 wrapper plugin for full federation authN  https://review.openstack.org/10675116:28
*** jasondotstar has joined #openstack-keystone16:29
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: SAML2 wrapper plugin for full federation authN  https://review.openstack.org/10675116:30
*** Sharath_ has quit IRC16:31
*** sambetts has quit IRC16:34
*** gokrokve has joined #openstack-keystone16:34
*** radez_g0n3 is now known as radez16:34
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Add v3 openstackclient CLI examples  https://review.openstack.org/12448916:36
openstackgerritA change was merged to openstack/keystone: Open Kilo development  https://review.openstack.org/12469216:39
*** ChanServ sets mode: +o morganfainberg16:39
* dolphm OPEN FOR KILO16:39
*** morganfainberg changes topic to "Development for Kilo is now open on Master."16:40
*** dolphm changes topic to "Now open for Kilo development! Blocking reviews: https://gist.github.com/dolph/651c6a1748f69637abd0"16:40
dolphmlol16:40
stevemardolphm, the peasants rejoice!16:40
morganfainbergLOL16:40
stevemari'm a fan of the blocking reviews, can we keep it :)16:40
ayoungI thought it was Pheasants that were rejoicing16:40
dolphmstevemar: yeah, i'd like to formalize it and make it available to other projects16:41
stevemarthey are squaking16:41
stevemardolphm, fair enough16:41
dolphmstevemar: i'll certainly keep the gist running for now16:41
stevemarthats all i ask16:41
morganfainbergyeah it's a good thing to have.16:41
*** wwriverrat has left #openstack-keystone16:42
Davieyayoung: I didn't have v3 api enabled, i do now.. and works via curl + negotiate.  However, I can't get your snippet working.. I think it is because it is lacking tenantName/name.16:46
ayoungDaviey, could be...do you have a curretn keystonclient repo?16:46
Davieyayoung: Doesn't seem to be related to the Session object, but it is that where you call get_token()... So i think it is16:46
Davieyayoung: I have Master from this morning16:47
ayoungDaviey, you are backing kerberso with LDAP?16:47
ayoungI assume no default project?16:47
ayoungshould be doing the same thing...I just confirmed I had it working16:48
ayoung tenantName/name  should not be necessary16:48
Davieyayoung: Hmm, currently sql16:48
ayoungDaviey, NP16:48
Davieyachudnovets:16:49
ayoungshould work, too, but I haven't tested that16:49
ayoungGesudnheit16:49
Davieyayoung: Well, if i miuss out the name from my curl request it also fails16:49
ayoungwhat name?16:49
Davieynull16:49
ayoungok,  so it is a server side issue16:49
ayoungwhat "name"16:50
ayoungusername?16:50
ayoung'{ "auth": { "identity": { "methods": ["kerberos"], "kerberos": {}}}}'  is all I pass16:50
Davieylet me try that16:52
Davieyayoung: http://pb.daviey.com/4pYn/16:55
Davieyayoung: specifying the other details provides the valid response16:57
ayoungDaviey, you have "kerberos" as an auth methon in your server?16:59
*** gokrokve has quit IRC16:59
DavieyDug16:59
DavieyDuh16:59
ayoung[auth]16:59
ayoungmethods=kerberos,password,token16:59
*** gokrokve has joined #openstack-keystone16:59
DavieyWhen i made that empty, your example also worked16:59
Davieyshould be external, i guess16:59
ayoungNope17:00
ayoungwe are standardizing on Kerberos17:00
ayoungbut, last release you would have been correct17:00
Davieyayoung: ok, right.. when i s/external/kerberos in keystone.conf - your example worked17:05
ayoungschweet17:05
DavieySo seems i was wrong about it being the tenantName17:05
ayoungDaviey, ok, so lets see if we can get stevedore working17:05
Davieyayoung: Did you work out how stevedore works?17:06
ayoungDaviey, not a clue17:06
* ayoung just gonna wing it17:06
Daviey:)17:07
DavieyStevedore claims to make use of stevedore, and i am using an old version 1.4... but it doesn't declare a minimal version, so pretty sure it is ok17:07
Davieyerr, Stevedore claims to make use of setuputils*17:08
Davieysetuptools*. Bah17:08
*** thedodd has quit IRC17:10
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Remove token persistence proxy  https://review.openstack.org/12480917:11
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Remove unused ec2 driver option  https://review.openstack.org/12481017:15
*** harlowja has joined #openstack-keystone17:16
dstanekdolphm: yay! kilo17:21
*** Dafna has quit IRC17:21
ayoungDaviey, OK,  got it17:21
morganfainbergdstanek, stevemar, dolphm, I pressed go on the placeholder migrations17:22
*** harlowja has quit IRC17:22
ayoungDaviey, needs a change to the kerberos plugin17:22
ayoungI added, in setup .cfg17:22
ayoungDaviey, http://paste.openstack.org/show/116787/17:22
ayoungthen17:22
ayounginstead of importing the kerberos plugin directly, do17:23
ayoungkerb_mgr = driver.DriverManager(17:23
ayoung        namespace='keystoneclient.auth.plugin',17:23
ayoung        name='kerberos',17:23
ayoung        invoke_on_load=False,17:23
ayoung    )17:23
ayoungsess=session.Session(kerb_mgr.driver(OS_AUTH_URL), verify=OS_CACERT)17:23
ayoungDaviey, I still don't know where Stevedore stores the mapping of entrypoints to plugins, so I might be overwriting something that way....17:24
ayoungshould check that password still works:17:24
*** harlowja has joined #openstack-keystone17:24
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Remove unused ec2 driver option  https://review.openstack.org/12481017:24
Davieybrb17:24
ayoungDaviey, added http://paste.openstack.org/show/116789/  and got a token  using the token plugin from the token feched via the kerberos plugin17:29
*** marcoemorais has quit IRC17:30
openstackgerritayoung proposed a change to openstack/python-keystoneclient-kerberos: kerberos client plugin  https://review.openstack.org/12361417:30
ayoungmorganfainberg, now that I look at the stevedore code, and see how it works, I know where termie was going with the manager/driver thing17:31
*** john-davidge has quit IRC17:31
morganfainbergayoung, makes a bit more sense right?17:31
*** marcoemorais has joined #openstack-keystone17:33
*** marcoemorais has quit IRC17:33
*** marcoemorais has joined #openstack-keystone17:34
*** Sharath_ has joined #openstack-keystone17:34
*** Daviey has quit IRC17:37
*** Daviey has joined #openstack-keystone17:41
*** Sharath_ has quit IRC17:51
*** marcoemorais has quit IRC17:52
*** vishy has joined #openstack-keystone17:52
vishying17:52
morganfainbergvishy, hello there17:53
vishyhi17:53
morganfainbergvishy, how goes?17:53
vishylost all my scrollback :(17:53
vishyQQ17:53
morganfainbergvishy, boo :(17:53
vishydurn xen bug17:53
*** marcoemorais has joined #openstack-keystone17:53
*** montanvi is now known as bambam117:54
*** marcoemorais has quit IRC17:55
*** marcoemorais has joined #openstack-keystone17:56
dolphmmorganfainberg: p.s. i'm working on juno release notes17:56
morganfainbergdolphm, yay juno release notes!17:57
dolphmmorganfainberg: and all the reviews i blocked for kilo myself should now be unblocked - let me know if i missed any17:57
morganfainbergdolphm, yeah i looked earlier, looks like you unblocked them.17:57
morganfainbergi unblocked the ones i tossed a -2 on as well17:58
*** marcoemorais has quit IRC17:58
*** marcoemorais has joined #openstack-keystone17:58
*** marcoemorais has quit IRC17:58
*** marcoemorais has joined #openstack-keystone17:59
Davieyayoung: Sorry, had to go afk.. But that worked, thanks :)... Stevedore makes more sense to me now18:00
morganfainbergoh i should go create the LP project for keystoneclient-federation18:00
morganfainberghm. wonder if we could just move those plugins to storyboard instead...18:01
ayoungmorganfainberg, you go PTL!18:01
* morganfainberg goes to poke at infra folks 18:01
ayounger18:01
openstackgerritA change was merged to openstack/python-keystoneclient: Update hacking to 0.9.x  https://review.openstack.org/12298918:01
ayoungPTL2B18:01
morganfainbergayoung hehe :)18:01
*** lsmola has quit IRC18:01
*** zeus has quit IRC18:03
*** zeus has joined #openstack-keystone18:05
*** zeus is now known as Guest197418:05
*** Guest1974 has quit IRC18:10
*** sigmavirus24 has joined #openstack-keystone18:10
ayoungDaviey, I'm trying to decide if I should make Django-OpenStack auth use stevedore now18:14
*** gokrokve has quit IRC18:14
ayoungI'd ask the horizon folks, but pretty sure I alienate them all earier18:15
ayoungearlier18:15
ayoungdoug-fish, what do you think?  Should Horizon use Stevedore to load the auth plugins for keystone client?18:15
*** marcoemorais has quit IRC18:16
doug-fishayoung:  I don't know enough about it to have an opinion.18:17
ayoungdoug-fish, that never stopped me18:17
doug-fishlol18:17
doug-fishwhy the change?18:17
*** marcoemorais has joined #openstack-keystone18:18
doug-fishayoung: is this question specific to Horizon?  Aren't other OS components going to need to do the same?18:19
ayoungnope18:20
ayoungdoug-fish, only Horizon is a consumer of the auth plugins18:20
ayoungwell, Heat too18:20
doug-fishCLI?18:21
rodrigodsnow that kilo is open, time to review HM patches!!! =)18:22
Davieyayoung: Funnily enough, stevedore does seem to be a pretty good way of doing runtime plugin handling.18:23
ayoungDaviey, well, yeah, it does now, doesn't it18:23
Davieyayoung: But now, my reading up on stevedore is filling my adsense with job opportunities working at the docks.18:24
*** sigmavirus24 has left #openstack-keystone18:24
DavieySo.. Either i'll work at Docker, or my local Port.18:24
ayoungDawka!18:24
ayoungDawka!Dawka!Dawka!Dawka!Dawka!18:24
*** vdreamarkitex has joined #openstack-keystone18:25
*** gokrokve has joined #openstack-keystone18:26
*** gokrokve has quit IRC18:27
*** marcoemorais1 has joined #openstack-keystone18:28
*** gokrokve has joined #openstack-keystone18:29
ayoungDaviey, the thing is, now I need a way to figure out how to pass config options from Horizon through to the plugin in a non-threatening manner.  Django OpenStack Auth gets a conifg object from Django with is a python object....its just icky18:30
*** marcoemorais has quit IRC18:30
ayoungBut using Stevedore to replace registered components with the proper Mock objects for a unit tests sounds right to me18:31
*** thedodd has joined #openstack-keystone18:32
*** ukalifon has joined #openstack-keystone18:34
*** gokrokve has quit IRC18:34
*** gokrokve has joined #openstack-keystone18:35
Davieyayoung: I was following your thread... but confused now.. Surely you want to just do it in js, rather than using request-kerberos?18:36
openstackgerritTerry Howe proposed a change to openstack/python-keystoneclient: Identity plugin that manages passwords and tokens  https://review.openstack.org/12483018:50
ayoungDaviey, ah...phased approach.18:52
ayoungI want to do Kerberos in JS, yes18:52
ayoungbut I need something to work with the current set up18:52
ayoungwhich means a Horizon server side auth plugin18:52
*** morgan_remote_ has joined #openstack-keystone18:52
ayoungDaviey, I have a proof of concept working (well it was working, seems to break each time I turn around)  of Kerberos and Horizon18:53
ayoungI uses black magic from Hades to get a Kerberos service ticket for the end user that Horizon can use18:54
ayoungIts called Nosforuto Proxy, or S4U2Proxy for short18:54
*** andreaf has quit IRC19:03
*** andreaf has joined #openstack-keystone19:04
Davieyayoung: Right, that has been on my todo.. But i couldn't quite follow why this wasn't just done in pure js19:05
DavieyAs in, i can see people not wanting to use the delegation extensions of kerberos for the proxy19:05
ayoungDaviey, because unless Keystone and Horizon are on the same machine you have issues with same origin policy and need proper CORS support19:05
ayoungand that scares people....probably rightfully so19:06
DavieyAhhh, yes.19:06
* morgan_remote_ hides from the scary CORS.19:07
*** marcoemorais1 has quit IRC19:11
openstackgerritA change was merged to openstack/keystone: add --rebuild option for ssl/pki_setup  https://review.openstack.org/8820719:12
*** flwang has quit IRC19:13
*** marcoemorais has joined #openstack-keystone19:15
*** Tahmina has quit IRC19:19
*** radez is now known as radez_g0n319:20
*** marcoemorais has quit IRC19:21
*** marcoemorais has joined #openstack-keystone19:21
Davieyayoung: Maybe i am smoking crack, but if you rely on external auth and REMOTE_USER is valid.. kerberos in horizon is less interesting (other than to validate token binding?).  If Horizon serverside can retrieve a token directly from keystone on behalf of the user, without getting into the kerberos path - things seem simpler, no?19:21
ayoungDaviey, how does Horizon get a token as the user?19:21
ayoungShould Keystone just trust Horizon?19:22
ayoungIt can't use password19:22
DavieyThat is what i was thinking..19:24
Davieyhorizon / apache can have pre-stashed tokens, no?19:24
DavieyKRB5 tokens19:25
ayoungDaviey, For Kerberos in the short term, we Do S4U2.  Longer term, user gets the token from Keystone and hands it to Horizon19:25
ayounglonger term, there is no Horizon, user hands the token direct to Nova et alles19:25
Davieyok19:26
*** vhoward has left #openstack-keystone19:31
ayoungzigo, Running Sphinx v1.1.319:41
ayoungfatal: Not a git repository (or any of the parent directories): .git19:41
ayoungI assume you have a work around for that as well?19:42
*** ukalifon has quit IRC19:50
*** harlowja has quit IRC19:50
*** topol has quit IRC19:52
*** radez_g0n3 is now known as radez19:53
*** marcoemorais has quit IRC19:54
*** harlowja has joined #openstack-keystone19:55
*** marcoemorais has joined #openstack-keystone19:55
*** NM1 has joined #openstack-keystone19:57
*** ukalifon has joined #openstack-keystone19:57
*** gokrokve has quit IRC19:58
*** flwang has joined #openstack-keystone19:58
*** marcoemorais has quit IRC19:58
*** marcoemorais has joined #openstack-keystone19:59
*** gokrokve has joined #openstack-keystone19:59
*** flwang1 has joined #openstack-keystone20:01
stevemardolphm, whats the deal with kilo design session proposals this time around?20:03
stevemardolphm, also if you know what's going on with the cross-project ones, that would be great too20:04
stevemarcc morganfainberg ^20:04
dolphmstevemar: there won't be a summit.openstack.org to submit ideas through20:04
morganfainbergstevemar, ah i need to migrate the topics over, but there is an etherpad TTX put up20:04
dolphmstevemar: it'll be more of a collaborative schedule design per program (via eitherpad, etc)20:04
bknudsonhttps://etherpad.openstack.org/p/kilo-crossproject-summit-topics -- cross-project20:05
dolphmso, basically what keystone did the last two cycles, without the red tape20:05
bknudsonhttps://etherpad.openstack.org/p/keystone-kilo-summit-sessions20:05
morganfainberghttps://etherpad.openstack.org/p/kilo-keystone-summit-topics20:07
morganfainbergneed to move our topics to that one20:07
bknudsonpicked the wrong name.20:07
*** serverascode_ has joined #openstack-keystone20:08
flwang1bknudson: any lucky you around?20:09
ekarlsois domains gonna be removed ?20:09
bknudsonflwang1: I am around... not sure why a question would be specific to me...20:10
flwang1oh, sorry, not specific for you, because I just know you :)20:10
bknudsonI don't know anything.20:10
*** sigmavirus24 has joined #openstack-keystone20:10
flwang1:(20:10
ekarlsoI just see domains under the deprecate list ?20:10
flwang1bknudson: and because I had discussed the similar question with you, so I assume you're the best guy I can ask for help20:11
*** ayoung is now known as ayoung-afk20:11
bknudsonflwang1: if you ask the question here somebody might know the answer.20:12
ekarlsobknudson: u kniw the answer to the domains q ?20:12
bknudsonassuming it's keystone related.20:12
flwang1bknudson: ok, i apologize if I'm making any troubles20:12
bknudsonflwang1: what's the questions?20:13
flwang11. as a user, can I add more user for my tenant?20:13
flwang12. as a user, can I add a ^sub tenant^ under my tenant?20:14
flwang1seems v3 can resolve partial of above questions, but I'm not really sure20:14
ekarlsoguess noone wants to answer my thing then :)20:14
bknudsonflwang1: for 2, there are no sub tenants.20:14
flwang1how about the domain in v3?20:15
bknudsonflwang1: for 1, that depends on the policy20:15
bknudsonflwang1: domains are only in v3. There's no domains in v2, other than the default domain.20:15
flwang1bknudson: for #1, may I know more details?20:15
ekarlsobknudson: is it under discussion to remove them or ?20:15
bknudsonekarlso: I haven't heard any discussions to remove domains.20:16
bknudsonflwang1: domains are documented in the identity api v3 spec: https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#openstack-identity-api-v320:16
flwang1bknudson: cool20:17
flwang1so do you think the domain can resolve my #2?20:17
bknudsonflwang1: domains and projects are different things.20:18
bknudsona domain just provides a namespace.20:18
flwang1bknudson: ok, I will dig into it. then how about the #1?20:19
ekarlsonkinder: around ?20:19
bknudsonflwang1: I think this will depend on your policy configuration.20:19
bknudsonnot something I'm really familiar with... haven't had to work with policy configuratoin20:20
flwang1bknudson: ok, got it. thanks a lot20:20
*** marcoemorais has quit IRC20:21
flwang1ekarlso: do you know who is guy working on keystone of HP cloud?20:21
ekarlsoflwang1: not sure :/20:21
ekarlsothink we have a few20:21
flwang1because I saw HP cloud allow current user send invitation to a new user20:22
flwang1so i'm curious if there are some guys know more20:22
*** ukalifon has quit IRC20:28
*** thedodd has quit IRC20:29
*** ukalifon has joined #openstack-keystone20:30
*** thedodd has joined #openstack-keystone20:32
*** comstud has joined #openstack-keystone20:38
*** marcoemorais has joined #openstack-keystone20:39
*** thedodd has quit IRC20:45
*** ayoung-afk is now known as ayoung20:45
*** radez is now known as radez_g0n320:48
*** andreaf has quit IRC20:49
*** andreaf has joined #openstack-keystone20:50
*** aix has joined #openstack-keystone20:56
*** thedodd has joined #openstack-keystone21:10
*** NellyK has joined #openstack-keystone21:20
*** joesavak has quit IRC21:21
*** thedodd has quit IRC21:25
nkinderekarlso: hey, what's up?21:28
*** ukalifon has quit IRC21:29
*** stevemar has quit IRC21:35
*** stevemar has joined #openstack-keystone21:36
openstackgerritTerry Howe proposed a change to openstack/python-keystoneclient: Identity plugin that manages passwords and tokens  https://review.openstack.org/12483021:37
*** zzzeek has quit IRC21:43
*** zzzeek has joined #openstack-keystone21:43
*** dims_ has joined #openstack-keystone21:44
*** NellyK has quit IRC21:45
*** NM1 has quit IRC21:46
*** dims_ has quit IRC21:47
*** dims has quit IRC21:47
*** dims has joined #openstack-keystone21:47
*** aix_ has joined #openstack-keystone21:57
openstackgerritA change was merged to openstack/keystone: Add placeholders for reserved migrations  https://review.openstack.org/12420421:57
*** aix has quit IRC22:00
*** rkofman has quit IRC22:01
*** rkofman has joined #openstack-keystone22:02
*** samuelmz has quit IRC22:09
*** mikedillion has joined #openstack-keystone22:10
*** nkinder has quit IRC22:13
*** ayoung is now known as ayoung-afk22:14
*** NellyK has joined #openstack-keystone22:15
*** Tahmina has joined #openstack-keystone22:16
*** NellyK has quit IRC22:21
*** thedodd has joined #openstack-keystone22:21
*** mikedillion has quit IRC22:23
*** mikedillion has joined #openstack-keystone22:31
*** thedodd has quit IRC22:33
*** jasondotstar has quit IRC22:33
*** bknudson has quit IRC22:40
*** gordc has quit IRC22:40
*** andreaf has quit IRC22:44
*** andreaf has joined #openstack-keystone22:45
*** andreaf has quit IRC22:47
*** andreaf has joined #openstack-keystone22:47
*** r1chardj0n3s is now known as r1chardj0n3s_afk22:48
*** marcoemorais has quit IRC23:01
*** marcoemorais has joined #openstack-keystone23:01
*** marcoemorais has quit IRC23:02
*** marcoemorais has joined #openstack-keystone23:02
*** jaosorior has quit IRC23:03
*** sigmavirus24 is now known as sigmavirus24_awa23:08
*** nkinder has joined #openstack-keystone23:10
nkinderAnyone have some time to give this keystoneclient issue a review? https://review.openstack.org/#/c/123954/23:11
nkinderThis would be a good one to knock out from a security hardening standpoint, and it looks good to me.23:11
*** dims has quit IRC23:12
*** dims has joined #openstack-keystone23:13
*** dims has quit IRC23:17
*** doug-fish has left #openstack-keystone23:17
*** r1chardj0n3s_afk is now known as r1chardj0n3s23:24
*** mikedillion has quit IRC23:25
*** wanghong has quit IRC23:40
*** shakamunyi has quit IRC23:51
*** Tahmina has quit IRC23:53
*** andreaf has quit IRC23:54
*** gokrokve has quit IRC23:55
*** andreaf has joined #openstack-keystone23:55
*** wanghong has joined #openstack-keystone23:56
*** harlowja is now known as harlowja_away23:59

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