17:58:24 <stevemar> #startmeeting keystone
17:58:25 <openstack> Meeting started Tue Nov  8 17:58:24 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:58:26 <rodrigods> hello
17:58:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:58:28 <stevemar> lbragstad: yeah
17:58:29 <openstack> The meeting name has been set to 'keystone'
17:58:36 <knikolla> o/
17:59:01 <edtubill> o/
17:59:10 <breton> to early!
17:59:13 <lbragstad> stevemar we did that through a roll call over the course of a couple meetings the last time we pruned the list didn't we?
17:59:13 <stevemar> lbragstad: i'll trim the list soon
17:59:17 <breton> it's :59
17:59:23 <stevemar> breton: :O :O
17:59:48 <stevemar> breton: i wanted to give a few extra minutes to the people who will inevitably be caught by daylight savings time change
18:00:06 <breton> ok, we're good to go, it's :00 now
18:00:13 <bknudson> hi
18:00:14 <crinkle> o/
18:00:16 <browne> o/
18:00:17 <gagehugo> dst is rough
18:00:28 <srwilkers> o/
18:00:28 <stevemar> lbragstad: i'll look at the logs, anyone who hasn't said anything in the last 4 meetings will be cut
18:00:45 <jgrassler> Hello
18:01:08 <stevemar> alright, let's get the show on the road
18:01:13 <samueldmq> hi all
18:01:15 <stevemar> #topic announcements
18:01:17 <henrynash_> (hi)
18:01:26 <stevemar> New keystone/horizon meeting
18:01:32 <dstanek> o/
18:02:05 <samueldmq> stevemar: weekly meeting ?
18:02:08 <stevemar> theres a new meeting that'll take place (it's on tuesdays just after this one or an hour after)
18:02:17 <samueldmq> nice
18:02:21 <stevemar> samueldmq: today is the kick starter
18:02:25 <stevemar> we'll see how it goes
18:02:39 * samueldmq nods
18:02:43 <knikolla> great!
18:02:51 <stevemar> but basically we want to form a squad to take down these long standing keystone/horizon integration issues
18:03:00 <stevemar> if you're interested, let me know
18:03:01 <lbragstad> stevemar is that one proposed to the openstack meeting tracker?
18:03:08 <stevemar> lbragstad: probably
18:03:11 <lbragstad> so that people can grab the .ics file?
18:03:11 <stevemar> lbragstad: link?
18:03:15 <lbragstad> stevemar looking
18:03:26 <stevemar> what will be discussed is here: https://etherpad.openstack.org/p/ocata-keystone-horizon
18:03:33 <ayoung> nice
18:03:47 <rodrigods> nice effort
18:04:18 <stevemar> it'll be nice to either a) get patches up for the issues, or b) create an undertstanding between the teams on things that can't be fixed
18:04:28 <stevemar> the whole thing is in the spirit of more cross team communication
18:04:44 <ayoung> that is a good time for the meeting
18:05:09 <dstanek> I think that's a real good idea. Is the first one right after this?
18:05:17 <edtubill> nice, so there's a keystone/horizon meeting today at 19:00 UTC?
18:05:23 <david-lyle> stevemar, just noticing that's at the same time as the TC meeting, thinking may need to move the meeting time
18:05:51 <stevemar> david-lyle: i can live with it, meh
18:06:04 <stevemar> david-lyle: but we can bring that up at the kick off
18:06:11 <david-lyle> stevemar, fair enough
18:06:29 <stevemar> dstanek: sounds like the first one is in an hour after keystone ends
18:06:35 <breton> where will it be?
18:06:45 <stevemar> keep an eye on the #openstack-meeting-cp channel
18:06:48 <stevemar> breton: ^
18:06:53 <breton> ok
18:06:53 <lbragstad> we should propose it here - https://github.com/openstack-infra/irc-meetings
18:07:16 <stevemar> if you're interested, add your name to the keystone meeting etherpad, i'll make sure you get pinged
18:07:48 <stevemar> so far it's just rderose :)
18:08:15 <rderose> I like to be firs6t
18:08:17 <rderose> *first
18:08:18 <samueldmq> stevemar: nice. that will also help us in UX aspects
18:08:25 <stevemar> samueldmq: yep
18:08:33 <ayoung> ok, hold Horizon issues until that meeting.
18:08:46 <stevemar> second announcement is #What we agreed to do for Ocata-ish
18:09:07 <stevemar> i tried to recap all the items from the various work sessions
18:09:09 <stevemar> #link https://docs.google.com/document/d/1dCJyP2bfXIWoQK_wWALU83EF3G-2fJSMaFgNGCJsIhs/edit?usp=sharing
18:09:31 <stevemar> please comment on it, i'm trying to figure out a way to best represent and track the items
18:10:24 <stevemar> i can see folks are already commenting on it :)
18:10:45 <stevemar> i'm done announcements
18:10:53 <stevemar> we can switch gears to spec reviews
18:11:12 <stevemar> oh i guess on more announcement
18:11:20 <stevemar> i added the keystone specific dates to https://releases.openstack.org/ocata/schedule.html
18:11:36 <stevemar> the first one is "Keystone Spec Proposal Deadline" -- next week
18:11:59 <stevemar> the dates were decided at the summit
18:12:20 <stevemar> so if you want to propose a spec, get it up soon!
18:12:22 <jgrassler> Regarding the Google doc: Cannot edit, vimperator conflicting with Google docs... :-/
18:12:34 <breton> jgrassler: press insert
18:12:51 <breton> jgrassler: or shift-escape
18:13:15 <stevemar> jgrassler: breton you guys are too leet for me, i just use chrome
18:13:23 <jgrassler> breton: Ah, the latter did the trick. Thanks :-)
18:13:23 <dstanek> jgrassler: turn it off for that site
18:13:26 <gagehugo> that looks interesting
18:13:36 <ayoung> anyone have anything to propose that is not on the list yet?
18:13:47 <jgrassler> breton: I'll have to try that for the Horizon console, too, one of these days
18:13:54 <stevemar> dstanek: did you want to propose the pysaml middleware for ocata?
18:14:17 <knikolla> i will cough up a spec that details the overall plans for the devstack plugin and how it ties with integration/functional tests
18:14:38 <stevemar> knikolla: cool
18:15:02 <dstanek> stevemar: unless there is a tangible reason not to finish, I'm going to finish anyway. better that it's tracked
18:16:23 <stevemar> dstanek: eh? i'm asking for a spec for it. do you already have a patch proposed?
18:16:53 <stevemar> dstanek: did you name it something funny like "nteresting idea" or "do not review me"
18:17:45 * stevemar pokes dstanek
18:17:56 <dstanek> stevemar: mostly written but not submitted. I wanted to hear if it was talked about at summit and what the response was...
18:18:02 <lbragstad> stevemar i found an open time slot and a room for the cross project horizon/keystone meeting https://review.openstack.org/#/c/395106/
18:18:36 <stevemar> dstanek: oh, it was talked about, and the ops in the room think it'll be nice to not have to restart apache
18:19:10 <dstanek> stevemar: then I shall button up my draft and submit
18:19:31 <stevemar> \o/
18:19:48 <stevemar> lbragstad: thanks!
18:20:08 <stevemar> alright
18:20:11 <stevemar> #topic spec discussion
18:20:17 <stevemar> this should take up the bulk of the meeting
18:20:44 <stevemar> PCI-DSS Reason in Notifications
18:20:49 <stevemar> https://review.openstack.org/#/c/381302/
18:20:51 <stevemar> #link https://review.openstack.org/#/c/381302/
18:20:53 <gagehugo> yes
18:21:05 <stevemar> it's got 2x +2s
18:21:19 <stevemar> anyone against it?
18:21:41 <stevemar> has anyone not been given enough time to review it...?
18:21:58 <ayoung> push it on ahead
18:22:05 <rodrigods> looks good to me
18:22:10 <rodrigods> and makes total sense
18:22:24 <ayoung> I'll +2...one sec
18:22:24 <bknudson> do we have versioning of notifications?
18:22:27 <stevemar> yeah, the notification ones are rarely contentious
18:22:31 <stevemar> bknudson: no
18:23:17 <stevemar> do we have 2 people that have the bandwidth to review it?
18:23:29 <stevemar> i can probably do it, but need one other person
18:23:34 <ayoung> which one?
18:23:54 <ayoung> just +2A https://review.openstack.org/#/c/381302/
18:23:55 <knikolla> ayoung +2/+A-ed
18:24:18 <ayoung> Next
18:24:37 <stevemar> ayoung: i'm assuming you will help me review it then :) thanks for volunteering :)
18:24:55 <stevemar> next
18:24:58 <stevemar> PCI-DSS Expired Password Users
18:25:04 <stevemar> #link https://review.openstack.org/#/c/383832
18:25:12 <stevemar> this one is a bit weird
18:25:17 <gagehugo> yeah
18:25:35 <stevemar> i keep mixing the terms enabled/disabled and expired
18:25:41 <gagehugo> yeah it is confusing
18:25:54 <stevemar> but expired users can still be enabled and should be allowed to reset their password
18:26:14 <bknudson> user has a new attribute?
18:26:30 <gagehugo> password_expires_at
18:26:45 <stevemar> what this spec does it allow an admin to get a list of users who have expired passwords
18:26:50 <bknudson> although unlikely, somebody could be using that already
18:27:48 <stevemar> the other funny funny about this is the query string
18:28:04 <gagehugo> the ewwwwww comment?
18:28:04 <stevemar> "password_expires_at=gt:2016-10-14T15:30:22Z"
18:28:09 <stevemar> :)
18:28:21 <stevemar> gagehugo: its better now!
18:28:36 <gagehugo> yes, much better
18:28:37 <bknudson> it's not clear if every user now has a new attribute.
18:28:37 <rderose> yeah, that would be weird
18:28:49 <rderose> most likely on greater than, less than
18:29:06 <gagehugo> bknudson: that spec doesnt add a new attribute
18:29:12 <gagehugo> if that's what you mean
18:29:25 <rderose> bknudson: every user now already has the password_expires_at attribute
18:29:25 <bknudson> it says that when you list users you get back a new attribute
18:29:32 <bknudson> ok
18:29:51 <bknudson> I thought we already supported querying by attribute values
18:30:03 <rderose> bknudson: me too
18:30:16 <rderose> bknudson: I think it is only partially implemented
18:30:19 <stevemar> bknudson: it'll be a little different since it's a timestamp
18:31:02 <lamt> I don't think it allows for inequality match
18:31:30 <knikolla> i see more value to this being a relative timestamp. like 'expires_in=1d'
18:31:42 <dstanek> no, the gt,inequality,etc needs to be done
18:31:52 <rderose> dstanek: ++
18:32:15 <ayoung> We don't need a generla puproe comparator language
18:32:29 <ayoung> make it part of the URL:   all_after  etc
18:32:31 <bknudson> I thought we already had a general purpose comparator language
18:32:34 <dstanek> api-wg defined one
18:32:34 <stevemar> sounds like no one is really against it. do we have people who are willing to review the code ?
18:32:43 <ayoung> password_expires_after
18:33:04 <knikolla> ayoung: ++
18:33:36 <stevemar> i think the use case is "i want to list all users that are expired as of now"
18:33:38 <dstanek> I will review
18:33:50 <stevemar> dstanek: thanks, anyone else?
18:34:00 <knikolla> stevemar: for that case is it not enough a expired=True?
18:34:06 <bknudson> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/driver_hints.py#n85
18:34:09 <rderose> stevemar: I've already reviewed it
18:34:22 <gagehugo> no because a user can be expired but their enabled field does not change
18:34:26 <stevemar> rderose: i mean, someone who is willing to review the implementation :)
18:34:29 * rodrigods can review
18:34:36 <stevemar> good enough for me
18:34:39 <dstanek> knikolla: nope. I need to notify users that expire in 7 days
18:34:45 <rderose> ah
18:35:06 <lbragstad> bknudson you want to use hints to get that information?
18:35:19 <bknudson> lbragstad: isn't that what it's for?
18:35:31 <stevemar> approved it
18:35:33 <dstanek> knikolla: just like your employer probably does for your corporate account
18:35:52 <stevemar> the implementation detail can change while we review the impl.
18:36:03 <gagehugo> yeah we can fine tune it
18:36:07 <lbragstad> bknudson yeah - we'd have to enrich the hints functionality though - it has bugs
18:36:16 <stevemar> gagehugo: do you mind if we review https://review.openstack.org/#/c/345113/ before the project/props one?
18:36:21 <bknudson> that sounds like a useful thing to do anyways
18:36:29 <gagehugo> stevemar: yeah go for it
18:36:34 <stevemar> Next spec is https://review.openstack.org/#/c/345113/
18:36:51 <stevemar> good ol MFA
18:37:14 <dstanek> it's a good idea
18:37:21 <stevemar> i like it
18:37:34 <stevemar> and adriant already has the impl. up
18:37:51 <stevemar> it just didn't make the cut off last cycle, but i think it's good to go
18:38:12 <stevemar> there are limitations (won't be enforced in v2 only deployments), but i'm still OK with it
18:38:38 <stevemar> there will be some issues with the client side work too, but we'll need to work that out separately
18:39:19 <dstanek> stevemar: I thought client side was a non-issue
18:39:41 <lbragstad> i thought i remember that, too
18:39:55 <lbragstad> wasn't the client just going to concatenate the code and password together?
18:40:03 <stevemar> dstanek: the issue there was that the user would need to get a new token every time and keep retyping their passcode
18:40:10 <dstanek> you just combine the code and password
18:40:21 <stevemar> since passcodes are only good for a few seconds
18:40:26 <knikolla> but code expires, and user will have to resource the rc file
18:40:29 <dstanek> Ah, I see
18:40:44 <stevemar> we need to do a better job of caching tokens and getting new ones on the client side
18:40:48 <bknudson> user could get an oauth token or something
18:40:51 <lbragstad> ah - so this is a different usability issue
18:40:57 <dstanek> looks like we need client side token caching
18:41:03 <knikolla> yeah
18:41:15 <bknudson> you can cache the token but it's going to expire
18:41:15 <stevemar> dstanek: which has been an osc issue for a while
18:41:19 <lbragstad> ++ that would be good overall
18:41:53 <stevemar> given that limitation, i think we're still OK for approving it on the server side
18:41:55 <dstanek> stevemar: I wanna discuss that offline with you... If I can remember
18:42:08 <stevemar> dstanek: sure, pull in jamielennox too
18:42:26 <dstanek> sure
18:42:50 <stevemar> dstanek: lbragstad bknudson i'll let you guys approve it if you agree to review the impl.
18:43:28 <dstanek> already been!
18:43:29 <ayoung> stevemar, better job caching tokens where?
18:43:39 <knikolla> client side
18:43:43 <stevemar> ayoung: on the client side
18:43:45 <knikolla> openstackclient doesn't cache tokens
18:43:46 <ayoung> I'm gonna mess that up
18:44:00 <dstanek> ayoung: ?
18:44:15 <ayoung> if we merge role validation into the token validation, caching is not going to be worth much
18:44:27 <ayoung> same token, different call, will have to be reauthenticated
18:44:42 <stevemar> that definitely messes things up
18:44:48 <dstanek> client will still be able to use the same token more than once right?
18:44:57 <lbragstad> dstanek maybe, maybe not
18:45:04 <lbragstad> depends on the call the user is making
18:45:09 <bknudson> it was just getting the token that required the code
18:45:40 <lbragstad> a token might be valid for one call and invalid for another depending on the operation
18:45:40 <ayoung> heh
18:45:46 <ayoung> glad I could derail this
18:45:56 <stevemar> yeah lets put the train back on the tracks
18:46:00 <dstanek> so we wouldn't support OS_TOKEN anymore?
18:46:02 <stevemar> comment on the spec if need be
18:46:05 <ayoung> so..yeah, its going to wreak total havoc with caching
18:46:28 <stevemar> ayoung: the fallout from your spec is independent of this new one
18:46:36 <ayoung> heh
18:46:45 <stevemar> it'll break caching everywhere
18:46:58 <stevemar> so reviewers: do not treat the two as related...
18:47:01 <lbragstad> we probably need to set aside time to talk about that one again
18:47:07 <dstanek> ayoung: which spec is that?
18:47:15 <bknudson> ayoung: I think it'll depend on if the server returns a 401 or 403 error
18:47:16 <ayoung> but if you are talking about having the client reuse tokens, that is different, and yes, we should do that
18:47:25 <bknudson> not having role should return 403
18:47:37 <knikolla> https://review.openstack.org/#/c/391624/
18:47:40 <bknudson> invalid token should return 401
18:47:40 <lbragstad> #link https://review.openstack.org/#/c/391624/
18:47:42 <stevemar> dstanek: https://review.openstack.org/#/c/391624/
18:47:59 <dstanek> :) thx all
18:48:02 <stevemar> ayoung: you added everyone to that review
18:48:22 <ayoung> stever, well, not EVERYONE, but yeah
18:48:30 <dstanek> if OS_TOKEN stops work than my personal automation will stop working :-(
18:48:54 <stevemar> dstanek: a lot of automation would stop working
18:49:02 <bknudson> dstanek loves the admin token
18:49:12 <stevemar> bknudson: different than admin token
18:49:13 <dstanek> yeah, but i'm mostly worried about mine
18:49:30 <ayoung> OS_TOKEN should and will die
18:49:34 <ayoung> die die die die
18:50:13 <stevemar> 10 minutes left, lets jump to the last spec
18:50:18 <stevemar> Projects and properties!
18:50:28 <ayoung> Mazes and Monsters!
18:50:31 <stevemar> #link https://review.openstack.org/#/c/388886/
18:50:41 <stevemar> i posted this to the mailing list
18:50:43 <stevemar> Mailing List Discussion: http://lists.openstack.org/pipermail/openstack-dev/2016-November/106806.html
18:50:47 <ayoung> Yeah, this is a bad idea
18:50:52 <gagehugo> There was good discussion on the mailing list
18:51:07 <bknudson> the response on the mailing list was that we hate quotas
18:51:14 <lbragstad> i thought we got some good feedback from other developers
18:51:37 <ayoung> Youthought HMT was hard to solve...
18:51:49 <ayoung> anyone care to summarizethe feedback?
18:52:03 <stevemar> ayoung: ops are for it
18:52:18 <stevemar> nova folks are saying to watch out for a few things
18:52:29 <stevemar> make sure you use a strict set of valid keys
18:52:38 <bknudson> there's an extra metadata call for projects?
18:52:44 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/106822.html
18:52:56 <stevemar> jaypipes said to use tags
18:53:08 <dstanek> i'm definitely not a fan of this yet
18:53:23 <bknudson> horizon already has panels for editing metadata
18:53:37 <stevemar> bknudson: keystone metadata?
18:53:47 <stevemar> well.. extras?
18:53:49 <bknudson> no, volume and instance
18:53:57 <ayoung> here is one way to think of it
18:53:57 <gagehugo> s/metadata/properties
18:54:05 <stevemar> so should be copy/paste for keystone projects :D
18:54:06 <ayoung> from a Keystone perspective, no service is special
18:54:08 <bknudson> I don't know what it has for projects
18:54:16 <ayoung> Nova is no more special than Neutron
18:54:26 <ayoung> and that goes out into the things floating around the big tent
18:54:32 <ayoung> and off into the sunset
18:54:58 <stevemar> dstanek: why are you against it?
18:55:06 <ayoung> we are not making a clearing house of project specific information, because if the project can't figure out how to deal with the type of info, ofbbing it off on Keystone will not solve the problem
18:55:15 <ayoung> it will exacerbate it
18:55:29 <ayoung> if we need a sound approach to quotas, solve quotas
18:55:45 <ayoung> don't solve it in a project specific manner, but make sure the solution works for cinder and neutron
18:55:53 <breton> lets not talk quota yet
18:55:53 <dstanek> stevemar: well, i think it's an interesting usecase, but in implementing it we open a can of worms
18:55:57 <gagehugo> project properties is not for quotas
18:56:02 <stevemar> breton: ++ this isn't for quotas
18:56:02 <ayoung> breton, this is all about quotas
18:56:10 <ayoung> it is the same damn thing
18:56:18 <breton> ayoung: no it isn't, and it is different :)
18:56:24 <ayoung> quota is a specific instnace of a type of data specific to nova, neutron
18:56:26 <dstanek> for instance, i commented on the spec that it was broken because it allowed people with the ability to create projects to edit the metadata
18:56:27 <lbragstad> this sounds like extras v2
18:56:34 <stevemar> ayoung: read adriant's use case: http://lists.openstack.org/pipermail/openstack-dev/2016-November/106839.html
18:56:38 <ayoung> and the billing info tags etc
18:56:40 <gagehugo> lbragstad: yes, more or less
18:56:51 <dstanek> that makes sense unless you real the usecase which is really wanting only the cloud admin to edit
18:57:10 <gagehugo> which is what we want
18:57:18 <dstanek> so does this mean we are opening ourselves to have multple levels or metadata controlled by permissions?
18:57:40 <lbragstad> so - i know everyone here pretty much hates the idea of extras and we've been trying to get rid of it for a while... if we move forward with properties we need to make sure we don't reimplement the things we hate about extras
18:57:41 <stevemar> we already have to support "extras", may as well make a decent API for it
18:57:50 <ayoung> we have not even solved basic RBAC.  We can't do what they want.
18:57:58 <dstanek> lbragstad: it is formalizing extras in a way, but their usecase limits who should have the ability to modify the metadata
18:58:05 <dstanek> (at least some of the metadata)
18:58:24 <ayoung> stevemar, we make NO guarnatees about that data.  AAnd if people realized just how easy it was for that data to be something other than what they want it to be, they will freak
18:58:30 <dstanek> stevemar: this isn't an api for metadata.
18:59:01 <stevemar> dstanek: eh?
18:59:02 <dstanek> the original spec made it seem that way, but i was not aligned with the usecase
18:59:27 <lamt> metadata might be an overloaded term - it is more storing properties (or tags) and associate it with keystone entities
18:59:41 <lamt> right now the user table's stores emails in the extra column
18:59:56 <stevemar> i dunno, i can't believe we're arguing over what seems like a basic use case
19:00:11 <stevemar> times up
19:00:13 <stevemar> #endmeeting