18:01:25 <stevemar> #startmeeting keystone
18:01:26 <openstack> Meeting started Tue Dec  8 18:01:25 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:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:30 <openstack> The meeting name has been set to 'keystone'
18:01:43 <stevemar> thanks for coming to this week's installment of keysone-meeting :)
18:01:49 <stevemar> the agenda is here: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:01:52 <stevemar> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:02:16 <ayoung> He yo!
18:02:20 <stevemar> its rather light, i guess some folks are already in holiday mode
18:02:37 <stevemar> #topic MFA
18:02:48 <stevemar> nonameentername: did you want to chat about this one?
18:02:49 <dstanek> o/
18:02:56 <stevemar> #link https://review.openstack.org/#/c/130376/
18:03:01 <stevemar> the review is up here ^
18:03:17 <gyee> do it!
18:03:27 <lbragstad> gyee will you champion?
18:03:27 <topol> o/
18:03:38 <stevemar> i know *a lot* of folks want this in
18:03:39 <dstanek> gyee is a champion!
18:03:39 <nonameentername> Yeah, basically I want to add another authntication type 'passcode' that is based on TOTP, HOTP
18:03:41 <gyee> lbragstad, you mean like writing code?
18:03:55 <lbragstad> gyee i think champion is dedicating review time
18:04:02 <lbragstad> gyee owner is the one writing the code
18:04:04 <stevemar> lbragstad: correct
18:04:09 <gyee> lbragstad, sure, I am quite familiar with that one
18:04:14 <bknudson> what if the owner gets too busy?
18:04:21 <lbragstad> gyee awesome
18:04:22 <nonameentername> and require users to specify both password and passcode for some domains and projects.
18:04:37 <stevemar> bknudson: then someone else can pick up the work or we can see it in N
18:04:50 <lbragstad> nonameentername how far along are you?
18:04:54 <lbragstad> on the implementation?
18:04:58 <lbragstad> if at all..
18:05:37 <stevemar> nonameentername: so the things i'm looking for in the spec... where are the API changes? what's the impact to non SQL users (ldap/federated/trust/etc)
18:05:38 <nonameentername> I already have a poc that has TOTP working for authenticate, but it's missing the database part that stores backend
18:05:42 <gyee> so as long as we do the time hash only
18:05:47 <gyee> managing sequence is not fun
18:06:10 <bknudson> do we need to change the current auth plugin framework we have in keystone?
18:06:17 <gyee> no
18:06:19 <nonameentername> stevemar: I can add api changes to the spec
18:06:21 <gyee> just another plugin
18:06:55 <nonameentername> it, will need an apy to enable / disable mfa for user, domain and project
18:07:01 <nonameentername> *api
18:07:19 <nonameentername> and also to setup mfa for a specific user
18:07:19 <bknudson> it's unfortunate that we have to implement this in keystone. we already have federation so can't the idps do this?
18:07:31 <gyee> nonameentername, you want to go that far?
18:07:42 <gyee> so far we don't tied auth mechanism with users
18:07:48 <stevemar> bknudson: so yeah, if i have google as my IDP, then i get MFA for free
18:07:59 <jamielennox> bknudson: ++
18:08:19 <bknudson> I guess it depends on how easy it is. Maybe it's only a few lines of code. In which case go ahead.
18:08:24 <lbragstad> but that's only for federation, right?
18:08:29 <stevemar> lbragstad: correct
18:08:34 <bknudson> is there a python library for google auth?
18:08:43 <nonameentername> What if a user wants to setup mfa for his own account without using federation?
18:08:47 <stevemar> this would be useful for sql accounts and possibly.... ldap?
18:09:09 <stevemar> nonameentername: right, theres definitely a use case for sql users
18:09:17 <jamielennox> nonameentername: i think it's more a case of if a provider wants to make those sort of requirements then it should be done via federation
18:09:22 <bknudson> I wish we'd get rid of sql users.
18:09:37 <jamielennox> because this sounds to me like enhancing the SQL user store - which i thought we weren't doing
18:09:59 <lbragstad> we also have the shadow user stuff coming
18:10:16 <lbragstad> doesn't that enhance the sql user store?
18:10:24 <stevemar> lbragstad: not really
18:10:28 <jamielennox> lbragstad: that's more tracking than being source of truth
18:10:35 <stevemar> lbragstad: the biggest gain is for federated users
18:11:17 <bknudson> for sql users we've to the extras column so I don't care if we're expecting new fields.
18:11:23 <lhcheng> I think one reason the MFA needs to be in keystone is we want to setup MFA for certain projects/domain only. Can we do that in federation?
18:11:38 <stevemar> "certain projects/domains"
18:11:41 <rderose> mfa can be used with LDAP, correct; not only sql users
18:11:43 <stevemar> can you expand on that?
18:11:56 <stevemar> rderose: thanks for confirming
18:12:09 <lhcheng> stevemar: the use case would be..
18:12:11 <stevemar> i thought it was likely to work with ldap
18:12:25 <bknudson> since this doesn't actually require any changes to keystone I'm fine with it going ahead.
18:12:39 <lhcheng> I want to setup a global keystone to access my data center, and within the data center there would be different security zone.
18:12:39 <bknudson> let's see the code
18:12:42 <nonameentername> In a public cloud I setup a project and want users to use the project, but I only want them to use it when they have MFA enabled.
18:12:52 <gyee> bknudson, it does, it depends how far we want to go
18:13:28 <stevemar> bknudson: how would it not have changes to keystone?
18:13:36 <lhcheng> for server running in higher security zone, I want higher security. The idea is have a project that can have access to higher security zone, and add MFA to those projects.
18:13:37 <bknudson> it's just a new plugin
18:13:41 <gyee> if we have to associate domain/project and user with auth mechanisms, this require framework changes
18:13:45 <lbragstad> most of the implementation lives in the authentication plugin
18:13:48 <bknudson> so you're not changing any existing code, only adding new
18:13:58 <stevemar> thats the hope :)
18:14:28 <jamielennox> would we expect this to affect federtaed users?
18:14:38 <jamielennox> or want it to?
18:14:44 <bknudson> maybe we can make the security zone thing explicit and work with any auth
18:14:54 <stevemar> nonameentername: update the spec to be explicit about what user's this will work for (I think just SQL and LDAP), and write out any new APIs as well.
18:15:05 <bknudson> maybe give the user a role if they auth with some method and you can use that in policy?
18:15:17 <jamielennox> stevemar: well with shadow users table you'll pretty much get it anyway
18:15:17 <nonameentername> stevemar: ok, I can do that
18:15:20 <lbragstad> so, no federated support for mfa initially (i'm not sure that seems right anyway?)
18:15:37 <bknudson> federation already gives you mfa today
18:15:45 <stevemar> nonameentername: i believe lhcheng and lbragstad are going to "champion" this spec
18:15:51 <bknudson> if you're using federation you don't need this
18:15:56 <topol> bknudson how so?
18:15:57 <stevemar> bknudson: right-o!
18:15:59 <lbragstad> right, so i'm not sure it makes sense to have federation in the scope of this sepc
18:16:00 <gyee> federation is orthogonal to MFA
18:16:01 <lbragstad> spec*
18:16:04 <davechen> bknudson: how? +1
18:16:10 <stevemar> topol: the idp will have it for free
18:16:15 <bknudson> set up your identity provider to do mfa
18:16:32 <stevemar> topol: like how google tells me to enter the code it sends to my phone
18:16:32 <topol> bknudson, k just checking. thought you would say that
18:16:41 <topol> stevemar +++
18:16:50 <stevemar> nonameentername: you've got 2 TODOs and 2 champions
18:16:58 <stevemar> update the spec and we'll approve
18:17:02 <gyee> just to be clear, this one is not about entering codes send to the phone
18:17:03 <nonameentername> stevemar: thanks
18:17:08 <gyee> this is strictly for time hash
18:17:10 <stevemar> gyee: yes yes
18:17:21 <lbragstad> so TOTP specific?
18:17:24 <bknudson> so federation is even better
18:17:28 <nonameentername> gyee: this is not for sms, only totp, and hotp
18:17:33 <stevemar> bknudson: it's always better
18:17:43 <gyee> nonameetername, no sequence hash please
18:17:45 <jamielennox> where's ayoung, i expect he's going to have some opinions on how this is done
18:17:47 <gyee> that's very hard to manage
18:17:56 <gyee> syncing sequence number is not easy to implement
18:17:56 <stevemar> gyee: yes, it was just an example :)
18:17:57 <lbragstad> gyee did you try this already ?
18:17:58 <jamielennox> and doing it in/out of keystone
18:18:00 <bknudson> I thought keystone supported auth with multiple roundtrips?
18:18:17 <nonameentername> gyee: ok, I can implement only totp and ignore hotp
18:18:20 <gyee> lbragstad, we have some inhouse POCs awhile back
18:18:25 <ayoung> Nah, I never have opinions
18:18:27 <lbragstad> gyee gotcha,
18:18:27 <jamielennox> bknudson: we could make it work, but not explicitly i think
18:18:44 <henrynash> ayoung: bland, quiet….
18:18:48 <jamielennox> ayoung: you hadn't said anything for a while - typically i take that to mean you're not around :)
18:19:05 <stevemar> calling this topic finito
18:19:14 <henrynash> ole
18:19:19 <stevemar> #topic Domain Specific Roles
18:19:28 <stevemar> #link https://review.openstack.org/#/c/254139/
18:19:38 <ayoung> jamielennox, was still catching up...my kneejerk reaction is "can we do this with federation"
18:19:41 <stevemar> henrynash gyee ayoung -- figure this mess out
18:19:45 <henrynash> oh, didn;t know this was on here!
18:19:45 <gyee> I am struggling mightily with that one right now
18:20:00 <ayoung> we tried OTP with SAML and basically had it working
18:20:04 <henrynash> gyee: so see my comments to the link steve just posted
18:20:19 <ayoung> try to keep crypto stuff out of Python if possible.
18:20:45 <henrynash> (just for background to all): Since gyee had argued for using a role-group concept for Domain Specific Roles, I posted a review (just for discussion) on how that would look: https://review.openstack.org/#/c/254139/
18:20:50 <jamielennox> ayoung: mine to, was mentioned
18:20:57 <ayoung> but...still need more details to make a firm recommendation
18:21:18 <gyee> henrynash, we can more or less can accomplish role groups with user groups
18:21:43 <gyee> so role groups doesn't buy much
18:22:05 <gyee> user groups are essentially  perm templates
18:22:11 <stevemar> domain specific roles are roles that a domain administrator can create/delete/assign, right?
18:22:18 <henrynash> gyee: so *some* companies might, but others haev strict user groups defined in LDAP etc..  and don’t necessarily lend themslevs to this
18:22:21 <gyee> only difference is that role groups have no targets
18:22:24 <lbragstad> stevemar that's what I was thinking
18:22:24 <topol> stevemar I hope so
18:22:25 <henrynash> stevemar: yes
18:22:47 <lbragstad> so these roles only mean anything within that domain, how does that tie in with policy?
18:23:06 <gyee> stevemar, yes, but we can't prevent the creator from mapping them to some global roles
18:23:09 <samueldmq> lbragstad: yes, they don't go into the policies, only globalroles go
18:23:10 <ayoung> gyee, so...we could split groups out of the identity backend
18:23:21 <henrynash> and I think gyee, the nub of your concern is that it will be confusing in the case of DSRs based on implied roles,….that the DSR iteself doesn;t go in the token
18:23:33 <stevemar> lbragstad: cause you don't want the domain admin to be able to create/delete/assign roles globally
18:23:47 <samueldmq> lbragstad: they're expanded into global role when issueing  tokens
18:23:53 <lbragstad> so domain roles won't be applied to other services?
18:23:53 <henrynash> so see my comment and scenario I posted on https://review.openstack.org/#/c/254139/ - I really don;t see the confusion youare concerend about
18:24:00 <ayoung> that might make sense anyway.  It means that a user could get their identity from one domain, and their groups from a second
18:24:07 <gyee> henrynash, right, that was my original concern
18:24:36 <henrynash> lbragstad: DSRs are mapped into global roles…which is what go esin the token
18:24:43 <samueldmq> lbragstad: no, other services only need to know about global roles
18:24:49 <samueldmq> henrynash: ++
18:24:51 <lbragstad> samueldmq ok, so you have super granular global roles
18:24:55 <ayoung> gyee, so, I was thinking we do the "URL safe" approach.  If you go URL safe, then you can do
18:25:04 <david8hu> Domain admin can only delete/create/mod users, roles in his/her domain?
18:25:11 <ayoung> domain/IBM/admin versuse domain/HP/admin vs domain/redhat/admin
18:25:11 <lbragstad> and the domain roles are combinations of really granular global roles
18:25:13 <henrynash> david8hu yes
18:25:19 <samueldmq> lbragstad: yes and you can group them as you want, with custom names for your domain ,etc
18:25:21 <henrynash> lbragstad: ++
18:25:33 <ayoung> but...not sure if having them in the token would ever be used to enforce policy
18:25:42 <lbragstad> samueldmq henrynash gotcha, interesting
18:25:47 <gyee> ayoung, we can, but its useless till we can update the enforcement part
18:26:13 <ayoung> gyee, while we could enforce on that now, I just don't know when that would be required
18:26:22 <gyee> right now role is unidimentional, not multidimentional
18:26:26 <jamielennox> ayoung: they'd go in the token?
18:26:28 <ayoung> I mean, yeah, you would have to edit policy by hand
18:26:41 <ayoung> jamielennox, this is IF they go in the token, what would they look like
18:26:42 <henrynash> remember (not wishing to be forward or nothin’) but we did vote on DSRs using implies roles alst week and got 7 For and 6 or 7 abstains, and none against
18:26:50 <gyee> if we agree that role is multidimentional, then we have some flexibility there
18:27:13 <ayoung> jamielennox, I can't see a reason to put them into the token
18:27:16 <jamielennox> ayoung: yea, not in token
18:27:36 <david8hu> henrynash, if I create custom role within the domain I administers, are you going to have policy per domain?
18:27:38 <lbragstad> the token will still only have the global roles
18:27:46 <samueldmq> gyee: what does that mean ? roles being unidimentional vs multidimentional ?
18:28:07 <gyee> samueldmq, it means instead of just a name, it is a set of attributes
18:28:22 <gyee> role.name, role.domain_id, role.type, etc
18:28:27 <henrynash> david8hu: so you cannot cahneg the policy file as a domain admin…but the idea is that if yoru cloud provider has created a nice fine-grained policy file, you can use DSRs to better model what those mean to your users
18:28:45 <ayoung> I kindof agree that what henrynash is working for here is due to the groups concept being taken, but really what we want.  This is an internal mapping step, from individual user to role assignment
18:28:46 <samueldmq> gyee: so you basically want to expand the role entity, rather than creating a new first citizen in keystone ,
18:29:25 <ayoung> I really don't want a new concept.  EIther go with DSRs, or rework groups
18:30:17 <henrynash> samuedlmq, gyee: and of course that’s what the current DSR is….a special tyoe of role (that has a domain_id set)
18:30:52 <gyee> henrynash, not really, we don't enforce it on the policy side
18:31:02 <gyee> since they don't return in token response
18:31:23 <henrynash> gyee: and absolutely don’t want them to…this is a pro onot a con
18:31:34 <samueldmq> gyee: that'd cause headaches, we'd need to keep list of implied roles synced with endpoints ,etc
18:31:39 <ayoung> groups might be a little strange.  When the assertion comes in, you would have REMOPTE_USER and REMOTE_GROUPS set. You'd make REMOTE_GROUPS to groups in the users own domain...or in any other domain...and the REMOTE_USER to group mapping would be either from the Federation mapping, or an explicit Federated user to group mapping from... where?
18:31:58 <henrynash> gyee: I have to ask you again to read what I posted in the review….I really do not see the confusion of DSRs not goiong in the token
18:32:24 <ayoung> So, I kindof like DSRs as the abstraction, because they are Keystone specific data, not identity.
18:33:05 <gyee> henrynash, if your support person comes to you and ask why don't they get that role as it was seemingly assigned, what do you do?
18:33:18 <ayoung> I'd like to point out that this is why David CHadwick origianlly wanted the mapping to go from the assertion all the way to the roles, and to skip the group concept.
18:33:45 <ayoung> gyee, that was why I was asking about diagnostic APIS.  I think we would want that
18:34:01 <henrynash> gyee: so you have to think through teh scenario….the domain admin and project admin will know what the roels are
18:34:17 <gyee> and figure out which DSRs to assign in order to get some specific role
18:34:20 <ayoung> #link https://openstack.nimeyo.com/66396/openstack-dev-keystone-diagnostic-apis-for-keystone
18:34:36 <henrynash> (sorry to past this, but I already write this out):
18:34:36 <henrynash> 1) A public cloud provider wants to attract as many, diverse customers as possible
18:34:37 <henrynash> 2) To do that, they are likely to offer a flexible, fine-grained set of roles that are encoded in policy rules
18:34:38 <henrynash> 3) As part of the on-boarding of a customer (represented as a domain), they will give the domain admin the spec of what roles they must assign their used to give the permission to execute various APIs. These are set by the cloud provider, the domain admin has no control over this.
18:34:39 <henrynash> 4) Without DSRs the domain admin will either use this list or explain this list to their project admins for project within their domain. They'll work out (and probably circulate internally) how the set of roles defined by the cloud provider shod map onto what every usage model they have
18:34:40 <henrynash> 5) With DSRs, they'll encode that model in DSRs and use those (or tell their project admins to use those). So they'll be fully aware of what roles are cloud provider roles and which are DSRs.
18:34:52 <henrynash> …hence I don’t see the confusion
18:35:19 <samueldmq> gyee: DSRs should have very suggestive names (as they can be customized), so not too hard to realize that ?
18:36:34 <gyee> samueldmq, its the working backward part, from token response
18:36:36 <ayoung> henrynash, I think that any of us that spend time on the issue will come up with a similiar solution.  The real issue is what do we call them, and how do we implement without retolling the entire UI.
18:37:12 <ayoung> If we assume Federation as the starting point (ID in SQL or LDAP is simpler) then there are several layers of indirection
18:37:32 <ayoung> Assertion->identiyt (users, groups)->role assignments.  DSR adds an additional layer
18:37:45 <ayoung> Assertion->identiyt (users, groups)->DSRs->globalrole assignments.
18:37:58 <henrynash> ayoung: agreed
18:38:08 <stevemar> it would be an entry in the shadow table, preferably
18:38:19 <ayoung> So, I stand firm on not wanting to add a new abstraction (rokle groups) but am flexible on which of the layers we modify
18:38:29 <ayoung> stevemar, not quite
18:38:49 <ayoung> it would be keyed by the shadow talbes User iD, but these are additional layers of assignment
18:38:53 <stevemar> gyee: your issue with the current API is that policy will be hard to write?
18:39:24 <gyee> stevemar, DSRs still constraint by global roles
18:39:37 <gyee> so if you make your policies and global fine grained that's fine
18:39:43 <gyee> global roles
18:39:50 <gyee> like one to one
18:39:58 <lbragstad> i think gyee's problem is that it's hard to tell what your DSR is from the token response
18:40:02 <gyee> one global role per API or something
18:40:05 <henrynash> For me, although I origionally propes role-groups 18 months ago and fought against implied roles for a while, amd convinced that our current (merged) DSR approach is the one we should do for.
18:40:42 <samueldmq> DSR (and implied roles) is about easing the way you assign global roles
18:40:43 <gyee> but I can't restrict domain-admin from seeing all the global roles
18:40:44 <henrynash> gyee: in the end, that’s probably where it goes, but with some “cloud wide” grouping encoded in the policy file by teh cloud provdier
18:40:57 <samueldmq> if you, as a deployer, don't think it does, just don't use it ?
18:42:02 <stevemar> gyee: OK
18:42:07 <henrynash> gyee: that’s a different problem
18:42:13 <ayoung> I think we are going to want a diagnostic API no matter what solution we come to here
18:42:13 <gyee> samueldmq, so what kind of role can someone assign?
18:42:38 <stevemar> gyee: the current suggested API is just a new attribute to the roles API, it's pretty minimal, we can get away with have that option be experimental for 1 release
18:42:42 <samueldmq> gyee: one (who is allowed to assign roles) can assign either global roles or DSR (from his domain) to someone else
18:42:43 <gyee> if someone have permission to assign roles, what kind of roles can they assign?
18:42:45 <henrynash> gyee: I’m not trying to solve role hiding here
18:42:54 <stevemar> we can see how it works out and if it sucks, we can go to another design
18:43:29 <gyee> stevemar, sure, make it experimental then
18:43:32 <stevemar> gyee: the proposed spec is minimally invasive, let's try it out first
18:43:37 <ayoung> ++
18:43:46 <david8hu> Can domain admin assign the "admin" role to himself?
18:43:48 <henrynash> aren’t all major new featiures experiemental
18:43:49 <stevemar> gyee: yep, we can add that to the documented APIs
18:43:51 <gyee> stevemar, I am not worry about the implementation part, its all code
18:44:00 <gyee> its the APIs that I am loosing sleep over
18:44:07 <gyee> implement can be changed anytime
18:44:11 <gyee> implementation
18:44:39 <stevemar> gyee: right, but let's try it out first, if we dont like the API, we can rework it a bit since it's experimental
18:44:46 <stevemar> just like we did with service providers
18:45:03 <ayoung> david8hu, in order to solve what you are implying, we need the unified delegation spec
18:45:13 <stevemar> gyee: we cool?
18:45:22 <bknudson> yea, we coo'
18:45:30 <gyee> stevemar, sure, as our role assignment is pretty messy as is right now :)
18:45:32 <ayoung> david8hu, unified delegation says "a user can only assign(delegate) roles that they themself have"
18:45:41 <stevemar> alright :)
18:45:46 <topol> cool
18:45:51 <stevemar> ayoung: gonna give davechen some time
18:46:04 <stevemar> #topic need to support delete/get V3 endpoints via V2 API
18:46:05 <henrynash> absolutely agree on it being experimental - all majoe new features should be experimental to start - that’s what we agreed a while back
18:46:08 <ayoung> gyee, ponder over whether you would be happier with a modification to mapping or groups abstactions than this
18:46:15 <stevemar> davechen: you've got about 10 minutes, sorry
18:46:22 <davechen> okay,
18:46:31 <ayoung> why do we need to do anything via V2?
18:46:38 <davechen> it's fine, i am just wondering if we could support to do that.
18:46:39 <gyee> ayoung, I don't want role groups
18:46:45 <bknudson> let's not support this in v2 api
18:46:53 <davechen> support get/del endpoint via v2 api
18:47:13 <davechen> but it's currently possible to list v3 endponints
18:47:16 <davechen> by v2 api
18:47:32 <david8hu> ayoung, I have a usecase that combo of DSR and UD will solve.
18:47:35 <stevemar> how much work is it? just a few lines?
18:47:40 <davechen> so, it's looks a little werid that we cannot get or delete. etc.
18:47:50 <ayoung> davechen, I'd be more prone to say "allow V3 API modify V2 stuff" than the reverse.  No changes to V2 if we can avoid it.
18:48:04 <lbragstad> at the summit we had the opposite discussion in our deprecation session i think?
18:48:21 <bknudson> keystone v2 can be a little weird.
18:48:31 <davechen> ayoung: just keep it as is?
18:49:08 <lbragstad> we wanted to deprecate/remove everything that wasn't absolutely required v2 (like auth and validate)
18:49:13 <stevemar> davechen: if a user is adding endpoints in v3, then how likely is it that they'll list endpoints with v2?
18:49:18 <davechen> bknudson: i agree that we should no add new ability for v2 api
18:49:40 <rderose> davechen: what is the risk if we keep it as is?
18:49:43 <davechen> stevemar: i am not saying add, but get and delete
18:49:55 <ayoung> why delete?
18:49:57 <lbragstad> rderose just the inconsistency?
18:50:03 <ayoung> ignoring get for the moment
18:50:22 <stevemar> rderose: i think the risk is pretty low
18:50:24 <davechen> ayoung: just from end use's persepctive, you can see these endpoint but you can do noting about it
18:50:26 <stevemar> do we have a bug about this?
18:50:30 <davechen> is that make sense?
18:50:39 <davechen> stevemar: not yet
18:50:42 <bknudson> you can do something about it. use the v3 api and do it
18:50:45 <gyee> davechen, look, no touch OK :)
18:51:14 <davechen> gyee: don't touch it?
18:51:16 <davechen> :)
18:51:23 <dstanek> davechen: how often are people actually modifying/deleting endpoints?
18:51:40 <davechen> dstanek: not quite often, i think
18:51:43 <lbragstad> modifying and deleting v3 endpoints through the v2 api
18:51:49 <stevemar> davechen: unless someone is actually running into this error, then i say don't bother fixing
18:51:58 <davechen> dstanek: but it quite often for get
18:52:05 <dstanek> stevemar: ++
18:52:08 <ayoung> davechen, reserving admin for V3 for any lingering V2 isms is a better bet
18:52:13 <davechen> get some info for specific endpoints
18:52:23 <dstanek> devananda: get works for things with a publicURL right?
18:52:27 <ayoung> you can read old data, or new data in an old format, but you need to use the new format to change it.
18:52:30 <davechen> stevemar: gotcha
18:52:53 <stevemar> i think it's settled that this is a `won't fix` issue
18:53:01 <dstanek> stevemar: yey!
18:53:23 <stevemar> #topic champions
18:53:38 <stevemar> i wanted to share something i've been using to keep track of work
18:53:48 <stevemar> heres a google doc for anyone to comment on: https://docs.google.com/document/d/1MD1WJNasuDkDFstK6kgfZiA7SkIGKdH6n69AoVaTy1g/edit?usp=sharing
18:54:19 <stevemar> cores, add yourself as "champions" meaning you *will* review the spec
18:54:25 <stevemar> err implementation*
18:54:42 <stevemar> i'll be keeping track of links for implementation, somehow, probably a gist
18:54:54 <gyee> stevemar, you'll be adding MFA?
18:55:00 <stevemar> try not to over commit yourself
18:55:06 <henrynash> stevemar: like it
18:55:07 <stevemar> gyee: yes, it was blessed just 30 minutes ago LO
18:55:08 <samueldmq> stevemar: great idea!
18:55:10 <stevemar> :P
18:55:19 <bknudson> also, leave lots of room for reviewing bug fixes.
18:55:28 <bknudson> because we still have to do that, too
18:55:31 <stevemar> thats the goal
18:55:38 <stevemar> bknudson: on that note...
18:55:53 <stevemar> i've updated LP to reflect ALL of our deliverable for mitaka: https://launchpad.net/keystone/+milestone/mitaka-2
18:56:00 <stevemar> so far nothing is in mitaka-3
18:56:09 <stevemar> mitaka-2 ends in ~45 days
18:56:11 <henrynash> stevemar: the one thing I would add is maybe the Phase 1 of reseller (projects acting as toplevel domains)….althoug the spec was approved in a previous cycle, most of the code is up for review in M
18:56:11 <gyee> wow, the slots are filling up, fast
18:56:36 <stevemar> feel free to add more slots ... i don't mind additional champs :)
18:57:07 <lbragstad> gyee do you want to champion the mfa stuff?
18:57:08 <stevemar> so please HAVE a patch up for review BEFORE MITAKA-2 ENDS!
18:57:16 <gyee> lbragstad, yes
18:57:19 <stevemar> otherwise it'll get booted to N :)
18:57:55 <stevemar> if the patch is not yet merged, we can still land stuff in M3, even though it was targeted for M2
18:58:08 <amakarov> stevemar, ayoung  I expect unified delegation code to be finished in mitaka timeframe, and the problem is that spec is being modified in the process. Should I just do what I do now and propose everything in N release?
18:58:27 <stevemar> amakarov: that sounds like a good plan
18:58:36 <stevemar> we can slide that right into N1
18:58:48 <stevemar> i don't want to overcommit ourselves
18:58:48 <amakarov> stevemar, ok
18:58:54 <bknudson> functional testing is not on the doc
18:59:00 <bknudson> python3 support is not on the doc
18:59:04 <stevemar> bknudson: it's "ongoing" at the bottom of the doc
18:59:10 <stevemar> both are
18:59:16 <lbragstad> yep
18:59:32 <bknudson> what's ongoing?
18:59:38 <bknudson> how is that different than the other work?
18:59:40 <stevemar> bknudson: they span many releases
18:59:42 * lbragstad high fives bknudson
18:59:42 <samueldmq> stevemar: fyi: I am grabbing functional tests on keystoneclient
18:59:50 <lbragstad> tag team online migrations!
18:59:54 <bknudson> we're not planning to complete these for M?
18:59:58 <ayoung> amakarov and if there are any pre-reqs we can do in M that are non-disruptive, we can merge them when they are ready.
19:00:05 <stevemar> bknudson: ideally we should
19:00:05 <dstanek> stevemar: python3 shouldn't it should be completed in M
19:00:08 <stevemar> out of time!
19:00:10 <stevemar> #endmeeting