18:03:07 #startmeeting Keystone 18:03:07 Meeting started Tue Oct 28 18:03:07 2014 UTC and is due to finish in 60 minutes. The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:03:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:10 The meeting name has been set to 'keystone' 18:03:31 So we're headed to Paris! 18:03:32 woot 18:03:39 wait what 18:03:50 ppl arriving Sat or Sun? 18:03:57 I'll be there Saturday 18:03:58 (some Monday i heard) 18:03:59 Sun 18:04:04 I'll be there on saturday morning 18:04:05 Sunday 18:04:07 Sat morning 18:04:10 Sun early...overnight Saturday night 18:04:11 saturday morning 18:04:20 Sunday 18:04:28 flying through MSP? 18:04:36 I am! 18:04:36 * marekd Sunday 18:04:42 bknudson: ^ 18:04:42 i arrive at 7am give or take 18:04:55 Sunday night 18:04:57 lbragstad: you'll be on the flight the day before. 18:05:15 bknudson: yeah, friday night arriving Saturday morning 18:05:18 o/ 18:05:19 Ill be there Sunday 18:05:26 for international fights is it better to carry-on or check baggage? 18:05:27 lbragstad: smart! 18:05:36 Sunday morning 18:05:39 o/ 18:05:41 bknudson: we'll see 18:05:42 topol, nice - first round of cognac on you? :P 18:05:47 dstanek always best to carry on 18:05:48 dstanek: both? :-) 18:05:54 dstanek: always carry on! but i'm doing both 18:05:54 Saturday 18:06:01 critical stuff stays on my back :) 18:06:02 dstanek, depends on how long you'll be there 18:06:12 since i'm staying for an extra week i'll be checking clothing mostly. 18:06:14 is there good place to get lub? 18:06:15 morganfainberg: only a week 18:06:33 for 1wk i'd do carry on unless you need lots of stuff 18:06:34 i almost always carry on, but i've never done international 18:06:39 I carried on even for 7 days to Hong Kong. I wont go back to checking bags 18:06:40 I'm also staying an extra week. 18:06:41 Had them get ripped to shreds in the past 18:06:55 topol: ++ 18:07:01 dstanek if you can carry on definetly do that 18:07:05 i only brought my backpack to atl 18:07:18 topol, it's when you start hitting ~12-20 days it's hard to do as a single carryon internationally 18:07:25 morganfainberg: bring detergent 18:07:28 problem solved 18:07:33 morganfainberg: or hard to keep friends 18:07:43 morganfainberg if I leave for 12 days my wife will kill me. wont be a problem 18:07:48 dolphm, *or* abuse my friends in Lyon when i'm visiting for their washing mashine 18:07:53 henrynash: unless they did the same. 18:07:54 ;) 18:08:06 henrynash, haha 18:08:16 dolphm, they sell it at the laundromats 18:08:24 we do that when we goto Italy 18:08:31 henrynash, you are sleeping at home each night, right? 18:08:37 just commuting via train? 18:08:44 ayoung: no..but nice idea! 18:08:51 travel size laundry soap http://www.amazon.com/dp/B001TUZS98/ 18:09:01 I wouldn't want to spend my time in paris washing clothes. 18:09:01 Cuz crashing with you was my backup sleeping plan 18:09:13 ayoung: ah! 18:09:16 I can do that here. 18:09:18 bknudson, pay the hotel to do it for you. most will (even internationally) 18:09:40 ok so. 18:09:45 #topic Review of Keystone Blueprints for "Trivial" Status 18:09:51 ayoung how come you can never afford a room? 18:10:10 ayoung: if you're looking at backup plans i'm well and truly screwed 18:10:11 We're going to try something new here. mostly this is just to cover the plan once we hit the swing of things. 18:10:16 jamielennox: ? 18:10:28 marekd: he organized my accom 18:10:28 topol, "Backup" meaning when jamielennox kicks me out. once again he is subjected to sharing a room with me 18:10:35 jamielennox: ayoung ? 18:10:58 marekd, same company, trying to keep down costs 18:11:18 #undo 18:11:19 Removing item from minutes: 18:11:20 ayoung: i was a studnent not so long time ago - i know what you are talking. 18:11:58 ok we can discuss accomodations in -keystone 18:12:05 :) 18:12:09 yes 18:12:09 #topic Review of Keystone Blueprints for "Trivial" Status 18:12:18 what are the blueprints to review? 18:12:48 Actually, morganfainberg you want to explain what is going on with backlog etc? 18:12:58 This is basically the way we're going to handle BPs that *dont* have a spec going forward, we will do a quick review each meeting and classify as "trivial" meaning no Spec needed 18:13:23 cool 18:13:26 if they are trivial they're approved and can be targeted for *this* milestone (or any) 18:13:31 maybe I'd get more reviews if I wrote up a bp. 18:13:32 criteria for trivial status? 18:13:32 an example of trivial: Fix documents 18:13:35 morganfainberg: I have one: https://blueprints.launchpad.net/keystone/+spec/remove-role-metadata 18:14:04 gyee, i'm working on full details, but basically stuff that doesn't change the REST API, is something "we should just do" 18:14:07 morganfainberg: this might be a good test…it’s not as trivial as documentation 18:14:09 henrynash: doesn't affect the API? 18:14:12 and is self explanitory 18:14:17 e.g. CADF everywhere 18:14:32 bknduson: teh manager-driver api, yes, not the controller-manager api 18:14:48 yes we all agree we should make all notifications cadf, but do we need a big heavy formalized spec for it? probably not 18:14:54 sounds reasonable 18:14:54 bknudson: which we may say, menas it’s not trivial? 18:15:06 so lets take a look at keystone-client ( henrynash we'll use yours in a sec ) 18:15:09 #link https://blueprints.launchpad.net/python-keystoneclient 18:15:09 https://blueprints.launchpad.net/keystone/+spec/remove-role-metadata seems basic enough to me. 18:15:18 I hate to call it trivial. 18:15:26 bknudson: :-) 18:15:44 if you look at the list ^ we're only interested in "undefined, new, and untargeted" BPs 18:15:57 keystoneclient bp isn't going to affect the rest api 18:16:01 for ksc there are 6. 18:16:18 bknudson, exactly and also because the list is short, i'm using it to explain things 18:16:19 I've got code for https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-i18n , just didn't know there was a bp. 18:16:22 keystoneclient has always been a little weird about blueprints - i don't think it's just me 18:16:34 bknudson, that is also why reviewing these helps :) 18:16:49 jamielennox, yeah. 18:17:19 jamielennox: ++ 18:17:32 so we're not oging to go through all of these this meeting. we'll pick just a couple ( like henry's ) and I'll finish cleaning everything up so the first meeting post summit we can start this process. 18:17:47 story board should unify the approach between clients & server 18:17:53 dolphm, ++ 18:18:02 *excited* 18:18:03 and storyboard will help make this waaaaay better 18:18:22 ok so lets look at henry's bp now. 18:18:25 #link https://blueprints.launchpad.net/keystone/+spec/remove-role-metadata 18:18:35 not to derail again but do we expect storyboard soon? 18:18:42 jamielennox, not this cycle 18:18:49 jamielennox: nope. 18:18:49 it's in beta for -infra to use 18:19:04 jamielennox, help krotscheck get storyboard in shape for everyone else :) 18:19:06 jamielennox: Come to the lighting talk at the summit on monday to get an update. 18:19:10 we need a storyboard demo at the summit 18:19:19 ^^ lightning talk 18:19:32 bknudson: what's a storyboard? 18:19:34 The lightning talk is titled “Storyboard: Lightning Walkthrough" 18:19:36 i'd be keen to see it, i saw some of the beta but didn't really look at all the features 18:19:45 marekd: a new tracking tool to replace launchpad 18:19:55 lbragstad: thanks. 18:19:56 lbragstad, marekd, wow 18:20:32 ok 18:20:37 so Henry's BP 18:20:49 https://blueprints.launchpad.net/keystone/+spec/remove-role-metadata 18:21:11 so this is non-trivial in that it isn’t, say, just documentation.... 18:21:18 this looks like something that doesn't affect the API contract 18:21:40 but involves migration 18:21:43 data migration I mean 18:21:46 it does affect the manager->driver API….but not the controller->manaager API 18:21:52 gyee: no 18:22:14 so the meta are leftovers? 18:22:28 henrynash, this might be a case because it affects more things that we want a spec, but i'm open for anything to be classified as "no spec needed" (as long as it doesn't change API contract) 18:22:30 henrynash you can just remove the role metadata and all is well? 18:22:41 Is there any demand to PKI signe CADF messages? Or sign at log rotation? 18:22:50 ah..sorry, I'm behind 18:22:51 ayoung, different topic 18:22:52 gyee: yes…a few old manager APIs use it…and the drivers “fake up” the metadata from the underlying data 18:23:20 henrynash, k, I see 18:23:47 topol: it's about changing the "metadata" construction in the manager->driver API and replacing it with something more explicit 18:23:48 i could see this one go either way tbh. 18:23:54 then lets go spec 18:24:03 if there is a question...it probably means non-trivial 18:24:11 so I’m open to doing a spec if people think it needs it….I think this one is a good test of the border line 18:24:12 we can always downgrade if there isn't enough there 18:24:14 feels like it needs a spec 18:24:25 ok, done 18:24:25 i think this one would be better as a spec because there is a question of the more-explicit metadata -> other things 18:25:13 specs dont really help the dolphs and morgans of the world. but as a member of the unwashed masses they really help me to understand keystone arch and direction 18:25:14 I think this one is probably the type that you people needs to see a spec before they could agree you didn;t need a spec :-) 18:25:25 Let me make this explicit: if you are reviewing one of my specs, and you want to rewrite a section of it, please do so, and add yourself as a contributor/author 18:25:50 ayoung, i'll circle back on the backlog thing 18:26:01 until a spec is approved, lets treat them as collaborative documents 18:26:17 morganfainberg: let’s try and find one that we can agree that’s trivial so we can hone in where the boundry is 18:26:32 henrynash, looking for one now 18:26:33 actually 18:26:43 If it is a one line change already written 18:27:02 topol: unwashed? is that a continuation of the “do i packa carry on or not for paris"? 18:27:10 henrynash, https://blueprints.launchpad.net/keystone/+spec/deprecate-ssl-functions 18:27:24 None of mine are Trivial 18:27:47 henrynash I refused to answer on the basis that I may incriminate myself 18:27:52 this one is likely something that we "don't" care about a spec for. 18:27:54 #link https://blueprints.launchpad.net/keystone/+spec/deprecate-ssl-functions 18:28:00 it's mostly affecting testing 18:28:25 if we make the mechanism for handling the "self signed CA" better, everyone wins 18:28:43 morganfainberg, I have a solution to that! 18:28:48 but it wont have massive impact on too many things outside of devstack 18:28:54 dogtag? :) 18:28:58 and/or toy setups. 18:28:59 so. 18:29:07 thoughts on https://blueprints.launchpad.net/keystone/+spec/deprecate-ssl-functions ? 18:29:10 any blueprint that only affects keystone developers should be second guessed for necessity 18:29:13 not sure what the point is of making self signed CA more complicated. 18:29:17 Use Certmonger 18:29:19 ayoung: so on this one, we would explain how to set up certmonger (in the place of wherever we explain pki_setup)? 18:29:28 yep 18:29:33 basically. 18:29:35 ayoung: ok 18:29:43 morganfainberg: so as much as i think yes trivial the advantage of a spec there is that later we can point someone to it and say why we did it 18:29:43 and...for the selfsign, we would use certmaster. 18:29:49 its a trivial CA 18:29:59 openssl is a trivial ca 18:30:01 or just get certs from anywhere not keystone 18:30:05 morganfainberg: because as much as i consider that obvious it's used by enough deployments that someone will notice it missing 18:30:07 dolphm, exactly 18:30:17 jamielennox, i'm not saying we want this bp 18:30:19 i don't see any reason at all why keystone should be advocating for certmonger 18:30:23 in fact i think it's not worth the effort 18:30:25 so here is a question. what I liked about the specs is I can always go and do a review and see what needed to be reviewed. With trivial BPs now I have to look another place as well and do a merge/diff 18:30:29 there's an argument to make for devstack, i suppose 18:30:34 but, this is a case where the BP if we wanted it doesn't need a spec 18:30:42 dolphm: ++ keystone doesn't care, just configure it with certs 18:30:46 it would be interesting to see it in devstack 18:30:49 https://fedorahosted.org/certmaster/ 18:31:01 so in short, i'd say ditch this BP for keystone. 18:31:14 but it's not worthy of a spec even if we wanted it. 18:31:17 is XML RPC, in a stand alone server 18:31:20 jamielennox: and actually half of keystone's ssl / pki config options are so that it can generate it's own certs... so all those can go away 18:31:49 i'm actually a fan of repurposing this spec to "remove self-signed SSL options from keystone" 18:31:55 dolphm: yep, cause they are really confusing options when you come to it with a cert already 18:31:58 and not care *how* we get there. 18:32:09 they can be changed to cli options on keystone-manage 18:32:25 e.g. "here is where you stick your certs"- how devstack works is not really keystone's scope. 18:32:26 bknudson: remove the whole command from -manage 18:32:29 morganfainberg, because in real deployments the self-signed is never used correct? 18:32:29 if we still want to make it somewhat easy 18:32:32 morganfainberg: ++ 18:32:36 topol, , exactly 18:32:40 I'm also fine with removing the function 18:32:43 morganfainberg: devstack already has a CA and cert generating component 18:32:46 I'd leave the command in manage and make it call certmonger functions instead 18:32:55 but this discussion ios beyond the scope of this meeting 18:32:55 ayoung: nope - kill it 18:33:00 ok, so proposal: make this BP "remove self-signed cert generation options" 18:33:07 and call it a "no-spec needed" BP 18:33:13 jamielnnox ++ less code to learn/maintain :-) 18:33:48 I don't know if we need to deprecate the function 18:33:57 or if we can just remove it 18:34:01 morganfainberg: +1 to change purpose, -1 to no spec - it doesn't need to be long but i think it's more about documenting why we removed it 18:34:03 this could just be merged into the deprecated-for-kilo bp wherever that is 18:34:19 bknudson may be right. how do we know some one didnt find a crazy use for it? 18:34:20 dolphm, i like that 18:34:21 or merged into deprecated would be fine 18:34:32 our products use it. 18:34:46 but we can adapt to this one pretty easily 18:35:21 ok will kill this BP, with the comment that we should merge this topic into "removed-in-kilo" 18:35:26 so I agree this doesn’t need a spec, but just becasue it is a no-spec BP, shoudl not mean it is any more likely to achieve agreement….we need to allow people to object just as a full spec BP 18:35:48 henrynash, we can discuss in code review and on the BP. 18:35:49 i think pki_setup was my first keystone contribution - it seemed like a good idea at the time 18:36:12 henrynash, largely if there is a question it wont be "approved" 18:36:26 henrynash, and we can say "no agreement that this is trivial" 18:36:42 morganfainberg: yep 18:37:27 ah here is one 18:37:31 #link https://blueprints.launchpad.net/keystone/+spec/alembic 18:37:42 honestly, probably doesn't need a spec. 18:37:58 there are lots of questions around the conversion to alembic 18:37:58 it could help to have one but i think the spec will be "migrate data to alembic" 18:38:09 but i don't think a spec will answer them 18:38:15 in any meaningful way 18:38:21 I think there are a lot of devils hiding in the weeds with the migrations 18:38:22 is it only for new migrations,or is it existing ones, too? 18:38:42 this isn't a trivial bp, it is a "there isn't a lot of ways to do this, but lots of things to change? 18:38:43 " 18:38:46 what if we accect a hybrid 18:38:49 bknudson: i think ceilometer (?) did the transition successfully mid cycle using only new migrations 18:39:00 sql-a up to now, alembic assumes that SQL has been run first 18:39:03 seems like we do have to move away from sqlalchemy-migrate at some point since I think it's abandoned. 18:39:04 morganfainberg: agreed, i don't think the spec will tell anything about the code direction - so BP is good for tying it together but i'm ok with a BP only 18:39:06 dolphm, that is the general direction we would like to go is possible 18:39:26 when we get to the point that we can collapse the migrations, and drop all of the sql-a ones, we drop sql-a 18:39:44 ayoung: I like that plan. 18:39:45 ayoung: ++ 18:40:17 i'll change the topic in the meeting from "Trivial" to "No-Spec-Required" 18:40:17 should i #action that? 18:40:25 ayoung, sure! 18:41:06 we should make the decision that kilo is alembic or not before we get a migration 18:41:20 #action Current SQl migrations will stay in SQL Alchemy. New migrations will be done in Alembic. We will have a Hybrid solution for a couple of releases until we can collapse all of the SQL-Alchemy ones into Alembic. 18:41:24 bknudson: well we need the support in db_sync to run both 18:41:30 bknudson: (first) 18:41:44 bknudson: when we accept that, the rest of kilo becomes alembic 18:41:54 ++ 18:42:40 all these great details should get pushed into the blueprint or spec 18:42:48 dstanek, Agreed 18:42:51 ++ 18:43:02 ok 18:43:09 so lets move on. we have other topics to cover 18:43:18 ayoung, mind updating the spec? 18:43:20 erm bp 18:43:22 "When in doubt, spec it out." 18:43:22 maybe the spec-less BP is an urban myth? 18:43:25 Will do 18:43:31 ayoung +++ 18:43:55 #topic QA Liason 18:43:57 henrynash, nice! 18:43:58 (or maybe just a lot rarer than we thought) 18:43:59 #link https://wiki.openstack.org/wiki/CrossProjectLiaisons#QA 18:44:08 we need someone to take the role on. 18:44:12 (please) 18:44:24 this is the same as oslo and VMT liasons 18:44:25 henrynash: there is always something to argue about 18:44:28 just for QA 18:44:42 morganfainberg: as in tempest like stuff? 18:44:48 dstanek, yep 18:44:51 so, same things as oslo liason? 18:44:53 dstanek, and the gate etc. 18:44:59 morganfainberg: i'll do that 18:45:03 everyt time the gate breaks you know they're going to blame keystone! 18:45:04 I'll be backup 18:45:04 unless someone else wants to 18:45:13 dstanek,awesome please add yourself tot he wiki 18:45:37 #action dstanek QA Liason, lbragstad backup 18:45:41 #topic Keystone IRC Meeting Cancelled November 3rd and November 10th 18:45:54 we'll be at the summit and the post-summit one we likely don't have a lot to talk about 18:46:24 so next keystone meeting will be the 17th 18:46:49 before thanksgiving 18:46:52 Nov 10th is a monday ? 18:46:53 plus lots of people will either still be in France or jet lagged 18:47:02 sorry 11th 18:47:06 marekd, , good catch 18:47:22 #topic Keystone IRC Meeting Cancelled November 3rd and November 11th 18:47:28 and the next meeting is actually tyhe 18th 18:47:29 works for me. 18:47:42 err…can’t be the 3rd then either 18:47:59 #undo 18:48:00 Removing item from minutes: 18:48:05 4th & 11th cancelled 18:48:18 #topic next keystone meeting is 18th. (yes i can't do date math--morganfainberg) 18:48:27 ok 18:48:33 #topic Scoping federated tokens with 'token' identity method 18:48:37 marekd, o/ 18:48:40 o/ 18:48:48 so that should be quick 18:49:21 doesn't it work now? 18:49:43 we spoke with jamielennox last week about it, and it turns out that there is a relatively simple way to unify scoping federated classic tokens. No need to add extra method name 'saml2' or 'mapped'. 18:49:49 just wanted to hear your opinions 18:49:55 it's is now: https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-federation-ext.md#request-a-scoped-os-federation-token-post-authtokens 18:50:21 and looks like we could use 'token' which would simplyfy few things, let us remove some code from keystoneclient 18:50:41 y, it's the same as getting a token from a token 18:50:52 what has to change, though? 18:51:02 bknudson, keystoneclient code/ 18:51:03 ? 18:51:10 no, keystonecode 18:51:12 if the payloads are the same, then yes 18:51:13 keystone code 18:51:18 auth payloads I mean 18:51:19 do you change the info sent in on the restful APIs? 18:51:19 gyee: payload are not the same 18:51:21 Um...that is not why we were doing that in the past 18:51:22 bknudson: ++ that's kind of the point, i don't know why it was ever a different auth method anyway, it should have always just been token 18:51:31 we need to differencitate if that a federated or 'classic' token 18:51:32 the "method" is what the client sets...like "kerberos" 18:51:39 as you recall, I didn't even want that... 18:51:41 if the auth payloads are not the same, then we need different identifications 18:51:49 can we just drop the methods all together? 18:51:58 ayoung: not really 18:52:02 https://review.openstack.org/#/c/130593/1/keystone/auth/plugins/token.py 18:52:07 didn't think so, but worth asking 18:52:07 i made a super quick fix 18:52:34 oh that is kindof slick marekd 18:52:58 meta programing without metaprogramming. 18:53:13 morganfainberg: i don't say it's the best way - we could do some upper object TokenBase that would call either Mapped or Token classes 18:53:18 * morganfainberg wonders how that can break things 18:53:26 that's kindda chaotic though, have to parse the payload in order to figure what it is 18:53:28 probably should do that. 18:53:35 if we're parsing payload 18:53:44 but this is somewhere where this 'switch' needs to be done, as we must enter Token.authenticate() method 18:53:52 we're actually doubling the validate in this case 18:54:03 we need something unambiguous 18:54:03 so method name should indicate what was used to request the token 18:54:20 it would make the client side a whole lot easier - there is no reason that an unscoped federation token should be any different from a regular unscoped token 18:54:26 but, I'd be ok with the method being added to the token after the fact, and not be part of the token request 18:54:33 IN fact, I'd prefer iot 18:54:36 it 18:54:37 jamielennox: ++ 18:54:37 my only concern here is we're doubling the validate call (very expensive) 18:54:49 (6 mins) 18:55:22 we can talk about this a little further in -keystone, but i think tokens should be tokens 18:55:30 not "federated tokens are special" 18:55:30 unscoped token is unscoped token, there shouldn't be any differece 18:55:36 The issue I have is that I need different AUTH_URLS for Kerberos etc 18:55:39 morganfainberg: it's a pure wip as i didn't know if its worth working on that 18:55:48 morganfainberg: but looks like validation doesn't need to be done twice. 18:55:57 ok 18:56:00 need to move on 18:56:01 anyway, is it worth working on that? no -2 objections? 18:56:09 method and scope are two different thing 18:56:10 no objections from me :) 18:56:12 marekd, lets talk next week 18:56:17 #topic Hierarchical Multitenancy API spec 18:56:17 ayoung: sure 18:56:20 rodrigods, o/ 18:56:23 we might be able to go even further 18:56:23 o/ 18:56:26 does it break anything if someone was already using this? 18:56:27 (sorry you only have a couple mins) 18:56:28 o/ 18:56:30 ayoung: yes yesyes! 18:56:32 ok 18:56:35 quick one: please please review https://review.openstack.org/#/c/130103/ , it's a dependency from https://review.openstack.org/#/c/117786/ (once we had a plan that everything would be merged by the summit or just after it) 18:56:41 that's it =) 18:56:49 ++ 18:57:12 please aim to get them reviewed merged as close to summit/post summit as possible 18:57:25