Tuesday, 2014-04-15

*** cynosure_ has joined #openstack-keystone00:01
*** wchrisj has joined #openstack-keystone00: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.py00:05
*** wchrisj has quit IRC00:10
*** shakamunyi has joined #openstack-keystone00:11
jamielennoxcynosure_:  the above sudo thing are you sure that was the apache user not having permission or your local user doesn't have permission00:14
jamielennoxswitch to root and try the sudo line again00:15
*** thedodd has joined #openstack-keystone00:50
*** dims has quit IRC00:52
*** cynosure_ has quit IRC00:53
*** browne has quit IRC00:53
*** shakamunyi has quit IRC00:54
*** cynosure_ has joined #openstack-keystone00:56
*** thedodd has quit IRC00:56
*** cynosure_ has quit IRC00:58
*** thedodd has joined #openstack-keystone00:58
*** cynosure_ has joined #openstack-keystone01:01
*** cynosure_ has quit IRC01:06
*** Mikalv has quit IRC01:13
*** Mikalv has joined #openstack-keystone01:13
*** thedodd has quit IRC01:15
*** stevemar has joined #openstack-keystone01:19
*** stevemar has quit IRC01:19
*** stevemar has joined #openstack-keystone01:24
*** marcoemorais has quit IRC01:24
*** gyee has quit IRC01:35
*** jamiec has joined #openstack-keystone01:41
*** richm has quit IRC01:46
*** Daviey has quit IRC01:47
*** jzl-ctrip has joined #openstack-keystone01:48
*** amcrn has quit IRC01:50
*** pjzl-ctri has joined #openstack-keystone01:51
pjzl-ctrihi,all,it seems the local variable 'config' in each factory functions in keystone/service.py is undesired.01:51
*** Daviey has joined #openstack-keystone01:51
*** harlowja has quit IRC01:52
*** harlowja_ has joined #openstack-keystone01:52
*** jzl-ctrip has quit IRC01:52
jamielennoxpjzl-ctri: i'm not sure what you mean01:53
*** pjzl-ctri has quit IRC01:55
openstackgerritA change was merged to openstack/python-keystoneclient: Add CRUD operations for Federation Mapping Rules.  https://review.openstack.org/8374201:57
*** Daviey has quit IRC02:01
*** Daviey has joined #openstack-keystone02:04
morganfainbergjamielennox, ok that didn't make sense to me either02:07
*** cloud_ has joined #openstack-keystone02:07
*** cloud_ is now known as jzl-ctrip02:07
jamielennoxmorganfainberg: i figured it out02:07
morganfainbergjamielennox, what was it?02:07
jamielennoxfor example here: https://github.com/openstack/keystone/blob/master/keystone/service.py#L85-L8702:08
jamielennoxwe do a thing to copy and then update a conf object and then never use it02:08
morganfainbergjamielennox, i see.02:08
jamielennoxi've seen that before just never fixed it02:08
morganfainbergsure we should fix that.02:08
jamielennoxi'm not sure what was ever intended to be done with those paste options02:08
jamielennoxmorganfainberg: as in you're doing that now?02:10
morganfainbergjamielennox, neg02:12
morganfainbergjamielennox, have other things to do before i can say "lets clean that up" personally02:12
morganfainbergand i think i still have a chunk of reviewing to do02:12
jamielennoxmorganfainberg: alright, i may as well i'm waiting for something to finish anyway02:12
morganfainbergi think the cost of that is minimal and not feeling like chasing it down if it causes issues.02:12
morganfainbergnot that i expect it would02:12
morganfainbergit 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
jamielennoxmorganfainberg: it's quicker to fix it than file the bug02:13
*** pjzl-ctri has joined #openstack-keystone02:13
morganfainberghehe sure!02:13
*** jzl-ctrip has quit IRC02:14
morganfainbergshould prob. file a bug in either case >.>02:14
morganfainbergwas my point :P02:14
morganfainbergthat whole... track things we change02:14
*** pjzl-ctri has quit IRC02:15
jamielennoxergh, so i can expect you to be a stickler for that from now on then02:16
*** ayoung has quit IRC02:19
openstackgerritJamie Lennox proposed a change to openstack/keystone: Remove unnecessary dict copy  https://review.openstack.org/8743002:21
openstackgerritNathanael I Burton proposed a change to openstack/python-keystoneclient: Fix typo of ANS1 to ASN1  https://review.openstack.org/8706902:23
*** david-lyle has joined #openstack-keystone02:38
openstackgerritA change was merged to openstack/keystone: Updated from global requirements  https://review.openstack.org/8576202:39
jamielennoxmorganfainberg and anyone else here: can you think of a better name for https://review.openstack.org/#/c/86237/02:47
*** ayoung has joined #openstack-keystone02:49
ayoungjamielennox, 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
ayoungThe question, though, is whether NSS as an alternative to openssl is viable in Python.02:50
ayoungI 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 IRC02:56
*** dstanek has joined #openstack-keystone02:57
openstackgerritMatt Fischer proposed a change to openstack/keystone: Make the LDAP debug option a configurable setting  https://review.openstack.org/8706802:57
*** mberlin has quit IRC02:59
jamielennoxayoung: it does have a long way but i know it's on there roadmap03:02
jamielennoxi'd say nss is a viable alternative - everything is there03:02
ayoungjamielennox, yeah on both accounts03:02
jamielennoxand i'd say it should be looked at earlier rather than later so it doesn't end up with PEM by default or something stupid03:02
jamielennoxthough i know they are taking that stuff into consideration03:02
ayoungI'm wondering if I should take a look at what it would take to get CMS S/MIME working03:03
ayoungyou need to go through DER to get to PEM anyway03:03
jamielennoxayoung: 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 validation03:03
ayoungI'd expect that PEM would be the default at the recipe level03:03
jamielennox'recipe' so you watched that video too :)03:03
ayoungits the need to have an abstraction that covers both the NSS and openSSL way of storing certs that worries me03:03
jamielennoxthat's the first time i've ever heard it called that03:04
ayoungyeah, watched it today in chunks03:04
jamielennoxayoung: indeed03:04
jamielennoxit 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 ok03:04
jamielennoxbut i was doing some messing around with NSS and it is very DB centric03:05
jamielennoxlike it wants you to initialize the lib with a DB and then that gets used for everything03:05
jamielennoxNSS and OpenSSL both have obviously started life as an application and had a half-hearted attempt at making a library03:05
ayoungyes, the DB approach is probably more likely to sneak over to the openssl side than the reverse03:05
ayoungopenssl is doing more to lock down the direcotory where you store the certs03:06
ayoungthe DB in NSS case is pretty much: this directory and this set of berkeleydb files03:06
jamielennoxoh, i get it - it just means you have a stateful library03:06
ayoungjamielennox, just checked and my blog post on this from last year is still valid03:06
jamielennoxand there's no real concept of having the library work with multiple databases03:07
ayoungrun that and you see what a minimal nss database looks like03:07
ayoungits go03:07
ayoungcert8.db  key3.db  secmod.db03:08
jamielennoxayoung: oh i know, i've done all that03:08
ayoungwell, it has changed a bit over time03:08
jamielennoxi'm more talking about the C and python libraries than the cmdline03:08
ayoungit used to be a single file03:08
ayoungbut that abstraction is, what pkcs11?03:08
ayoung12?  I can never keep the numbers straight03:08
ayoung11 is the database03:09
ayoung12 is tls03:09
jamielennoxyea 1103:09
ayoungthe token stuff that FreeIPA is implementing now03:09
jamielennox11 is the hardware etc common interface03:09
ayoungso the nss DB is the software implementation03:09
jamielennoxso they do a lot of pksc11, but that's not what the library interface usess03:09
jamielennox11 is about how to communicate with hardware etc, the db is a storage mechanism and purely an nss thing AFAIK03:10
ayoungit exposes the same interface, somehow.03:11
ayoungI defer to nalin on things of this ilk03:11
jamielennoxthere is a graphic somewhere that kind of explains it03:11
ayoungI know that doing the 11 stuff is a huge part of the complexity in DOgtag...all the C Code etc03:12
jamielennoxhuh maybe db is lower than i though03:12
jamielennoxbut the work level is all handled via a pkcs11 interface03:13
jamielennoxguess it means you can swap out crypto modules all in one place03:13
ayoungI think what they did is said that the nssdb would implement a software version of the same interface as any other pkcs11 module03:14
*** mberlin has joined #openstack-keystone03:14
jamielennoxanyway, i was going to see if i could make kite use cryptography03:14
jamielennoxhaven't got there yet03:14
ayoungjamielennox, BTW, they moved NSS from CVS to Mercurial, and I used the git-mercurial bridge to check it out...03:15
ayoungits nice03:15
jamielennoxcool, i can never remember how to use hg03:16
jamielennoxit's all the same concepts as git with different names03:16
ayoungit becomes git clone hg::http:// ....03:16
ayoungtempted to push a branch onto github...03:17
*** morganfainberg has quit IRC03:19
*** morganfainberg_Z has joined #openstack-keystone03:19
*** morganfainberg_Z is now known as morganfainberg03:20
*** harlowja_ is now known as harlowja_away03:21
ayoungjamielennox, wget https://raw.github.com/felipec/git/fc/master/git-remote-hg.py -O ~/bin/git-remote-hg03:27
ayounggit clone hg::https://hg.mozilla.org/projects/nspr03:27
ayounggit clone hg::https://hg.mozilla.org/projects/nss03:27
*** ayoung is now known as ayoung-ZZZzzz03:27
jamielennoxsurely that's packaged03:28
jamielennoxthere is a rpm for hg-git and git-hg :(03:28
jamielennoxoh wait, that's obvious03:28
*** zhiyan_ is now known as zhiyan03:30
jamielennoxyep, same thing03:30
*** zhiyan is now known as zhiyan_03:31
*** zhiyan_ is now known as zhiyan03:47
*** dstanek has quit IRC03:52
*** harlowja_away is now known as harlowja_03:53
*** dstanek has joined #openstack-keystone03:54
*** wchrisj has joined #openstack-keystone03:55
*** david_lyle_ has joined #openstack-keystone04:01
*** david-lyle has quit IRC04:01
*** chandan_kumar has joined #openstack-keystone04:08
*** dstanek has quit IRC04:09
*** Guest____ has joined #openstack-keystone04:10
*** wchrisj has quit IRC04:11
*** marcoemorais has joined #openstack-keystone04:13
*** chandan_kumar has quit IRC04:17
*** praneshp has joined #openstack-keystone04:24
praneshpHey guys, anyone working on batching up keystone operations?04:25
*** david_lyle_ has quit IRC04:37
*** david-lyle has joined #openstack-keystone04:38
*** stevemar has quit IRC04:40
*** chandan_kumar has joined #openstack-keystone04:50
*** gokrokve has quit IRC04:51
*** dstanek has joined #openstack-keystone04:51
*** nkinder has joined #openstack-keystone04:52
*** dstanek has quit IRC04:56
morganfainbergpraneshp, what do you mean by batching up keystone operations?04:59
praneshphi morganfainberg I mean doing bulk operations. not one user/tenant at a time05:06
praneshpI have a blueprint in mind to add a bulk operations extension to Keystone05:08
*** harlowja_ is now known as harlowja_away05:37
jamielennoxpraneshp: i've never heard of anyone looking at it - is there any other projects doing that?05:44
jamielennoxin general i would think that keystone is the last of the openstack services to need something like that05:45
praneshpjamielennox: not sure.05:45
jamielennoxbecause once it's running the standard usage is just to get tokens05:45
jamielennoxpraneshp: what's your primary use case?05:45
praneshpjamielennox:  I'l; get back with some sort of a blueprint?05:45
praneshpjamielennox: something like: get a set of users everyday, diff from previous days list, and do some work with the diff05:46
jamielennoxpraneshp: so that won't be allowed because you shouldn't be able to list all users05:46
jamielennoxyes you somewhat can now but in general it's going away05:46
praneshpjamielennox:  list not from keystone05:47
jamielennoxthink of an enterprise with a 50k person LDAP server05:47
praneshpfrom an enterprise to add into keystone, etc05:47
jamielennoxpraneshp: so why would you do that via keystone?05:47
jamielennoxif you are in that situation then keystone is acting as a front end for a more reliable data store05:47
praneshpso if an employee goes away, remove him from keystone, do something with his VMs, and so on05:47
jamielennoxprobably ldap05:47
praneshpand if there are new ones, give them access to your openstack infrastructure.05:48
jamielennoxldap specifically in this case you would auto provision that user05:48
jamielennoxkeystone knowing when a user is removed is a problem with external data sources05:48
jamielennoxthere has been some talk around how to do that with federation and using sources that you can't actually contact to know that05:49
jamielennoxi'm not the best person to talk to about that05:49
praneshpthank you jamielennox05:49
praneshpI'll wait to collect more feedback, and read up some more about ldap.05:50
jamielennoxbut in general if you need batch operations then i'd be thinking about using LDAP as a backend and doing your operations on that directly05:50
jamielennoxusing keystone in that sense is not supposed to hide the fact that you are using another source of users05:50
praneshpLet'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
jamielennoxpraneshp: not really, but your kind of mixing terms05:52
jamielennoxusers exist outside the concept of tenants05:52
jamielennoxie you just have users05:52
jamielennoxthen some of those users have permissions in a tenant05:53
praneshpyeah, I know. And then you add users to tenants, with  role(s) in that tenant05:53
jamielennoxthere's nothing i can think of that would help you batch delete05:53
praneshpsay now I want to nuke all users with role SnapshotCreator in tenant X05:53
jamielennoxyea, i know what you mean - i don't think we export anything like that05:54
jamielennoxit's not a common operation05:54
praneshpyeah, we do it everyday though (for good or bad :|)05:55
praneshpI'll write up a blueprint, gather my ideas into that, and ping you again.05:55
jamielennoxok - then sure i'd propose that05:55
praneshpmaybe a couple of more days05:55
praneshpthanks jamielennox05:55
praneshpI'm new-ish to the community, and people at nova and here have been really helpful.05:56
jamielennoxpraneshp: np, and that's always good to hear05:56
jamielennoxbut i would also recommend looking into a proper LDAP server and running keystone off of that05:56
praneshpyeah, I'll def look into that05:57
openstackgerritJenkins proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/8395506:01
*** jamielennox is now known as jamielennox|away06:07
openstackgerritwanghong proposed a change to openstack/keystone: delete the tokens when deleting ec2 credential  https://review.openstack.org/8745006:30
*** Guest____ has quit IRC06:33
*** Guest____ has joined #openstack-keystone06:34
*** Guest____ has quit IRC07:04
*** tomoiaga has joined #openstack-keystone07:06
*** praneshp has quit IRC07:23
*** leseb has joined #openstack-keystone07:45
*** morganfainberg is now known as morganfainberg_Z07:56
*** ukalifon has joined #openstack-keystone08:01
*** marekd|away is now known as marekd08:06
*** zhiyan is now known as zhiyan_08:10
*** zhiyan_ is now known as zhiyan08:10
*** zhiyan is now known as zhiyan_08:14
*** zhiyan_ is now known as zhiyan08:15
*** marcoemorais has quit IRC08:27
*** ukalifon has quit IRC08:33
*** ukalifon has joined #openstack-keystone08:34
*** derek_c has quit IRC08:35
*** derek_c has joined #openstack-keystone08:37
*** derek_c has quit IRC08:45
*** dims has joined #openstack-keystone09:10
*** zhiyan is now known as zhiyan_09:13
*** zhiyan_ is now known as zhiyan09:15
*** ilives has joined #openstack-keystone09:20
*** marcoemorais has joined #openstack-keystone09:24
*** leseb_ has joined #openstack-keystone09:28
*** marcoemorais has quit IRC09:28
*** leseb has quit IRC09:31
*** leseb_ has quit IRC09:32
openstackgerritSergey Nikitin proposed a change to openstack/keystone: Some methods in ldap were moved to superclass  https://review.openstack.org/8625009:32
*** leseb has joined #openstack-keystone09:33
*** leseb_ has joined #openstack-keystone09:35
*** chandan_kumar has quit IRC09:38
*** leseb has quit IRC09:39
*** andreaf has joined #openstack-keystone09:55
*** chandan_kumar has joined #openstack-keystone09:55
*** marcoemorais has joined #openstack-keystone10:00
openstackgerritSergey Nikitin proposed a change to openstack/keystone: Some methods in ldap were moved to superclass  https://review.openstack.org/8625010:01
*** marcoemorais has quit IRC10:04
*** leseb_ has quit IRC10:18
*** chandan_kumar has quit IRC10:23
*** topol has joined #openstack-keystone10:30
*** ilives has quit IRC10:33
*** chandan_kumar has joined #openstack-keystone10:37
*** ilives has joined #openstack-keystone10:42
*** leseb has joined #openstack-keystone10:49
*** leseb has quit IRC10:53
*** marcoemorais has joined #openstack-keystone11:01
*** marcoemorais has quit IRC11:06
*** david-lyle has quit IRC11:20
*** dims has quit IRC11:22
openstackgerritSergey Nikitin proposed a change to openstack/keystone: Code which gets and deletes elements of tree was moved to one method  https://review.openstack.org/8657811:26
*** dims has joined #openstack-keystone11:29
openstackgerritwanghong proposed a change to openstack/keystone: delete proj_dp_association when delete proj or dp  https://review.openstack.org/8755111:37
*** tomoiaga1 has joined #openstack-keystone11:40
*** chandan_kumar has quit IRC11:42
*** tomoiaga has quit IRC11:42
*** tomoiaga1 is now known as tomoiaga11:48
*** leseb has joined #openstack-keystone11:49
*** leseb_ has joined #openstack-keystone11:53
*** leseb has quit IRC11:55
*** chandan_kumar has joined #openstack-keystone11:58
*** dstanek has joined #openstack-keystone12:01
*** jzl-ctrip has joined #openstack-keystone12:02
*** jzl-ctrip has quit IRC12:03
openstackgerritAla Rezmerita proposed a change to openstack/python-keystoneclient: Enable users to manage EC2-credentials on publicURL  https://review.openstack.org/7721912:05
*** chandan_kumar has quit IRC12:26
*** erecio has joined #openstack-keystone12:34
*** kun_huang has joined #openstack-keystone12:34
*** ilives has quit IRC12:36
*** chandan_kumar has joined #openstack-keystone12:41
*** bada has joined #openstack-keystone12:52
*** leseb_ has quit IRC12:52
*** leseb_ has joined #openstack-keystone12:56
*** marcoemorais has joined #openstack-keystone13:02
*** marcoemorais has quit IRC13:07
*** vhoward has left #openstack-keystone13:10
*** leseb_ has quit IRC13:16
*** henrynash has joined #openstack-keystone13:23
*** ayoung-ZZZzzz has quit IRC13:25
*** bknudson has joined #openstack-keystone13:26
*** vhoward has joined #openstack-keystone13:28
*** leseb has joined #openstack-keystone13:49
dstanekeverytime 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 IRC13:53
*** gordc has joined #openstack-keystone13:54
*** ukalifon has quit IRC13:58
*** wchrisj has joined #openstack-keystone13:59
*** gokrokve has joined #openstack-keystone14:02
*** marcoemorais has joined #openstack-keystone14:03
*** marcoemorais1 has joined #openstack-keystone14:05
*** jagee has joined #openstack-keystone14:07
*** marcoemorais has quit IRC14:07
*** marcoemorais1 has quit IRC14:09
*** ayoung has joined #openstack-keystone14:11
*** nkinder has quit IRC14:13
*** topol_ has joined #openstack-keystone14:13
*** chandan_kumar has quit IRC14:13
*** topol has quit IRC14:14
*** topol_ is now known as topol14:14
*** wchrisj has left #openstack-keystone14:15
*** joesavak has joined #openstack-keystone14:18
*** tomoiaga has left #openstack-keystone14:23
*** RockKuo has quit IRC14:23
*** jaosorior has quit IRC14:23
*** stevemar has joined #openstack-keystone14:25
dolphmdstanek: we need "bknudson is going to catch you" stickers14:25
*** leseb has joined #openstack-keystone14:29
*** leseb has quit IRC14:30
*** leseb has joined #openstack-keystone14:31
*** dolphm is now known as dolphem14:31
*** jsavak has joined #openstack-keystone14:33
*** derek_c has joined #openstack-keystone14:34
*** leseb has quit IRC14:35
*** joesavak has quit IRC14:37
gordchey 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
uvirtbotLaunchpad bug 1291136 in ceilometer "Periodic tasks drive token table growth" [Low,In progress]14:37
*** thedodd has joined #openstack-keystone14:45
*** jsavak has quit IRC14:48
*** david-lyle has joined #openstack-keystone14:54
*** jaosorior has joined #openstack-keystone14:54
dstanekgordc: i don't understand the last comment in the bug about the race condition14:56
dstanekgordc: 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
gordcdstanek: i think that comment is out of scope for the bug.14:57
*** leseb has joined #openstack-keystone14:58
*** RockKuo has joined #openstack-keystone14:58
gordcdstanek: 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
dstanekgordc: 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 works15:00
gordcdstanek: cool cool. i'll give it a try and see how it goes.15:01
*** joesavak has joined #openstack-keystone15:04
*** RockKuo_iPad has joined #openstack-keystone15:04
*** browne has joined #openstack-keystone15:07
*** joesavak has quit IRC15:08
ayoungdolphem, 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 passwords15:08
ayounggordc, it would mitigate the problem to cache tokens, but also we want to move toward ephemeral tokens.15:09
dstanekayoung: there seemed to be at least a few vocal people looking for password rotation15:10
*** leseb has quit IRC15:11
ayoungdstanek  are these vocal people paying your paycheck?15:11
dstanekthis was discussed at our face-to-face in San Antonio15:11
ayoungdstanek, and I think I said the same thing there, probably less vocally15:11
*** leseb has joined #openstack-keystone15:11
dstanekayoung: nope, this is not something Rackspace needs as far as I know15:11
ayoungdstanek  the phrase that comes to mind is "rearrainging the deck chairs on the Titanic."15:12
*** leseb has quit IRC15:12
ayoungdstanek, 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 effects15:13
*** leseb has joined #openstack-keystone15:13
dstanekis removing passwords on the roadmap for keystone?15:13
ayoungdstanek, I think we should at least discuss it15:13
gordcayoung: i assume ephemeral tokens is a v3 item?15:14
ayounggordc, it is a Juno item15:14
ayounggordc, not API version specific15:14
ayoungit could be done with any version of PKI tokens15:14
ayoungbut it does need support from the V3 api for revocation support.15:14
gordcayoung: oh ok. i'll keep an eye out for that.15:14
ayounggordc, 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 concern15:15
ayoungdstanek, what do you think?15:15
ayoungShould Keystone continue to support Passwords?15:15
ayoungdstanek, let me rephrase that15:16
ayoungshould Keystone continue to perform Password administration15:16
dstanekayoung: i guess it would depend on how many real deployments use it and what their other options would be15:16
dstanekfrom a security perspective it would be nice to not have them stored in our system15:17
ayoungdstanek, 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
ayoungOne way or the other, no half-measures15:18
ayoungThat means rotation, as you are doing, but also proper storage, archival, retrieval, classes of characters, secure reset mechanisms, etc15:19
dstanekayoung: there was talk of some of that stuff, but i don't know if there are any blueprints to support those features15:22
dolphemayoung: 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 backend15:23
*** derek_c has quit IRC15:24
*** richm has joined #openstack-keystone15:26
*** RockKuo_iPad has quit IRC15:26
dstanekdolphem, ayoung: that's correct. the blueprint does specify some other features that they would eventually like to implement15:27
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: Deprecate admin_token option in auth_token  https://review.openstack.org/8709115:35
ayoungdstanek, dolphem so I would think that splitting service users into their own datastore would be higher priority than this to some degree.15:37
ayoungI'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 that15:37
bknudsonI was hoping I could debug bug 1300581 with https://review.openstack.org/#/c/86472/ but it hasn't merged yet.15:38
uvirtbotLaunchpad bug 1300581 in keystone "test_revoke.RevokeTreeTests.test_cleanup fails" [Critical,Triaged] https://launchpad.net/bugs/130058115:38
browneayoung: is there a blueprint for storing service users in its own datastore?15:38
ayoungbrowne, not per-se but rather allowing multiple datastores15:38
ayoungbrowne, its a summit session, actually15:39
*** tomoiaga has joined #openstack-keystone15:39
browneayoung: i always thought service users should somehow to be separate from other users.  this is especially true when using ldap15:39
ayoungbrowne, we get that a lot.15:39
ayoungI Wholeheartedly concur15:40
bknudsonwe tried it once but ran into issues15:40
ayounghttp://summit.openstack.org/cfp/details/35  browne15:40
dstanekbknudson: what were the issues?15:40
browneayoung: thx.  also big fan of x509 authentication15:40
bknudsondstanek: we couldn't figure out what backend the user was in based on the id15:40
brownebknudson: i've separated them before using 2 keystone instances.15:41
ayoungbrowne, that is a little more heavyweight a solution than we are looking for15:41
browneyeah, most likely15:42
bknudsonbrowne: that seems like a good way to do it.15:42
ayoungbknudson, doesn't scale.  1 Keystone per IdP?15:42
bknudsonayoung: If all you're doing is separating out service users it doesn't have to scale beyond 215:42
dstanekayoung: couldn't you just have 2 clusters? one for service user and one for real users?15:43
brownewhat 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 public15:43
ayoungbknudson, 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
ayoungbrowne, uuid tokens or PKI?15:43
bknudsonayoung: that's a good question... who's got the revocation list.15:43
*** nkinder has joined #openstack-keystone15:43
brownewanted to use pki, but ran into the apache+pki problem15:43
ayoungbrowne, that is now solved15:44
browneayoung: that's good15:44
ayoungyou 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/315:44
browneayoung: yep15:44
dstanekbknudson: 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
dstanekbknudson: i just don't want to do the work on import, but i agree that it only needs to be done once15:46
bknudsondstanek: I'm fine with a run_once decorator. This can be done in a separate commit as an enhancemnt15:47
dstanekbknudson: ha, too late i just wrote it - tests are running now to see if it still works15:48
ayoungdstanek, 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
ayoungand....would that still stand if I were to be targetting eventually merging my effort with cryptography.py15:49
dstanekayoung: probably, but i have never used it; i learned the C-API a long time ago because i'm very familiar with C15:50
*** browne has quit IRC15:50
ayoungdstanek, Oh, the C part doesn't bother me at all.15:50
dstanekayoung: 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
ayoungyeah, 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 now15:51
dstanekthe hardest part about the C-API is the reference counting - you have to know which calls steal a reference and which ones create their own15:51
dstanekif you decrement the wrong reference you'll segfault15:51
*** gyee has joined #openstack-keystone15:52
ayoungdstanek, I thought it was tellin the greenthread schedule "you can do some work now"15:52
ayoungbut seriously...15:52
ayounglet me see what they did at the binding layer15:52
ayoung TODO: This typedef is wrong.15:54
dstanekayoung: that's lovely to see15:55
dstanekand it's crypto code15:55
ayoungOK, here is some "real code"  https://github.com/pyca/cryptography/blob/master/cryptography/hazmat/primitives/hmac.py15:55
*** marcoemorais has joined #openstack-keystone15:55
ayoungfrom cryptography.hazmat.backends.interfaces import HMACBackend  seems like it means that one should be somewhat fleshed out15:56
ayoung ctx = self._backend._ffi.gc(15:59
ayoung                ctx, self._backend._lib.HMAC_CTX_cleanup15:59
ayoung            )15:59
ayoungdstanek, ^^ is from https://github.com/pyca/cryptography/blob/master/cryptography/hazmat/backends/openssl/backend.py#L70615:59
ayoungAssuming ffi is foreign function interface, and that is where they actually call into native code16:01
*** thedodd has quit IRC16:01
ayounghttps://github.com/pyca/cryptography/blob/master/cryptography/hazmat/backends/openssl/backend.py#L63   self._ffi = self._binding.ffi16:01
ayoungdstanek, https://github.com/pyca/cryptography/blob/master/cryptography/hazmat/bindings/openssl/hmac.py   that looks like C code embedded in the CUSTOMIZATIONS string16:03
ayoungis that normal?16:03
*** Gu_______ has joined #openstack-keystone16:04
dstanekayoung: i've not seen that before - looks very interesting16:04
ayoungimport cffi  https://github.com/pyca/cryptography/blob/master/cryptography/hazmat/bindings/utils.py#L2016:05
dstanekayoung: cffi is pretty interesting - just started reading this https://cffi.readthedocs.org/en/release-0.8/16:05
ayoungdstanek, yep, me too16:06
*** browne has joined #openstack-keystone16:06
ayoungdstanek, I like the philosophy16:07
bknudsonAny opinion on how we should advertise extensions for v3?16:10
bknudsonas in, which extensions are available16:10
ayoungbknudson, yes16:11
ayoungbknudson, /v3/extensions16:11
ayoungbknudson, or:16:11
ayoungwe could even do it as a collection under /v316:11
bknudsonayoung: that makes sense since that's what's documented in the api docs already16:11
ayoungcrazy talk!16:12
*** zhiyan is now known as zhiyan_16:12
bknudsonayoung: but I can also see having it in the v3/ response.16:12
ayoungbknudson, I'd like to do that with all of the modules, actually:  identity, policy, token...16:12
bknudsonayoung: for example in "links": [] ?16:13
ayoungbknudson, I'd also like to return HTML, but dolphem said no last time I asked.  I asked politely, too.16:13
bknudsonayoung: do we want v3 extensions to have admin & public versions?16:13
bknudsonayoung: for v2 extensions they can register as public or admin16:14
ayoungbknudson, hmmm...I kindof want that distinction to go away16:14
bknudsonwhich makes sense since there are still 2 pipelines.16:14
ayoungbknudson, but...16:14
bknudsonand someone could leave the extension out of 1 pipeline or the other16:14
ayoungit really should be somethuing like this:16:14
ayoung1  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
bknudsonthat makes more sense from rbac -- we'd need some way to register roles for extensions or something16:16
ayoungyeah....and Horizon was asking for that at least a Year ago, too16:16
*** thedodd has joined #openstack-keystone16:19
ayoungbknudson, 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
bknudsonayoung: that sounds slow.16:22
bknudsonayoung: so /v3 returns '{ "rel": "self", "href": "" }' for the link16:23
bknudsonayoung: how about { "rel": "extension", "href": "" }16:23
*** nkinder has quit IRC16:24
ayoungbknudson, thats the idea, yea16:24
bknudsonand, 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-keystone16:24
*** nkinder has joined #openstack-keystone16:24
ayoungbknudson, so long as I have a way to navigate down to it without knowing a-priori, I would be happy16:26
ayoungbknudson, 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
bknudsonayoung: ok, I'll look at mocking something up.16:32
*** nkinder has quit IRC16:34
*** erecio has quit IRC16:36
*** amcrn has joined #openstack-keystone16:40
*** bknudson has quit IRC16:41
*** erecio has joined #openstack-keystone16:46
*** leseb has quit IRC16:50
*** thiagop has quit IRC16:51
*** harlowja_away is now known as harlowja_16:58
*** marcoemorais has quit IRC16:58
*** marcoemorais has joined #openstack-keystone16:59
*** zuqiang has joined #openstack-keystone17:00
*** jaosorior has quit IRC17:01
*** thedodd has quit IRC17:03
openstackgerritA change was merged to openstack/keystone: More debug output for test  https://review.openstack.org/8647217:08
*** mat-lowery has joined #openstack-keystone17:13
*** browne has quit IRC17:24
*** morganfainberg_Z is now known as morganfainberg17:25
*** bknudson has joined #openstack-keystone17:27
*** browne has joined #openstack-keystone17:28
openstackgerritDavid Stanek proposed a change to openstack/keystone: Moves test database setup/teardown into a fixture  https://review.openstack.org/8565117:28
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds table and model for storing rotated passwords  https://review.openstack.org/7336817:28
openstackgerritDavid Stanek proposed a change to openstack/keystone: password rotation extension WIP  https://review.openstack.org/7462317:28
*** bknudson has quit IRC17:32
openstackgerritguang-yee proposed a change to openstack/keystone: Make sure all the auth plugins agree on the shared identity attributes.  https://review.openstack.org/8494517:33
*** praneshp has joined #openstack-keystone17:42
morganfainbergayoung, 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
morganfainbergayoung, dstanek, and do it "right". this is probably true about R/W LDAP as well.17:43
*** thedodd has joined #openstack-keystone17:45
*** rupsky has joined #openstack-keystone17:46
*** bknudson has joined #openstack-keystone17:46
ayoungmorganfainberg, perhaps, although LDAP can do a lot of the password stuff for you if you use the right controls.17:48
ayoungmorganfainberg, gonna grab a smmidge before our meeting.,,,17:48
morganfainbergayoung, agreeed17:48
morganfainbergayoung, 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 jamielennox18:01
*** dolphem is now known as dolphm18:01
*** Gu_______ has quit IRC18:01
*** gokrokve_ has joined #openstack-keystone18:08
mat-loweryjamielennox: ping18:11
*** gokrokve has quit IRC18:12
jamielennoxmat-lowery: i'm here if it's fairly simple, but keystone's meeting is on18:12
*** lnxnut has joined #openstack-keystone18:12
*** doddstack has joined #openstack-keystone18:12
*** gordc has left #openstack-keystone18:12
mat-loweryOK. 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 IRC18:14
jamielennoxmat-lowery: sure, i remember18:15
jamielennoxand that's ok - what are you needing from the factory?18:16
jamielennoxoh - i bet i know if you're server side - there is no way to distinguish between v2 and v318:16
uvirtbotLaunchpad bug 1302970 in python-keystoneclient "middleware provides no way to know if a catalog is v2 or v3" [High,Triaged]18:17
jamielennoxmat-lowery: yea, i'm struggling to see a good way to adapt that in auth_token middleware18:18
jamielennoxit's one of the biggest blockers for v2/v318:19
mat-loweryI 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-loweryI see. That bug pretty much captures my problem.18:20
jamielennoxyea, i hadn't realized the extent of the problem by then i think18:21
jamielennoxthere is a way to distinguish but it's not useful for factory (and it could be error prone)18:21
jamielennoxi'd still reccomend you go via factory()18:21
jamielennoxnova just wraps a serviceCatalog element around it all and assumes v218:21
jamielennoxhonestly 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 is18:22
mat-loweryJust 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-loweryI 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-3518:25
jamielennoxmat-lowery: join #openstack-meeting we just started talking about it18:26
*** gokrokve_ has quit IRC18:30
*** gokrokve has joined #openstack-keystone18:35
jamielennoxmat-lowery: ok that seems to have got off track18:39
jamielennoxmat-lowery: but i think in the short term i'll try and convert a v3 catalog into a v2 catalog18:39
openstackgerritRaildo Mascena de Sousa Filho proposed a change to openstack/keystone: Filter User by project  https://review.openstack.org/8413618:39
jamielennoxand then add a new header for the proper catalog that can be consumed later18:39
*** gokrokve has quit IRC18:39
openstackgerritPriti Desai proposed a change to openstack/keystone: Adding one more check on project_id  https://review.openstack.org/8519918:40
mat-loweryjamielennox: Just to confirm: You'll change middleware to attempt parsing of a v2 or v3 service catalog in the "serviceCatalog" key?18:41
jamielennoxmat-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 key18:42
jamielennoxso exactly what you get now if you use v2 tokens18:42
openstackgerritRaildo Mascena de Sousa Filho proposed a change to openstack/keystone: Filter User by project  https://review.openstack.org/8413618:42
jamielennoxso to use it you would wrap a 'serviceCatalog' key around it and pass it to ServiceCatalog.factory18:43
mat-lowerySo even on v3 keystone, X_SERVICE_CATALOG will contain a v2-compatible service catalog?18:43
mat-lowerysorry, I'm trying to keep up18:43
mat-loweryno need to explain. I understand your directions. I'll watch the bug report to see how it's fixed.18:44
jamielennoxmat-lowery: yes, that's the plan - X_SERVICE_CATALOG will b3 a v2 catalog regardless of token format18:44
mat-loweryjamielennox: thanks!!18:45
*** doddstack has quit IRC18:46
*** lnxnut has quit IRC18:47
*** zuqiang has quit IRC18:57
morganfainbergso back here.18:59
dstanekmorganfainberg: that would be interesting - where i used to work our token was created with struct18:59
ayoungmorganfainberg, lets not go binary, please18:59
topolhow would our curl examples look with binary tokens???18:59
ayoungtopol, they would still be base64ed19:00
morganfainbergayoung, if we go binary, i'd use a standardized lib to do it (e.g. protobuf)19:00
dstanektopol: they'd still be base6419:00
gyeedumb question, if I add an email address to .mailmap would my openstack emails go to both addresses?19:00
*** browne has quit IRC19:00
topolK, I guess I need to see what the binary example looked like19:00
dolphmbknudson: http://pasteraw.com/6o2b3k48gb8wubyjz6ln843qv2e4lbu19:00
morganfainbergayoung, but i refuse to create our own binary format.19:00
bknudsonI was kidding about the binary tokens!!19:00
ayoungmorganfainberg, the IDs are still character strings.  that is the big part.  The rest of the JSON overhead is  "  and {  stuff...minor19:00
*** gokrokve has joined #openstack-keystone19:01
topolsee what happens when you make jokes19:01
topolsomeone loses an eye19:01
morganfainberggyee, shouldn;'t it should only be used for correlating data externally for git19:01
bknudsonI'll put a one-eyed person to remind everyone next time -- ;(19:01
morganfainbergayoung, sure, we should at the very least keep (in-tree) json schema for the tokens.19:01
ayoungmorganfainberg, I think you are now officially taking the joke too far19:02
morganfainbergayoung, ;)19:02
ayoungN-E Ways....19:02
topolkeystone humor is brutal....19:02
morganfainbergayoung, i try.19:02
topolnot enough emitcons19:02
dstanekjamielennox: you still around?19:03
jamielennoxdstanek: yep, listening in on the -sdk meeting but i'm here19:03
morganfainbergok so .. in ATL work out (dev lounge probably) any further specifics on token formatting ?19:03
* morganfainberg needs food now.19:03
ayoungmorganfainberg, token pipeline refactoring19:03
dstanekjamielennox: adding a couple quick comments to https://review.openstack.org/#/c/7841019:03
ayoungsame session19:03
gyeemorganfainberg, so .mailmap is used for statistics only?19:03
morganfainbergayoung, ++ sounds good!19:03
*** zigo has quit IRC19:04
jamielennoxgyee: i think it's like changing your git commit email, so mostly for attribution19:04
morganfainberggyee, statistics and knowing who is who, if you're submitting with multiple email addresses to git19:04
morganfainbergjamielennox, +19:04
morganfainberggyee, most of the time you see mailmap entries for people who submit with work email and then change jobs19:05
ayoungHere we go:    ∠(・`_´・ )19:05
morganfainbergayoung, what no table flipping?19:05
ayoung (^-^)ゝ19:05
*** topol has quit IRC19:05
morganfainberg(╯°□°)╯︵ ┻━┻19:05
gyeeI am kindda fedup with my internal email server right now19:06
stevemar (╯°□°)╯︵ ┻━┻)19:06
ayoungヽ(`Д´)ノ︵ ┻━┻19:06
morganfainberg┬─┬ ノ( ゜-゜ノ)19:06
morganfainbergsee what topol did, he started this and left IRC19:07
*** zigo has joined #openstack-keystone19:07
jamielennoxdstanek: i don't see your comments19:08
jamielennoxdstanek: oh, adding as in in progress19:08
dstanekjamielennox: just submitted19:09
*** browne has joined #openstack-keystone19:10
*** kun_huang has quit IRC19:12
*** derek_c has joined #openstack-keystone19:28
*** thedodd has joined #openstack-keystone19:30
stevemardolphm, any word on what we should do with the security docs?19:33
stevemaris 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
dolphmstevemar: i think the consensus last week was to use the wiki19:34
dolphmnasty bug https://bugs.launchpad.net/keystone/+bug/130821819:35
uvirtbotLaunchpad bug 1308218 in keystone "keystone.tenant.list_users returns user multiple times" [Medium,Triaged]19:35
openstackgerritguang-yee proposed a change to openstack/python-keystoneclient: Implement endpoint filtering functionality on the client side.  https://review.openstack.org/8271319:36
*** lbragstad has left #openstack-keystone19:37
*** chandan_kumar has joined #openstack-keystone19:40
openstackgerritA change was merged to openstack/python-keystoneclient: Fix typo of ANS1 to ASN1  https://review.openstack.org/8706919:40
stevemardolphm, i think i'll abandon the change then, i'll add the comments to the wiki19:41
*** gyee has quit IRC19:43
*** ayoung has quit IRC19:44
*** bach_ has joined #openstack-keystone19:45
*** chandan_kumar has quit IRC19:48
*** browne has quit IRC19:49
*** browne has joined #openstack-keystone19:49
*** browne has quit IRC19:50
*** browne has joined #openstack-keystone19:51
*** browne has joined #openstack-keystone19:51
*** browne has quit IRC19:51
*** browne has joined #openstack-keystone19:52
*** chandan_kumar has joined #openstack-keystone19:55
*** lbragstad has joined #openstack-keystone19:55
*** praneshp has quit IRC19:55
*** praneshp has joined #openstack-keystone19:56
morganfainbergdolphm oh icky bug20:05
openstackgerritBrant Knudson proposed a change to openstack/keystone: Sync with oslo-incubator 2fd457b  https://review.openstack.org/8396620:15
bknudsonthe only conflict with ^ was in the sample config file20:15
morganfainbergbknudson, ah ok20:16
*** chandan_kumar has quit IRC20:18
*** bach_ has quit IRC20:19
bknudsonhttp://logs.openstack.org/68/73368/10/check/gate-keystone-python26/184f2e8/console.html -- we've got some data for bug 130058120:19
uvirtbotLaunchpad bug 1300581 in keystone "test_revoke.RevokeTreeTests.test_cleanup fails" [Critical,Triaged] https://launchpad.net/bugs/130058120:19
*** morganfainberg is now known as morganfainberg_Z20:20
*** morganfainberg_Z is now known as morganfainberg20:21
openstackgerritRaildo Mascena de Sousa Filho proposed a change to openstack/keystone: Filter User by project  https://review.openstack.org/8413620:30
*** bach has joined #openstack-keystone20:31
*** Chicago has quit IRC20:32
*** lnxnut has joined #openstack-keystone20:34
*** lnxnut has quit IRC20:35
*** lnxnut has joined #openstack-keystone20:35
*** dstanek has quit IRC20:38
*** Chicago has joined #openstack-keystone20:38
*** andreaf has quit IRC20:41
*** dstanek has joined #openstack-keystone20:45
*** browne has quit IRC20:54
*** ayoung has joined #openstack-keystone20:56
*** gyee has joined #openstack-keystone20:57
*** harlowja_ has quit IRC20:58
*** marcoemorais has quit IRC21:02
*** marcoemorais has joined #openstack-keystone21:02
*** harlowja has joined #openstack-keystone21:03
*** zigo has quit IRC21:06
*** zigo has joined #openstack-keystone21:08
dolphmjamielennox: releasing keystoneclient 0.8.0 in next 24 hours21:09
dolphmjamielennox: per cross-project meeting (heat needs the critical race fix)21:09
jamielennoxdolphm: having https://review.openstack.org/#/c/78410/ would be really good21:10
dolphmjamielennox: looking21:10
*** bach_ has joined #openstack-keystone21:10
jamielennoxhttps://review.openstack.org/#/c/87411/ needs to happen as it's a failure21:10
dolphmjamielennox: a failure of what?21:11
openstackgerritBrant Knudson proposed a change to openstack/keystone: Advertise extensions for v3.  https://review.openstack.org/8778621:11
jamielennoxthe exception mentioned doesn't exist21:11
jamielennoxbecause of the oslo.apiclient exceptions change21:11
*** bach has quit IRC21:11
jamielennoxthis: https://review.openstack.org/#/c/78878/ useful as V2 is already merged and then i can start looking at other clients - but not essential21:12
jamielennoxthat's all for me i think21:12
*** browne has joined #openstack-keystone21:14
stevemarbknudson, where in the api spec does it say /v3/extensions will list extensions?21:14
bknudsonstevemar: it's in the api doc21:14
bknudsondid I say spec/21:14
stevemari think so?21:15
stevemarnope, doc21:15
stevemarmy bad21:15
bknudsonstevemar: http://api.openstack.org/api-ref-identity-v3.html#identity-v3-ext21:15
dolphmhttp://api.openstack.org/api-ref-identity-v3.html is just a bunch of lies21:15
stevemarwhere is that even maintained?21:16
stevemarif it's lies, then we should remove it21:16
bknudsondolphm: we're trying to throw users off so they don't get too comfortable.21:16
dolphmopenstack/openstack-api-site i think?21:16
stevemarahh, the 'keeping them on their toes' strategy21:16
bknudsondolphm: stevemar: I've made several updates to those docs.21:16
dolphmwe get a ton of bug reports because we don't match the crap that has landed in that doc21:16
stevemarsounds like something we should fix21:17
dolphmis it being produced from XSD's?21:17
praneshpjamielennox: ping21:18
dolphmall the types are xsd:string etc21:18
jamielennoxpraneshp: hey21:18
praneshpjamielennox: I was talking to you about bulk operations for keystone yesterday21:18
bknudsondolphm: stevemar: https://review.openstack.org/#/c/87393/ is an example of a change.21:18
*** browne has joined #openstack-keystone21:18
bknudsondolphm: I don't know where xsd:string comes from.21:18
praneshpjamielennox: ^^ is what i wanted feedback on.21:18
bknudsonThat's one of the global problems I have with these docs that makes it hard to contribute21:19
jamielennoxdolphm, bknudson, morganfainberg, dstanek, stevemar: ^^ bulk operations blueprint21:19
morganfainbergjamielennox, ohai21:19
jamielennoxwe were discussing it yesterday but it's not specific to me21:19
morganfainbergjamielennox, in a meeting, (and was watching release meeting sideband) i'll look when done here21:19
praneshpthanks jamielennox21:20
*** tomoiaga has left #openstack-keystone21:20
morganfainbergs/release/cross project21:20
jamielennoxmorganfainberg: that's ok, just pinging more people than myself21:20
bknudsondo we need bulk operations only because we don't have streaming operations? or keepalive TCP?21:20
morganfainbergjamielennox, ok21:20
bknudsonI mean keepalive HTTP21:20
morganfainbergoh right saw the start of that.21:20
praneshpbknudson:  no, to workaround doing things one by one21:22
praneshpwe dind't face issues due to sockets dying, etc21:23
morganfainbergbknudson, i think this would be to do something like delete all users in group X21:23
morganfainbergpraneshp, ^ is that a usecase?21:23
praneshpmorganfainberg: correct21:23
praneshpget the delta from a list of employees or something, and add them all to our openstack infra21:23
jamielennoxpraneshp: do you think with an API like that you would continually be adding more targets for bulk operations21:23
praneshpand nuke those who left21:24
bknudsonok, if that's the case then the blueprint doesn't have enough information21:24
bknudsonwe should switch to nova's system.21:24
praneshpjamielennox: I don't plan to. This has been our API for a while now.21:25
praneshpbut that's just our use case21:25
praneshpso not sure if someone would want to add more targets if they take a similar approach21:25
jamielennoxbknudson: what is nova's system?21:27
jamielennoxthat's useful context to have21:27
bknudsonjamielennox: they review blueprints in gerrit21:27
bknudsonjamielennox: https://review.openstack.org/#/q/status:open+project:openstack/nova-specs,n,z21:28
praneshpjamielennox: i htink he's talking about opentack/nova-specs21:28
bknudsonI didn't realize they had so many in review... wow21:28
praneshpbknudson: I'd love to hear more feedback about the blueprint, sorry if it isn't as complete as youd like.21:28
dolphmbknudson: russell mandated that if it wasn't proposed against openstack/nova-specs, it wouldn't land in juno21:29
praneshpbknudson: "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
jamielennoxdolphm: let's have that for keystone - no-one looks at the blueprints21:30
morganfainbergjamielennox, i think infra asked projects to hold off on that21:30
stevemarjamielennox, i try to, but the bps are a complete mess21:30
dolphmjamielennox: i'd prefer to use gerrit, but i'm wondering if using gerrit will improve the quality of blueprints21:30
openstackgerritA change was merged to openstack/keystone: Moves test database setup/teardown into a fixture  https://review.openstack.org/8565121:30
morganfainbergjamielennox, until they see how nova/etc does it21:30
morganfainbergjamielennox, LP is the mess, cc stevemar21:30
morganfainbergnot the bps.21:30
dolphmmorganfainberg: blueprints are a mess too21:31
stevemarmorganfainberg, there are so many dupes21:31
morganfainbergdolphm, i think that is a symptom of LP.21:31
dolphmmorganfainberg: i've seen blueprints with one line descriptions that claim to be "Approved"21:31
morganfainbergstevemar, ^21:31
stevemardolphm, ++21:31
dolphmno external reference, no nothing21:31
morganfainberglike i said, i think this is a symptom of LP being far sub-optimal21:31
* morganfainberg wants storyboard.21:32
dolphmmorganfainberg: but will gerrit improve crap like that?21:32
stevemarLP's link to external api spec (or whatever it is) is awful21:32
morganfainbergdolphm, i think gerrit/ git is thr wrong tool, i don't have a better tool therefore it is the best current method21:32
morganfainbergdolphm, it would likely be wayyyyy better than what we have21:32
jamielennoxthat and approved or not is a very easy thing to set - and there is no check that something is approved before people start submitting patches21:33
morganfainbergdolphm, 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 IRC21:33
morganfainbergdolphm, 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
morganfainbergdolphm, provided we do the same-ish thing nova is doing21:33
jamielennoxpraneshp: so do the bulk operations adhere to the standard GET/DELETE and whateer?21:33
praneshpjamielennox: yes,21:34
dolphmnova-specs is evolving quickly... i'm hoping it stabilizes by summit time :)21:34
praneshpjamielennox: scratch that21:34
praneshpI have to get back on that21:34
morganfainbergdolphm, ++21:34
dolphmmaybe we can use it for juno-2 forward21:34
jamielennoxi think it would be useful to flesh it out more - including attempting an identity-api review specifying the whole API21:34
praneshpjamielennox:  sure, we're still drafting the bp21:35
jamielennoxpraneshp: i'd be interested to see things like how you specify multiple id21:35
praneshp"identity-api review " ?21:35
jamielennoxthings like bulk update do you specify id's and changes or change per id21:35
dolphmpraneshp: openstack/identity-api21:36
jamielennoxpraneshp: https://review.openstack.org/#/q/project:openstack/identity-api,n,z21:36
jamielennoxpraneshp: https://github.com/openstack/identity-api/21:36
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: auth_token middleware hashes tokens with configurable algorithm  https://review.openstack.org/8039821:36
jamielennoxso before you can implement something that touches the actual API there needs to be a fairly strict specification21:36
praneshpOk, this is just the Keystone rest api, correct?21:36
dolphmmorganfainberg: i'm also curious to see how well (or not) nova-specs serves as documentation21:36
*** bknudson has joined #openstack-keystone21:37
jamielennoxpraneshp: 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 details21:37
jamielennoxand blueprints are often completely out of date21:37
praneshpjamielennox: got it. I'm fairly certain there is no change to the identity-api21:38
jamielennoxpraneshp: extensions are in there as well21:38
jamielennoxanything maintained in the tree21:38
praneshpjamielennox: yeah, I tried to make a couple of nova bps for Juno, but held off because they existed.21:38
praneshpthought they were more than a year old, etc21:38
praneshpthanks a lot dolphm  jamielennox bknudson morganfainberg. I'll work a bit more on the bp.21:38
jamielennoxyep, blueprints seem to be a straight dump of an idea - sometimes lots of detail, sometimes nothing21:39
bknudsonthat's what the nova-specs system is trying to solve21:39
jamielennoxbknudson: ++, and i like it21:39
*** nkinder has joined #openstack-keystone21:39
bknudsonalso, it gives them a chance to "reset" their blueprints... get rid of abandoned ones.21:40
bknudsonthey'll probably have to come up with another system to reset again in a year.21:40
dolphmjamielennox: 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
dolphmbknudson: they've already come up with that system21:41
dolphmbknudson: 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 that21:41
dolphmbknudson: otherwise, your review gets a -1 and it's abandoned in a week! problem solved21:41
openstackgerritA change was merged to openstack/python-keystoneclient: Prefer () to continue line per PEP8  https://review.openstack.org/8401021:42
*** nkinder has quit IRC21:44
jamielennoxbknudson: regarding extensions i think we should bring back https://review.openstack.org/#/c/40776/21:45
jamielennoxit was reverted so that you should just get everything via links in responses21:45
jamielennoxbut i don't think that having that removes the need to check what extensions are enabled on a servr21:46
jamielennoxboth should be available21:46
bknudsonjamielennox: yes, we need some way to know what extensions are there.21:47
bknudsonjamielennox: talking with ayoung and dolphm it seems like they'd prefer the extensions in links in /v3 ?21:47
ayoungbknudson, I think both21:47
jamielennoxbknudson: that's why it was reverted21:47
jamielennoxi think both is appropriate21:47
*** nkinder has joined #openstack-keystone21:48
bknudsonah, 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 go21:48
ayoungI see no drawback to a specific url just for extensions, but lets get the links part done first?21:48
dolphmayoung: it's redundant with the restful solution21:48
bknudsonI didn't know we have / documented in the spec, I'll have to update it.21:48
jamielennoxdolphm: yes - but does it matter21:48
jamielennoxthere is a lot of information that is relevant to the extension that might not be relevant to the objects that the extension provides21:49
jamielennoxeg description, author, homepage ...21:49
bknudsonalthough it just says TBD21:49
jamielennoxbknudson: if you write that have a look at https://wiki.openstack.org/wiki/VersionDiscovery and see what we need to fix up21:51
ayoungdolphm, 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  etc21:53
dolphmayoung: ++21:53
morganfainbergayoung, ++21:53
bknudsonayoung: in /v3?21:53
ayoungI know I hacked that up at one point, as a part of some other patch21:54
ayoungbknudson, yes,  off the /v3 page21:54
*** derek_c has quit IRC21:54
bknudsonayoung: what would that look like? I didn't know what to put for "rel" for the extensions.21:54
ayoungdolphm, ?21:54
dolphmayoung: ?21:54
ayoungdolphm, what would make sense for 'rel' for modules or extensions?21:55
bknudsonwe use "rel" "self", "next", "previous"21:55
ayoungbknudson, rel is not in https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md  BTW21:55
ayoungso we should make it explicit21:55
dolphmbknudson: "users" for example21:56
jamielennoxplease make these relative links rather than use CONF.public_endpoint21:56
dolphmbknudson: 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
*** daneyon has quit IRC21:57
ayoungI would think "extension" or "module" might be the right value, unless there is a standard21:57
dolphmayoung: "rel": "OS-TRUST:trusts" <-- indicates it's an extension and what is available at the destination url21:58
jamielennoxdolphm: not that's a pain to parse21:58
jamielennox{'rel': 'self', 'url': 'trusts', 'extension': 'extensions/OS-TRUST'}21:58
dolphmjamielennox: gotta love xml hand-me-downs21:58
jamielennoxif 'extension' (maybe 'provider') is not provided then it's core21:59
jamielennox'extension' is a link as well21:59
dolphmjamielennox: keystone didn't make up this schema, i'd much rather avoid making up another variation of it22:00
jamielennox'rel': 'self', 'url': 'link' is standard now22:00
jamielennoxthat's what we use for discovery right22:00
ayoung'rel': 'self  does not make sense22:00
ayoungthat is a link to "this document"22:01
dolphmayoung: ++22:01
ayoungso from v3,   rel=self would be "http://hostname/v3/"22:01
jamielennoxi wasn't sure that it was because it's not listed in bknudson's above link22:01
*** rupsky has quit IRC22:01
ayoungI would thinkg 'rel'='module'  or 'rel'='extension'  would be OK22:01
bknudsonlooks like 'rel': 'self' is from the atom format.22:02
ayoungcategory is a bit of a stretch22:02
dolphmjamielennox: 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 IRC22:02
ayoungrel='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-keystone22:03
*** harlowja has quit IRC22:03
jamielennoxcurrent output of discovery: http://paste.openstack.org/show/75837/22:03
jamielennoxthis is what i was basing the 'rel': 'self' on22:03
ayoungeach of the modules should have a landing page.  GET /v3/users  GET /extensions/OS-TRUSTS22:03
jamielennoxayoung: ++ extensions should be a limited CRUD as well22:04
ayoungand each of those langin pages should have "rel="home"  point to /v3  or even one level up22:04
jamielennoxayoung: is 'home' something you made up? is there a format for this anywhere?22:04
ayoungI just saw it22:04
*** david_lyle_ has joined #openstack-keystone22:04
*** harlowja has joined #openstack-keystone22:05
jamielennoxok, sure that should be /v322:05
dolphmayoung: i'd be curious to see an actual use case22:06
ayoungdolphm, I was thinkng "auto generating the UI for Horizon"22:06
ayoungdolphm, something like this:22:06
* jamielennox saw that coming :)22:06
dolphmayoung: how does "rel": "home" address that?22:06
*** david-lyle has quit IRC22:07
ayoungdolphm, maybe that was the wrong level...home should be the root of whatever...so it might be /v3 for horizon usage22:07
ayoungsince horizon is not going to talk to v2 once we do this22: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
ayoungcalling 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 sens22:09
ayounghttp://microformats.org/wiki/rel-category   might not be a bad   abstraction for both extensions and modules22:09
ayoungsubresource  also would apply22:11
jamielennoxinteresting, close-ish to what we do now: http://blog.stateless.co/post/13296666138/json-linking-with-hal22:12
jamielennoxbetter: http://json-schema.org/latest/json-schema-hypermedia.html22:14
jamielennoxWSME would be nice to have but i'm loving jsonschema more and more22:15
*** dstanek has quit IRC22:19
jamielennoxdolphm: does jenkins -1 on https://review.openstack.org/#/c/78410/ pull it from gate? i don't see it on zuul22:20
*** stevemar has quit IRC22:22
openstackgerritA change was merged to openstack/python-keystoneclient: Rename HTTPError -> HttpError  https://review.openstack.org/8741122:22
*** morganfainberg is now known as morganfainberg_Z22:23
*** browne has quit IRC22:25
*** browne has joined #openstack-keystone22:26
*** nkinder has quit IRC22:27
*** henrynash has quit IRC22:30
*** browne has quit IRC22:30
*** browne has joined #openstack-keystone22:31
*** marcoemorais has quit IRC22:33
*** marcoemorais has joined #openstack-keystone22:33
dolphmjamielennox: it's not gating, it's doing a check run first22:34
jamielennoxdolphm: yea, i did a recheck22:34
dolphmjamielennox: with a recent passing check and a +A, it'll enter the gate22:34
jamielennoxok, if not i'll make sure it passes today22:35
*** bknudson has quit IRC22:41
*** thedodd has quit IRC22:41
*** dims has quit IRC22:44
*** dstanek has joined #openstack-keystone22:46
*** henrynash has joined #openstack-keystone22:52
*** browne has quit IRC22:56
*** david_lyle_ has quit IRC22:57
*** dims has joined #openstack-keystone22:57
*** praneshp has quit IRC23:11
*** praneshp has joined #openstack-keystone23:14
*** dstanek has quit IRC23:18
*** Krsna has joined #openstack-keystone23:23
*** gokrokve has quit IRC23:24
Krsnamorganfainberg_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 IRC23:25
marekdmorganfainberg_Z: what Krsna meant by saying "Federated keystone has been officially accepted" ?23:29
*** morganfainberg_Z is now known as morganfainberg23:31
*** openstackstatus has quit IRC23:32
morganfainbergmarekd, krsna is saying that there wikll be resources allocated to help work on getting keystone able to provide a federated Identity to another keystone23:32
morganfainbergmarekd, e.g. internal SQL or LDAP to another cloud.23:32
morganfainbergmarekd, s/wikll/will23:32
*** openstackstatus has joined #openstack-keystone23:32
marekdmorganfainberg: saml2 and stuff.23:33
morganfainbergmarekd, that is the plan23:33
marekdmorganfainberg: ok, i was was accepting that. I now see this is some thing inside company/org23:35
marekdi was wondering who was accepting that*23:35
morganfainbergmarekd, yeah krsna was saying employer accepted dedicating resources to it23:37
morganfainbergmarekd, yeah23:37
marekdmorganfainberg: ok23:38
marekdgood to know.23:38
morganfainbergi also pointed krsna at you and stevemar as people working on the federation stuff on the other side23:38
morganfainbergso expect to be roped in some.23:39
*** derek_c has joined #openstack-keystone23:41
marekdmorganfainberg: that's good, cause I started wondering if you even associate myself with the federation work  after you started explaining what it is :P23:44
morganfainbergmarekd, wait what? :P23:44
morganfainbergmarekd, dude..... you've done awesome work on it23:45
morganfainbergmarekd, sorry if i haven't said it enough :(23:45
marekdmorganfainberg: hey, no worries! that was not my point :-)23:45
morganfainbergmarekd, very pleased with where it is going. i want more of it though, so ....23:47
marekdmorganfainberg: sure, another pair of hands is always very welcome.23:47
*** henrynash has quit IRC23:47
morganfainbergmarekd, soooo *aims the willing contributors your way*23:47
*** bach_ has quit IRC23:48
morganfainbergmarekd, :)23:48
morganfainbergmarekd, 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
morganfainbergmarekd, don't know if it prevented sleep or not :)23:49
marekdmorganfainberg: thanks :-)23:50
marekdhowever, still lots of things pending ;/23:51
*** gokrokve has joined #openstack-keystone23:51
morganfainbergyeah. but hey the client stuff is coming togther now as well23:51
morganfainbergmarekd, i kindof want to see the federation work being the basis for all identity not just external identity23:52
marekdmorganfainberg: yeah, heard the rumors...:-)23:52
morganfainbergmarekd, i think we have a summit session proposal on that as well.23:53
*** gokrokve has quit IRC23:54
marekdmorganfainberg: you mean federation in general ? stevemar proposed one long time ago.23:54
morganfainbergmarekd, maybe. i haven't looked at the proposals today... seems like each time i look there are more!23:55
*** dstanek has joined #openstack-keystone23: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!