18:02:53 <dstanek> #startmeeting keystone
18:02:53 <openstack> Meeting started Tue Aug 18 18:02: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:02:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:55 <samueldmq> henrynash, tr�s bien :)
18:02:58 <openstack> The meeting name has been set to 'keystone'
18:03:00 <dstanek> not a ton today!
18:03:06 <dstanek> #topic Agenda
18:03:13 <dstanek> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:03:21 <dstanek> lbragstad: you in here?
18:03:23 * stevemar will probably be a bit quiet while he finishes up lunch
18:03:28 <lbragstad> dstanek: yep
18:03:35 <ayoung> oyez
18:03:38 <dstanek> #topic Voting on SPFE for IdP Specific WebSSO
18:03:38 <dstanek> #link https://review.openstack.org/#/c/199339/2 is the spec
18:03:40 <henrynash> type and chew, type and chew
18:03:45 <dstanek> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/071131.html is the mailing list discussion
18:03:52 <dstanek> lbragstad: go fer it
18:03:57 <lbragstad> is jamielennox here?
18:04:01 <jamielennox> ya
18:04:16 <lbragstad> cool, just wanted to get an idea for how people felt about this as an SPFE?
18:04:32 <lbragstad> I think what jamielennox has is a good solution for the public cloud cases
18:04:35 <stevemar> +1 on it being a spfe
18:04:47 <lbragstad> (which have been brought up and highlighted on the mailing list)
18:04:52 <ayoung> the current is too limiting...need what jamielennox is proposing for any sane deployment
18:05:05 <dstanek> lbragstad: want to give the 10 second overview?
18:05:15 <lbragstad> basically,
18:05:17 <henrynash> (and how much code are we talkin’ here)
18:05:38 <lbragstad> we would be adding a call to keystone federation that would allow us to get federated authentication based on the IdP id
18:05:44 <lbragstad> and the protocol
18:06:04 <lbragstad> like this call; https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/routers.py#L80-L81
18:06:08 <lbragstad> but specific for an IdP
18:06:45 <dstanek> henrynash: when we were talking about it last week it didn't seem like a lot
18:07:05 <henrynash> dstanek: that would be my guess
18:07:05 <stevemar> henrynash: very little new code
18:07:17 <lbragstad> so, it would kinda look like http://goo.gl/80yyjF
18:07:21 <stevemar> it should just be the new route, thats about it
18:07:33 <dstanek> questions, comments or concerns? or just vote?
18:07:42 <lbragstad> where step 3 would be the new stuff being added in the SPFE
18:08:24 <lbragstad> so, this part - /v3/OS-FEDERATION/identity_providers/{idp_id}/protocol/{protocol_id}/websso/
18:08:26 <topol> o/
18:09:20 <jamielennox> so i consider this a blocker for doing some of chadwick's horizon based discovery, or properly running a lot of different protocols on the same websso page, the concern is obviously how close we are to feature freeze
18:09:48 <ayoung> I think it is fine...won't break anyone
18:09:52 <jamielennox> but i expect if we get the go ahead there can be code up in the next day or two and it should be a relatively easy revie
18:09:54 <jamielennox> w
18:09:55 <ayoung> existing code will run fine
18:10:07 <dstanek> if we are really talking about a route and a few controller lines is there much risk or regressions elsewhere?
18:10:18 <lbragstad> I'm stepping up to sponsor this, so i'll have eyes on reviews as soon as they are posted
18:10:19 <jamielennox> it's more of a refactoring of existing code than anything new
18:10:30 <dstanek> who will be coding it?
18:11:01 <lbragstad> I can help out with the coding, but I'd feel comfortable if jamielennox reviewed it
18:11:02 <stevemar> spec says jamie or lance :)
18:11:11 <jamielennox> lbragstad and I will manage between us
18:11:16 <lbragstad> jamielennox: ++
18:11:36 <dstanek> ok, then we can hold both of your feet to the fire
18:11:55 <dstanek> #startvote Approve SPFE for IdP Specific WebSSO? yes,no,dont_care
18:11:56 <openstack> Begin voting on: Approve SPFE for IdP Specific WebSSO? Valid vote options are yes, no, dont_care.
18:11:57 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:12:02 <henrynash> so I minded to support this….my concren is whether manyof our cores are off coding real late in the cycle and not available for reviews…and we have some big stuff yet to get in  (e.g. reseller)
18:12:04 <stevemar> #vote yes
18:12:07 <lbragstad> #vote yes
18:12:22 <ayoung> #vote yes
18:12:27 <rodrigods> #vote yes
18:12:35 <stevemar> henrynash: reasonable thing to be worried about
18:12:37 <bknudson> #vote yes
18:12:48 <raildo> #vote yes
18:13:00 <bknudson> why do we even have a spec freeze?
18:13:15 <stevemar> bknudson: process for the sake of proces
18:13:15 <morgan_2549> #vote dont_care
18:13:17 <jamielennox> bknudson: at least it makes things difficult at this point
18:13:29 <henrynash> #vote no (even though I love the feature…we need cores doing reviews)
18:13:30 <openstack> henrynash: no (even though I love the feature…we need cores doing reviews) is not a valid option. Valid options are yes, no, dont_care.
18:13:40 <henrynash> #vote no
18:13:59 <dstanek> #vote i'll let the cards fall where they fall
18:14:00 <openstack> dstanek: i'll let the cards fall where they fall is not a valid option. Valid options are yes, no, dont_care.
18:14:03 <bknudson> I agree with henrynash but if cores don't want to do reviews they're not going to do them.
18:14:13 <ayoung> henrynash, this is a small one code wise, but big feature for end users
18:14:26 <dstanek> bknudson, henrynash: yeah, we definitely need more reviews
18:14:29 <breton> #vote yes
18:14:36 <dstanek> vote closing in 5..
18:14:40 <jamielennox> #vote yes
18:14:41 <henrynash> ayoung: I’m sure that’s true….but....
18:14:43 <bknudson> 5 hours?
18:14:45 <jamielennox> and i was thinking about it..
18:14:47 <ayoung> it allows a singe IdP to support multipe protocols for Federation
18:14:51 <lbragstad> bknudson: long running votes
18:14:56 <dstanek> #endvote
18:14:56 <openstack> Voted on "Approve SPFE for IdP Specific WebSSO?" Results are
18:14:57 <openstack> yes (8): rodrigods, lbragstad, ayoung, bknudson, jamielennox, raildo, breton, stevemar
18:14:58 <openstack> dont_care (1): morgan_2549
18:14:59 <henrynash> ayoung: I love the fetaure, don’t get me wrounf
18:14:59 <openstack> no (1): henrynash
18:15:07 <dstanek> bknudson: nope, done ... need to move on!
18:15:19 <lbragstad> thanks all
18:15:20 <dstanek> roxanaghe_: you here?
18:15:28 <roxanaghe_> dstanek, yes
18:15:31 <ayoung> henrynash, we need to push right up until Milestone 3.  There is not enough time to get work done in the release the way we have things tstrucutured nw
18:15:45 <dstanek> #action lbragstad and/or jamielennox to code up the IdP specific WebSSO flow
18:15:54 <dstanek> #topic Change default endpoint type for Keystone v3 to 'public'
18:16:06 <dstanek> #link https://review.openstack.org/#/c/185200/ is the review
18:16:12 <dstanek> roxanaghe_: you're up
18:16:14 <jamielennox> i would suggest we revist next week where we want to have things more or less merged
18:16:24 <roxanaghe_> ok, so this review has been sitting there for a while
18:16:27 <roxanaghe_> we need a decision
18:16:29 <dstanek> jamielennox: ++
18:16:45 <roxanaghe_> it's about changing default endpoint type for v3 keystone to public
18:16:48 <samueldmq> jamielennox, ++ for all the big subjects we are planning to get this cycle
18:17:06 <roxanaghe_> all other services have public by default
18:17:31 <roxanaghe_> but there are concerns about breaking stuff if we just change it like that
18:17:42 <breton> ++ for that
18:17:48 <breton> *for the switch
18:17:57 <jamielennox> i'm pretty sure this is changed using sessions
18:18:12 <jamielennox> looking for the code to back me up there
18:19:01 <ayoung> what does that mean "default" anyway?
18:19:06 <Haneef__> All the services use public_endpoint from catalog except keystone.
18:19:12 <jamielennox> https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/auth/identity/base.py#L313
18:20:03 <jamielennox> so to my understanding this was the compromise to having fixed this in the past
18:20:21 <jamielennox> that if you use the Client(session) format without specifying an interface you would get public
18:20:32 <tim_o> asselin?
18:20:47 <jamielennox> (because i completely agree the admin default is wrong)
18:21:08 <dstanek> jamielennox: does that mean we don't need the proposed change or that it's likely to break less than we think?
18:21:19 <roxanaghe_> jamielennox, from what I saw the default is in httpclient and is the same for v2 and v3: admin
18:21:20 <bknudson> for v2 if you use the public interface then a lot of calls aren't going to work.
18:22:00 <jamielennox> dstanek: given that the admin and public interface for v3 is the same it's probably not going to break as much as i would think
18:22:17 <jamielennox> roxanaghe_: if you use session then it should do it's best to skip httpclient
18:22:20 <Haneef__> We want to make this change only for keystone v3, as v2 is bit differnet. In v2 only subset of apis are exposed at public endpoint. That is the reason why defaulted to admin
18:23:00 <bknudson> so maybe applications can already opt-in to the behavior by using sessions.
18:23:31 <bknudson> and it's deprecated to not use a session
18:23:33 <jamielennox> oh, blah https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/httpclient.py#L237
18:23:47 <roxanaghe_> jamielennox, ok, I'm not sure if the current code goes that code flow
18:24:22 <roxanaghe_> jamielennox - yes, that's the line
18:24:54 <jamielennox> ok, so v3 default is going to end up as admin
18:24:59 <jamielennox> umm
18:25:16 <roxanaghe_> so since no value is passed at that point it will get the default admin
18:25:59 <roxanaghe_> so are there any concerns if we switch?
18:26:05 <ayoung> lets just drop v2, and then admin,public is ireelevant
18:26:10 <jamielennox> ok, i think we can change that
18:26:24 <jamielennox> it's a behaviour change but i would be very surprised if anyone is relying upon it
18:26:28 <bknudson> I'm concerned that it will break somebody.
18:26:34 <dstanek> what about bknudson's worry about breaking existing applications?
18:26:35 <jamielennox> given admin/public is the same thing
18:26:59 <jamielennox> the other option is we are planning a client v2 start of next cycle
18:28:10 <roxanaghe_> sinve admin and public go through the same endpoint is it possible to break anyone?
18:28:16 <roxanaghe_> *since
18:28:50 <jamielennox> roxanaghe_: it goes through the same code but most people will configure admin and public to use different urls, admin is often not routable by the public
18:28:54 <ayoung> break it
18:29:24 <jamielennox> i'm ok to break it
18:29:38 <ayoung> vote?
18:29:47 <dstanek> sure...
18:30:04 <roxanaghe_> jamielenox ok, so if only admin is configured - we have now in openstack cli a new option to specify the interface - that could help
18:30:27 <dstanek> #startvote Do we want to change from admin -> public and possibly break some applications? yes,no,dont_care
18:30:27 <openstack> Begin voting on: Do we want to change from admin -> public and possibly break some applications? Valid vote options are yes, no, dont_care.
18:30:29 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:30:48 <bknudson> #vote no
18:30:50 <jamielennox> roxanaghe_: sure, and you can override the setting now. we just try very hard to not change defaults on people so that things that did work don't stop when they update
18:30:52 <roxanaghe_> #vote yes
18:31:13 <dstanek> #vote no
18:31:23 <jamielennox> gah, torn
18:31:36 <ayoung> #vote yes
18:31:40 <bknudson> deprecate the old behavior and we can change it in 2.0
18:31:52 <dstanek> i'd rather see something like bknudson suggested in the review getting in
18:32:04 <lbragstad> dstanek: you mean the deprecation?
18:32:22 <jamielennox> #vote no
18:32:24 <henrynash> #vote no
18:32:24 <henrynash> [7:31pm]
18:32:26 <stevemar> blah
18:32:27 <henrynash> oops
18:32:36 <lbragstad> #vote no
18:32:39 <stevemar> #vote no
18:32:43 <stevemar> deprecate it, then change
18:32:46 <jamielennox> it's a good idea, but we've turned down less blatant changes for compatibility reasons
18:32:47 <samueldmq> #vote no
18:32:55 <dstanek> henrynash: sorry you are wrong....it's 14:32
18:33:14 <lbragstad> or is it 13:33?
18:33:19 <dstanek> lbragstad: nope
18:33:26 <henrynash> dstanek: timezones are all secret cunnig plan to keep us all confused
18:33:42 <jamielennox> roxanaghe_: it'll definetly be the default in a new release
18:33:46 <breton> 21:33.
18:33:50 <dstanek> voting over in 5...
18:33:51 <breton> #vote deprecate
18:33:53 <openstack> breton: deprecate is not a valid option. Valid options are yes, no, dont_care.
18:34:04 <dstanek> #endvote
18:34:04 <roxanaghe_> ok, just wanted to take a decision on it :)
18:34:06 <openstack> Voted on "Do we want to change from admin -> public and possibly break some applications?" Results are
18:34:07 <openstack> yes (2): roxanaghe_, ayoung
18:34:08 <openstack> no (7): lbragstad, bknudson, dstanek, samueldmq, jamielennox, henrynash, stevemar
18:34:43 <dstanek> are there any follow ups for this? roxanaghe_ did you want to implement the deprecation idea?
18:35:02 <roxanaghe_> dstanek, yeah I can do that
18:35:15 <bknudson> I'm not sure how you deprecate this... might just be documentation.
18:35:16 <roxanaghe_> you have some guidance on that process?
18:35:50 <dstanek> #action roxanaghe_ to look into alternatives (maybe deprecation) to "Change default endpoint type for Keystone v3 to 'public'"
18:36:07 <dstanek> roxanaghe_: sure, in -keystone later you can find some help
18:36:14 <dstanek> #topic Must tokens always have a user domain ID?
18:36:16 <roxanaghe_> dstanek, ok cool
18:36:22 <dstanek> lots of links here and i'm not sure how bknudson wants to drive this discussion
18:36:24 <roxanaghe_> thanks!
18:36:29 <dstanek> ok bknudson
18:36:42 <bknudson> the question is do tokens always have a user domain ID
18:37:11 <bknudson> they always have a user ID , that's required by the code that converts token to auth dict
18:37:19 <henrynash> bknduson: well, v2 ones don’t :-)
18:37:32 <ayoung> 23 minutes left
18:37:38 <bknudson> v2 ones always have the default domain ID as the domain
18:37:46 <lbragstad> fernet's DomainScopedPayloads do
18:37:58 <stevemar> federated users should always have the domain 'federated' - right?
18:38:02 <bknudson> domain scope isn't the user domain ID
18:38:15 <henrynash> bknudson: ++
18:38:30 <bknudson> as far as I can tell from the config option federated users have a domain named "federated"
18:38:39 <bknudson> but there's no ID for the federated domain
18:39:01 <bknudson> also, I think those are ephemeral users... are there actual federated users too?
18:39:08 <ayoung> always domain id
18:39:13 <ayoung> default was a porting hack
18:39:25 <ayoung> if you change the default domain, you will surprise the hell out of everytone
18:39:28 <ayoung> everyone
18:39:37 <jamielennox> ignoring v2, whta doesn't have a user domain id?
18:39:37 <ayoung> stevemar, not alwyas
18:39:39 <ayoung> always
18:39:47 <bknudson> I could add a config option for the federated ephemeral user domain.
18:39:54 <ayoung> you should be able to use just a userid, or username + some domain data.
18:39:59 <jamielennox> bknudson: isn't that a mapping thing?
18:40:02 <ayoung> either domain id or name
18:40:15 <ayoung> bknudson, no more config values for federation
18:40:32 <ayoung> lets make it so all federation stuff can be changed without restarting the server
18:41:40 <bknudson> jamielennox: I think there's a way to do mapping to either get an ephemeral user or a real one... I assume there's a way to specify the domain ... I'm no expert and haven't looked into it.
18:42:48 <jamielennox> so are we working around another fernet issue?
18:43:05 <ayoung> so...is there any realquestion here?
18:43:07 <bknudson> the issue only shows up in a fernet test
18:43:46 <jamielennox> bknudson: but that would seem to me the only place where you could end up without a user_domain_id in a token body
18:43:58 <ayoung> fernet for federated needs to record all of the information that is needed to reproduce the token
18:44:13 <ayoung> don't worry about token size, worry about accuracy.
18:44:55 <jamielennox> so i've thought this before - at this point i think fernet needs to keep a shadow user table
18:45:20 <bknudson> ok, if it's not a problem to add the user domain ID to the fernet token for federated users that's fine.
18:45:32 <ayoung> jamielennox, can it use the id mapping table?
18:45:34 <bknudson> I'm not sure where the domain ID is going to come from
18:45:37 <jamielennox> you get the win of still not storing tokens, but it might just need to record users that login via federation
18:46:12 <ayoung> ++
18:46:16 <dstanek> lbragstad: dolphm: thoughts? ^
18:46:40 <lbragstad> I thought marekd_404 had a review up for adding the username to the fernet payload?
18:46:46 <dstanek> jamielennox: won't that still be a table that grows forever?
18:46:49 <ayoung> jamielennox, alternative is to make the fernet body larger and record the info there
18:47:03 <jamielennox> the table can still be cleaned after a certain period of time since last login, but it'd be max a couple of million rows with unique ids
18:47:23 * dstanek see that there is only about 13 minutes left and bknudson has one more topic
18:47:23 <jamielennox> ayoung: the thing i really like about fernet is not growing the table
18:47:30 <jamielennox> s/table/token
18:47:47 <jamielennox> i'll write something up
18:47:52 <ayoung> jamielennox, it is either/or...
18:47:52 <bknudson> lbragstad: this one? https://review.openstack.org/#/c/202176/ -- I linked to it
18:47:54 <jamielennox> for now i think user_domain_id should be in everything
18:48:02 <lbragstad> bknudson: yep, looking at that now
18:48:14 <bknudson> that doesn't have the user domain ID either.
18:48:44 <jamielennox> however as far as i know most of the time when using federated login (web sites etc) you generally create an entry in a user table somewhere that you can link to later
18:48:45 <lbragstad> bknudson: maybe the domain ID is something that we can build into the federated info?
18:48:52 <jamielennox> it would also solve the groups issue
18:49:23 <bknudson> lbragstad: sure. I'm not sure if ephemeral users actually have a domain ID at this point either.
18:49:40 <bknudson> there's a config option for the name but none for the ID
18:49:52 <lbragstad> right now it consists of groups_ids, idp_id, and protocol_id
18:49:52 <lbragstad> https://github.com/openstack/keystone/blob/master/keystone/token/providers/fernet/core.py#L123
18:49:58 <lbragstad> #link https://github.com/openstack/keystone/blob/master/keystone/token/providers/fernet/core.py#L123
18:50:09 <bknudson> I don't know how it's supposed to work but if users are actually supposed to always have a domain ID then that will require some changes.
18:50:31 <lbragstad> yeah, how would we handle that for UUID?
18:50:33 <bknudson> we can move on if we're agreed on that
18:50:43 <dstanek> it sounds like this is an offline (out of meeting) conversation that needs to happen
18:50:48 <bknudson> lbragstad: I'd add a config option with a random uuid.
18:51:06 <dstanek> moving on....
18:51:14 <dstanek> #topic keystoneclient keystoneauth_integration feature branch still broken bknudson
18:51:15 <dstanek> #link https://review.openstack.org/#/c/213573/ proposed review
18:51:21 <dstanek> bknudson again!
18:51:30 <stevemar> dstanek: its all broken
18:51:39 <henrynash> ya cn’t keep a good man down
18:51:50 <bknudson> just a notice that the keystoneauth_integration branch is falling way behind due to not being able to merge with master
18:52:08 <bknudson> the change to keystoneauth that I think is needed is merged
18:52:08 <dstanek> stevemar: way to stay positive!
18:52:18 <jamielennox> so the purpose of keystoneauth_integration has changed
18:52:23 <bknudson> but now I think we need a release of keystoneauth in order to start using it.
18:52:46 <jamielennox> it was initially to make a keystoneclient that depended on keystoneauth, however at this point it's been decided that won't happen during the ksc 1 period
18:53:12 <jamielennox> keystoneauth_integration is therefore the keystoneclient 2 branch that will depend on keystoneauth
18:53:40 <jamielennox> but if we change the branch names we need to change a bunch of rules in zuul that do things like exclude the requirement check based on the branch name
18:53:48 <bknudson> we need to keep the branch in sync with master
18:54:20 <jamielennox> the CRUD interface should remain unchanged, anything related to the session/auth will need to be synced to keystoneauth
18:54:57 <jamielennox> tests are the larger problem with cherry-picking between the two
18:55:31 <bknudson> ok, that was it... if you're wondering why keystoneauth_integration isn't up-to-date with master it's because changes were made in master that didn't get to keystoneauth
18:55:41 * lbragstad waves the 5 minute flag
18:55:50 <dstanek> is that it on that topic?
18:56:23 <jamielennox> bknudson: i go back and cherry-pick occasionaly but i don't think there have been many changes to session/auth in ksc recently
18:56:23 <dstanek> i'll take that as a *yes*
18:56:33 <jamielennox> do you have a list?
18:56:34 <dstanek> ...or not...
18:57:29 <bknudson> jamielennox: the fix that I needed I made with https://review.openstack.org/#/c/210010/
18:57:52 <bknudson> "Commit 6950527 in python-keystoneclient added role_ids and role_names properties to fixtures.v3.Token"
18:58:00 <dstanek> should we have some cleanup activity to get the branch in sync?
18:58:32 <bknudson> that commit was made to master but wasn't made to keystoneauth
18:58:53 <bknudson> so when I go to merge master to the feature branch, the tests fail since the master tests are using the properties.
18:59:18 <bknudson> but there hasn't been a release since then so the merge is still failing tests
18:59:52 * Shrews lurks
19:00:16 <dstanek> #endmeeting