18:01:17 #startmeeting keystone 18:01:17 Meeting started Tue Jun 16 18:01:17 2015 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:18 jamie won't be here... 18:01:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:21 The meeting name has been set to 'keystone' 18:01:36 marekd, yeah, jamie is on the other side of OZ today 18:01:39 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:01:41 I need Jamie on one of the topics 18:02:00 #topic Release numbering 18:02:24 quick one, i wanted to give everyone a heads up on the numbering change that will occur (likely) 18:02:28 stevemar: numbering of what: ksc, kmw, ksa, keystone? 18:02:30 you can read about it here: http://lists.openstack.org/pipermail/openstack-dev/2015-June/067082.html 18:02:44 keystone will be released as 8.0.0 in liberty, instead of 2015.2 18:02:58 M-release will be 9.0.0 18:03:03 just like windows 8 :( 18:03:04 marekd: all the things 18:03:07 8 is a luck number for me 18:03:09 bknudson, lol 18:03:10 the thinking is, it's been the 8th integrated release 18:03:21 nova is at 12.0.0 18:03:23 looks like a snowman 18:03:36 bknudson never fails to make me laugh 18:03:48 any questions about it? 18:04:00 That is going to break so many things 18:04:02 wwill the third number ever change? 18:04:05 aside from what the numbers look like, snowmen or otherwise 18:04:22 packaging is supposed to be monotonically increasing. OTOH, I think it will aslign with RDO 18:04:27 I mean, shall we have 8.0.1? 18:04:45 breton, the second and third will be reserved for if we need to release a stable version of keystone 18:04:53 (sorry to be late) 18:04:55 like we do now 18:05:12 cool, thanks 18:05:23 instead of 2015.1.1 (the next stable release of kilo), it would be 8.0.1 (stable release for liberty) 18:05:31 or 8.1.0 depending on how much changes 18:05:45 we're also going to have 8.0.0b1 for milestone 1 18:05:57 is it actually following semver? 18:06:00 ayoung, sorry if it breaks things, this one is out of my hands :( 18:06:04 bknudson, i believe that's the intent 18:06:05 or it's just a number? 18:06:19 stevemar, any objections from the packagers? 18:06:25 besides ayoung 18:06:27 stevemar, I'll be fine. RDO and RH-OSP are at 7 right now anyway 18:06:37 I'm just laughing to myself 18:06:38 the REST API is versioned separately so I guess this doesn't help us much 18:06:41 gyee, this was made at the TC level, i wasn't really involved, just relaying the decision 18:07:03 henrynash, 2 laps for being late 18:07:18 next? 18:07:20 stevemar: ok, agreed, two laps of the table underway 18:07:35 #topic Outcome of DB2 CI 18:07:36 if the packages are not concerned about the version change, I guess we're fine 18:07:48 bknudson, did you want to take this one? 18:07:54 oh, sure... 18:08:01 I think the outcome is that DB2 CI isn't going to report 18:08:10 * stevemar throws bknudon under the bus 18:08:10 until we can show that it's more stable 18:08:41 currently it's at a 88% success rate right? 18:08:42 or we can get people in US time to be available to disable it when it's not working 18:08:51 that's the only number I've seen 18:09:02 and it only covers tempest tests 18:09:03 I don't think we have actual numbers. 18:09:13 probably not :P 18:09:28 where did the 88% number come from? 18:09:39 dstanek: it was from other projects, not keystone 18:09:48 DB2 CI is running on several other projects 18:10:01 so it might be accurate for keystone but I don't know. 18:11:13 bknudson, i guess we'll let the keystone team know if anything changes 18:11:26 but the db2 team will monitor it internally for now 18:11:45 y, I'm sure they'll talk to me again here when they're ready 18:11:56 skipping over the jamie topic 18:12:02 #topic It's time to fix Bug 1291157 18:12:04 bug 1291157 in python-keystoneclient "idp deletion should trigger token revocation" [High,Triaged] https://launchpad.net/bugs/1291157 - Assigned to Navid Pustchi (npustchi) 18:12:06 marekd, the floor is yours 18:12:49 hi, i wanted to get back to the bug and refreshed some knoweldge. I know some of you were tackling it. 18:12:57 stevemar: you reported that a long time ago 18:13:19 bknudson, i did, basically the description is pretty sufficient 18:13:21 I will have an intern this summer and thought i could make him work on that, as clearly this bug is not something that can be fixed in 1-2 hours. 18:13:43 marekd, sounds like a good project for the intern 18:14:02 under your expert guidance of course ;) 18:14:19 stevemar: i think so, as he would need to learn about revocations in keystone either way. 18:14:24 stevemar: don't be sarcastic :P 18:14:38 revoke by IdP will be fun 18:14:53 stevemar: anyway, i think it's pretty straightforward how to tackle uuid tokens, yet it may need extending the db schema. 18:14:56 we don't index the tokens by IdP do we? 18:15:07 is Navid the intern? 18:15:12 bknudson: no 18:15:16 bknudson, navid was a utsc guy 18:15:19 i'll unassign 18:15:23 stevemar: please. 18:15:27 stevemar: please do 18:15:29 done 18:15:42 utsc? 18:15:47 utsa 18:15:50 ahh 18:15:53 whoops 18:16:04 utsc is a canadian uni :P my bad 18:16:12 i wanted to know what is the status of the revocation events... 18:16:15 stevemar, your very bad 18:16:16 does it even work now? 18:16:21 ayoung: ^^ 18:16:28 nope 18:16:35 revocation events can be used in keystone server 18:16:37 I mean, not by IdP 18:16:47 you can disable revoke by list 18:16:50 acutally, I don't know. I have not touched revocation events in a while 18:17:02 bknudson: ok, so we must take into consideration while working on this bug 18:17:17 ayoung, and I still wait for them in ksc )) 18:17:33 y, you either need to support both since the best we could do now is deprecate one or the other 18:17:38 or both 18:17:40 marekd, it sucks that this depend on what kind of token is issued 18:17:52 amakarov, go for it. 18:18:00 stevemar: that's the nature of different tokens....lots of things change :-) 18:18:05 amakarov, I'm done tilting at that particular Windmill. 18:18:29 marekd, even if it's a solution for just 1 token format, it's better than nothing 18:18:44 ayoung, let's drop revocations 18:18:50 OK 18:18:54 uh...? 18:19:20 stevemar: do you think it would need some specs, approved by June 21? 18:19:52 marekd, preferably, but i understand if your intern hasn't started yet and you want to put them through the process 18:20:10 this is also low impact, so i think it's OK to make it an exception 18:20:28 stevemar: he will be here end of June, and i will need to make some intro to the Openstack world so it may few days :-) 18:20:31 this is a bug, so no blueprint or spec for that 18:20:38 bknudson: ah, cool 18:20:41 bknudson: right. 18:20:57 bknudson, if the outcome is a new API or feature then a spec might be needed 18:20:59 ayoung: is there any vision on how you'd like to see it inrevocation events? 18:21:02 so...intern is going to work on revoke by IdP? 18:21:12 ayoung: that's one of the ideas i had. 18:21:20 it does depend on the changes, since yo can't change the api for a bug, that would be a feature 18:21:26 marekd, yeah, lots of visions. I think it was the Peyote 18:21:33 marekd, too long for me to derail here 18:21:34 Peyote? 18:21:49 ayoung: i will catch up with ya one day after the meeting. 18:22:04 lbragstad: for fernet.... 18:22:18 marekd, so, revocation events in the client only make sense for PKI style tokens. I am done trying to push that through 18:22:22 lbragstad: any opinoins, or you already see any corner cases? 18:22:27 marekd: https://en.wikipedia.org/wiki/Peyote 18:22:33 tokens in geenral should live for 5 minutes, no revation necessary 18:23:01 any thing longer than 5 minutes gets a trust, or a better delegation agreement than we have now anyway 18:23:02 marekd: the middleware will need the token revocation lists 18:23:07 but...not for Liberty 18:23:07 do we all agree revocations shall die? 18:23:16 ayoung, ideally tokens should have single use! 18:23:26 i don't want to make him work on something that will die 18:23:33 anteaya: thanks. 18:23:38 revocation shall die 18:24:06 marekd, my view is that dynamic policy is key to any future sanity coming out of Keystone 18:24:30 so in principle I agree…but we need to make sure we understand the path the point when revocations can really die 18:24:33 with that, we can then work on unfied delegation, and many other things besides 18:24:35 lbragstad: ayoung how do we revoke fernet tokens? 18:24:39 marekd: otherwise we are always stuck to online validation 18:25:03 marekd, let me defer for now... 18:25:11 marekd: np 18:25:12 what impact on client apps who (almost entirely today) grab a token and assume that it will never experie (well not likely when the user is still logged in) 18:25:45 lbragstad: how do we revoke fernet tokens? online validation ? 18:25:49 henrynash, the latest auth plugins handles token renewal pretty smoothly now 18:26:17 marekd: a revocation event is built and the renovation list is checked on validation of a token 18:26:34 which is totally teh wrong thing to do….but us wishing it wasn’t so doesn’t make it any less true 18:26:40 lbragstad: ok, so basically it's the same mechanism as with PKI ? 18:26:58 marekd: maybe, I'm not all that familiar with pki 18:27:16 marekd, fernet uses revocation events 18:27:24 so, no revocation list 18:27:27 marekd: we have a bunch of those test cases added to test_v3_auth.py 18:27:52 ayoung: ouch, so you want revocation *lists* or *events* to die? 18:27:53 do we kill revocation events or lists? 18:27:54 or both? 18:27:58 we should, imho: get a godo solution of short lived tokens (provided in parallel with the current ones), provide loads of wroking examples of client code that shows how to work with such things (how to “refresh”) 18:28:01 breton: ++ :-) 18:28:06 breton: same question 18:28:17 marekd, I *want* both to die. but I am not the decider. I never wanted either, even though I wrote both 18:28:22 henrynash, ++ 18:29:07 I just have no desire to continue working on either, so I'll defer. But Revoke by IdP would have been easy if we mapped 1 IdP to one domain 18:29:19 ayoung: ok, so it looks like i will make my guy focus on uuid for now, this should be good for a warmup at least. 18:29:39 marekd, what you do have for him to do for encore? :) 18:30:07 if revoke by IdP is just a warmup 18:30:21 gyee: so you claim it's hard or too easy? :-) 18:30:44 its hard 18:30:44 so, what's going to replace revocation events/lists if it's removed? 18:30:52 lbragstad, nothing! 18:30:56 lbragstad, short term tokens 18:30:57 gyee: so, maybe i will not need any encore :-) 18:31:03 lbragstad: it's just a bad model 18:31:12 he wil be there for 2 months and it's not a really full time job. 18:31:13 the idea is that a token should last such a short amount of time, that by the time you revoke it, it has expired 18:31:19 token_expiration = 60 or something? 18:31:32 lbragstad: that's the point -- the token will die young and their exposure will not give anything 18:31:33 I say 5 minutes, as that seems to be the limit of click skew, but sure 18:31:39 ok, i have a clearer vision. thanks for now. 18:31:42 stevemar: ^^ 18:31:42 ok 18:31:44 makes sense 18:31:45 thanks 18:31:51 lbragstad, I'd like to see tokens themselves go away 18:32:09 ayoung: in favor of what? 18:32:12 saml assertions? 18:32:19 instead, I authenticate as me using X509 or Kerberos or SAML, and the remote server looks at the deleagtion ID I provide to see if Ia ma ctually authorized 18:32:22 * marekd please, not saml! 18:32:35 we didn't we use oauth instead of tokens? 18:32:42 marekd, SAML for those that want it, X509 or Kerberos for those of us that want it 18:32:54 breton, same same 18:33:07 brethon, oath uses *tokens* 18:33:11 i think we're getting off topic ish 18:33:12 oauth and keystone are pretty similar, as far as why...ask those who came before the project 18:33:13 access tokens, refresh tokens, etc 18:33:18 yes we are 18:33:21 I tried to defer 18:33:38 everytime I think I'm out they pull.me.back.in! 18:33:42 stevemar, next topic 18:33:44 next topic 18:33:46 let's end it here and give raildo htruta and rodrigods some time 18:33:47 ++ 18:33:47 ++ next topic 18:33:53 #topic New way to get a project scoped token by name with Reseller 18:33:56 cool 18:34:01 :D 18:34:09 hey guys, as we had discussed last week, we created a etherpad with the alternatives to get a project scoped token by name after reseller 18:34:11 so it's time to vote :) 18:34:16 https://etherpad.openstack.org/p/reseller-project-token 18:34:16 guess most of you guys have read the etherpad 18:34:33 rodrigods, ++ 18:34:43 we decided to take a vote to choose the best option and after that we will write the spec. 18:35:20 raildo, htruta rodrigods go over the options quickly? 18:35:38 I vote for 5 18:35:44 stevemar, can be 18:35:51 ok 18:35:53 (1) Specify the project hierarchy up to the domain as a string separeted by a configurable delimiter 18:35:54 oh geez 6 options 18:36:08 stevemar, sorry about that :( 18:36:09 gyee, ++ I kind of agree, at least for now :) 18:36:10 gyee: +1000 18:36:13 (2) Provide empty project name when intended to get a project scoped token to is_domain project. 18:36:15 everyone take a few minutes to read the options 18:36:28 guess I don't need to paste them all here, write? 18:36:30 gyee: definitely disagree! 18:37:04 I don't like the 5 option too :P 18:37:13 if we allow intermix between project and domain, I see OSSA/Ns in the future 18:37:14 ewww to 2 18:37:16 henrynash: the problem i have is that Project should be treated like a domain and not a project5 18:37:37 we already have project/service admin bleedover 18:37:44 no…becomes scope specifies we are looking for a project 18:37:46 stevemar: ++ 18:37:57 i kinda like 3 18:38:02 if we choose the 5, we are not having domains as a feature of project 18:38:09 why do we even allow domain-scoped by name? 18:38:14 which is on of the main proposals of reseller 18:38:21 stevemar: did I hint i liked that one as ell too strongly? 18:38:26 the eww factor only applies to the JSON representation. The client lib and CLI can make it look better 18:38:31 lets use uuids 18:38:47 henrynash, not at all 18:38:50 breton: we support both project and domain tokens today by name 18:38:51 3 looks more readible at hte 1st glance 18:39:12 breton, imo the best way is provide tokens by uuids, but since we provide tokens by names, we will have this issue after reseller 18:39:16 i'm thinking 3 or 5 18:39:17 or make a new field, like slug. 18:39:22 i dislike 3 because it Cons 18:39:24 whats the impact of 5? 18:39:47 breton: just that today they refer to seperate entites…which now get merger with “ a domain is represented as a project with teh is_domain attrbute set” 18:39:56 stevemar: I think it will make if difficult to integrate with other services 18:39:57 we need to clearly distinguish betwen project admin, service admin, and domain admin 18:39:58 stevemar, as htruta said, we are not having domains as a feature of project 18:40:06 I like option 1 where the hierarchy is a list instead of a string. 18:40:13 imo 5 keeps the domain/project dynamic much closer to what it is today and will be less confusing overall 18:40:22 #vote 5 18:40:23 bknudson, bad for exporting vars 18:40:27 we wanted to be able to treat all of them as project to make it easier to other OS services 18:40:27 dstanek: ++ 18:40:32 amakarov, haven't started the vote yet :P 18:41:03 we could use the vote to narrow down options at least 18:41:10 if we don't do #5 i don't understand how a user know what is a domain or project and when to act is if it's either 18:41:10 and work through the details in the spec 18:41:10 stevemar, but you saw it :P 18:41:19 yep, remember that one of the goals here is to allow cilents to not have to worry about domain tokens….eveything should (in the end) be project tokens 18:41:34 stevemar, or we can put +6 on a single choice :_ 18:41:34 henrynash: ++ 18:41:38 stevemar, and if we choose other option 1-4, we don't need, for example, provide domain scoped token to Horizon 18:41:41 henrynash, ++ 18:41:47 henrynash, ++ 18:42:24 a domin is just a funny kind of project that allows you to also hang users/groups off 18:42:31 everyone ready for a vote? 18:42:32 htruta: for other OS services what's the use case where they need to get domain scoped token? 18:42:39 henrynash: then why don't we drop support for them in general? 18:42:58 lhcheng_: they won't. they'll keep using project scoped tokens 18:42:59 dstanek, it's simple, if the is_domain=True, is a project that behaviour as a domain 18:43:11 dstanek: I think we are headed taht way…we are basically frezzingthe domain API and ding evyerting via teh project APi now 18:43:17 security guys don't like ambiguity 18:43:23 raildo: what does that mean tho? what is the behavior? 18:43:46 dtsanek: e.g. you can create a “domain” with create_project if the attribute is_domain=True in the entity you apss in 18:43:52 as a domain works today... create user, groups... 18:43:59 henrynash: i still don't get why we allow projects to have a parent that is not is_domain=True 18:44:02 gyee, we intend to drop the ambiguity in the future 18:44:08 htruta: if other services won't use it, we're not making it easier for anyone. since no services is really going to use it. we might be just making it complicated. 18:44:25 dstanek: you mean project hierachy below a “domain”? 18:44:40 henrynash: yes 18:44:41 lhcheng_, how does horizon do to create users ? what token does it use ? 18:45:17 dstanek: that’s so complex environemtn can model there projects better (and do thinsg like quotas that role up a tree etc,) 18:45:24 samueldmq: project token, horizon still doesn't support domain scoped token. 18:45:35 lhcheng_: they do not use today and we are not making them use in the future. we're just ensuring that they cant handle the whole hierarchy, without even knowing what a domain is 18:45:48 they can** 18:46:09 henrynash: it seems that the model would be much simpler to say a project's parent must alwasy be is_domain=True 18:46:16 samueldmq: still wip, because horizon have some issue consuming the keystone v3 policy files. 18:46:29 funny project versus project is ambiguity 18:46:39 dtsanek: which is basically the model we have before any of the projec hierachy stuff arrived….! 18:46:40 lhcheng_: all policy files are v3. 18:46:45 gyee: ++ exactly 18:46:57 should we vote? 18:47:05 henrynash: not true...you couldn't nest domains right? 18:47:09 bkundson: ++ ( I rue the date I named that sampel file the way I did!) 18:47:16 dstanake: nope 18:47:50 dstanek: all domains are at the top, each has a flat layer of projects….that was the original (pre-hierarchy) sitaution 18:47:50 vote time 18:47:52 dstanek, henrynash, actually, you can 18:47:57 bknudson: our default policy is not domain aware. 18:48:03 henrynash: to me a easier model for this would be a filesystem - directories(domain) contain other directories and files(projects) 18:48:06 you'll be able to, in reseller 18:48:14 hruta: NOW you can yes, but not befor we had hieracrchys 18:48:53 #startvote option for getting a project scoped token? 1, 2, 3, 4, 5, 6 18:48:54 Begin voting on: option for getting a project scoped token? Valid vote options are 1, 2, 3, 4, 5, 6. 18:48:55 Vote using '#vote OPTION'. Only your last vote counts. 18:49:00 #link https://etherpad.openstack.org/p/reseller-project-token 18:49:01 #vote 1 18:49:06 #vote 5 18:49:07 #vote 5 18:49:07 dtsanek: (I did actually argue for that when hieracrhies came in.. that acyuallywhat we ewanted was domain hieracries not project hierachies) 18:49:10 #vote 5 18:49:11 #vote 5 18:49:12 #vote 3 18:49:16 #vote 3 18:49:18 #vote 3 18:49:18 #vote 3 18:49:19 #vote 3 18:49:20 #vote 3 18:49:22 #vote 3 18:49:25 #vote 5 18:49:25 henrynash: ++ yep 18:49:33 #vote 5 18:49:35 #showvote 18:49:36 1 (1): bknudson 18:49:37 3 (7): rodrigods, marekd, iurygregory, htruta, henrynash, raildo, stevemar 18:49:38 5 (6): gyee, dstanek, lbragstad, david8hu, amakarov, lhcheng_ 18:49:39 #vote 5 18:49:57 you had to tie things up haneef ! 18:49:59 ouch! 18:50:01 #showvote 18:50:02 1 (1): bknudson 18:50:03 3 (7): rodrigods, marekd, iurygregory, htruta, henrynash, raildo, stevemar 18:50:03 haneef for the tie 18:50:04 5 (6): gyee, dstanek, lbragstad, david8hu, amakarov, lhcheng_ 18:50:05 k, no run-away ehre 18:50:20 haneef, can you vote again, without a leading space :) 18:50:31 #vote 5 18:50:32 bknudson, change to 3? :) 18:50:36 thx! 18:50:38 #showvote 18:50:39 1 (1): bknudson 18:50:40 3 (7): rodrigods, marekd, iurygregory, htruta, henrynash, raildo, stevemar 18:50:42 haha 18:50:42 5 (7): gyee, dstanek, haneef, lbragstad, david8hu, amakarov, lhcheng_ 18:50:43 dumb question about #3.... are all domain names unique? 18:50:49 dstanek, yes 18:50:50 dstanek, yes 18:50:50 dstanek: yes, they are 18:51:06 not only in 3, btw :P 18:51:24 how do we enforce that? 18:51:37 in the backends i believe 18:51:46 dtsanek, stevemar: yes 18:51:46 bummer :-( 18:51:53 about 9 minutes remaining 18:52:19 so i'm ending the vote here, raildo rodrigods htruta take the 2 options going forward and present them in the spec 18:52:22 #endvote 18:52:23 Voted on "option for getting a project scoped token?" Results are 18:52:24 1 (1): bknudson 18:52:25 3 (7): rodrigods, marekd, iurygregory, htruta, henrynash, raildo, stevemar 18:52:26 5 (7): gyee, dstanek, haneef, lbragstad, david8hu, amakarov, lhcheng_ 18:52:33 thanks guys 18:52:46 ok, thank you guys :) 18:52:48 stevemar: ++ it’s too close to call just here 18:52:49 really quickly going to gyee 18:52:58 #topic Should Endpoint Constraint Enforcement be its own middleware, or not? 18:53:02 thanks guys 18:53:06 ++ 18:53:25 stevemar, I need jamielennox on this one since he's the only one wants it to be a separate middleware 18:53:38 I guess I can play this out in ML? 18:53:49 educate us us for 2 minutes? 18:53:59 you guys have any strong opinion on this one? 18:54:13 theres also this: https://review.openstack.org/#/c/177661/ 18:54:15 basically for endpoint enforcement, it is currently part of auth_token middleware 18:54:37 gyee, I kind of agree with him ... auth_token should only be doing what it is supposed to do (validte tokens) 18:54:40 gyee current thought make it its own middleware 18:54:46 and it shoudlbe for enforcing policy 18:54:46 gyee, anything different should go in a separate middleware 18:54:47 arguments for it were 1) it should be part of "token validation", and 2) it is less disruptive for CMS 18:55:26 ayoung, right, I had it as separate middleware at the beginning 18:55:31 but...morgan was the one that wanted it unified 18:55:36 and we can;t make that call without him 18:55:39 you and morganfainberg convinced me to merge it with auth_token 18:55:53 gyee, and you are OK with either approach, and really, so am I 18:55:58 I am happy to separate it out again 18:56:05 gyee, prisoner to the whims of the ptl 18:56:18 stevemar, :) 18:56:20 actually, who said split it besides Jamie? 18:56:34 I'm a pushover here..I just want progress 18:56:34 ayoung, Jamie so far 18:56:40