18:01:49 <dolphm> #startmeeting keystone 18:01:50 <openstack> Meeting started Tue Sep 2 18:01:49 2014 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:54 <openstack> The meeting name has been set to 'keystone' 18:01:55 <dolphm> #topic Feature freeze September 4th 18:01:56 <morganfainberg> oh we got oslofmt again i think for devstack + apache now. 18:02:17 <dolphm> so we're at the final countdown to feature freeze on thursday, and we're facing a 9 hour gate which is rapily growing 18:03:01 <dolphm> by my count, we have about 8 patches targeting juno-3 left to land, plus endpoint grouping 18:03:05 <dolphm> #link https://gist.github.com/dolph/651c6a1748f69637abd0 18:03:09 <topol> I assume we only are gonna worry on the hottest potatoes at this point 18:03:23 <topol> err worry about 18:03:40 <dolphm> on endpoint grouping, we approved the spec, and then it totally slipped off my radar until steve noticed the implementation floating around in gerrit last week 18:03:54 <dolphm> so, i apologize for that :( 18:04:14 <dstanek> dolphm: did you star that one? 18:04:19 <stevemar> dolphm, star it! 18:04:20 <dolphm> dstanek: i have not 18:04:26 <dstanek> topol: most of the reviews are really close 18:04:37 <stevemar> dolphm, it's been through a lot of reviews 18:04:42 <topol> dstanek+++ 18:04:52 <dolphm> bobt: morganfainberg: ^ 18:05:06 <morganfainberg> bobt, take it. 18:05:19 <bobt> Hopefully, it's good to go. Needs some further love from core. 18:05:24 <morganfainberg> :) 18:05:34 <dolphm> stevemar: how close is it to being +A'd now, by your estimation? 18:05:55 <gyee> it was loved and unloved, but I think its all love now :) 18:05:57 <stevemar> dolphm, fairly close, i haven't looked at the last few patch sets 18:06:08 <stevemar> been busy with other things :) 18:06:19 <dolphm> stevemar: we all have! 18:06:33 <dstanek> bobt: thx for adding the patch to listen to delete notifications 18:06:40 <stevemar> stress levels are high all around yay 18:06:58 <dolphm> lbragstad: you just got a pep8 fail on https://review.openstack.org/#/c/104066/ 18:08:07 <dstanek> lbragstad: ugg...sorry. i ran the tests after you pushed, but not pep8 18:08:08 <lbragstad> dolphm: respinning 18:08:14 <lbragstad> dstanek: no worries 18:09:25 <dolphm> it looks like stevemar, dstanek and gyee have been fairly active on the endpoint grouping impl, so thanks! https://review.openstack.org/#/c/111949/ 18:09:43 <gyee> dolphm, keep an eagle eye on it :) 18:10:15 <dolphm> if ya'll approve it today, i'll try to make sure it lands for j3 18:10:27 <stevemar> oh, just got an email from henry nash, he's traveling and will miss the meeting 18:10:28 <dolphm> gate woes and whatnot 18:10:33 <dolphm> stevemar: ack 18:10:49 <dolphm> jamielennox_: o/ 18:10:56 <dolphm> jamielennox_: good morning! 18:10:58 <dstanek> dolphm: i think that one looks good - just have to +2 it 18:11:30 * jamielennox_ yawns 18:11:31 <dolphm> jamielennox_: we need your follow up on https://review.openstack.org/#/c/113998/ which is sort of blocking the implementation i just approved on https://review.openstack.org/#/c/114138/ 18:11:45 <dstanek> dolphm: there is also a follow up patch to it for adding delete notifications 18:11:46 <dolphm> dstanek: good to hear! 18:12:01 <dolphm> dstanek: part of the bp? 18:12:30 <dstanek> dolphm: it's not in the commit message, but it should be https://review.openstack.org/#/c/117723/ 18:13:26 <raildo1> about hierarchical multitenancy , we are keeping our patches on this branch 18:13:28 <raildo1> #https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:feature/hierarchical-multitenancy+topic:bp/hierarchical-multitenancy,n,z 18:13:32 <raildo1> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:feature/hierarchical-multitenancy+topic:bp/hierarchical-multitenancy,n,z 18:13:42 <dolphm> raildo1: perfect, thank you! 18:14:19 <stevemar> bknudson, i have a new patch for marek's stuff coming up, mind taking a look? 18:14:21 <raildo1> dolphm: but we have a question,what is the better way to keep it updated with the master? 18:14:31 <bknudson> stevemar: just send a link 18:15:05 <raildo1> dolphm: We want to commit our code, but it shows that will commit all the other changes together. (as you can see here: http://paste.openstack.org/show/104791/) 18:15:36 <dstanek> raildo1: are you checking out your branch and committing to that? 18:16:18 <jamielennox_> dolphm: removed -1 18:16:27 <dolphm> raildo1: there's a wiki page that carefully documents the process to keep feature branches up to date 18:16:42 <dolphm> raildo1: doing it wrong causes infra terrible pain, so let's walk through that after the meeting 18:16:44 <jamielennox_> dolphm: i disagree but a day before feature freeze is not the time for me to suddenly notice something like this and hold things up 18:16:55 <raildo1> dolphm: ok 18:17:03 <raildo1> dstanek: yes 18:17:09 <ayoung> jamielennox_, of course not. That's my job. 18:17:10 <dolphm> jamielennox_: your point is certainly valid :( 18:17:16 <ayoung> Not really 18:18:13 <jamielennox_> do we expect the bulk of k2k to be ready and released for Juno? 18:18:40 <jamielennox_> if it's going to slip it's something i would like to change 18:19:00 <jamielennox_> that and the regions are suddenly a scoping concept 18:20:01 <bknudson> when I looked at it I wondered about the scope to a region. 18:20:22 <jamielennox_> bknudson: so i added this to the meeting agenda as again i only discovered it last night 18:20:40 <jamielennox_> adding a URL to a region and expecting that to double as a SP is a bad idea IMO 18:20:53 <dolphm> jamielennox_: the last few changes for k2k are much simpler than the first patch. i think we have a solid chance of seeing them all gating today 18:21:06 <jamielennox_> (these are all things that are apparently discussed at the midcycle :( ) 18:21:09 <dolphm> but: 18:21:11 <dolphm> #topic Overloading regions with federated auth urls is a bad idea 18:21:17 <stevemar> jamielennox_, i think you preferred adding os-federation/sp/{sp} rather than overloading regions 18:21:56 <jamielennox_> i'm concerned what having the URL on region and then having it available as a scope in the federated case - what does this imply for the non-federated 18:22:15 <dolphm> for a touch of background, hierarchical regions were initially proposed by jaypipes to include an auth_url -- essentially the endpoint of a remote keystone for that region 18:22:21 <jamielennox_> why should those two things be differnt 18:22:32 <dolphm> we dropped the attribute before merging since it was a little ahead of the curve 18:22:46 <jamielennox_> is that still the intention? 18:23:09 <jamielennox_> because that is a fairly major change to what we consider a region to be today 18:23:35 <dolphm> jamielennox_: well, the problem with regions has always been that everyone has a slightly different interpretation of the concept :-/ 18:24:10 <ayoung> are regions fundamental here, or are they a "we can do that too" concept? 18:24:19 * ayoung hasn't refreshed on the patch yet 18:24:52 <jamielennox_> dolphm: i don't disagree, i've always considered that a failing of ours - but do you think that us suddenly trying to define them like this will improve that situation? 18:25:03 <dolphm> stevemar: the patch already merged to both the API and for the implementation for region URLs, right? 18:25:17 <jamielennox_> as i see it now a region is just a filter, you get a service catalog and you pick one of many 18:25:18 <stevemar> dolphm, yes 18:25:28 <dolphm> jamielennox_: i'm going to turn the question around, and ask how it's might make it worse? 18:25:40 <dolphm> s/it's/it/ 18:25:57 <ayoung> https://review.openstack.org/#/q/status:merged+project:openstack/keystone,n,z 18:26:20 <dolphm> so, regions now have an optional "url" attribute in core identity api https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#regions-v3regions 18:26:22 <dolphm> as part of v3.3 18:26:25 <jamielennox_> if i have arbitrary labels on my existing endpoints, i get a k2k token - why should i suddenly have my endpoints restrictd 18:26:39 <jamielennox_> s/labels/regions - but they are the same thing 18:27:09 <jamielennox_> in this case why should me having a federated token change the experience to me having a regular token 18:27:41 <ayoung> jamielennox_, yeah...SAML should only be considered a marshalling format 18:28:45 <jamielennox_> and even with hierarchical i'm not really sure what having the auth_url on a region would be used for 18:28:49 <dolphm> jamielennox_: regions are really just an organizational tool to facilitate discovery in a complex environment, right? 18:29:05 <topol> dolphm +++ 18:29:27 <jamielennox_> i'm concerned that we bled extension concepts over into the core API because we didn't want to add a couple of hundred lines of controllers for a new resource type 18:29:40 <jamielennox_> dolphm: sure 18:30:20 <dolphm> jamielennox_: if it was region["OS-FEDERATION:url"], would that be more sane in your eyes? 18:31:00 <jamielennox_> dolphm: it would at least remove it from the regular pool - i'm just not sure why it's not it's own resource 18:31:18 <ayoung> leaving SAML out of it for a moment, though, does having distinct Auth URLS in the same service catalog make any sense? I always thought "domain" would be the reasonable fissure, not reagion, for the span of control of a KEystone server 18:31:37 <ayoung> or, really, whatever we call the "assignment domain" 18:31:44 <ayoung> Region is not that 18:32:14 <jamielennox_> ayoung: i don't think so 18:32:24 <ayoung> all this Auth Url would be is "here is a closer keystone server" 18:32:27 <dolphm> ayoung: region URLs don't appear in the service catalog 18:32:31 <dolphm> it's sort of a meta-catalog 18:32:39 <dolphm> and potentially cross-cloud 18:32:43 <jamielennox_> dolphm: so another question - how do i list all the auth_urls that i can get to with this token? 18:32:56 <jamielennox_> is that some sort of filter on a region list operation? 18:32:56 <ayoung> dolphm, region is the wrong abstraction 18:33:20 <ayoung> region is not a security namespace. Domain is a secuiryt namespace. 18:33:37 <jamielennox_> yea, but domain doesnt fit here 18:34:32 <dstanek> the reason i thought regions needed to grow the auth_url was that the EAST region may be from cloud provider 1 an the WEST region from cloud provider 2 18:35:25 <dolphm> dstanek: ++ that's the use case we discussed. it's also obviously one of federation in that example, so i'm inclined to buy the argument that it should have been an OS-FEDERATION extension attribute. 18:35:41 <jamielennox_> dstanek: wouldn't access to them be controlled by seperate service catalogs/tokens? 18:35:58 <dolphm> does the core API have a use case for region URL's without consideration for OS-FEDERATION? 18:36:05 <dstanek> jamielennox_: my understanding is separate token, but same catalog 18:36:10 <ayoung> wow....Um, that is really diffferent from how I understood regions 18:36:12 <stevemar> dolphm, doubtful 18:36:21 <dolphm> dstanek: that point has proponents on both sides 18:36:26 <jamielennox_> dstanek: why would be share a catalog between different tokens? 18:36:58 <jamielennox_> if you can't access the resource with the current token it should not be in the service catalog 18:37:23 <dolphm> stevemar: what's the cost to hackishly move region.url to be an OS-FEDERATION attribute in the implementation? 18:37:23 <ayoung> jamielennox_, ++ 18:37:30 <jamielennox_> also unless we start listing the auth_url for that region in the service catalog there is no way for existing services to know they need a new token before accessing it 18:37:32 <dstanek> jamielennox_: in some cases the internal cloud may not want the customer to directly care that the region is from a different provider 18:38:43 <jamielennox_> dstanek: but it's not so much the customer - if we need a new token how do the developers know they need to do that? 18:38:44 <dolphm> jamielennox_: i'd assume (perhaps wrongly, and i know others disagree) that if a region appears with a URL, then i'm not going to have it's endpoints in my service catalog. i'd have to go auth (somehow) with that endpoint to get a new catalog 18:39:24 <dolphm> people fuss too much over obscuring endpoints from their own users, that i can't see any deployments willing to expose & maintain a complete catalog of their own services in multiple clouds 18:39:53 <dstanek> jamielennox_: someone mentioned (maybe at the hackathon) that the client could take care of negotiating for new token to be used in the other could - transparently to the user 18:40:15 <jamielennox_> so i think this was discussed in the talk at atlanta and it was a question from the audience about getting a catalog full of endpoints for other cloud providers 18:40:32 <bknudson> what client? 18:40:56 <jamielennox_> and chadwick stood up (and we all agreed) that no, you would be able to get a listing of other providers and then if you went and got a token from them you could get the endpoints you could access with that token in that new cloud 18:41:11 <jamielennox_> that stuffing every possible endpoint into the one token was not the way to do this 18:42:10 <jamielennox_> s/one token/one catalog 18:42:12 <ayoung> jamielennox_, ++ 18:42:17 <dstanek> jamielennox_: i thought that was one of the reasons to break remove the catalog from the token 18:42:32 <dstanek> bknudson: the keystone client or any other thridparty clients 18:43:06 <jamielennox_> dstanek: on client i don't think that's going to be backwards compatible 18:43:07 <stevemar> dolphm, removing url from region isn't too bad, just don't know where to add it to 18:43:12 <dstanek> my understanding may be outdated and stevemar/marek may have new ideas 18:43:34 <jamielennox_> dstanek: i think we are a long way from removing the catalog from the token though 18:43:35 <topol> dstanek +++ I thought it was a reason to break the catalog from the token as well 18:44:04 <jamielennox_> stevemar: i think OS-FEDERATION/sp is as good as any 18:44:08 <dolphm> stevemar: for juno, i don't want to break a bunch of stuff. if renaming region.url to region.OS-FEDERATION:url is something we need to consider for juno though, i want to take the shortest, least risky path to make that happen 18:44:15 <dstanek> jamielennox_: why not? get a 403 saying federation is possible and do the magic - old clients don't do the magic and old servers won't say they support the magic 18:44:37 <jamielennox_> i even see it reasonable to list available service providers as a field in the token response so that you don't need to query that as an additional step 18:46:16 <ayoung> shall we vote on it? 18:46:45 <dolphm> ayoung: we don't have a code review to vote on :) 18:46:57 <ayoung> dolphm, is it the right approach? 18:47:03 <jamielennox_> dstanek: fair it will just fail, though in reality what will happen is that getting a 401/403 from a response will make the client dump its existing token reauthenticate with keystone (because the only reason it knows to get blocked from an endpoint in it's catalog is that it has been revoked or something else) and try the request again - but it will fail out after that 18:47:37 <dolphm> jamielennox_: ++ 18:48:40 <jamielennox_> also i would be interested in what we were thinking about in terms of "breaking out the service catalog" 18:48:50 <ayoung> I'm most concerned with sticking the Federation Endpoints in the Service catalog. 18:49:03 <ayoung> that is a commitment we can't break lightly 18:49:04 <jamielennox_> it's been a long held theoretical belief - but not one i've seen come even close in practice 18:49:11 <jamielennox_> ayoung: ++ 18:49:19 <dolphm> stevemar: jamielennox_: let's look at the API impact after the meeting, and see if anyone wants to volunteer to write a patch for juno 18:49:21 <jamielennox_> ayoung: that's a really bad idea IMO 18:50:01 <jamielennox_> however i'm more concerned that is it the only thing that's going to otherwise prevent us from landing all the k2k work in juno? 18:50:02 <stevemar> ayoung, it wouldn't be an endpoint, it's just an auth url 18:50:10 <ayoung> jamielennox_, so we are agreed that K2K Federation should not use the Auth URL for a region. I think Region specifc auth urls are suspect 18:50:11 <dolphm> jamielennox_: that's just something we've put little effort into 18:50:32 <ayoung> stevemar, doesn't matter what you call it, it matters that it is in the service catalog 18:50:34 <dolphm> ayoung: we're agreed that it's suspect, i think. that's all 18:50:42 <stevemar> but it's one url vs many 18:51:35 <dolphm> bknudson: is your JSON home #topic for juno or kilo? 18:51:45 <jamielennox_> stevemar: so the catalog would contain 'auth_url' rather than public/internal/admin? 18:51:50 <bknudson> dolphm: well, I was hoping to discuss it for juno, if possible 18:51:56 <dolphm> bknudson: alright, then let's do it 18:52:00 <dolphm> #topic JSON Home for /, /v2.0 18:52:02 <dolphm> bknudson: o/ 18:52:06 <jamielennox_> bknudson: sorry, take it away 18:52:15 <bknudson> so the discussion is, do we want to be able to have json home for /, too 18:52:33 <bknudson> I did some experimenting over the weekend and it turned out I could use webob to request the /v3 18:52:51 <bknudson> and then all that needs to happen is change the URLs in the v3 JSON home and now / returns the JSON Home 18:53:02 <bknudson> this seems useful because then a client can get JSON Home from / or /v3 18:53:04 * ayoung likes that 18:53:14 <topol> bknudson, very cool! 18:53:17 <bknudson> so no need to do version discovery 18:53:25 <stevemar> bknudson, seems like a no brainer 18:53:26 <ayoung> I think that is the right approach....so long as /v3 in this case implies "latest" 18:53:29 <dolphm> i'd really like that! 18:53:32 <jamielennox_> bknudson: for existing clients i've always assumed that the response from / and from /vX is the same 18:53:33 <ayoung> but we are a long way from /v4 18:53:54 <bknudson> on top of that, can do /v2.0 and have it also return the /v3 JSON Home 18:53:58 <topol> bknudson, do you have a review link? 18:54:01 <jamielennox_> obviously not the same, but that i don't need to query both 18:54:11 <bknudson> #link https://review.openstack.org/#/c/118240/ 18:54:24 <bknudson> this is a WIP since I didn't do tests 18:54:43 <bknudson> and also the wacky Version controllers don't make this easy 18:55:04 <topol> bknudson the /v2.0 returns JSON for v2 correct/ 18:55:05 <dolphm> bknudson: i don't follow the /v2.0 comment 18:55:07 <bknudson> so I'll work on this and I should be able to get it done in a couple hours. 18:55:22 <topol> dolphm, me iether 18:55:37 <jamielennox_> bknudson: you would return the v3 urls for Get /v2.0? 18:55:40 <bknudson> GET /v2.0 w/ Accept: application/json-home will return a JSON Home document that has relationships / links to the v3 resources 18:56:06 <bknudson> so if you've got /v2.0 in your catalog, you'd have links to the v3 resources. 18:56:07 <dolphm> bknudson: that sounds slighly scary, but i know some rest api's basically do that 18:56:27 <bknudson> I'll split it out 18:56:33 <jamielennox_> bknudson: i'm not sure the way i've been thinking about discovery with json home will work with that 18:56:38 <topol> how does crossing those two ghostbuseter streams not lead to toruble? 18:56:42 <jamielennox_> (which is probably a problem with my thinking) 18:56:57 <dolphm> bknudson: support on / is super nice to have, support on /v2.0 is way down my personal wishlist 18:56:57 <bknudson> the relationship links are always the same 18:57:16 <bknudson> so you've got a relationship that says http://identity/v3/auth_tokens 18:57:20 <ayoung> 3 minutes left 18:57:24 <dolphm> ayoung: thanks 18:57:28 <dolphm> and yikes 18:57:40 <bknudson> when the client needs to get the URL to v3 auth tokens it looks for that relationship 18:57:51 <bknudson> and then follows the link for that relationship 18:58:15 <dolphm> bknudson: in reality, are we going to have any JSON-Home aware clients interacting with v2? 18:58:22 <jamielennox_> dolphm: yes 18:58:31 <jamielennox_> dolphm: keystoneclient 18:58:31 <bknudson> as long as people have /v2.0 in their catalog 18:58:36 <dolphm> jamielennox_: i mean, with *only* v2 18:58:52 <jamielennox_> dolphm: not particularly because i want it for v2 but i want the flow to be the same for v2 and v3 18:59:20 <dolphm> jamielennox_: but this flow won't work on, say, icehouse, so you'll never have the same flow all the time anyway 18:59:29 <dolphm> jamielennox_: have to account for it not existing 18:59:48 <dolphm> (1 min) 18:59:49 <jamielennox_> dolphm: but it's how you stack your accept headers, we will always need to fall back to current discovery 19:00:15 <dolphm> jamielennox_: you wouldn't rather just always fallback to current discovery for v2, instead of introducing and supporting a new thing? 19:00:25 <jamielennox_> moving to channel 19:00:27 <lbragstad> time 19:00:30 <bknudson> thanks 19:00:42 <dolphm> \o/ 19:00:45 <dolphm> #endmeeting