*** cynosure_ has joined #openstack-keystone | 00:01 | |
*** wchrisj has joined #openstack-keystone | 00:02 | |
cynosure_ | jamielennox, dolphm: any inputs ? | 00:04 |
---|---|---|
cynosure_ | thing is i can't run mod_wsgi keystone application present in the source at keystone/httpd/keystone.py | 00:05 |
*** wchrisj has quit IRC | 00:10 | |
*** shakamunyi has joined #openstack-keystone | 00:11 | |
jamielennox | cynosure_: the above sudo thing are you sure that was the apache user not having permission or your local user doesn't have permission | 00:14 |
jamielennox | switch to root and try the sudo line again | 00:15 |
*** thedodd has joined #openstack-keystone | 00:50 | |
*** dims has quit IRC | 00:52 | |
*** cynosure_ has quit IRC | 00:53 | |
*** browne has quit IRC | 00:53 | |
*** shakamunyi has quit IRC | 00:54 | |
*** cynosure_ has joined #openstack-keystone | 00:56 | |
*** thedodd has quit IRC | 00:56 | |
*** cynosure_ has quit IRC | 00:58 | |
*** thedodd has joined #openstack-keystone | 00:58 | |
*** cynosure_ has joined #openstack-keystone | 01:01 | |
*** cynosure_ has quit IRC | 01:06 | |
*** Mikalv has quit IRC | 01:13 | |
*** Mikalv has joined #openstack-keystone | 01:13 | |
*** thedodd has quit IRC | 01:15 | |
*** stevemar has joined #openstack-keystone | 01:19 | |
*** stevemar has quit IRC | 01:19 | |
*** stevemar has joined #openstack-keystone | 01:24 | |
*** marcoemorais has quit IRC | 01:24 | |
*** gyee has quit IRC | 01:35 | |
*** jamiec has joined #openstack-keystone | 01:41 | |
*** richm has quit IRC | 01:46 | |
*** Daviey has quit IRC | 01:47 | |
*** jzl-ctrip has joined #openstack-keystone | 01:48 | |
*** amcrn has quit IRC | 01:50 | |
*** pjzl-ctri has joined #openstack-keystone | 01:51 | |
pjzl-ctri | hi,all,it seems the local variable 'config' in each factory functions in keystone/service.py is undesired. | 01:51 |
*** Daviey has joined #openstack-keystone | 01:51 | |
*** harlowja has quit IRC | 01:52 | |
*** harlowja_ has joined #openstack-keystone | 01:52 | |
*** jzl-ctrip has quit IRC | 01:52 | |
jamielennox | pjzl-ctri: i'm not sure what you mean | 01:53 |
*** pjzl-ctri has quit IRC | 01:55 | |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Add CRUD operations for Federation Mapping Rules. https://review.openstack.org/83742 | 01:57 |
*** Daviey has quit IRC | 02:01 | |
*** Daviey has joined #openstack-keystone | 02:04 | |
morganfainberg | jamielennox, ok that didn't make sense to me either | 02:07 |
*** cloud_ has joined #openstack-keystone | 02:07 | |
*** cloud_ is now known as jzl-ctrip | 02:07 | |
jamielennox | morganfainberg: i figured it out | 02:07 |
morganfainberg | jamielennox, what was it? | 02:07 |
jamielennox | for example here: https://github.com/openstack/keystone/blob/master/keystone/service.py#L85-L87 | 02:08 |
morganfainberg | oh | 02:08 |
jamielennox | we do a thing to copy and then update a conf object and then never use it | 02:08 |
morganfainberg | jamielennox, i see. | 02:08 |
jamielennox | i've seen that before just never fixed it | 02:08 |
morganfainberg | thats... | 02:08 |
morganfainberg | sure we should fix that. | 02:08 |
jamielennox | i'm not sure what was ever intended to be done with those paste options | 02:08 |
jamielennox | morganfainberg: as in you're doing that now? | 02:10 |
morganfainberg | jamielennox, neg | 02:12 |
morganfainberg | jamielennox, have other things to do before i can say "lets clean that up" personally | 02:12 |
morganfainberg | and i think i still have a chunk of reviewing to do | 02:12 |
jamielennox | morganfainberg: alright, i may as well i'm waiting for something to finish anyway | 02:12 |
morganfainberg | i think the cost of that is minimal and not feeling like chasing it down if it causes issues. | 02:12 |
morganfainberg | not that i expect it would | 02:12 |
morganfainberg | it was just a "we should file a bug mark it low hanging and move on" if neither of us wanted to fix it now. | 02:13 |
jamielennox | morganfainberg: it's quicker to fix it than file the bug | 02:13 |
*** pjzl-ctri has joined #openstack-keystone | 02:13 | |
morganfainberg | hehe sure! | 02:13 |
*** jzl-ctrip has quit IRC | 02:14 | |
morganfainberg | should prob. file a bug in either case >.> | 02:14 |
morganfainberg | was my point :P | 02:14 |
morganfainberg | that whole... track things we change | 02:14 |
*** pjzl-ctri has quit IRC | 02:15 | |
jamielennox | ergh, so i can expect you to be a stickler for that from now on then | 02:16 |
*** ayoung has quit IRC | 02:19 | |
openstackgerrit | Jamie Lennox proposed a change to openstack/keystone: Remove unnecessary dict copy https://review.openstack.org/87430 | 02:21 |
openstackgerrit | Nathanael I Burton proposed a change to openstack/python-keystoneclient: Fix typo of ANS1 to ASN1 https://review.openstack.org/87069 | 02:23 |
*** david-lyle has joined #openstack-keystone | 02:38 | |
openstackgerrit | A change was merged to openstack/keystone: Updated from global requirements https://review.openstack.org/85762 | 02:39 |
jamielennox | morganfainberg and anyone else here: can you think of a better name for https://review.openstack.org/#/c/86237/ | 02:47 |
*** ayoung has joined #openstack-keystone | 02:49 | |
ayoung | jamielennox, that does not surprise me. Considering they have not even touched X509, either, I'd say cryptography has a long way to go. | 02:49 |
ayoung | The question, though, is whether NSS as an alternative to openssl is viable in Python. | 02:50 |
ayoung | I know that there was some reason that JCCE could not be used from Tomcat in Java as the access mode into NSS. Something about that abstraction approach that the Common Criteria process rejected. rcrit thought it might just be the jar signing, though. | 02:53 |
*** dstanek has quit IRC | 02:56 | |
*** dstanek has joined #openstack-keystone | 02:57 | |
openstackgerrit | Matt Fischer proposed a change to openstack/keystone: Make the LDAP debug option a configurable setting https://review.openstack.org/87068 | 02:57 |
*** mberlin has quit IRC | 02:59 | |
jamielennox | ayoung: it does have a long way but i know it's on there roadmap | 03:02 |
jamielennox | i'd say nss is a viable alternative - everything is there | 03:02 |
ayoung | jamielennox, yeah on both accounts | 03:02 |
jamielennox | and i'd say it should be looked at earlier rather than later so it doesn't end up with PEM by default or something stupid | 03:02 |
jamielennox | though i know they are taking that stuff into consideration | 03:02 |
ayoung | I'm wondering if I should take a look at what it would take to get CMS S/MIME working | 03:03 |
ayoung | you need to go through DER to get to PEM anyway | 03:03 |
jamielennox | ayoung: i've been watching - as i said i wouldn't mind doing the NSS port and getting into it - but anything like that still is going to involve cert validation | 03:03 |
ayoung | I'd expect that PEM would be the default at the recipe level | 03:03 |
jamielennox | 'recipe' so you watched that video too :) | 03:03 |
ayoung | its the need to have an abstraction that covers both the NSS and openSSL way of storing certs that worries me | 03:03 |
jamielennox | that's the first time i've ever heard it called that | 03:04 |
ayoung | yeah, watched it today in chunks | 03:04 |
jamielennox | ayoung: indeed | 03:04 |
jamielennox | it might be that that can never be quite reconciled and so long as there is a basic way of transfering the certs themselves around it is ok | 03:04 |
jamielennox | but i was doing some messing around with NSS and it is very DB centric | 03:05 |
jamielennox | like it wants you to initialize the lib with a DB and then that gets used for everything | 03:05 |
jamielennox | NSS and OpenSSL both have obviously started life as an application and had a half-hearted attempt at making a library | 03:05 |
ayoung | yes, the DB approach is probably more likely to sneak over to the openssl side than the reverse | 03:05 |
ayoung | openssl is doing more to lock down the direcotory where you store the certs | 03:06 |
ayoung | the DB in NSS case is pretty much: this directory and this set of berkeleydb files | 03:06 |
jamielennox | oh, i get it - it just means you have a stateful library | 03:06 |
ayoung | jamielennox, just checked and my blog post on this from last year is still valid | 03:06 |
jamielennox | and there's no real concept of having the library work with multiple databases | 03:07 |
ayoung | http://adam.younglogic.com/2012/05/signing-certutil/ | 03:07 |
ayoung | run that and you see what a minimal nss database looks like | 03:07 |
ayoung | its go | 03:07 |
ayoung | t | 03:07 |
ayoung | cert8.db key3.db secmod.db | 03:08 |
jamielennox | ayoung: oh i know, i've done all that | 03:08 |
ayoung | well, it has changed a bit over time | 03:08 |
jamielennox | i'm more talking about the C and python libraries than the cmdline | 03:08 |
ayoung | it used to be a single file | 03:08 |
ayoung | but that abstraction is, what pkcs11? | 03:08 |
ayoung | 12? I can never keep the numbers straight | 03:08 |
jamielennox | neither | 03:09 |
ayoung | 11 is the database | 03:09 |
ayoung | 12 is tls | 03:09 |
jamielennox | yea 11 | 03:09 |
ayoung | the token stuff that FreeIPA is implementing now | 03:09 |
jamielennox | 11 is the hardware etc common interface | 03:09 |
ayoung | so the nss DB is the software implementation | 03:09 |
jamielennox | so they do a lot of pksc11, but that's not what the library interface usess | 03:09 |
jamielennox | no | 03:10 |
jamielennox | 11 is about how to communicate with hardware etc, the db is a storage mechanism and purely an nss thing AFAIK | 03:10 |
ayoung | it exposes the same interface, somehow. | 03:11 |
ayoung | I defer to nalin on things of this ilk | 03:11 |
jamielennox | there is a graphic somewhere that kind of explains it | 03:11 |
ayoung | I know that doing the 11 stuff is a huge part of the complexity in DOgtag...all the C Code etc | 03:12 |
jamielennox | https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_API_GUIDELINES | 03:12 |
jamielennox | huh maybe db is lower than i though | 03:12 |
jamielennox | but the work level is all handled via a pkcs11 interface | 03:13 |
jamielennox | guess it means you can swap out crypto modules all in one place | 03:13 |
ayoung | I think what they did is said that the nssdb would implement a software version of the same interface as any other pkcs11 module | 03:14 |
*** mberlin has joined #openstack-keystone | 03:14 | |
jamielennox | anyway, i was going to see if i could make kite use cryptography | 03:14 |
jamielennox | haven't got there yet | 03:14 |
ayoung | jamielennox, BTW, they moved NSS from CVS to Mercurial, and I used the git-mercurial bridge to check it out... | 03:15 |
ayoung | its nice | 03:15 |
jamielennox | cool, i can never remember how to use hg | 03:16 |
jamielennox | it's all the same concepts as git with different names | 03:16 |
ayoung | it becomes git clone hg::http:// .... | 03:16 |
ayoung | tempted to push a branch onto github... | 03:17 |
*** morganfainberg has quit IRC | 03:19 | |
*** morganfainberg_Z has joined #openstack-keystone | 03:19 | |
*** morganfainberg_Z is now known as morganfainberg | 03:20 | |
*** harlowja_ is now known as harlowja_away | 03:21 | |
ayoung | jamielennox, wget https://raw.github.com/felipec/git/fc/master/git-remote-hg.py -O ~/bin/git-remote-hg | 03:27 |
ayoung | git clone hg::https://hg.mozilla.org/projects/nspr | 03:27 |
ayoung | git clone hg::https://hg.mozilla.org/projects/nss | 03:27 |
ayoung | https://developer.mozilla.org/en-US/docs/NSS_Sources_Building_Testing | 03:27 |
*** ayoung is now known as ayoung-ZZZzzz | 03:27 | |
jamielennox | surely that's packaged | 03:28 |
jamielennox | there is a rpm for hg-git and git-hg :( | 03:28 |
jamielennox | oh wait, that's obvious | 03:28 |
*** zhiyan_ is now known as zhiyan | 03:30 | |
jamielennox | yep, same thing | 03:30 |
*** zhiyan is now known as zhiyan_ | 03:31 | |
*** zhiyan_ is now known as zhiyan | 03:47 | |
*** dstanek has quit IRC | 03:52 | |
*** harlowja_away is now known as harlowja_ | 03:53 | |
*** dstanek has joined #openstack-keystone | 03:54 | |
*** wchrisj has joined #openstack-keystone | 03:55 | |
*** david_lyle_ has joined #openstack-keystone | 04:01 | |
*** david-lyle has quit IRC | 04:01 | |
*** chandan_kumar has joined #openstack-keystone | 04:08 | |
*** dstanek has quit IRC | 04:09 | |
*** Guest____ has joined #openstack-keystone | 04:10 | |
*** wchrisj has quit IRC | 04:11 | |
*** marcoemorais has joined #openstack-keystone | 04:13 | |
*** chandan_kumar has quit IRC | 04:17 | |
*** praneshp has joined #openstack-keystone | 04:24 | |
praneshp | Hey guys, anyone working on batching up keystone operations? | 04:25 |
*** david_lyle_ has quit IRC | 04:37 | |
*** david-lyle has joined #openstack-keystone | 04:38 | |
*** stevemar has quit IRC | 04:40 | |
*** chandan_kumar has joined #openstack-keystone | 04:50 | |
*** gokrokve has quit IRC | 04:51 | |
*** dstanek has joined #openstack-keystone | 04:51 | |
*** nkinder has joined #openstack-keystone | 04:52 | |
*** dstanek has quit IRC | 04:56 | |
morganfainberg | praneshp, what do you mean by batching up keystone operations? | 04:59 |
praneshp | hi morganfainberg I mean doing bulk operations. not one user/tenant at a time | 05:06 |
praneshp | I have a blueprint in mind to add a bulk operations extension to Keystone | 05:08 |
*** harlowja_ is now known as harlowja_away | 05:37 | |
jamielennox | praneshp: i've never heard of anyone looking at it - is there any other projects doing that? | 05:44 |
jamielennox | in general i would think that keystone is the last of the openstack services to need something like that | 05:45 |
praneshp | jamielennox: not sure. | 05:45 |
jamielennox | because once it's running the standard usage is just to get tokens | 05:45 |
jamielennox | praneshp: what's your primary use case? | 05:45 |
praneshp | jamielennox: I'l; get back with some sort of a blueprint? | 05:45 |
praneshp | jamielennox: something like: get a set of users everyday, diff from previous days list, and do some work with the diff | 05:46 |
jamielennox | praneshp: so that won't be allowed because you shouldn't be able to list all users | 05:46 |
jamielennox | yes you somewhat can now but in general it's going away | 05:46 |
praneshp | jamielennox: list not from keystone | 05:47 |
jamielennox | think of an enterprise with a 50k person LDAP server | 05:47 |
praneshp | from an enterprise to add into keystone, etc | 05:47 |
jamielennox | praneshp: so why would you do that via keystone? | 05:47 |
jamielennox | if you are in that situation then keystone is acting as a front end for a more reliable data store | 05:47 |
praneshp | so if an employee goes away, remove him from keystone, do something with his VMs, and so on | 05:47 |
jamielennox | probably ldap | 05:47 |
praneshp | and if there are new ones, give them access to your openstack infrastructure. | 05:48 |
praneshp | Hmm | 05:48 |
jamielennox | ldap specifically in this case you would auto provision that user | 05:48 |
jamielennox | keystone knowing when a user is removed is a problem with external data sources | 05:48 |
jamielennox | there has been some talk around how to do that with federation and using sources that you can't actually contact to know that | 05:49 |
jamielennox | i'm not the best person to talk to about that | 05:49 |
praneshp | thank you jamielennox | 05:49 |
praneshp | I'll wait to collect more feedback, and read up some more about ldap. | 05:50 |
jamielennox | but in general if you need batch operations then i'd be thinking about using LDAP as a backend and doing your operations on that directly | 05:50 |
jamielennox | using keystone in that sense is not supposed to hide the fact that you are using another source of users | 05:50 |
praneshp | Let's forget about the other source of users for a min. Supposing I want to nuke all the users in tenant X, is there a way to do that in one operation? | 05:51 |
jamielennox | praneshp: not really, but your kind of mixing terms | 05:52 |
jamielennox | users exist outside the concept of tenants | 05:52 |
jamielennox | ie you just have users | 05:52 |
jamielennox | then some of those users have permissions in a tenant | 05:53 |
praneshp | yeah, I know. And then you add users to tenants, with role(s) in that tenant | 05:53 |
jamielennox | there's nothing i can think of that would help you batch delete | 05:53 |
praneshp | say now I want to nuke all users with role SnapshotCreator in tenant X | 05:53 |
jamielennox | yea, i know what you mean - i don't think we export anything like that | 05:54 |
jamielennox | it's not a common operation | 05:54 |
praneshp | yeah, we do it everyday though (for good or bad :|) | 05:55 |
praneshp | I'll write up a blueprint, gather my ideas into that, and ping you again. | 05:55 |
jamielennox | ok - then sure i'd propose that | 05:55 |
praneshp | maybe a couple of more days | 05:55 |
praneshp | thanks jamielennox | 05:55 |
praneshp | I'm new-ish to the community, and people at nova and here have been really helpful. | 05:56 |
jamielennox | praneshp: np, and that's always good to hear | 05:56 |
jamielennox | but i would also recommend looking into a proper LDAP server and running keystone off of that | 05:56 |
praneshp | yeah, I'll def look into that | 05:57 |
openstackgerrit | Jenkins proposed a change to openstack/keystone: Imported Translations from Transifex https://review.openstack.org/83955 | 06:01 |
*** jamielennox is now known as jamielennox|away | 06:07 | |
openstackgerrit | wanghong proposed a change to openstack/keystone: delete the tokens when deleting ec2 credential https://review.openstack.org/87450 | 06:30 |
*** Guest____ has quit IRC | 06:33 | |
*** Guest____ has joined #openstack-keystone | 06:34 | |
*** Guest____ has quit IRC | 07:04 | |
*** tomoiaga has joined #openstack-keystone | 07:06 | |
*** praneshp has quit IRC | 07:23 | |
*** leseb has joined #openstack-keystone | 07:45 | |
*** morganfainberg is now known as morganfainberg_Z | 07:56 | |
*** ukalifon has joined #openstack-keystone | 08:01 | |
*** marekd|away is now known as marekd | 08:06 | |
*** zhiyan is now known as zhiyan_ | 08:10 | |
*** zhiyan_ is now known as zhiyan | 08:10 | |
*** zhiyan is now known as zhiyan_ | 08:14 | |
*** zhiyan_ is now known as zhiyan | 08:15 | |
*** marcoemorais has quit IRC | 08:27 | |
*** ukalifon has quit IRC | 08:33 | |
*** ukalifon has joined #openstack-keystone | 08:34 | |
*** derek_c has quit IRC | 08:35 | |
*** derek_c has joined #openstack-keystone | 08:37 | |
*** derek_c has quit IRC | 08:45 | |
*** dims has joined #openstack-keystone | 09:10 | |
*** zhiyan is now known as zhiyan_ | 09:13 | |
*** zhiyan_ is now known as zhiyan | 09:15 | |
*** ilives has joined #openstack-keystone | 09:20 | |
*** marcoemorais has joined #openstack-keystone | 09:24 | |
*** leseb_ has joined #openstack-keystone | 09:28 | |
*** marcoemorais has quit IRC | 09:28 | |
*** leseb has quit IRC | 09:31 | |
*** leseb_ has quit IRC | 09:32 | |
openstackgerrit | Sergey Nikitin proposed a change to openstack/keystone: Some methods in ldap were moved to superclass https://review.openstack.org/86250 | 09:32 |
*** leseb has joined #openstack-keystone | 09:33 | |
*** leseb_ has joined #openstack-keystone | 09:35 | |
*** chandan_kumar has quit IRC | 09:38 | |
*** leseb has quit IRC | 09:39 | |
*** andreaf has joined #openstack-keystone | 09:55 | |
*** chandan_kumar has joined #openstack-keystone | 09:55 | |
*** marcoemorais has joined #openstack-keystone | 10:00 | |
openstackgerrit | Sergey Nikitin proposed a change to openstack/keystone: Some methods in ldap were moved to superclass https://review.openstack.org/86250 | 10:01 |
*** marcoemorais has quit IRC | 10:04 | |
*** leseb_ has quit IRC | 10:18 | |
*** chandan_kumar has quit IRC | 10:23 | |
*** topol has joined #openstack-keystone | 10:30 | |
*** ilives has quit IRC | 10:33 | |
*** chandan_kumar has joined #openstack-keystone | 10:37 | |
*** ilives has joined #openstack-keystone | 10:42 | |
*** leseb has joined #openstack-keystone | 10:49 | |
*** leseb has quit IRC | 10:53 | |
*** marcoemorais has joined #openstack-keystone | 11:01 | |
*** marcoemorais has quit IRC | 11:06 | |
*** david-lyle has quit IRC | 11:20 | |
*** dims has quit IRC | 11:22 | |
openstackgerrit | Sergey Nikitin proposed a change to openstack/keystone: Code which gets and deletes elements of tree was moved to one method https://review.openstack.org/86578 | 11:26 |
*** dims has joined #openstack-keystone | 11:29 | |
openstackgerrit | wanghong proposed a change to openstack/keystone: delete proj_dp_association when delete proj or dp https://review.openstack.org/87551 | 11:37 |
*** tomoiaga1 has joined #openstack-keystone | 11:40 | |
*** chandan_kumar has quit IRC | 11:42 | |
*** tomoiaga has quit IRC | 11:42 | |
*** tomoiaga1 is now known as tomoiaga | 11:48 | |
*** leseb has joined #openstack-keystone | 11:49 | |
*** leseb_ has joined #openstack-keystone | 11:53 | |
*** leseb has quit IRC | 11:55 | |
*** chandan_kumar has joined #openstack-keystone | 11:58 | |
*** dstanek has joined #openstack-keystone | 12:01 | |
*** jzl-ctrip has joined #openstack-keystone | 12:02 | |
*** jzl-ctrip has quit IRC | 12:03 | |
openstackgerrit | Ala Rezmerita proposed a change to openstack/python-keystoneclient: Enable users to manage EC2-credentials on publicURL https://review.openstack.org/77219 | 12:05 |
*** chandan_kumar has quit IRC | 12:26 | |
*** erecio has joined #openstack-keystone | 12:34 | |
*** kun_huang has joined #openstack-keystone | 12:34 | |
*** ilives has quit IRC | 12:36 | |
*** chandan_kumar has joined #openstack-keystone | 12:41 | |
*** bada has joined #openstack-keystone | 12:52 | |
*** leseb_ has quit IRC | 12:52 | |
*** leseb_ has joined #openstack-keystone | 12:56 | |
*** marcoemorais has joined #openstack-keystone | 13:02 | |
*** marcoemorais has quit IRC | 13:07 | |
*** vhoward has left #openstack-keystone | 13:10 | |
*** leseb_ has quit IRC | 13:16 | |
*** henrynash has joined #openstack-keystone | 13:23 | |
*** ayoung-ZZZzzz has quit IRC | 13:25 | |
*** bknudson has joined #openstack-keystone | 13:26 | |
*** vhoward has joined #openstack-keystone | 13:28 | |
*** leseb has joined #openstack-keystone | 13:49 | |
dstanek | everytime i think "maybe i shouldn't do it like this", i'll have to remember that bknudson's going to call me on it :-) | 13:51 |
*** leseb has quit IRC | 13:53 | |
*** gordc has joined #openstack-keystone | 13:54 | |
*** ukalifon has quit IRC | 13:58 | |
*** wchrisj has joined #openstack-keystone | 13:59 | |
*** gokrokve has joined #openstack-keystone | 14:02 | |
*** marcoemorais has joined #openstack-keystone | 14:03 | |
*** marcoemorais1 has joined #openstack-keystone | 14:05 | |
*** jagee has joined #openstack-keystone | 14:07 | |
*** marcoemorais has quit IRC | 14:07 | |
*** marcoemorais1 has quit IRC | 14:09 | |
*** ayoung has joined #openstack-keystone | 14:11 | |
*** nkinder has quit IRC | 14:13 | |
*** topol_ has joined #openstack-keystone | 14:13 | |
*** chandan_kumar has quit IRC | 14:13 | |
*** topol has quit IRC | 14:14 | |
*** topol_ is now known as topol | 14:14 | |
*** wchrisj has left #openstack-keystone | 14:15 | |
*** joesavak has joined #openstack-keystone | 14:18 | |
*** tomoiaga has left #openstack-keystone | 14:23 | |
*** RockKuo has quit IRC | 14:23 | |
*** jaosorior has quit IRC | 14:23 | |
*** stevemar has joined #openstack-keystone | 14:25 | |
dolphm | dstanek: we need "bknudson is going to catch you" stickers | 14:25 |
*** leseb has joined #openstack-keystone | 14:29 | |
*** leseb has quit IRC | 14:30 | |
*** leseb has joined #openstack-keystone | 14:31 | |
*** dolphm is now known as dolphem | 14:31 | |
*** jsavak has joined #openstack-keystone | 14:33 | |
*** derek_c has joined #openstack-keystone | 14:34 | |
*** leseb has quit IRC | 14:35 | |
*** joesavak has quit IRC | 14:37 | |
gordc | hey folks, we have this bug in ceilometer: https://bugs.launchpad.net/ceilometer/+bug/1291136 ... can we just set use_keyring and problem solved? | 14:37 |
uvirtbot | Launchpad bug 1291136 in ceilometer "Periodic tasks drive token table growth" [Low,In progress] | 14:37 |
*** thedodd has joined #openstack-keystone | 14:45 | |
*** jsavak has quit IRC | 14:48 | |
*** david-lyle has joined #openstack-keystone | 14:54 | |
*** jaosorior has joined #openstack-keystone | 14:54 | |
dstanek | gordc: i don't understand the last comment in the bug about the race condition | 14:56 |
dstanek | gordc: but my understanding is that using keyrings will allow your token to be cached. have you given it a try to see if it works? | 14:57 |
gordc | dstanek: i think that comment is out of scope for the bug. | 14:57 |
*** leseb has joined #openstack-keystone | 14:58 | |
*** RockKuo has joined #openstack-keystone | 14:58 | |
gordc | dstanek: i haven't tried using keyring :) ... just asking because there's also the ability to pass in auth_ref so i'm not sure what the correct solution is... based on the description of both attribute i would think both would work? | 14:58 |
dstanek | gordc: it seems like it, but i don't have all that much experience with the client; i would have give it a try and see if it works | 15:00 |
gordc | dstanek: cool cool. i'll give it a try and see how it goes. | 15:01 |
*** joesavak has joined #openstack-keystone | 15:04 | |
*** RockKuo_iPad has joined #openstack-keystone | 15:04 | |
*** browne has joined #openstack-keystone | 15:07 | |
*** joesavak has quit IRC | 15:08 | |
ayoung | dolphem, dstanek https://blueprints.launchpad.net/keystone/+spec/password-rotation is probably a mistake. We should not be building additional Functionality into the Identity backend. I would go so far as to say that we should work towards deprecating Keystone using and managing passwords | 15:08 |
ayoung | gordc, it would mitigate the problem to cache tokens, but also we want to move toward ephemeral tokens. | 15:09 |
dstanek | ayoung: there seemed to be at least a few vocal people looking for password rotation | 15:10 |
*** leseb has quit IRC | 15:11 | |
ayoung | dstanek are these vocal people paying your paycheck? | 15:11 |
dstanek | this was discussed at our face-to-face in San Antonio | 15:11 |
ayoung | dstanek, and I think I said the same thing there, probably less vocally | 15:11 |
*** leseb has joined #openstack-keystone | 15:11 | |
dstanek | ayoung: nope, this is not something Rackspace needs as far as I know | 15:11 |
ayoung | dstanek the phrase that comes to mind is "rearrainging the deck chairs on the Titanic." | 15:12 |
*** leseb has quit IRC | 15:12 | |
ayoung | dstanek, I am really starting to think that there are no good solutions, but the recent Heartbleed issue does show that something like X509 used for authentication would have far reaching positive effects | 15:13 |
*** leseb has joined #openstack-keystone | 15:13 | |
dstanek | is removing passwords on the roadmap for keystone? | 15:13 |
ayoung | dstanek, I think we should at least discuss it | 15:13 |
gordc | ayoung: i assume ephemeral tokens is a v3 item? | 15:14 |
ayoung | gordc, it is a Juno item | 15:14 |
ayoung | gordc, not API version specific | 15:14 |
ayoung | it could be done with any version of PKI tokens | 15:14 |
ayoung | but it does need support from the V3 api for revocation support. | 15:14 |
gordc | ayoung: oh ok. i'll keep an eye out for that. | 15:14 |
ayoung | gordc, yeah, it is a summit topic. Lots of people have issues with the token table growing out of control. We want to remove that as a concern | 15:15 |
ayoung | dstanek, what do you think? | 15:15 |
ayoung | Should Keystone continue to support Passwords? | 15:15 |
ayoung | dstanek, let me rephrase that | 15:16 |
ayoung | should Keystone continue to perform Password administration | 15:16 |
dstanek | ayoung: i guess it would depend on how many real deployments use it and what their other options would be | 15:16 |
dstanek | from a security perspective it would be nice to not have them stored in our system | 15:17 |
ayoung | dstanek, if Keystone is going to continue to be a password management system, we have to get really serious about it and do it right. | 15:18 |
ayoung | One way or the other, no half-measures | 15:18 |
ayoung | That means rotation, as you are doing, but also proper storage, archival, retrieval, classes of characters, secure reset mechanisms, etc | 15:19 |
dstanek | ayoung: there was talk of some of that stuff, but i don't know if there are any blueprints to support those features | 15:22 |
dolphem | ayoung: the use case fabio/gyee were looking for was to support password rotation for service users, specifically. i think that's the only use case we're targeting for the SQL identity backend | 15:23 |
*** derek_c has quit IRC | 15:24 | |
*** richm has joined #openstack-keystone | 15:26 | |
*** RockKuo_iPad has quit IRC | 15:26 | |
dstanek | dolphem, ayoung: that's correct. the blueprint does specify some other features that they would eventually like to implement | 15:27 |
openstackgerrit | Brant Knudson proposed a change to openstack/python-keystoneclient: Deprecate admin_token option in auth_token https://review.openstack.org/87091 | 15:35 |
ayoung | dstanek, dolphem so I would think that splitting service users into their own datastore would be higher priority than this to some degree. | 15:37 |
ayoung | I'd like to make it possible to authenticate service users via something more cryptographically secure. I can't see anything working better than X509 for that | 15:37 |
bknudson | I was hoping I could debug bug 1300581 with https://review.openstack.org/#/c/86472/ but it hasn't merged yet. | 15:38 |
uvirtbot | Launchpad bug 1300581 in keystone "test_revoke.RevokeTreeTests.test_cleanup fails" [Critical,Triaged] https://launchpad.net/bugs/1300581 | 15:38 |
browne | ayoung: is there a blueprint for storing service users in its own datastore? | 15:38 |
ayoung | browne, not per-se but rather allowing multiple datastores | 15:38 |
ayoung | browne, its a summit session, actually | 15:39 |
*** tomoiaga has joined #openstack-keystone | 15:39 | |
browne | ayoung: i always thought service users should somehow to be separate from other users. this is especially true when using ldap | 15:39 |
ayoung | browne, we get that a lot. | 15:39 |
ayoung | I Wholeheartedly concur | 15:40 |
bknudson | we tried it once but ran into issues | 15:40 |
ayoung | http://summit.openstack.org/cfp/details/35 browne | 15:40 |
dstanek | bknudson: what were the issues? | 15:40 |
browne | ayoung: thx. also big fan of x509 authentication | 15:40 |
bknudson | dstanek: we couldn't figure out what backend the user was in based on the id | 15:40 |
bknudson | uuid | 15:40 |
browne | bknudson: i've separated them before using 2 keystone instances. | 15:41 |
ayoung | browne, that is a little more heavyweight a solution than we are looking for | 15:41 |
browne | yeah, most likely | 15:42 |
bknudson | browne: that seems like a good way to do it. | 15:42 |
ayoung | bknudson, doesn't scale. 1 Keystone per IdP? | 15:42 |
bknudson | ayoung: If all you're doing is separating out service users it doesn't have to scale beyond 2 | 15:42 |
dstanek | ayoung: couldn't you just have 2 clusters? one for service user and one for real users? | 15:43 |
browne | what i had done was create a sql backend instance on the internal endpoint. and another ldap keystone instance on the public endpoint. services used the internal endpoint. everything else on public | 15:43 |
ayoung | bknudson, yes, I know, but we need to do more than that. PLus, we have no way to figure out "which keystone signed this token" | 15:43 |
ayoung | browne, uuid tokens or PKI? | 15:43 |
browne | uuid | 15:43 |
bknudson | ayoung: that's a good question... who's got the revocation list. | 15:43 |
*** nkinder has joined #openstack-keystone | 15:43 | |
browne | wanted to use pki, but ran into the apache+pki problem | 15:43 |
ayoung | browne, that is now solved | 15:44 |
browne | ayoung: that's good | 15:44 |
ayoung | you are talking token size, right? There was a bunch of extra data in the service catalog that we cut, shrinking the token size by about 1/3 | 15:44 |
browne | ayoung: yep | 15:44 |
dstanek | bknudson: in https://review.openstack.org/#/c/85651/6/keystone/tests/ksfixtures/database.py i was thinking about using a run_once decorator that i have used in the past and then keeping the call in the __init__, thoughts? | 15:46 |
dstanek | bknudson: i just don't want to do the work on import, but i agree that it only needs to be done once | 15:46 |
bknudson | dstanek: I'm fine with a run_once decorator. This can be done in a separate commit as an enhancemnt | 15:47 |
dstanek | bknudson: ha, too late i just wrote it - tests are running now to see if it still works | 15:48 |
ayoung | dstanek, so...if you were to have to make a native call from python...where would you start? I've been told Cython in the past. Is that advice still good? | 15:48 |
ayoung | and....would that still stand if I were to be targetting eventually merging my effort with cryptography.py | 15:49 |
dstanek | ayoung: probably, but i have never used it; i learned the C-API a long time ago because i'm very familiar with C | 15:50 |
*** browne has quit IRC | 15:50 | |
ayoung | dstanek, Oh, the C part doesn't bother me at all. | 15:50 |
dstanek | ayoung: that would be more of a question for them. if they are not using Cython, they probably wouldn't want you to use it either. | 15:50 |
ayoung | yeah, jsut realized that myself, although I am not sure I want to do that as a first steop. I need a libary way to do the CMS code, and nothingr really exists right now | 15:51 |
dstanek | the hardest part about the C-API is the reference counting - you have to know which calls steal a reference and which ones create their own | 15:51 |
dstanek | if you decrement the wrong reference you'll segfault | 15:51 |
*** gyee has joined #openstack-keystone | 15:52 | |
ayoung | dstanek, I thought it was tellin the greenthread schedule "you can do some work now" | 15:52 |
ayoung | but seriously... | 15:52 |
ayoung | let me see what they did at the binding layer | 15:52 |
ayoung | https://github.com/pyca/cryptography/tree/master/cryptography/hazmat/bindings/openssl | 15:53 |
ayoung | TODO: This typedef is wrong. | 15:54 |
ayoung | nice | 15:54 |
dstanek | ayoung: that's lovely to see | 15:55 |
dstanek | and it's crypto code | 15:55 |
ayoung | OK, here is some "real code" https://github.com/pyca/cryptography/blob/master/cryptography/hazmat/primitives/hmac.py | 15:55 |
*** marcoemorais has joined #openstack-keystone | 15:55 | |
ayoung | from cryptography.hazmat.backends.interfaces import HMACBackend seems like it means that one should be somewhat fleshed out | 15:56 |
ayoung | ctx = self._backend._ffi.gc( | 15:59 |
ayoung | ctx, self._backend._lib.HMAC_CTX_cleanup | 15:59 |
ayoung | ) | 15:59 |
ayoung | dstanek, ^^ is from https://github.com/pyca/cryptography/blob/master/cryptography/hazmat/backends/openssl/backend.py#L706 | 15:59 |
ayoung | Assuming ffi is foreign function interface, and that is where they actually call into native code | 16:01 |
*** thedodd has quit IRC | 16:01 | |
ayoung | https://github.com/pyca/cryptography/blob/master/cryptography/hazmat/backends/openssl/backend.py#L63 self._ffi = self._binding.ffi | 16:01 |
ayoung | dstanek, https://github.com/pyca/cryptography/blob/master/cryptography/hazmat/bindings/openssl/hmac.py that looks like C code embedded in the CUSTOMIZATIONS string | 16:03 |
ayoung | is that normal? | 16:03 |
*** Gu_______ has joined #openstack-keystone | 16:04 | |
dstanek | ayoung: i've not seen that before - looks very interesting | 16:04 |
ayoung | import cffi https://github.com/pyca/cryptography/blob/master/cryptography/hazmat/bindings/utils.py#L20 | 16:05 |
dstanek | ayoung: cffi is pretty interesting - just started reading this https://cffi.readthedocs.org/en/release-0.8/ | 16:05 |
ayoung | dstanek, yep, me too | 16:06 |
*** browne has joined #openstack-keystone | 16:06 | |
ayoung | dstanek, I like the philosophy | 16:07 |
bknudson | Any opinion on how we should advertise extensions for v3? | 16:10 |
bknudson | as in, which extensions are available | 16:10 |
ayoung | bknudson, yes | 16:11 |
ayoung | bknudson, /v3/extensions | 16:11 |
ayoung | bknudson, or: | 16:11 |
ayoung | we could even do it as a collection under /v3 | 16:11 |
bknudson | ayoung: that makes sense since that's what's documented in the api docs already | 16:11 |
ayoung | crazy talk! | 16:12 |
*** zhiyan is now known as zhiyan_ | 16:12 | |
bknudson | ayoung: but I can also see having it in the v3/ response. | 16:12 |
ayoung | bknudson, I'd like to do that with all of the modules, actually: identity, policy, token... | 16:12 |
bknudson | ayoung: for example in "links": [] ? | 16:13 |
ayoung | yeah | 16:13 |
ayoung | bknudson, I'd also like to return HTML, but dolphem said no last time I asked. I asked politely, too. | 16:13 |
bknudson | ayoung: do we want v3 extensions to have admin & public versions? | 16:13 |
bknudson | ayoung: for v2 extensions they can register as public or admin | 16:14 |
ayoung | bknudson, hmmm...I kindof want that distinction to go away | 16:14 |
bknudson | which makes sense since there are still 2 pipelines. | 16:14 |
ayoung | bknudson, but... | 16:14 |
bknudson | and someone could leave the extension out of 1 pipeline or the other | 16:14 |
ayoung | it really should be somethuing like this: | 16:14 |
ayoung | 1 hit /v3 and see the "public" extensions. THen get a token, and, based on that token, see "all" the extensions...or at least all the ones you have access to see. | 16:15 |
bknudson | that makes more sense from rbac -- we'd need some way to register roles for extensions or something | 16:16 |
ayoung | yeah....and Horizon was asking for that at least a Year ago, too | 16:16 |
*** thedodd has joined #openstack-keystone | 16:19 | |
ayoung | bknudson, which means we need to be able to parse a policy file, and do the query "based on the roles you have, what can you execute" | 16:22 |
bknudson | ayoung: that sounds slow. | 16:22 |
bknudson | ayoung: so /v3 returns '{ "rel": "self", "href": "http://192.168.122.176:35357/v3/" }' for the link | 16:23 |
bknudson | ayoung: how about { "rel": "extension", "href": "http://192.168.122.176:35357/v3/OS-FEDERATION" } | 16:23 |
*** nkinder has quit IRC | 16:24 | |
ayoung | bknudson, thats the idea, yea | 16:24 |
bknudson | and, would you expect all the extension info in /v3 links or should that be returned by the extension root? | 16:24 |
*** daneyon has joined #openstack-keystone | 16:24 | |
*** nkinder has joined #openstack-keystone | 16:24 | |
ayoung | bknudson, so long as I have a way to navigate down to it without knowing a-priori, I would be happy | 16:26 |
ayoung | bknudson, I guess it is a question of how we would want people to consume the info. I would not see any benefit to requireing an additional query to get the extensions data, but I could see the use of having that query available. I see moduels and extensions as two sides of the smae coin: enumeratable chunks of functionality. I'd like to have them both available right under the version url. | 16:30 |
bknudson | ayoung: ok, I'll look at mocking something up. | 16:32 |
ayoung | ++ | 16:32 |
*** nkinder has quit IRC | 16:34 | |
*** erecio has quit IRC | 16:36 | |
*** amcrn has joined #openstack-keystone | 16:40 | |
*** bknudson has quit IRC | 16:41 | |
*** erecio has joined #openstack-keystone | 16:46 | |
*** leseb has quit IRC | 16:50 | |
*** thiagop has quit IRC | 16:51 | |
*** harlowja_away is now known as harlowja_ | 16:58 | |
*** marcoemorais has quit IRC | 16:58 | |
*** marcoemorais has joined #openstack-keystone | 16:59 | |
*** zuqiang has joined #openstack-keystone | 17:00 | |
*** jaosorior has quit IRC | 17:01 | |
*** thedodd has quit IRC | 17:03 | |
openstackgerrit | A change was merged to openstack/keystone: More debug output for test https://review.openstack.org/86472 | 17:08 |
*** mat-lowery has joined #openstack-keystone | 17:13 | |
*** browne has quit IRC | 17:24 | |
*** morganfainberg_Z is now known as morganfainberg | 17:25 | |
morganfainberg | mornin | 17:25 |
*** bknudson has joined #openstack-keystone | 17:27 | |
*** browne has joined #openstack-keystone | 17:28 | |
openstackgerrit | David Stanek proposed a change to openstack/keystone: Moves test database setup/teardown into a fixture https://review.openstack.org/85651 | 17:28 |
openstackgerrit | David Stanek proposed a change to openstack/keystone: Adds table and model for storing rotated passwords https://review.openstack.org/73368 | 17:28 |
openstackgerrit | David Stanek proposed a change to openstack/keystone: password rotation extension WIP https://review.openstack.org/74623 | 17:28 |
*** bknudson has quit IRC | 17:32 | |
openstackgerrit | guang-yee proposed a change to openstack/keystone: Make sure all the auth plugins agree on the shared identity attributes. https://review.openstack.org/84945 | 17:33 |
*** praneshp has joined #openstack-keystone | 17:42 | |
morganfainberg | ayoung, dstanek, we can't remove password management in the near term imo. I know many smaller deployments use it. We need to get serious about the SQL identity provider. | 17:42 |
morganfainberg | ayoung, dstanek, and do it "right". this is probably true about R/W LDAP as well. | 17:43 |
*** thedodd has joined #openstack-keystone | 17:45 | |
*** rupsky has joined #openstack-keystone | 17:46 | |
*** bknudson has joined #openstack-keystone | 17:46 | |
ayoung | morganfainberg, perhaps, although LDAP can do a lot of the password stuff for you if you use the right controls. | 17:48 |
ayoung | morganfainberg, gonna grab a smmidge before our meeting.,,, | 17:48 |
morganfainberg | ayoung, agreeed | 17:48 |
morganfainberg | ayoung, LDAP might be able to do this, we just need to document a lot if we want to offload it there. | 17:48 |
*** jamielennox|away is now known as jamielennox | 18:01 | |
*** dolphem is now known as dolphm | 18:01 | |
*** Gu_______ has quit IRC | 18:01 | |
*** gokrokve_ has joined #openstack-keystone | 18:08 | |
mat-lowery | jamielennox: ping | 18:11 |
*** gokrokve has quit IRC | 18:12 | |
jamielennox | mat-lowery: i'm here if it's fairly simple, but keystone's meeting is on | 18:12 |
*** lnxnut has joined #openstack-keystone | 18:12 | |
*** doddstack has joined #openstack-keystone | 18:12 | |
*** gordc has left #openstack-keystone | 18:12 | |
mat-lowery | OK. Not sure how simple it is. You were helping me with https://review.openstack.org/#/c/68015/ a few weeks ago. I have some follow-up questions. I can ping you later. It's basically about using ServiceCatalog.factory in the absence of a raw keystone response. (I'm on the server and keystoneclient.middleware.auth_token has already authenticated the user.) | 18:14 |
*** thedodd has quit IRC | 18:14 | |
jamielennox | mat-lowery: sure, i remember | 18:15 |
jamielennox | and that's ok - what are you needing from the factory? | 18:16 |
jamielennox | oh - i bet i know if you're server side - there is no way to distinguish between v2 and v3 | 18:16 |
mat-lowery | right | 18:17 |
jamielennox | https://bugs.launchpad.net/python-keystoneclient/+bug/1302970 | 18:17 |
uvirtbot | Launchpad bug 1302970 in python-keystoneclient "middleware provides no way to know if a catalog is v2 or v3" [High,Triaged] | 18:17 |
jamielennox | mat-lowery: yea, i'm struggling to see a good way to adapt that in auth_token middleware | 18:18 |
jamielennox | it's one of the biggest blockers for v2/v3 | 18:19 |
mat-lowery | I can hard code to instantiate ServiceCatalogV2 but that was precisely you're initial problem: "Please don't do this you'll just end up broken for v3 tokens." | 18:19 |
mat-lowery | I see. That bug pretty much captures my problem. | 18:20 |
jamielennox | yea, i hadn't realized the extent of the problem by then i think | 18:21 |
jamielennox | there is a way to distinguish but it's not useful for factory (and it could be error prone) | 18:21 |
jamielennox | i'd still reccomend you go via factory() | 18:21 |
jamielennox | nova just wraps a serviceCatalog element around it all and assumes v2 | 18:21 |
jamielennox | honestly i don't have much of a better solution - if you stick with the keystoneclient catalog then at least you will get the change when we figure out what it is | 18:22 |
mat-lowery | Just to be clear, I won't get any changes automatically right? Since I'll be forcing it down the v2 route with the serviceCatalog key. | 18:24 |
mat-lowery | I think I'm going to need to make factory happy here too: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/service_catalog.py#L35-35 | 18:25 |
jamielennox | mat-lowery: join #openstack-meeting we just started talking about it | 18:26 |
mat-lowery | ok | 18:26 |
*** gokrokve_ has quit IRC | 18:30 | |
*** gokrokve has joined #openstack-keystone | 18:35 | |
jamielennox | mat-lowery: ok that seems to have got off track | 18:39 |
jamielennox | mat-lowery: but i think in the short term i'll try and convert a v3 catalog into a v2 catalog | 18:39 |
openstackgerrit | Raildo Mascena de Sousa Filho proposed a change to openstack/keystone: Filter User by project https://review.openstack.org/84136 | 18:39 |
jamielennox | and then add a new header for the proper catalog that can be consumed later | 18:39 |
*** gokrokve has quit IRC | 18:39 | |
openstackgerrit | Priti Desai proposed a change to openstack/keystone: Adding one more check on project_id https://review.openstack.org/85199 | 18:40 |
mat-lowery | jamielennox: Just to confirm: You'll change middleware to attempt parsing of a v2 or v3 service catalog in the "serviceCatalog" key? | 18:41 |
jamielennox | mat-lowery: i'll convert the catalog that is returned in auth_token middleware so what is returned via X_SERVICE_CATALOG is a v2 token without a serviceCatalog key | 18:42 |
jamielennox | so exactly what you get now if you use v2 tokens | 18:42 |
openstackgerrit | Raildo Mascena de Sousa Filho proposed a change to openstack/keystone: Filter User by project https://review.openstack.org/84136 | 18:42 |
jamielennox | so to use it you would wrap a 'serviceCatalog' key around it and pass it to ServiceCatalog.factory | 18:43 |
mat-lowery | So even on v3 keystone, X_SERVICE_CATALOG will contain a v2-compatible service catalog? | 18:43 |
mat-lowery | sorry, I'm trying to keep up | 18:43 |
mat-lowery | no need to explain. I understand your directions. I'll watch the bug report to see how it's fixed. | 18:44 |
jamielennox | mat-lowery: yes, that's the plan - X_SERVICE_CATALOG will b3 a v2 catalog regardless of token format | 18:44 |
mat-lowery | jamielennox: thanks!! | 18:45 |
*** doddstack has quit IRC | 18:46 | |
*** lnxnut has quit IRC | 18:47 | |
*** zuqiang has quit IRC | 18:57 | |
morganfainberg | so back here. | 18:59 |
dstanek | morganfainberg: that would be interesting - where i used to work our token was created with struct | 18:59 |
ayoung | morganfainberg, lets not go binary, please | 18:59 |
topol | how would our curl examples look with binary tokens??? | 18:59 |
ayoung | topol, they would still be base64ed | 19:00 |
morganfainberg | ayoung, if we go binary, i'd use a standardized lib to do it (e.g. protobuf) | 19:00 |
dstanek | topol: they'd still be base64 | 19:00 |
gyee | dumb question, if I add an email address to .mailmap would my openstack emails go to both addresses? | 19:00 |
*** browne has quit IRC | 19:00 | |
topol | K, I guess I need to see what the binary example looked like | 19:00 |
dolphm | bknudson: http://pasteraw.com/6o2b3k48gb8wubyjz6ln843qv2e4lbu | 19:00 |
morganfainberg | ayoung, but i refuse to create our own binary format. | 19:00 |
bknudson | I was kidding about the binary tokens!! | 19:00 |
topol | bknudson | 19:00 |
ayoung | morganfainberg, the IDs are still character strings. that is the big part. The rest of the JSON overhead is " and { stuff...minor | 19:00 |
*** gokrokve has joined #openstack-keystone | 19:01 | |
topol | see what happens when you make jokes | 19:01 |
topol | someone loses an eye | 19:01 |
morganfainberg | gyee, shouldn;'t it should only be used for correlating data externally for git | 19:01 |
bknudson | I'll put a one-eyed person to remind everyone next time -- ;( | 19:01 |
morganfainberg | ayoung, sure, we should at the very least keep (in-tree) json schema for the tokens. | 19:01 |
ayoung | morganfainberg, I think you are now officially taking the joke too far | 19:02 |
morganfainberg | ayoung, ;) | 19:02 |
ayoung | N-E Ways.... | 19:02 |
topol | keystone humor is brutal.... | 19:02 |
morganfainberg | ayoung, i try. | 19:02 |
topol | not enough emitcons | 19:02 |
topol | emoticons | 19:02 |
morganfainberg | o/ | 19:02 |
morganfainberg | \o | 19:02 |
dstanek | jamielennox: you still around? | 19:03 |
jamielennox | dstanek: yep, listening in on the -sdk meeting but i'm here | 19:03 |
morganfainberg | ok so .. in ATL work out (dev lounge probably) any further specifics on token formatting ? | 19:03 |
* morganfainberg needs food now. | 19:03 | |
ayoung | morganfainberg, token pipeline refactoring | 19:03 |
dstanek | jamielennox: adding a couple quick comments to https://review.openstack.org/#/c/78410 | 19:03 |
ayoung | same session | 19:03 |
gyee | morganfainberg, so .mailmap is used for statistics only? | 19:03 |
morganfainberg | ayoung, ++ sounds good! | 19:03 |
*** zigo has quit IRC | 19:04 | |
jamielennox | gyee: i think it's like changing your git commit email, so mostly for attribution | 19:04 |
morganfainberg | gyee, statistics and knowing who is who, if you're submitting with multiple email addresses to git | 19:04 |
morganfainberg | jamielennox, + | 19:04 |
gyee | oic | 19:05 |
morganfainberg | gyee, most of the time you see mailmap entries for people who submit with work email and then change jobs | 19:05 |
ayoung | Here we go: ∠(・`_´・ ) | 19:05 |
morganfainberg | ayoung, what no table flipping? | 19:05 |
ayoung | (^-^)ゝ | 19:05 |
*** topol has quit IRC | 19:05 | |
morganfainberg | (╯°□°)╯︵ ┻━┻ | 19:05 |
gyee | I am kindda fedup with my internal email server right now | 19:06 |
stevemar | (╯°□°)╯︵ ┻━┻) | 19:06 |
ayoung | ヽ(`Д´)ノ︵ ┻━┻ | 19:06 |
morganfainberg | ┬─┬ ノ( ゜-゜ノ) | 19:06 |
ayoung | ¯\_(ツ)_/¯ | 19:07 |
morganfainberg | see what topol did, he started this and left IRC | 19:07 |
*** zigo has joined #openstack-keystone | 19:07 | |
jamielennox | dstanek: i don't see your comments | 19:08 |
jamielennox | dstanek: oh, adding as in in progress | 19:08 |
dstanek | jamielennox: just submitted | 19:09 |
*** browne has joined #openstack-keystone | 19:10 | |
*** kun_huang has quit IRC | 19:12 | |
*** derek_c has joined #openstack-keystone | 19:28 | |
*** thedodd has joined #openstack-keystone | 19:30 | |
stevemar | dolphm, any word on what we should do with the security docs? | 19:33 |
stevemar | is it going to live somewhere else? | 19:33 |
harlowja_ | hey guys, made, https://blueprints.launchpad.net/keystone/+spec/bulk-operations (hopefully for juno) if u guys think its bad, good, needs adjustment let me know :) | 19:34 |
harlowja_ | *hopefully makes sense* | 19:34 |
dolphm | stevemar: i think the consensus last week was to use the wiki | 19:34 |
dolphm | nasty bug https://bugs.launchpad.net/keystone/+bug/1308218 | 19:35 |
uvirtbot | Launchpad bug 1308218 in keystone "keystone.tenant.list_users returns user multiple times" [Medium,Triaged] | 19:35 |
openstackgerrit | guang-yee proposed a change to openstack/python-keystoneclient: Implement endpoint filtering functionality on the client side. https://review.openstack.org/82713 | 19:36 |
*** lbragstad has left #openstack-keystone | 19:37 | |
*** chandan_kumar has joined #openstack-keystone | 19:40 | |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Fix typo of ANS1 to ASN1 https://review.openstack.org/87069 | 19:40 |
stevemar | dolphm, i think i'll abandon the change then, i'll add the comments to the wiki | 19:41 |
*** gyee has quit IRC | 19:43 | |
*** ayoung has quit IRC | 19:44 | |
*** bach_ has joined #openstack-keystone | 19:45 | |
*** chandan_kumar has quit IRC | 19:48 | |
*** browne has quit IRC | 19:49 | |
*** browne has joined #openstack-keystone | 19:49 | |
*** browne has quit IRC | 19:50 | |
*** browne has joined #openstack-keystone | 19:51 | |
*** browne has joined #openstack-keystone | 19:51 | |
*** browne has quit IRC | 19:51 | |
*** browne has joined #openstack-keystone | 19:52 | |
*** chandan_kumar has joined #openstack-keystone | 19:55 | |
*** lbragstad has joined #openstack-keystone | 19:55 | |
*** praneshp has quit IRC | 19:55 | |
*** praneshp has joined #openstack-keystone | 19:56 | |
morganfainberg | dolphm oh icky bug | 20:05 |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Sync with oslo-incubator 2fd457b https://review.openstack.org/83966 | 20:15 |
bknudson | the only conflict with ^ was in the sample config file | 20:15 |
morganfainberg | bknudson, ah ok | 20:16 |
*** chandan_kumar has quit IRC | 20:18 | |
*** bach_ has quit IRC | 20:19 | |
bknudson | http://logs.openstack.org/68/73368/10/check/gate-keystone-python26/184f2e8/console.html -- we've got some data for bug 1300581 | 20:19 |
uvirtbot | Launchpad bug 1300581 in keystone "test_revoke.RevokeTreeTests.test_cleanup fails" [Critical,Triaged] https://launchpad.net/bugs/1300581 | 20:19 |
*** morganfainberg is now known as morganfainberg_Z | 20:20 | |
*** morganfainberg_Z is now known as morganfainberg | 20:21 | |
openstackgerrit | Raildo Mascena de Sousa Filho proposed a change to openstack/keystone: Filter User by project https://review.openstack.org/84136 | 20:30 |
*** bach has joined #openstack-keystone | 20:31 | |
*** Chicago has quit IRC | 20:32 | |
*** lnxnut has joined #openstack-keystone | 20:34 | |
*** lnxnut has quit IRC | 20:35 | |
*** lnxnut has joined #openstack-keystone | 20:35 | |
*** dstanek has quit IRC | 20:38 | |
*** Chicago has joined #openstack-keystone | 20:38 | |
*** andreaf has quit IRC | 20:41 | |
*** dstanek has joined #openstack-keystone | 20:45 | |
*** browne has quit IRC | 20:54 | |
*** ayoung has joined #openstack-keystone | 20:56 | |
*** gyee has joined #openstack-keystone | 20:57 | |
*** harlowja_ has quit IRC | 20:58 | |
*** marcoemorais has quit IRC | 21:02 | |
*** marcoemorais has joined #openstack-keystone | 21:02 | |
*** harlowja has joined #openstack-keystone | 21:03 | |
*** zigo has quit IRC | 21:06 | |
*** zigo has joined #openstack-keystone | 21:08 | |
dolphm | jamielennox: releasing keystoneclient 0.8.0 in next 24 hours | 21:09 |
jamielennox | ah, | 21:09 |
dolphm | jamielennox: per cross-project meeting (heat needs the critical race fix) | 21:09 |
jamielennox | dolphm: having https://review.openstack.org/#/c/78410/ would be really good | 21:10 |
dolphm | jamielennox: looking | 21:10 |
*** bach_ has joined #openstack-keystone | 21:10 | |
jamielennox | https://review.openstack.org/#/c/87411/ needs to happen as it's a failure | 21:10 |
dolphm | jamielennox: a failure of what? | 21:11 |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Advertise extensions for v3. https://review.openstack.org/87786 | 21:11 |
jamielennox | the exception mentioned doesn't exist | 21:11 |
jamielennox | because of the oslo.apiclient exceptions change | 21:11 |
*** bach has quit IRC | 21:11 | |
jamielennox | this: https://review.openstack.org/#/c/78878/ useful as V2 is already merged and then i can start looking at other clients - but not essential | 21:12 |
jamielennox | that's all for me i think | 21:12 |
*** browne has joined #openstack-keystone | 21:14 | |
stevemar | bknudson, where in the api spec does it say /v3/extensions will list extensions? | 21:14 |
bknudson | stevemar: it's in the api doc | 21:14 |
bknudson | did I say spec/ | 21:14 |
stevemar | i think so? | 21:15 |
stevemar | nope, doc | 21:15 |
stevemar | my bad | 21:15 |
bknudson | stevemar: http://api.openstack.org/api-ref-identity-v3.html#identity-v3-ext | 21:15 |
dolphm | http://api.openstack.org/api-ref-identity-v3.html is just a bunch of lies | 21:15 |
stevemar | where is that even maintained? | 21:16 |
stevemar | if it's lies, then we should remove it | 21:16 |
bknudson | dolphm: we're trying to throw users off so they don't get too comfortable. | 21:16 |
dolphm | openstack/openstack-api-site i think? | 21:16 |
stevemar | ahh, the 'keeping them on their toes' strategy | 21:16 |
bknudson | dolphm: stevemar: I've made several updates to those docs. | 21:16 |
dolphm | we get a ton of bug reports because we don't match the crap that has landed in that doc | 21:16 |
stevemar | sounds like something we should fix | 21:17 |
dolphm | is it being produced from XSD's? | 21:17 |
praneshp | jamielennox: ping | 21:18 |
dolphm | all the types are xsd:string etc | 21:18 |
jamielennox | praneshp: hey | 21:18 |
praneshp | jamielennox: I was talking to you about bulk operations for keystone yesterday | 21:18 |
praneshp | https://blueprints.launchpad.net/keystone/+spec/bulk-operations | 21:18 |
bknudson | dolphm: stevemar: https://review.openstack.org/#/c/87393/ is an example of a change. | 21:18 |
*** browne has joined #openstack-keystone | 21:18 | |
bknudson | dolphm: I don't know where xsd:string comes from. | 21:18 |
praneshp | jamielennox: ^^ is what i wanted feedback on. | 21:18 |
bknudson | That's one of the global problems I have with these docs that makes it hard to contribute | 21:19 |
jamielennox | dolphm, bknudson, morganfainberg, dstanek, stevemar: ^^ bulk operations blueprint | 21:19 |
morganfainberg | jamielennox, ohai | 21:19 |
jamielennox | we were discussing it yesterday but it's not specific to me | 21:19 |
morganfainberg | jamielennox, in a meeting, (and was watching release meeting sideband) i'll look when done here | 21:19 |
praneshp | thanks jamielennox | 21:20 |
*** tomoiaga has left #openstack-keystone | 21:20 | |
morganfainberg | s/release/cross project | 21:20 |
jamielennox | morganfainberg: that's ok, just pinging more people than myself | 21:20 |
bknudson | do we need bulk operations only because we don't have streaming operations? or keepalive TCP? | 21:20 |
morganfainberg | jamielennox, ok | 21:20 |
bknudson | I mean keepalive HTTP | 21:20 |
morganfainberg | oh right saw the start of that. | 21:20 |
praneshp | bknudson: no, to workaround doing things one by one | 21:22 |
praneshp | we dind't face issues due to sockets dying, etc | 21:23 |
morganfainberg | bknudson, i think this would be to do something like delete all users in group X | 21:23 |
morganfainberg | praneshp, ^ is that a usecase? | 21:23 |
praneshp | morganfainberg: correct | 21:23 |
praneshp | get the delta from a list of employees or something, and add them all to our openstack infra | 21:23 |
jamielennox | praneshp: do you think with an API like that you would continually be adding more targets for bulk operations | 21:23 |
praneshp | and nuke those who left | 21:24 |
bknudson | ok, if that's the case then the blueprint doesn't have enough information | 21:24 |
bknudson | we should switch to nova's system. | 21:24 |
praneshp | jamielennox: I don't plan to. This has been our API for a while now. | 21:25 |
praneshp | but that's just our use case | 21:25 |
praneshp | so not sure if someone would want to add more targets if they take a similar approach | 21:25 |
jamielennox | bknudson: what is nova's system? | 21:27 |
jamielennox | that's useful context to have | 21:27 |
bknudson | jamielennox: they review blueprints in gerrit | 21:27 |
bknudson | jamielennox: https://review.openstack.org/#/q/status:open+project:openstack/nova-specs,n,z | 21:28 |
praneshp | jamielennox: i htink he's talking about opentack/nova-specs | 21:28 |
bknudson | I didn't realize they had so many in review... wow | 21:28 |
praneshp | bknudson: I'd love to hear more feedback about the blueprint, sorry if it isn't as complete as youd like. | 21:28 |
dolphm | bknudson: russell mandated that if it wasn't proposed against openstack/nova-specs, it wouldn't land in juno | 21:29 |
praneshp | bknudson: "here is a need at least at yahoo to increase the performance of keystone under certain operations (such as creating many users, fetching many users, adding many tenants to many roles, creating many tenants and so-on). " | 21:30 |
jamielennox | dolphm: let's have that for keystone - no-one looks at the blueprints | 21:30 |
morganfainberg | jamielennox, i think infra asked projects to hold off on that | 21:30 |
stevemar | jamielennox, i try to, but the bps are a complete mess | 21:30 |
dolphm | jamielennox: i'd prefer to use gerrit, but i'm wondering if using gerrit will improve the quality of blueprints | 21:30 |
openstackgerrit | A change was merged to openstack/keystone: Moves test database setup/teardown into a fixture https://review.openstack.org/85651 | 21:30 |
morganfainberg | jamielennox, until they see how nova/etc does it | 21:30 |
morganfainberg | jamielennox, LP is the mess, cc stevemar | 21:30 |
morganfainberg | not the bps. | 21:30 |
dolphm | morganfainberg: blueprints are a mess too | 21:31 |
stevemar | morganfainberg, there are so many dupes | 21:31 |
morganfainberg | dolphm, i think that is a symptom of LP. | 21:31 |
dolphm | morganfainberg: i've seen blueprints with one line descriptions that claim to be "Approved" | 21:31 |
morganfainberg | stevemar, ^ | 21:31 |
stevemar | dolphm, ++ | 21:31 |
dolphm | no external reference, no nothing | 21:31 |
morganfainberg | like i said, i think this is a symptom of LP being far sub-optimal | 21:31 |
* morganfainberg wants storyboard. | 21:32 | |
dolphm | morganfainberg: but will gerrit improve crap like that? | 21:32 |
stevemar | LP's link to external api spec (or whatever it is) is awful | 21:32 |
morganfainberg | dolphm, i think gerrit/ git is thr wrong tool, i don't have a better tool therefore it is the best current method | 21:32 |
morganfainberg | dolphm, it would likely be wayyyyy better than what we have | 21:32 |
jamielennox | that and approved or not is a very easy thing to set - and there is no check that something is approved before people start submitting patches | 21:33 |
morganfainberg | dolphm, so i def support using better tools, but i want to eventually move to the best tool for the job. | 21:33 |
*** bknudson has quit IRC | 21:33 | |
morganfainberg | dolphm, gerrit/git is the best option today. but likely will be a 2-3 cycle choice if other tools spin up and become useful. | 21:33 |
morganfainberg | dolphm, provided we do the same-ish thing nova is doing | 21:33 |
jamielennox | praneshp: so do the bulk operations adhere to the standard GET/DELETE and whateer? | 21:33 |
jamielennox | whatever* | 21:34 |
praneshp | jamielennox: yes, | 21:34 |
dolphm | nova-specs is evolving quickly... i'm hoping it stabilizes by summit time :) | 21:34 |
praneshp | jamielennox: scratch that | 21:34 |
praneshp | I have to get back on that | 21:34 |
morganfainberg | dolphm, ++ | 21:34 |
dolphm | maybe we can use it for juno-2 forward | 21:34 |
jamielennox | i think it would be useful to flesh it out more - including attempting an identity-api review specifying the whole API | 21:34 |
praneshp | jamielennox: sure, we're still drafting the bp | 21:35 |
jamielennox | praneshp: i'd be interested to see things like how you specify multiple id | 21:35 |
praneshp | "identity-api review " ? | 21:35 |
jamielennox | things like bulk update do you specify id's and changes or change per id | 21:35 |
praneshp | ok. | 21:35 |
dolphm | praneshp: openstack/identity-api | 21:36 |
jamielennox | praneshp: https://review.openstack.org/#/q/project:openstack/identity-api,n,z | 21:36 |
jamielennox | praneshp: https://github.com/openstack/identity-api/ | 21:36 |
openstackgerrit | Brant Knudson proposed a change to openstack/python-keystoneclient: auth_token middleware hashes tokens with configurable algorithm https://review.openstack.org/80398 | 21:36 |
jamielennox | so before you can implement something that touches the actual API there needs to be a fairly strict specification | 21:36 |
praneshp | Ok, this is just the Keystone rest api, correct? | 21:36 |
jamielennox | yes | 21:36 |
dolphm | morganfainberg: i'm also curious to see how well (or not) nova-specs serves as documentation | 21:36 |
praneshp | great. | 21:36 |
*** bknudson has joined #openstack-keystone | 21:37 | |
jamielennox | praneshp: generally bickering over details and ideas happens on the identity-api review. Blueprints are fairly high level and conceptual and most people don't have a strong opinion until there are details | 21:37 |
jamielennox | and blueprints are often completely out of date | 21:37 |
praneshp | jamielennox: got it. I'm fairly certain there is no change to the identity-api | 21:38 |
jamielennox | praneshp: extensions are in there as well | 21:38 |
jamielennox | anything maintained in the tree | 21:38 |
praneshp | jamielennox: yeah, I tried to make a couple of nova bps for Juno, but held off because they existed. | 21:38 |
praneshp | thought they were more than a year old, etc | 21:38 |
praneshp | thanks a lot dolphm jamielennox bknudson morganfainberg. I'll work a bit more on the bp. | 21:38 |
jamielennox | yep, blueprints seem to be a straight dump of an idea - sometimes lots of detail, sometimes nothing | 21:39 |
bknudson | that's what the nova-specs system is trying to solve | 21:39 |
jamielennox | bknudson: ++, and i like it | 21:39 |
*** nkinder has joined #openstack-keystone | 21:39 | |
bknudson | also, it gives them a chance to "reset" their blueprints... get rid of abandoned ones. | 21:40 |
bknudson | they'll probably have to come up with another system to reset again in a year. | 21:40 |
dolphm | jamielennox: the other thing it's solving is that blueprints used to be small enough in number that one person could be expected to review and approve them all - which we've learned doesn't scale! | 21:40 |
dolphm | bknudson: they've already come up with that system | 21:41 |
dolphm | bknudson: they'll create a new directory in nova-specs for the K release, and you'll have to update your nova-specs review to be proposed against that | 21:41 |
dolphm | bknudson: otherwise, your review gets a -1 and it's abandoned in a week! problem solved | 21:41 |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Prefer () to continue line per PEP8 https://review.openstack.org/84010 | 21:42 |
*** nkinder has quit IRC | 21:44 | |
jamielennox | bknudson: regarding extensions i think we should bring back https://review.openstack.org/#/c/40776/ | 21:45 |
jamielennox | it was reverted so that you should just get everything via links in responses | 21:45 |
jamielennox | but i don't think that having that removes the need to check what extensions are enabled on a servr | 21:46 |
jamielennox | both should be available | 21:46 |
bknudson | jamielennox: yes, we need some way to know what extensions are there. | 21:47 |
bknudson | jamielennox: talking with ayoung and dolphm it seems like they'd prefer the extensions in links in /v3 ? | 21:47 |
ayoung | bknudson, I think both | 21:47 |
jamielennox | bknudson: that's why it was reverted | 21:47 |
jamielennox | i think both is appropriate | 21:47 |
*** nkinder has joined #openstack-keystone | 21:48 | |
bknudson | ah, so have a v3/extensions like v2.0/extensions? | 21:48 |
jamielennox | /v3/extensions is a lot easier to get done now and then fix the links as we go | 21:48 |
ayoung | I see no drawback to a specific url just for extensions, but lets get the links part done first? | 21:48 |
dolphm | ayoung: it's redundant with the restful solution | 21:48 |
bknudson | I didn't know we have / documented in the spec, I'll have to update it. | 21:48 |
jamielennox | dolphm: yes - but does it matter | 21:48 |
jamielennox | there is a lot of information that is relevant to the extension that might not be relevant to the objects that the extension provides | 21:49 |
bknudson | https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#list-versions-get- | 21:49 |
jamielennox | eg description, author, homepage ... | 21:49 |
bknudson | although it just says TBD | 21:49 |
jamielennox | bknudson: if you write that have a look at https://wiki.openstack.org/wiki/VersionDiscovery and see what we need to fix up | 21:51 |
ayoung | dolphm, I think the biggest thing missing is not just having extensions in links, but the base modules, too. There should be a link for /v3/users /v3/assignments etc | 21:53 |
dolphm | ayoung: ++ | 21:53 |
morganfainberg | ayoung, ++ | 21:53 |
bknudson | ayoung: in /v3? | 21:53 |
ayoung | I know I hacked that up at one point, as a part of some other patch | 21:54 |
ayoung | bknudson, yes, off the /v3 page | 21:54 |
*** derek_c has quit IRC | 21:54 | |
bknudson | ayoung: what would that look like? I didn't know what to put for "rel" for the extensions. | 21:54 |
ayoung | dolphm, ? | 21:54 |
dolphm | ayoung: ? | 21:54 |
ayoung | dolphm, what would make sense for 'rel' for modules or extensions? | 21:55 |
bknudson | we use "rel" "self", "next", "previous" | 21:55 |
ayoung | bknudson, rel is not in https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md BTW | 21:55 |
ayoung | so we should make it explicit | 21:55 |
dolphm | bknudson: "users" for example | 21:56 |
jamielennox | please make these relative links rather than use CONF.public_endpoint | 21:56 |
bknudson | http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions | 21:56 |
dolphm | bknudson: the rest of v3 smashed those two key value pairs into a single key value pair (and didn't leave room for anything else) | 21:56 |
ayoung | http://www.w3schools.com/TAGS/att_link_rel.asp | 21:56 |
*** daneyon has quit IRC | 21:57 | |
ayoung | I would think "extension" or "module" might be the right value, unless there is a standard | 21:57 |
dolphm | ayoung: "rel": "OS-TRUST:trusts" <-- indicates it's an extension and what is available at the destination url | 21:58 |
jamielennox | dolphm: not that's a pain to parse | 21:58 |
jamielennox | {'rel': 'self', 'url': 'trusts', 'extension': 'extensions/OS-TRUST'} | 21:58 |
dolphm | jamielennox: gotta love xml hand-me-downs | 21:58 |
jamielennox | if 'extension' (maybe 'provider') is not provided then it's core | 21:59 |
jamielennox | 'extension' is a link as well | 21:59 |
dolphm | jamielennox: keystone didn't make up this schema, i'd much rather avoid making up another variation of it | 22:00 |
jamielennox | 'rel': 'self', 'url': 'link' is standard now | 22:00 |
jamielennox | that's what we use for discovery right | 22:00 |
ayoung | 'rel': 'self does not make sense | 22:00 |
ayoung | that is a link to "this document" | 22:01 |
dolphm | ayoung: ++ | 22:01 |
ayoung | so from v3, rel=self would be "http://hostname/v3/" | 22:01 |
jamielennox | i wasn't sure that it was because it's not listed in bknudson's above link | 22:01 |
*** rupsky has quit IRC | 22:01 | |
ayoung | I would thinkg 'rel'='module' or 'rel'='extension' would be OK | 22:01 |
bknudson | looks like 'rel': 'self' is from the atom format. | 22:02 |
ayoung | category is a bit of a stretch | 22:02 |
bknudson | http://www.ietf.org/rfc/rfc4287.txt | 22:02 |
dolphm | jamielennox: the goal with prefixing is to avoid collisions between extensions (i.e. two extensions trying to inject links to a "rel": "objects" shouldn't cause ambiguity) | 22:02 |
*** marcoemorais has quit IRC | 22:02 | |
ayoung | rel='edit' should be a link to the schema for JSON and an form in HTML (if we were to do that) | 22:02 |
*** marcoemorais has joined #openstack-keystone | 22:03 | |
*** harlowja has quit IRC | 22:03 | |
jamielennox | current output of discovery: http://paste.openstack.org/show/75837/ | 22:03 |
jamielennox | this is what i was basing the 'rel': 'self' on | 22:03 |
ayoung | each of the modules should have a landing page. GET /v3/users GET /extensions/OS-TRUSTS | 22:03 |
jamielennox | ayoung: ++ extensions should be a limited CRUD as well | 22:04 |
ayoung | and each of those langin pages should have "rel="home" point to /v3 or even one level up | 22:04 |
jamielennox | ayoung: is 'home' something you made up? is there a format for this anywhere? | 22:04 |
ayoung | I just saw it | 22:04 |
*** david_lyle_ has joined #openstack-keystone | 22:04 | |
ayoung | http://microformats.org/wiki/rel-home | 22:04 |
*** harlowja has joined #openstack-keystone | 22:05 | |
jamielennox | ok, sure that should be /v3 | 22:05 |
dolphm | ayoung: i'd be curious to see an actual use case | 22:06 |
ayoung | dolphm, I was thinkng "auto generating the UI for Horizon" | 22:06 |
ayoung | dolphm, something like this: | 22:06 |
* jamielennox saw that coming :) | 22:06 | |
dolphm | ayoung: how does "rel": "home" address that? | 22:06 |
*** david-lyle has quit IRC | 22:07 | |
ayoung | dolphm, maybe that was the wrong level...home should be the root of whatever...so it might be /v3 for horizon usage | 22:07 |
ayoung | since horizon is not going to talk to v2 once we do this | 22:07 |
ayoung | "Refers to the top level document for the current document. It can be combined with 'alternate' to indicate a feed for the site of the current page. " | 22:08 |
ayoung | calling all of Keystone a document is a bit of a stretch, but maybe if you consider it "the document of what this keystone server supports" it makes sens | 22:09 |
ayoung | e | 22:09 |
ayoung | http://microformats.org/wiki/rel-category might not be a bad abstraction for both extensions and modules | 22:09 |
ayoung | subresource also would apply | 22:11 |
jamielennox | interesting, close-ish to what we do now: http://blog.stateless.co/post/13296666138/json-linking-with-hal | 22:12 |
jamielennox | better: http://json-schema.org/latest/json-schema-hypermedia.html | 22:14 |
jamielennox | WSME would be nice to have but i'm loving jsonschema more and more | 22:15 |
*** dstanek has quit IRC | 22:19 | |
jamielennox | dolphm: does jenkins -1 on https://review.openstack.org/#/c/78410/ pull it from gate? i don't see it on zuul | 22:20 |
*** stevemar has quit IRC | 22:22 | |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Rename HTTPError -> HttpError https://review.openstack.org/87411 | 22:22 |
*** morganfainberg is now known as morganfainberg_Z | 22:23 | |
*** browne has quit IRC | 22:25 | |
*** browne has joined #openstack-keystone | 22:26 | |
*** nkinder has quit IRC | 22:27 | |
*** henrynash has quit IRC | 22:30 | |
*** browne has quit IRC | 22:30 | |
*** browne has joined #openstack-keystone | 22:31 | |
*** marcoemorais has quit IRC | 22:33 | |
*** marcoemorais has joined #openstack-keystone | 22:33 | |
dolphm | jamielennox: it's not gating, it's doing a check run first | 22:34 |
jamielennox | dolphm: yea, i did a recheck | 22:34 |
dolphm | jamielennox: with a recent passing check and a +A, it'll enter the gate | 22:34 |
jamielennox | ok, if not i'll make sure it passes today | 22:35 |
*** bknudson has quit IRC | 22:41 | |
*** thedodd has quit IRC | 22:41 | |
*** dims has quit IRC | 22:44 | |
*** dstanek has joined #openstack-keystone | 22:46 | |
*** henrynash has joined #openstack-keystone | 22:52 | |
*** browne has quit IRC | 22:56 | |
*** david_lyle_ has quit IRC | 22:57 | |
*** dims has joined #openstack-keystone | 22:57 | |
*** praneshp has quit IRC | 23:11 | |
*** praneshp has joined #openstack-keystone | 23:14 | |
*** dstanek has quit IRC | 23:18 | |
*** Krsna has joined #openstack-keystone | 23:23 | |
*** gokrokve has quit IRC | 23:24 | |
Krsna | morganfainberg_Z: Just a quick update. Federated keystone has been officaly accepted :D. I am assigned a few other things that hold higher priority. However, once those are done I will be looking forward to working with you! | 23:25 |
*** Krsna has quit IRC | 23:25 | |
marekd | morganfainberg_Z: what Krsna meant by saying "Federated keystone has been officially accepted" ? | 23:29 |
*** morganfainberg_Z is now known as morganfainberg | 23:31 | |
*** openstackstatus has quit IRC | 23:32 | |
morganfainberg | marekd, krsna is saying that there wikll be resources allocated to help work on getting keystone able to provide a federated Identity to another keystone | 23:32 |
morganfainberg | marekd, e.g. internal SQL or LDAP to another cloud. | 23:32 |
morganfainberg | marekd, s/wikll/will | 23:32 |
*** openstackstatus has joined #openstack-keystone | 23:32 | |
marekd | morganfainberg: saml2 and stuff. | 23:33 |
morganfainberg | marekd, that is the plan | 23:33 |
marekd | morganfainberg: ok, i was was accepting that. I now see this is some thing inside company/org | 23:35 |
marekd | i was wondering who was accepting that* | 23:35 |
morganfainberg | marekd, yeah krsna was saying employer accepted dedicating resources to it | 23:37 |
morganfainberg | marekd, yeah | 23:37 |
marekd | morganfainberg: ok | 23:38 |
marekd | good to know. | 23:38 |
morganfainberg | i also pointed krsna at you and stevemar as people working on the federation stuff on the other side | 23:38 |
morganfainberg | so expect to be roped in some. | 23:39 |
*** derek_c has joined #openstack-keystone | 23:41 | |
marekd | morganfainberg: that's good, cause I started wondering if you even associate myself with the federation work after you started explaining what it is :P | 23:44 |
morganfainberg | marekd, wait what? :P | 23:44 |
morganfainberg | marekd, dude..... you've done awesome work on it | 23:45 |
morganfainberg | marekd, sorry if i haven't said it enough :( | 23:45 |
marekd | morganfainberg: hey, no worries! that was not my point :-) | 23:45 |
morganfainberg | hehe | 23:46 |
morganfainberg | marekd, very pleased with where it is going. i want more of it though, so .... | 23:47 |
marekd | morganfainberg: sure, another pair of hands is always very welcome. | 23:47 |
*** henrynash has quit IRC | 23:47 | |
morganfainberg | marekd, soooo *aims the willing contributors your way* | 23:47 |
*** bach_ has quit IRC | 23:48 | |
morganfainberg | marekd, :) | 23:48 |
morganfainberg | marekd, don't think federation would ahve turned out nearly as well w/o your tireless work on it (ok maybe not tireless, but extensive) | 23:49 |
morganfainberg | marekd, don't know if it prevented sleep or not :) | 23:49 |
marekd | morganfainberg: thanks :-) | 23:50 |
marekd | however, still lots of things pending ;/ | 23:51 |
*** gokrokve has joined #openstack-keystone | 23:51 | |
morganfainberg | yeah. but hey the client stuff is coming togther now as well | 23:51 |
morganfainberg | marekd, i kindof want to see the federation work being the basis for all identity not just external identity | 23:52 |
marekd | morganfainberg: yeah, heard the rumors...:-) | 23:52 |
morganfainberg | marekd, i think we have a summit session proposal on that as well. | 23:53 |
*** gokrokve has quit IRC | 23:54 | |
marekd | morganfainberg: you mean federation in general ? stevemar proposed one long time ago. | 23:54 |
morganfainberg | marekd, maybe. i haven't looked at the proposals today... seems like each time i look there are more! | 23:55 |
marekd | cool! | 23:55 |
*** dstanek has joined #openstack-keystone | 23:55 | |
*** ChanServ changes topic to "Restarting gerrit really quick to fix replication issue" | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!