18:02:13 #startmeeting keystone 18:02:13 Meeting started Tue Apr 28 18:02:13 2015 UTC and is due to finish in 60 minutes. The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:17 The meeting name has been set to 'keystone' 18:02:19 Hi everyone! 18:02:20 answer: spring cabbage 18:02:25 o/ 18:02:30 welcome to "it's almost summit time" edition of the Keystone meeting 18:02:34 Greetings 18:02:34 BURMA! 18:02:44 #topic rollcall 18:02:44 Sorry, I panicked 18:02:51 ROBOT ROLL CALL! 18:02:58 #vote Rollcall! here 18:03:00 tom servo 18:03:02 o/ 18:03:03 #vote pedro 18:03:04 #votre here 18:03:08 #startvote Rollcall! here 18:03:10 Unable to parse vote topic and options. 18:03:11 #vote here 18:03:12 #vote here 18:03:14 #startvote Rollcall? here 18:03:15 Begin voting on: Rollcall? Valid vote options are here. 18:03:16 Vote using '#vote OPTION'. Only your last vote counts. 18:03:17 #vote here 18:03:17 #vote here 18:03:18 #vote here 18:03:19 #vote here, there, everywhere 18:03:19 #vote here 18:03:19 #vote here 18:03:19 dstanek: here, there, everywhere is not a valid option. Valid options are here. 18:03:21 #vote here 18:03:22 #vote here 18:03:24 #vote here 18:03:25 #vote here 18:03:26 #vote here 18:03:28 #vote here 18:03:28 #vote here\ 18:03:28 ayoung: here\ is not a valid option. Valid options are here. 18:03:29 #vote pedro 18:03:30 #vote here 18:03:31 stevemar: pedro is not a valid option. Valid options are here. 18:03:35 #vote here 18:03:39 openstack: valid options are where? 18:03:39 #vote for stevemar! 18:03:39 #vote here 18:03:39 stevemar: for stevemar! is not a valid option. Valid options are here. 18:03:40 #vote here 18:03:42 #vote here 18:03:43 #vote here 18:03:44 #vote here 18:03:49 This is the last rollcall 18:04:01 i will be unioning the last 3 meetings roll calls 18:04:04 and updating the list 18:04:06 fyi 18:04:06 #vote here 18:04:11 ayoung, voter fraud 18:04:12 then the room self destructs and we forget this ever happened 18:04:15 #vote here 18:04:22 dstanek: what ever happened? 18:04:23 #vote here 18:04:32 20s more 18:04:42 (them tune to mission impossible starts playing) 18:04:42 #vote here 18:04:56 your mission should you choose to accept it... 18:05:04 #vote here 18:05:15 #endvote 18:05:16 Voted on "Rollcall?" Results are 18:05:17 here (17): rodrigods, gyee, lbragstad, ayoung, morganfainberg, lhcheng, marekd, geoffarnold, david8hu, dolphm, samueldmq, amakarov, henrynash, roxanaghe, rharwood, raildo, stevemar 18:05:17 #vote here 18:05:19 #vote here 18:05:23 aww 18:05:26 jamielennox: saw it. no worries 18:05:28 slackers 18:05:31 jamielennox, always missing out 18:05:35 HA! 18:05:46 ok going to do things a bit out of order today 18:05:51 so we can get the easy stuff done first 18:05:51 always miss the first couple of minutes.. 18:06:01 #topic Midcycle update 18:06:03 ayoung: o/ 18:06:07 skip the snooze alarm 18:06:16 OK...Midcycle 18:06:34 #action morganfainberg to send midcycle info email this week 18:06:35 I've been talking with Orran Kreiger of the Mass. Open CLoud effort, HQed at Boston University. 18:06:56 Since it is summer session, there should be ample space available. 18:07:11 great. 18:07:17 We're trying to lock down where exactly that is, but suffice to say, BU should be a GO for the Midcycle 18:07:25 which dates? 18:07:33 BU? 18:07:36 * bknudson books travel 18:07:38 dates and hotel info is important 18:07:39 There are even Dorm rooms available if people want, at $75 / night 18:07:42 Boston university i guess 18:07:43 @ayoung Dorm rooms will be available as well for keystoners? 18:07:43 boston U? 18:07:48 dolphm: yes 18:07:57 co-ed? 18:07:59 dolphm, Boston University 18:08:01 * geoffarnold plans to spend a few days with family 18:08:13 ayoung: Jul 15-17? 18:08:25 Yes. that is the preferred dates 18:08:35 ayoung: ok we will plan for 15-17 18:08:56 #info Keystone midcycle, July 15-17 at Boston University 18:09:11 Henry confirms hs is definitely, categorically, not moving house then 18:09:17 #action ayoung to look into RedHat sponsorship of food etc. 18:09:22 Parking is $8/day, and if overnight parking is needed I believe that is $24/day. 18:09:28 #action morganfainberg to look into HP sponsorship of food etc 18:09:46 baked beans 18:09:56 ayoung: AAA discount for overnight stay in the dorm room? 18:10:09 There might be better hotel options per COmapny, if your company has a presense in the area. If so, please find out and share 18:10:31 I'll be looking into hotel blocks 18:10:33 etc 18:10:40 but that can wait a week or two 18:10:45 or until the summit 18:11:03 let's not spend the whole summit talking about the mid-cycle. 18:11:22 There is a really nice room in the Photonics building, but it is not available until the 28th. I don't think we want to wait on that, right? 18:11:30 July 27-29 18:11:32 bknudson: the goal is to do what we mostly do at the midcycle at the summit 18:11:50 bknudson: specifics about what will happen at the midcycle will be discussed *post* summit (e.g. goals/targets/etc) 18:12:27 morganfainberg, just to firm up; I asked them to target a space for 30 people 18:12:32 ayoung: perfect 18:12:33 is that too high or too low? 18:12:40 ayoung: we will keep it at max 30 18:12:45 I invited dhellmann to the meetup since he hasn't been to any. 18:12:47 i think 20-25 has been the numbers the last couple times 18:12:56 but 30 is our hard cap. 18:13:03 ok lets keep moving 18:13:05 OK. I think, then, we can probably even make use of a standard classroom. Should give us more options 18:13:10 #topic For stevedore, should I assume no extensions? 18:13:12 bknudson: o/ 18:13:30 so just a question on whether the stevedore should assume that extensions are there or not. 18:13:39 bknudson: i would drop the "Extension" part 18:13:41 i.e., should I have "contrib" in the endpoint names. 18:13:44 shouldn't they be discoverable? 18:13:46 i like the keystone.X 18:13:49 extensions I mean 18:13:51 not keystone.contrib.x 18:14:13 otherwise whoever does the final work for removing extensions will have to update the entrypoints 18:14:16 bknudson: hopefully we will see continued progress on dropping extensions into core this cycle. 18:14:26 bknudson: lets just drop contrib now. 18:14:32 unless someone is opposed to that 18:14:33 so if people agree I'll just drop the contrib. 18:14:46 I'm not opposed. 18:14:53 i don't mind, it's not hard either way 18:15:02 vote ? 18:15:16 i'd like to see contrib go away 18:15:18 drop contrib from where, request PATH? 18:15:19 samueldmq: just say if you're opposed to dropping .contrib. from the entrypoint name 18:15:33 gyee: it's the stevedore namespace for finding the driver 18:15:41 gyee: for stevedore loading, the entrypoint name should be Keystone.X or Keystone.contrib.X ? 18:15:50 bknudson, tell dhellmann to organize an oslo meetup :P 18:16:00 oh that, should be fine 18:16:08 going once. 18:16:10 stevemar: that's dims' problem now 18:16:12 morganfainberg, no I am not :) 18:16:15 twice 18:16:32 ok bknudson, dropping .contrib. now is the course 18:16:35 vs. later 18:16:41 ok, thanks 18:16:45 I would include "keystone" in the entry point namespace, but not in the name of each entry point, fwiw 18:17:00 dhellmann: the namespace yes 18:17:03 k 18:17:08 shouldn't be any backward compat concern right? 18:17:27 #info stevedore loading of extension/backends will not include '.contrib.' in the namespace 18:17:39 #topic Release Notes (Kilo) 18:17:44 RC2 is kilo 18:17:48 and please review the change that moves the first ext into core 18:17:51 it will be released on thursday 18:17:58 gyee: what we did in some other projects early on was register the old importable name as a duplicate plugin name (so "kombu" and "oslo.messaging.drivers.impl_kombu" pointed to the same thing) 18:18:10 so we'll have all batteries right under keystone. ? 18:18:27 #link https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Identity_.28Keystone.29 18:18:31 won't it be a bit messy? 18:18:33 please look at it. 18:18:46 amakarov: this is specifically about .contrib. code 18:18:56 amakarov: which is being moved into core already 18:18:57 dhellmann, so we'll need to use the same trick? 18:19:04 amakarov: so it would require a change later 18:19:16 gyee: bknudson is already handling those cases 18:19:27 excellent 18:19:30 so 18:19:32 release notes 18:19:34 gyee: we were just doing if you don't find it in stevedore fallback to the old way 18:19:38 the import code just falls back to the old method if stevedore didn't work. 18:19:43 the release notes need to be done by EOD tomorrow 18:20:10 I need someone willing to take on working on release notes 18:20:17 I am going to be offline all tomorrow 18:20:33 I will be doing some further work today. but i don't think it will be complete 18:20:41 everyone should feel free to edit them. 18:20:56 but i need a specific person delegated the job of "ensuring they are spot on" 18:20:58 morganfainberg, is that just to detail those points 18:21:02 and you'll talk w/ ttx tomorrow 18:21:10 to confirm everything is on track 18:21:21 samueldmq: it's making sure the notes are complete 18:21:34 * dolphm volunteers 18:21:36 morganfainberg, I can do if you want me to 18:21:38 dolphm: yay! 18:21:45 samueldmq: work with dolph 18:21:52 ++ 18:22:07 #action dolphm and samueldmq to confirm release notes are complete for Kilo by EOD Wednesday 18:22:30 ok moving on to summit and liberty planning 18:23:04 going to spend ½ the rest of the meeting on liberty priorities thne we will switch to summit planning so we can assign slots for session topics 18:23:10 #topic Liberty Priorities 18:23:20 #link https://etherpad.openstack.org/p/keystone-liberty-priority-specs 18:23:36 So. It's that time. what are we wanting to focus on for Liberty? 18:23:46 these aren't written in stone 18:23:53 just the first pass of priorities 18:24:33 Give me Liberty, or give me money back! 18:25:02 I'd like to see functional testing implemented 18:25:03 I might have some objectives regarding intercloud stuff, but that needs some more in depth discussions probably over the summit. 18:25:11 amakarov: ++ 18:25:13 Dual Scoped Token again? 18:25:26 marekd: intercloud stuff is worth a summit session for sure 18:25:40 I'm planning on just reviewing stuff as it comes up. 18:25:52 bknudson, no big features? 18:26:04 morganfainberg: i am not proposing anything for liberty know because as you know i don't have anything very detailed. I am really counting on some brainstorming with you in 3 weeks. 18:26:06 (from you) 18:26:14 marekd: sure. 18:26:27 My employer doesn't give me time to implement any features. 18:26:36 stevemar: reviews from bknudson are big feature itself. 18:26:37 ayoung, we have a spec for this https://review.openstack.org/#/c/176054/3/specs/liberty/dual-scoped-token.rst, I believe that we don't need to discuss in summit, but we want to implement this on liberty: 18:26:39 amakarov: we need some volunteers to start writing tests 18:26:43 marekd, true 18:27:16 dstanek, myself and I'll try to talk bbobrov into it :) 18:27:43 dstanek: there was some trials with federation setup/tests so, as long this is not done i can probably help with federation part of the functional tests. 18:27:48 so the way I'm seeing it now: 18:27:54 raildo, probably not 18:28:09 but let me read up first 18:28:11 marekd: you're going to be at the summit right? 18:28:17 dstanek: yes! 18:28:26 Features that look like they are a priority (API impacting): Policy, ???, ???, ???, Domain SQL enhancements 18:28:27 marekd: we should work together to get all the federation stuff done 18:28:34 dula scope is confusing, 18:28:40 just added Python3 to the list 18:28:47 oh and one of those ??? is reseller 18:28:52 but...the bones of the idea are solid 18:29:06 raildo, my only issue is with what we are calling it 18:29:17 dstanek: as much as time lets us do this. 18:29:19 so I'm ok with solving the other priorities at the summit for API impacting 18:29:23 dual scoped is going to think people want one token for two projects. 18:29:24 if marekd isn't there, a poster of him will be. 18:29:27 ayoung, polymorphism 18:29:28 And people have asked for that 18:29:41 As we deprecate LDAP assignment backend we need to start hardening SQL backend to support multi-master environments 18:29:43 gyee, just polyps actually 18:29:43 with the caveat that specs are proposed to the backlog before we all fly to vancouver 18:29:57 ayoung: maybe we don’t need to call it anything…it’s just teh token you get on a project this is alos acting as a domain? 18:30:03 henrynash, ++ 18:30:07 For ex. ensure we don't use autoincrement 18:30:13 henrynash, 100% 18:30:20 ayoung, yes... we are improving it. the dual scoped token is for just one entity that behaviour as project and a domain. 18:30:22 henrynash: we probably need to support domain in the scope if it doesn't break anything 18:30:24 henrynash, ++ 18:30:26 but easy to do that. 18:30:30 call it the "magik token" 18:30:31 morganfainberg, what about splitting up keystone? 18:30:37 stevemar: microservices? 18:30:43 stevemar: is that a realistic target for liberty 18:30:49 morganfainberg: yep…if you explictly ask for domain scope…that’s all you get 18:30:54 morganfainberg, hmm... maybe not 18:31:13 gyee, magic token hahah 18:31:14 i'm inclined to say we would need to focus on auth shuffling and/or a conductor like interface to identity store if we want that 18:31:15 we should at least remove the circular deps is any still exist 18:31:20 stevemar, we'll need a ton of TNT to explode it :) 18:31:21 but a real split... i don't think will happen 18:31:23 stevemar, I think so 18:31:40 stevemar, identity can be split off, as can policy, leaving assignment in the middle 18:31:47 morganfainberg, ++ for conductor 18:31:58 that one's very useful 18:31:58 gyee: morganfainberg what's conductor? 18:32:19 i think it's worth a chat, but maybe not realistic for L 18:32:20 marekd, layers between core and drivers 18:32:24 layer 18:32:58 stevemar, specifcially, we idenitfy new service types: identity is the good name, but really should be the user and group operations. token ops happen on Keystone assignmnet service. Policy is its own service. Maybe catalog, too 18:33:06 we needs to fix the layers we already have. especially isolating web stuff from the rest of the system 18:33:06 but conductor for nova is a separate application - i don't see us needing that for keystone 18:33:07 gyee, is there a spec for conductor? 18:33:10 stevemar, we start the ball rolling 18:33:12 for non-API impacting (aka not "features"), I see priorities being (in this order): stevedore for drivers, Functional Testing, Stable KSDI (driver interfaces) [yes this is personal bias], Fix Dependency Injection (no circular deps), Pecan, python3, v3-only 18:33:17 but assume that all these things are running in one server 18:33:22 http://docs.openstack.org/havana/config-reference/content/section_conductor.html 18:33:24 marekd, we can essentially does orchestration workflow in there 18:33:39 just to get the service catalog straight, and fix the client. 18:33:52 geoffarnold: thanks. 18:33:55 morganfainberg, v2.0 will be dropped? 18:34:09 amakarov: deprecated officially if openstack works with v2 turned off 18:34:18 conductor sounds like architecture envy - seems overly complicated for this cycle 18:34:43 dstanek: agreed. it's too much. 18:34:48 dstanek, ++ 18:35:01 overly complicated in general for us 18:35:05 the priorities mentioned by morganfainberg look good to me. 18:35:07 we dopn't need conductor 18:35:13 Conductor is most important for large scale in-service updates, so that mixed version configs will work 18:35:19 they need it for thngs that are NOT the API service talking to the DB\ 18:35:28 if we split off identity into it's own API conductor might be required 18:35:40 it's own micro-service thing 18:35:44 I don't see that we need it 18:35:50 morganfainberg, I don't think so ...different architecture 18:35:51 it's a long term goal 18:35:56 anyway 18:36:06 morganfainberg: we shouldn't, identity would just manage it's own db 18:36:24 jamielennox: how does assignment ask identity for user-information then? or are we pure federated? 18:36:30 are there specs or blueprints for everything on the priority list? 18:36:46 even if Identity "wrote" to the user table and tokens read from the user table, they can still share a DB instance for that and get things optimized 18:36:52 bknudson: the Stable KSDI, and python 3 has specs proposed to backlog 18:37:08 the one par to API V3 we should look at sp[litting off in liberty is policy 18:37:09 morganfainberg: sure there's some for of request/response there but why couldn't that just be the public identity API 18:37:14 bknudson: dependency fix is backlog iirc already, v3 only isn't a spec [it's cross-project devstack-y stuff] 18:37:25 do we also have middleware and client priorities? 18:37:28 bknudson, pecan is maybe a spec? 18:37:57 bknudson: middleware is going to release like the server, but i think it's not going to grow a lot of new features/capabilities 18:37:58 do we want a spec for pecan? that review's so old i hadn't considered it 18:38:03 jamielennox: yes please 18:38:06 For Liberty, I'm assuming that once all of the other projects have figured out what they need to do in order to support hierarchical multitenancy, we may get a few small change requests. Good to close out most of that during the summit 18:38:19 geoffarnold, ++ 18:38:19 ok let me re-iterate priorities: 18:38:24 I'd like bp/auth-token-use-client to be a priority, since it was approved in K timeframe but didn't make it. 18:38:31 geoffarnold, ++ 18:38:48 middleware's big thing is going to be tokenless 18:39:08 and...we need to make sure we make that work for X509, but also Kerberos and Basic Auth 18:39:24 bknudson: sure, the other thing i want to do for middleware is the bp/request-helpers and doing X-Service-Token automatically 18:39:27 API Impacting: Reseller(Has Spec, Approved), Domain SQL Enhancements (Needs spec?), Policy(Has spec, which specs?), TBD@Summit, TBD@summit 18:39:44 anyone have anything to add to that^ 18:39:57 how about getting rid of extensions? 18:40:00 bknudson: sure that BP should be non-api impacting 18:40:06 ayoung, the bit and pieces are in place to support Kerberos and Basic Auth 18:40:07 bknudson: i'll add that to the non-api impacting list. 18:40:09 really? 18:40:17 bknudson: the middleware one 18:40:25 bknudson: was the non-api impacting 18:40:37 bknudson: sorry was slow typing. 18:41:12 I'm now suggesting getting rid of extensions as API impacting. 18:41:24 gyee, yes...on the server side. Just want to make sure the middleware gets what it needs, too 18:41:27 ok we have 2 open priorities: tokenless-auth/operations one of them? or decide at summit? and rid of extensions is the other proposal 18:41:42 I'd like to see tokenless-auth on the list. 18:41:47 ok 18:41:47 tokenless-auth/operations should be there 18:41:51 morganfainberg, tokenless-auth has already decided 18:41:56 we just need to get the impl in 18:42:11 API Impacting: Reseller(Has Spec, Approved), Domain SQL Enhancements (Needs spec?), Policy(Has spec, which specs?), Tokenless-auth(Has Spec, not approved), TBD@summit 18:42:14 its close, last I saw 18:42:20 gyee: and figure out how tokenless-auth is going to impact X-Service-Tokens 18:42:29 bknudson: i'd be ok with adding "no-more extensions" 18:42:43 bknudson: if someone is signing up to do the work/spec 18:42:52 jamielennox, not yet, still losing hair over that one 18:42:55 morgainfainberg: I’ll have a speci for the Domain SQL Enhancements ready before the summit 18:43:00 henrynash: ok 18:43:05 morganfainberg, lets say dynamic-policy for now, and decide at the summit how far we are willing to commit to on that 18:43:11 ayoung: ok 18:43:12 tokenless-auth (has code) 18:43:26 ayoung: just remember API impacting code freeze is liberty 18:43:27 2 18:43:30 morganfainberg, I think we can cover that whole spec, 18:43:32 ok 18:43:55 ayoung, I signed up to help with dynamic policy. Do not forget about me :) 18:44:00 stevemar, https://review.openstack.org/#/c/156870/ 18:44:08 ok lets leave the last slot open for TBD@summit 18:44:15 only thing missing in that patch is to support ephemeral user 18:44:15 david8hu, you and samueldmq are going to become good friends 18:44:22 gyee, yep, i know - i've been reviewing it :P 18:44:23 we cna slot in extensions-no-more if we don't have something else to fill it 18:44:30 ayoung, hi - reading up 18:44:35 morganfainberg, that's not user facing though 18:44:40 well, it sort of is 18:44:40 morganfainberg, K2K client extensions? 18:44:44 ayoung, we should have Philz coffee together ;) 18:44:55 ayoung: that could include what i will probably want to wark 18:44:57 work 18:44:58 We need a smarter client approach if K2K is going to be part of it. 18:44:58 on 18:45:06 marekd, cool 18:45:09 morganfainberg: ^^ 18:45:09 ayoung, K2K client plugin is under review 18:45:26 and waiting for suggestions in its design 18:45:28 ayoung, there are a few bits of code around that are for k2k 18:45:39 * dims peeks 18:45:46 and we have a guy internally looking to add k2k support for horizon 18:45:47 rodrigods, its more than just an auth plugin. It needs to be smart about chosing "where to go" and I will wave my hands and dance and things 18:45:52 ayoung, ++ david8hu we can sync up later, I can work together in the specs (cleaning, etc0 18:45:56 K2K is a workflow, just like aggregator 18:45:58 #info Liberty Priorities (API Impacting): Reseller(Approved Spec), Domain SQL Enhancements(Spec will be prior to summit), Dynamic-Policy(Clear Spec proposed before summit, Scope TBD @ summit), Tokenless-auth (Has Spec, needs approval, code ready), TBD@summit 18:46:08 so..is this a good lead in to the policy discussion morganfainberg ? 18:46:16 ayoung, exactly, just called plugin because it was the first term 18:46:20 ayoung: going to finish the non-api list 18:46:20 those priorities look good to me. 18:46:23 stevemar, that's great, thanks for that 18:46:24 k 18:46:28 ayoung: then we will slip over to policy 18:46:29 15 minutes left 18:46:33 then do summit planning in -keystone channel 18:46:53 re-iterating non-API impacting priorities 18:47:39 samueldmq, we are going to have so much fun 18:47:46 lol 18:47:50 david8hu, ++ 18:48:18 stevedore for drivers(Approved, No-spec), Functional Testing (has spec?), Stable KSDI (has spec, against backlog), Fix Dependency Injection (has spec?), Pecan (needs spec?), python3 (has spec, backlog), v3-only (no keystone spec needed), keystonemiddleware-uses-auth-plugins(code-ready, has spec, approved) 18:48:19 marekd, hehe lol 18:48:25 am i missing anything from that list? 18:48:34 or did i add anything that shouldn't be there? 18:48:34 token provider cleanup? 18:48:39 lbragstad: ah yes 18:48:43 or is that in a different category? 18:48:43 ABI? 18:48:49 gyee: Stable KSDI 18:48:51 gyee: it's there 18:48:53 ah 18:48:57 ayoung: for the 'smarter client approach for k2k' i think we will have to stick with token-per-cloud for now. 18:49:06 marekd: yes 18:49:08 ayoung: and teach ksc to handle multiple tokens 18:49:13 marekd, that is fine. Questions is "when to get the token" 18:49:18 I'm fine with those priorities. 18:49:23 me too 18:49:28 anyone want to add more to the list/take things off? 18:49:34 marekd, yes, don't think you want to share the fernet key :) 18:49:38 i will need some people to step up for taking on some of the work. 18:49:44 and we will need specs. 18:49:44 I don't understand the need for pecan. 18:49:56 bknudson: it's a swap of the route framework. 18:49:56 morganfainberg: so, this intercloud thing? 18:50:02 morganfainberg, we are just starting to see Federation take off. I'd like to leave some wiggle room in there for features we find neceesarty to make federation usable 18:50:11 morganfainberg: unless you say no to add it here until summit 18:50:13 like...delegating the mapping rules to non-admin users 18:50:14 bknudson, uh, because pecan sounds sexy? 18:50:17 morganfainberg: I added one otehr minor one taht was approved for Kilo (supression of “extra” attr in SQL DB entities) 18:50:23 gyee: i don't know what you're talking about, we're building a pastebin-backed distributed fernet key share 18:50:25 ayoung: we have an open API impact, and we can always change prio/drop them as needed at the summit 18:50:28 ayoung: this is not "in stone" 18:50:30 gyee: I've been using pecans all wrong then. 18:50:33 henrynash, ++ 18:50:34 then I'm good 18:50:45 dolphm, I mean sharing key among independent clouds 18:50:51 bknudson: i'd like it for a couple of reasons, to get rid of our home grown wsgi that makes a mess, to get some structure to our models so i can find routes by api, not by component 18:50:56 bknudson: it would be a cleanup/tech-debt paydown on how we build the routing framework 18:50:59 o/ 18:51:00 and ^^ that 18:51:01 dolphm, share among instances, absolutely 18:51:05 ayoung, ++ 18:51:14 ayoung: ++ 18:51:16 ayoung, something will come down the pipeline for federation 18:51:24 I'd like to start policy now, if that is ok 18:51:29 9 minutes 18:51:31 bknudson: but i don't have any particular love for pecan, i just want to use some existing component 18:51:38 i'm focussed on reseller-style federation 18:51:41 gyee: and share with your end users. why make them auth with keystone when they can generate keys securely client-side? 18:51:44 ok sec and we will let rocky say 2 min thing then policy 18:51:46 morganfainberg: I’m not sure that it actually cahnges the API spec….so will move it to the other section 18:51:51 sorry, missed most of the meeting, but I'd like to make sure tests that run on clouds in the wild, non-admin are part of the liberty cycle 18:52:28 isn't that a question for tempest? 18:52:30 For trademark, but most importantly for interop between clouds and moving apps between clouds, we need to verify keystone key behaviors 18:52:43 It is both tempest and defcore. 18:52:43 #info Non-API Impacting Priorities: stevedore for drivers(Approved, No-spec), Functional Testing (has spec, needs approval), Stable KSDI (has spec, against backlog), Fix Dependency Injection (has spec, needs approval), Pecan (needs spec), python3 (has spec, backlog), v3-only (no keystone spec needed), keystonemiddleware-uses-auth-plugins(code-ready, has spec, approved), Token Provider Cleanup 18:52:50 dolphm, no, not sharing with end users, I mean sharing with neighbor clouds, I was responds to marekd's one token per cloud comment 18:52:56 Rockyg: that's a good point - i don't know if we can do anything from keystone specifically - but maybe an inter-project thing at summit needs to be 'how to write admin-less policy files' 18:53:05 gyee: oh you're serious 18:53:06 #topic Testing admin-less 18:53:21 The key is that there are certain assumptions tempest make that make testing outside of devstack hard 18:53:33 I assume there's already tempest tests for getting a token and using it. 18:53:42 jamielennox: ++ 18:53:46 gyee: your key management story gets a little more complicated (not sure but I have a feeling security would be tough?) 18:54:06 gyee, I wrote that up years ago 18:54:06 lbragstad, you did see the :) at the end of my first comment 18:54:09 I think getting a token and using it is the important part that needs to be standard 18:54:10 split on domain lines 18:54:15 lbragstad: gyee: please hold this convo until later 18:54:16 also, basic tests that validate keystone enforces roles. So negative tests that validate you get the right error message 18:54:25 "who can sign for what" 18:54:29 lbragstad: gyee: we have little time left 18:54:33 OK..policy 18:54:42 ayoung: sec. wait for Rockyg to finish 18:54:43 Currently all of the tempest tests require admin privelege 18:54:59 tenant admin is ok, but not cloud. 18:55:09 Rockyg, oof, yeah, that could be bad 18:55:11 Rockyg: and you want us to help with tests that would show API functionality w/o admin 18:55:12 ? 18:55:23 Yes, please 18:55:28 Rockyg, you need the policy stuff I'm about to talk about 18:55:34 Not just w/o admin, but with domain-local admin 18:55:37 cool. OK. 18:55:40 keystone will need to have some users. 18:55:42 Ok, please think aobut that and we should help Rockyg out. 18:55:50 and this does play right into policy 18:55:51 so... 18:55:56 #topic Policy 18:55:59 OK... 18:56:01 also, quickie, I think bknudson is the guy, but a liaison for log wg 18:56:01 ayoung: sorry about the limited time left 18:56:06 Rockyg: so i made a start on that in tempest to assume a domain scoped token, but i think that'll mostly be a tempest issue 18:56:08 ioram, has a proof of concept of DB drive policy 18:56:16 they are using a library that is py3 only 18:56:32 ioram, want to expound? 18:56:34 ayoung: unfortunately we can't make things py3 only 18:56:39 (4min left) 18:56:47 jamielennox: great. Let's talk either elsewhere in IRC, or at the summit. 18:57:04 morganfainberg, but we can potentially make db-driven policy Py3 only. It can be optional to start 18:57:05 Is there a wiki page on the policy ideas? 18:57:17 and, we can work towards splitting policy off of the rest of the Keystone server 18:57:24 ok. hi guys. My PhD is on federated policy administration service for multi cloud environment. 18:57:33 ayoung: negative. i do not want py3 only code in the tree until we drop py27 18:57:35 sorry 18:57:46 And I've been working on a database model to store Openstack policies. 18:57:56 morganfainberg, ok, we'll have to work to backport the DNF code that they are using, or find an alternative 18:58:01 ayoung: yes. 18:58:10 ayoung, morganfainberg: agree - but it's easier to support both py2/py3 if you start with py3 18:58:15 ioram, what is the library? 18:58:43 jamielennox: if the library is py3 only it's harder. 18:58:59 #link https://review.openstack.org/#/c/133814/ 18:59:05 OK...since little time 18:59:16 henrynash, need you to stick around and discuss roles in #keystone 18:59:19 morganfainberg: i mean surely they'll accept patches to support py2 as well 18:59:20 The library is to transform any logical expression into DNF. The name is pyeda. https://pypi.python.org/pypi/pyeda 18:59:26 jamielennox: i hope 18:59:33 ioram, have you have a chance to review ayoung's https://review.openstack.org/#/c/133814/ 18:59:43 david8hu, he 18:59:49 's take n ownership of it 18:59:50 ioram: i'm not opposed to that, but we will need to make it either py2 compat as well *or* find an alternative 19:00:12 The latest version don't support Py2.7, but I think there are some old ones that does. Maybe these old version also work for us. 19:00:12 ok we're out of time. 19:00:18 morganfainberg, I think that is fine. Suspect Py27 would be easiest, 19:00:21 ioram: we will need to look into it 19:00:28 ioram, I can also discuss with you some alternative post-meeting :) 19:00:30 everyone back to #openstack-keystone 19:00:31 so summit session planning in -keystone 19:00:39 ioram, feel free to ping me to talk about it 19:00:43 lets let infra have their meeting slot 19:00:46 #endmeeting