18:03:53 #startmeeting Keystone 18:03:54 Meeting started Tue Nov 3 18:03:53 2015 UTC and is due to finish in 60 minutes. The chair is dstanek. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:03:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:58 The meeting name has been set to 'keystone' 18:04:22 dolphm: yt? 18:05:01 thingee doesn't appear to be here either 18:05:23 it looks like that was our only meeting agenda item 18:05:36 i can see if he is in the office 18:05:49 anyone have anything else that needs to be discussed? 18:06:41 I can't think of anything. 18:07:04 dstanek: seems like henrynash is not around, but his email about reseller hasn't been replied yet 18:07:19 htruta: who does he need a reply from? 18:07:34 dstanek: good question 18:07:41 lbragstad you need t explain that ... to me :-) 18:07:43 damn time change 18:07:45 ok, dolphm is on his way 18:08:04 #topic Assert standard deprecation 18:08:14 #link http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html 18:08:18 dolphm: all you! 18:08:35 I put this on the agenda for everyone who couldn't attend the cross project session at the summit on deprecation policies 18:08:49 ++ Thanks 18:09:33 there was a lot of discussion about how to approach deprecating APIs, how to approach removing them, and how to handle all of this in the context of immature and mature projects 18:09:54 keystone is very much in the "mature" camp, so we have to be super conservative 18:10:23 dolphm +++ Definitely 18:11:06 and i'm happy to report that i think we've demonstrated pretty good leadership within the broader community on this already, but we're not one of the projects that has made the assertion to follow this document 18:11:45 dolphm: ++ nice 18:11:56 so, i'm hoping everyone will take a few minutes today to read through this, and if we're all on the same page, we can voluntold stevemar to add keystone as one of these projects 18:12:29 what's the verdict on v2.0? 18:12:45 we had action items from the summit for v2.0 18:12:56 v2 has been essentially deprecated "Code will be frozen and only receive minimal maintenance" for a few releases now 18:13:14 #action stevemar to add Keystone to the list of project that follow the standard deprecation process 18:13:23 but we can't mark it as deprecated yet 18:13:40 * dstanek likes to assign tasks to those that are not here :-) 18:13:53 we don't meet the criteria 18:14:03 "uses an automated test to verify that configuration files are forward-compatible from release to release " 18:14:19 introducing v3 only jobs to projects, make the v3 job voting, moving the last few bits that don't work on v3 18:14:33 dolphm: i thought we had to essentially keep v2 around forever 18:14:51 we can deprecate it even if we never remove it 18:14:59 bknudson: sounds like there are addition work items to weed out of there 18:15:03 make v2.0 middleware that translates to and from v3 18:15:45 we are keeping the public facing v2.0 APIs and deprecate the rest, if I remember correctly 18:16:12 that still the plan? 18:16:14 are we going to allow adding new features to the v2.0 APIs? 18:16:17 we narrowed it down to about four calls that we will never be able to remove 18:16:34 etherpad from the summit #link https://etherpad.openstack.org/p/keystone-mitaka-summit-deprecations 18:16:36 bknudson: i would love to say no 18:16:40 we could add support for domains to v2 auth 18:17:04 gyee: that's my idea for a long term plan, yes 18:17:42 bknudson: the reason why we didn't do that is to not break v2 validation responses that would otherwise be domain-unaware and thus result in namespace conflicts 18:17:49 bknudson: so, no, we can't 18:18:19 dolphm, that's good, so as long as the doc didn't say we have to deprecate the entire set 18:18:41 gyee: the ideal is that you deprecate nothing, and you're committed to every API forever 18:19:29 the reason to deprecate the v2 api is that we'd like to remove it so that we don't have to support the code 18:19:41 as long as you have users, you support the API, end of story. i think keystone can eventually get operators off of v2.0 administrator crud, but it'll be a much longer process to get users off v2 auth, if ever 18:20:07 bknudson: removal will not happen quickly. certainly not in 2 cycles. 18:20:34 the code is made more complicated and we'll likely have security bugs due to having to keep it around 18:20:47 agree 18:20:55 that's the cost of publishing an API in the first place 18:20:56 dolphm, so removal wont happen quickly but hopefully its stable and does not require much maintneance... and no enhancements 18:21:35 n 18:21:42 there is also the discussion of making v2 just use the v3 API under the hood 18:21:46 bknudson how many security bugs normally come in? 18:21:46 topol: ++ 18:22:12 topol: I don't think we've seen any due to v2 support yet. 18:22:22 i can't think of any, either 18:22:31 pki? :) 18:22:51 gyee never mention that again :-) 18:22:52 v2 already has a security problem where the tokens are in the request path 18:22:54 the original v2 security bug was "tokens in URLs may be logged" 18:23:04 so v3 doesn't put bearer tokens in URLs 18:23:06 o/ 18:23:17 "security issues can't be fixed due to backward compatibility requirements. see v3 API" 18:23:35 so do we wait until everyone is off to deprecate v2 crud or deprecate it to get people to stop using it? 18:23:37 dstanek ++ 18:24:03 what's the point of deprecating? 18:24:16 topol, my bad, I was shouting a random word :) 18:24:28 bknudson: to discourage any remaining use and say that v3 is ready for everyone to use 18:24:34 bknudson a nudge as opposed to a push 18:25:03 bknudson: I've heard from operators that when they do upgrades, they look for scary warnings that mention deprecation... so they can make plans for finishing upgrades. 18:25:07 dolphm +++ 18:25:24 i still come across people within the openstack community asking the question "should i use v3 yet?" 18:25:30 ok, let's deprecate v2 crud 18:25:35 dolphm, ++ 18:25:50 and we can also deprecate v2 public since we want operators to be scared and switch. 18:26:08 bknudson: disagree 18:26:13 bknudson: on the public auth calls 18:26:33 bknudson: the v2 token validation API should be deprecated though (but that's on the admin side, not :5000) 18:27:35 v2 auth usage is not remotely close to zero yet, not even within openstack/ - we have to achieve that first 18:28:51 yeah we can't deprecate v2 auth yet 18:28:53 sounds like we need a spec to layout the deprecation strategy 18:29:21 dstanek: that'd be reasonable in this case 18:29:40 #action dolphm to document keystone's approach to v2 deprecation in a spec 18:29:40 for each logical component v2 crud, v2 auth, etc. just what the strategy will be and maybe some high level timelines 18:30:08 if we write down the criteria for deprecating a feature we can use it when doing reviews 18:30:49 dstanek, spec would help 18:31:36 i have another topic that came up just now... 18:31:45 #topic stop editing the paste.ini? 18:31:49 #link https://review.openstack.org/#/c/185464/ 18:32:23 i've seen this ask a couple of times and haven't really heard the general opinion of the group 18:32:41 stop editing? 18:33:07 maybe this means we shouldn't require editing paste.ini to disable admin token 18:33:11 dolphm: right now you need to change it when you install keystone - that review attempts to start fixing that 18:33:23 bknudson: yes 18:33:28 I agree that the default for admin token (if not specified) should be that admin token is disabled 18:33:35 didn't we agree to provide the bootstrapping capability via keystone-manage and remove admin token? 18:33:52 so that patch can go away 18:33:53 we've taken our setting outs and blocked reviews like the OSProfiler one that wants to add setting to out paste.ini 18:34:24 gyee: i've heard we want to do that, but i don't know that we've committed to it 18:34:29 we have a cors review now that wants to add cors middleware to paste.ini 18:34:33 paste should be how we enable disable V2, but beyond that, no 18:34:54 althougjh...wanted a way to enable a specific auth mechansim for a pipeline 18:35:10 dstanek, I thought we all agree on that going forward, though I don't remember on who's plate 18:35:42 yeah, killing admin token should not require editing paste, except for backports 18:35:44 it's on my list of things to do to look into keystone-manage but it's low priority 18:35:47 i forget which session, but we had a short list of "remaining" things that required the admin token to bootstrap, so we could possibly just remove it as a thing altogether 18:35:49 gyee: maybe that's the problem then. 18:36:22 dolphm: oh, nice. i didn't remember seeing a list like that 18:36:32 https://review.openstack.org/#/c/185464/ looks like it's essentially abandoned since no updates for a couple months 18:36:52 so maybe this just needs a spec to enumerate the things we still have to fix before removing auth token 18:37:08 tempest I think 18:37:28 tempest uses admin token? 18:37:37 I'm not in love with the current state of paste but don't have the time to rewrite it ATM. 18:38:43 bknudson, I thought someone mentioned it at the session, but I'll need to double check 18:38:47 dolphm: is the bottom of this what you where talking about? 18:38:49 https://etherpad.openstack.org/p/keystone-mitaka-summit-deprecations 18:39:00 dstanek: no 18:40:55 #action dstanek to sort out the remaining things that depend on auth_token 18:41:16 ok, switching topics... 18:41:28 #topic Office Hours 18:41:58 dstanek: *admin_token 18:42:31 just wanted to let everyone know that i'll only be available for a bit this Friday to help with bugs and not at all on the 13th due to a vacation 18:42:33 I don't think we're getting rid of auth_token any time soon 18:42:38 although gyee might have a plan for that 18:42:38 dolphm: doh, thx 18:42:52 dstanek Enjoy your vacation 18:43:19 does anyone have anything to discuss or do y'all want your time back? 18:43:42 I'll be here on friday. 18:44:15 bknudson, dstanek volunteer for the auth_token investigation 18:44:30 feel free to add yourselves to the list 18:44:32 #link https://etherpad.openstack.org/p/keystone-office-hours 18:44:49 gyee: no, no, no... misspeak! misspeak! 18:44:56 hah 18:45:52 we did really good the last office hours day, but i'm hoping we can still do better 18:46:09 ++ 18:46:12 only other topics...going once 18:46:35 I second ending the meeting early 18:46:39 #endmeeting