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