18:03:44 #startmeeting keystone 18:03:45 Meeting started Tue Mar 10 18:03:44 2015 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:03:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:49 The meeting name has been set to 'keystone' 18:04:09 dolphm, ayoung, dstanek, jamielennox, morganfainberg, stevemar, gyee, henrynash, topol, marekd, lbragstad, joesavak, shardy, fabiog, nkinder, lloydm, shrekuma, ksavich, hrybacki, rharwood, grantbow, vdreamarkitex, raildo, rodrigods, amakarov, ajayaa, hogepodge, breton, lhcheng, nonameentername, samueldmq, htruta, amolock, wanghong, fmarco76 18:04:14 hi 18:04:19 incase anyone is thrown off by dst.. 18:04:22 o/ 18:04:57 lbragstad: thanks 18:05:04 o/ 18:05:07 Lbragstad, i was 18:05:20 hi 18:05:24 I think this is the first time I've actually showed up for a keystone meeting after a time change 18:05:27 o/ hello 18:05:29 is missing CEO of IBM meeting for this! 18:05:34 lbragstad: =) 18:05:34 o/ 18:05:35 #topic Kilo-3 deadline 18:05:44 #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule 18:05:51 Feature proposal freeze was last week, meaning that it's now too late to propose implementations of new features for Kilo 18:05:59 So now it's time for everyone to start putting review focus on what's already in review! 18:06:08 Our next deadline is actual the feature freeze: March 19th 18:06:20 So the clock is ticking on polishing and merging final implementations of features for Kilo. 18:06:40 tic tic tic booom! 18:06:42 And knowing the history with our gate, we should really be aiming for March 17th 18:06:53 Because transient failures, gate load, etc, etc. 18:07:01 gate has been really stable lately. 18:07:18 (due to a lot of hard work) 18:07:29 If you're looking for something to review, I'd point you to our list of release blocking reviews, but I just broke it last night and am working on getting it going again. 18:07:29 I havent gotten neutroned in a while 18:07:41 A link is in the #openstack-keystone /topic 18:07:48 bknudson: don't jinx it 18:08:09 first rule of gate failures is don't talk about gate failures. 18:08:30 Any questions on priority for the next 7-9 days? 18:08:34 never mention the F word when it is within earshot 18:08:57 if only DB2 CI was as stable! 18:09:04 Would like to make sure https://review.openstack.org/#/c/142573/ is on that list 18:09:27 bknudson: gate stability is already starting to drop though, compared it where it was a few weeks ago (around 96% of gate jobs were passing at one point!) 18:09:43 bknudson: it's now back down to 88% and failing as far as i've seen 18:09:51 :( 18:10:17 ayoung: i'll make sure it's on the list of release blockers 18:10:22 thanks 18:10:36 any other reviews that should be considered release-blocking for kilo-3? 18:10:42 can we pile on release blockers? 18:11:00 https://review.openstack.org/#/c/117372/ 18:11:01 bknudson: hopefully only things in direct support of targeted blueprints 18:11:07 samueldmq, rodrigo: is the lsit_assignments performance one on the list? 18:11:20 henrynash, it wasnt anymore 18:11:31 bknudson, +2A 18:11:32 https://review.openstack.org/#/c/142200/ 18:11:33 bknudson: keystoneclient falls outside the release process, but that's a good one 18:11:41 oh, these are both keystoneclient 18:11:42 I thought I had done that already 18:11:47 henrynash, I'd like to see it on that list again ... but I talked to morganfainberg and time is short .... 18:11:57 samueldmq: ok…just checking 18:12:01 bknudson: but we're hoping to do a release of ksc/ksm soon 18:12:02 for kc I'd like this one: https://review.openstack.org/#/c/150078/ 18:12:08 henrynash, and that is a long chain, but we could at least put it at the end 18:12:16 we will want to cut new versions and bump g-r before final release 18:12:37 that was it... the rest of mine are bugs. 18:12:54 jamielennox: ++ doing two releases before kilo is final would be good. one near kilo-3 and one more around stable/kilo 18:12:55 henrynash, 'Improve List Role Assignments Filters Performance' https://review.openstack.org/#/c/137202/ 18:13:09 bknudson: i guess we'll get to release blocking bugs after next week :) 18:13:16 OK...I'll be in code reveiw mode for the next few days. 18:13:21 ayoung: ++++ 18:13:27 dolphm: yep, the k3 one will probably be in g-r, final probably packaged 18:13:36 rodrigods, can you take back your patch for whitelists and get the comments in, so I can review it 18:13:42 yeah, i think i got patchset pushing out of my system now 18:14:07 ayoung, yes 18:14:22 We really need to make sure we have a client review push scheduled in. 18:14:30 ayoung, at least, I can try, will signalize otherwise 18:14:34 samueldmq: henrynash: https://review.openstack.org/#/c/137202/ isn't targeted to kilo-3, so i'll leave that one to morganfainberg 18:14:36 rodrigods, fair enough 18:14:59 dolphm: yep, understand 18:15:14 alright, let's move on to agenda items -- it's hard to discuss release blockers when the current list isn't available :) (sorry!) 18:15:24 #topic JSON Home 18:15:31 It isn't targeted because it's a nice to have. 18:15:35 to quote the agenda summary: 18:15:37 Fyi. 18:15:38 "Support for experimental/disabled. When we approved the spec for moving away from extensions, we specified that resources might be appear as "experimental" (if they were still maturing) or "disabled" (if that features had been turned off by a config switch) in the JSON Home response. Concern, however, has been raised as to whether this is a valid way of using JSON Home. The new domain-config-database support is the first 18:15:38 new resources to use this....before we merge its JSON Home support, let's make sure we are still happy with this approach." 18:15:42 henrynash: o/ all yours 18:15:45 thx 18:15:56 morganfainberg: ack 18:16:17 of so this is to revist the issue of how our resources/APIs are repreented via JSON Home in various sceanrios 18:16:49 as per teh comemnt above, I’d *thought* we had agreed we would use the hints property of a resource to indicate its status 18:17:09 I'm ok with "hints" for deprecated. 18:17:12 My only thought is disabled is not a classification. 18:17:17 (see paragraoh starting around line 70 in https://review.openstack.org/#/c/133809/8/specs/kilo/replace_extensions.rst) 18:17:36 is the question whether or not a disabled or experimental feature appears in a JSON Home response? 18:17:37 Experimental and deprecated are classifiers same as stable. 18:17:55 morganfainberg: well, teh json home spec actually even suggest using “gone” to indicate an API that was supported once….. 18:17:57 disabled seems different. 18:18:08 Disabled is not. 18:18:20 dolphm: yes…. 18:18:46 henrynash: Gone is an intruiging choice 18:19:08 I think it makes for more complicated clients to force them to check for "disabled"... they shouldn't need to do this. It should be handled by the server. 18:19:27 bknudson +++ 18:19:34 #link http://tools.ietf.org/html/draft-nottingham-json-home-03#section-4.10 18:20:12 we're not going to return a proper 410 Gone for a disabled extension, i assume 18:20:19 bknudson: well they don’t have to check disabled, (the server will return an error if they try and call the API on the resouce), but the json home hinst tells them why 18:20:31 dolphm: no 18:20:53 dolphm: we would retunrn 404 (I think) 18:21:28 henrynash: i'd support a 404, "server is oblivious of the thing you're asking for" (but i think morganfainberg disagrees?) 18:22:03 stevedroid: morganfainberg: i think ya'll were discussing 403, as if disabling a new API was a policy change? 18:22:05 I would assume that the priamry use of the JSON home is to generate other operations, specifically visual web for talking to Keystone. If the resource is gone, it should not show up in an enumeration. Its not so much looking for the resoruce itself as it is generating a form, where that resource would be one field. DIsabled would be vary useful to put a greyed out button for something that was no longer there, but the user migh 18:22:06 t be looking for 18:22:12 but if there is no way to enable it... 18:22:20 I guess my larger issue is that I *thought* the point of moving aeway from the course extension mechaism, is so that we have a more robust API for which you can also get JSON HOme info about, even if the resource you want is expermimetnal/disabled/gone etc. 18:22:31 ayoung: that's my real preference. no means of discovery + 404 if you try and skip discovery 18:22:55 provide a GET /v3?disabled 18:23:10 can we say "gone" is "experimental" 18:23:11 bknudson: IT'S A TRAP! 18:23:17 let's fail fast on this... 18:23:19 ayoung: definitely not 18:23:27 heh 18:23:30 ayoung: gone has subsequent behaviors tied to it 18:23:38 right, so if we do it, we are committed 18:23:41 exoectation of 410 Gone 18:23:44 expectation* 18:23:48 but if we don't, people will code around us 18:23:54 410 doesn't seem right for this 18:24:16 410 would indicate that it used to be there. 18:24:28 so question 1) should we use json home hints status on a per resouce basis to indicate any variance from “stable” 18:24:37 410 would mean that it will never be there 18:24:41 i'm not sure i can make an argument for 403, but does anyone want to try? 18:24:51 i like 410 when we *remove* an API 18:24:53 breton: ++ 18:24:57 I think we should use the hints status for deprecated. that's in the spec. 18:25:00 morganfainberg: ++ agreed 18:25:01 when we disable, i'd advocate a 403 18:25:05 and a 404 if it doesn't exist 18:25:07 morganfainberg: or soft delete an object 18:25:08 and never has 18:25:12 which we don't do 18:25:17 dolphm, sure 18:25:21 and we could use gone when it's past deprecation and removed. 18:25:35 this is specific to APIs not resources 18:25:51 bkndudson: if we got experimental added to the json home spec, would you support that? 18:26:00 o 18:26:01 bknudson: you're assuming you can actually remove previously-stable APIs? 18:26:01 o 18:26:14 Let me suggest that we code that up as a change to the API spec and document it? 18:26:19 dolphm: right... that never happens anyways so don't need to worry about it. 18:26:27 henrynash: I'm also ok with experimental... 18:26:32 I'd prefer /v3?experimental 18:26:49 bknudson: i like the opt in 18:26:53 or even ?unstable 18:27:13 we could have a separate resource for experimental, too... e.g., versioning 18:27:24 I mean a separate relationship. 18:27:27 so the specific review this is affect is: https://review.openstack.org/#/c/162484/4/api/v3/identity-api-v3.rst 18:27:28 Content type 18:27:38 #link https://review.openstack.org/#/c/162484/4/api/v3/identity-api-v3.rst 18:28:46 where I had suggested that the new domain-config APIs should be marked as expermental (I;d be OK if we wanted to make them stable, but not maing that assumption) 18:29:09 henrynash: what's the argument for experimental? 18:29:14 you planning to change the API? 18:30:08 bknudson: no…but in the spec for moving away from extensions we agreed that by default we would make new APIs experiemtnal for a cycle… 18:30:10 bknudson, not planned but it allows us to if needed 18:30:27 …with an option to agree to marking as stable within a cycle if we so chose 18:30:30 bknudson, basically it doesnt' lock us into a "stable" API the moment it is merged 18:30:32 as an example of using a relationship to indicate experimental, put a version on the rel: http://docs.openstack.org/api/openstack-identity/3/rel/domain_config/v0.1 18:30:37 it gives us a cycle to say "yes" or "no" or "needs more work" 18:31:07 then if you come up with a new API use http://docs.openstack.org/api/openstack-identity/3/rel/domain_config/v1.0 18:31:20 that certainly an option….hwoever… 18:31:25 and it keeps us from changing the URL from OS-TRUSTS when we decide to promote something 18:31:36 fwiw, i think microversioning is a trainwreck. 18:31:39 you want me to code up support for ?experimental ? 18:32:00 but i'm willing tochange my mind once we see more from nova on it 18:32:02 and how it works out 18:32:45 I woudl have though that as we mature Open Stack, people will want to be able to check clietns to see if tehy use expermiemental APIs, or deprecated ones….and json home seems the obvious way an automated analyser would do this 18:33:16 as oppsied to knowing that v0.1 meant experimental and v1.0 meant atsbale 18:33:16 check clients? 18:33:56 morganfainberg: ++ trainwreck 18:34:32 I’m thinking “applications that talk to the OpenStack API”…..I can envisage certains shops only allowing apps that talk to stable APIs etc. 18:34:34 jamielennox is smoking something :) 18:34:51 ok, let’s try and net this out 18:34:56 I think that can be done with /v3?experimental. 18:35:15 OK...moving on? 18:35:21 when we approve dthe spec for removing extensions we said we woudl use json home for disabled & experimental…. 18:35:25 gyee: just slow this morning 18:35:29 do we agree or disagre? 18:35:34 agree 18:36:06 ... thought we agreed that specs aren't written in stone. 18:36:06 let's vote it? 18:36:07 alrighty... 18:36:13 bknudson: ++ 18:36:24 bkndison: absoilutely!!! that;s why I brought it up here! 18:36:31 experimental agree, why put disabled in home? 18:36:50 henrynash: want a quick vote? 18:36:58 dolphmL sure 18:37:35 jamielennox: the argument woudl be so a cleint coudl work out WHY an API is returning an error (oh..it;s just diabled in this installation”) 18:37:58 henrynash: wouldn't that be the same as the resource being missing in jsonhome? 18:38:09 but I’d be Ok if we only wanted experimental/stable/deprecated for now 18:38:24 jammielennix: maybe it’s gone for ever? 18:38:25 assuming you went to jsonhome first rather than use it as an error checker 18:38:35 we publish all the relationships, so if you want to know just check which rels are available and which aren't. 18:38:58 am I supposed to call up dolphm and tell him to turn an extension on for me? 18:39:15 dolphm: so if disabled is contentions, let’s vote on json home supporting depreacted/experimental/stable 18:40:02 henrynash, that is kind of what I was implying before. We can split these into two reviews, and make sure we get the first part through 18:40:32 bknudson, a tool needs to talk to multiple keystone servers, and needs to know what features are enabled on each 18:40:43 JSON Home already shows that. 18:41:07 henrynash: i'm trying to figure out how to phrase the vote so that it's simple... 18:41:11 there's a security concern with telling your clients too much about your server already. 18:41:25 have to *tools guys* chime in, horizon, CLI 18:41:28 #startvote should we refelect a status of stable(teh default), experimental and deprecated in the JSON Home response on our resources 18:41:28 s/to/the/ 18:41:29 Only the meeting chair may start a vote. 18:42:06 henrynash: that presumes that they should appear at all? 18:42:31 dolphm: if so, vote no ?!!? 18:43:04 henrynash: #startvote needs options to be enumerated, and voters need to match the options exactly 18:43:05 dolphm: hinsts: {‘status’: } is part of the json hom spec 18:43:09 get out of here stevedroid you imposter 18:43:27 henrynash: how we advertise stable features is a given 18:43:35 * stevedroid leaves 18:43:56 We could have a vote just for deprecated... that's in the JSON Home spec. 18:44:09 bknudson, thats fine. 18:44:17 and a separate one for experimental. 18:44:22 i'd be ok with adhering to the spec. 18:44:28 so question 1) : should we refelect a status of deprecated in the JSON Home response on our resources 18:44:35 bknudson: so, yes/no, should deprecated/experimental features appear in json home at all? 18:44:46 dolphm, do deprecated 1st 18:44:46 dolphm: that;s do 18:44:48 then expirimental 18:44:51 agreed 18:44:52 alrighty 18:44:55 #startvote Should *deprecated* API features appear in JSON-Home at all? yes, no 18:44:56 Begin voting on: Should *deprecated* API features appear in JSON-Home at all? Valid vote options are yes, no. 18:44:57 Vote using '#vote OPTION'. Only your last vote counts. 18:45:02 yes 18:45:03 #vote yes 18:45:05 #vote yes 18:45:11 #vote yes 18:45:13 #vote yes 18:45:16 #vote yes 18:45:16 #vote yes 18:45:21 #vote , 18:45:22 #vote yes 18:45:23 ayoung: , is not a valid option. Valid options are yes, no. 18:45:26 damn 18:45:28 #vote yes 18:45:43 yes 18:45:46 ayoung, that , looks like a thumbs down 18:45:48 #vote yes 18:45:49 #votestatus 18:45:53 #vote yes 18:46:35 #showvote 18:46:36 yes (10): gyee, lbragstad, ayoung, morganfainberg, bknudson, dstanek, dolphm, jamielennox, amakarov, henrynash 18:46:39 they have to be in there if we claim to be RESTful! otherwise deprecating them is the same as removing them 18:46:48 ending in 10 seconds... 18:46:58 #endvote 18:46:59 Voted on "Should *deprecated* API features appear in JSON-Home at all?" Results are 18:47:00 yes (10): gyee, lbragstad, ayoung, morganfainberg, bknudson, dstanek, dolphm, jamielennox, amakarov, henrynash 18:47:00 #vote \m/_ (^^) _\m/ 18:47:05 #startvote Should *disabled-by-deployer* API features appear in JSON-Home at all? yes, no 18:47:06 #vote yes 18:47:06 Begin voting on: Should *disabled-by-deployer* API features appear in JSON-Home at all? Valid vote options are yes, no. 18:47:07 Vote using '#vote OPTION'. Only your last vote counts. 18:47:17 #vote no 18:47:17 #vote no 18:47:20 #vote no 18:47:22 #vote no 18:47:22 #vote no 18:47:26 #vote no 18:47:32 #vote yes 18:48:02 #vote maybe 18:48:03 ayoung: maybe is not a valid option. Valid options are yes, no. 18:48:10 * morganfainberg is having connection issues 18:48:14 #vote no 18:48:33 if nothing else if we start with them not appearing, it's much easier to add them later than try and remove them 18:48:38 henrynash, so if we change our mind on this one, we can add it in again later. RIght? 18:48:39 morganfainberg: voting on whether *disabled-by-deployer* API features appear in JSON-Home at all 18:48:56 ayoung: sure, yep…happy to adhere to teh vote 18:49:01 #showvote 18:49:02 yes (2): henrynash, topol 18:49:03 #vote I'm a coward 18:49:04 no (7): gyee, dstanek, bknudson, lbragstad, dolphm, jamielennox, breton 18:49:05 ayoung: I'm a coward is not a valid option. Valid options are yes, no. 18:49:09 damn 18:49:12 #vote no 18:49:17 ending in 10 seconds... 18:49:24 #vote no 18:49:30 #endvote 18:49:31 Voted on "Should *disabled-by-deployer* API features appear in JSON-Home at all?" Results are 18:49:32 yes (2): henrynash, topol 18:49:33 no (9): gyee, dstanek, ayoung, morganfainberg, bknudson, lbragstad, dolphm, jamielennox, breton 18:49:37 #startvote Should enabled-by-deployer *experimental* features appear in JSON-Home? yes, no 18:49:38 Begin voting on: Should enabled-by-deployer *experimental* features appear in JSON-Home? Valid vote options are yes, no. 18:49:39 Vote using '#vote OPTION'. Only your last vote counts. 18:49:48 #vote yes 18:49:48 #vote yes 18:49:49 #vote yes 18:49:51 #vote yes 18:49:51 #vote yes 18:49:57 #vote yes 18:50:05 #vote no 18:50:05 #vote yes 18:50:11 does this mean without /v3?experimental? 18:50:24 bknudson: presentation doesn't matter yet, just starting with the boolean 18:50:29 #vote yes 18:50:33 I’m assuming we *would* mark it as such 18:50:37 what's a client going to do with experimental? 18:50:43 gyee: use it 18:50:50 #vote yes 18:50:56 at who's discretion? client or user? 18:50:59 gyee: call it if specified to opt-into unstable features? 18:51:00 you might not want your application to use experimental APIs. 18:51:03 gyee: user, hopefully 18:51:07 gyee: if that’s ok in teh context (i.e. in a military application, probably not) 18:51:22 it's like calling the client with --insecure 18:51:33 arrh k 18:51:37 make sense now 18:51:38 --i-know-this-is-a-bad-idea-but-i-want-unstable 18:51:46 dolphm, yeah, make sense 18:51:46 #showvote 18:51:47 yes (9): lbragstad, morganfainberg, bknudson, dstanek, dolphm, jamielennox, amakarov, henrynash, breton 18:51:48 no (1): gyee 18:51:52 ending it 10 seconds ... 18:51:54 gyee: but that’s the point of giving the status..soit can know 18:51:54 changing my vote 18:52:02 gyee: go for it 18:52:06 gyee: only your last vote counts 18:52:09 #vote yes 18:52:13 #endvote 18:52:14 Voted on "Should enabled-by-deployer *experimental* features appear in JSON-Home?" Results are 18:52:15 yes (10): gyee, lbragstad, morganfainberg, bknudson, dstanek, dolphm, jamielennox, amakarov, henrynash, breton 18:52:34 okay so in summary: 18:53:42 We agree that: A) Deprecated API features should, somehow, appear in JSON-Home. B) *Disabled-by-deployer* API features should NOT appear in JSON-Home at all. C) Enabled-by-deployer *experimental* features should, somehow, appear in JSON-Home. 18:53:49 ok, great, that gives me what I need to know - will process accordingly, thanks to all 18:54:16 henrynash: the *how* for A and C are the interesting part :) 18:54:20 i yield the floor with 6 mins to go :-) 18:54:34 henrynash: maybe we can enumerate the How options in advance for next meeting? 18:54:41 dolphm, ++ 18:54:45 henrynash: stick them on the agenda 18:54:46 dolphm: sure 18:55:02 #agree Deprecated API features should, somehow, appear in JSON-Home. 18:55:08 #agree *Disabled-by-deployer* API features should NOT appear in JSON-Home at all. 18:55:12 #agree Enabled-by-deployer *experimental* features should, somehow, appear in JSON-Home. 18:55:17 i think those will appear in the meeting notes 18:55:23 #topic keystone vs Keystone 18:55:30 #link https://review.openstack.org/#/c/162561/ 18:55:32 breton: o/ all yours 18:55:37 how do we call keystone? 18:55:40 in several reviews I saw people nitting that it should be "Keystone" and not "keystone" everywhere. 18:55:44 now there is that patch 18:55:44 henrynash: as an early vote it would be nice if it was somehow in the json home doc so that i can cache the whole doc with one call 18:55:51 in that review there is a link to wiki.o.o which suggests to use "keystone" 18:55:54 breton: the official project name is lowercased, "keystone" 18:56:04 I think we should stick with the doc naming convention. 18:56:12 jamielennox:agree 18:56:12 makes it easier to write the docs 18:56:15 bknudson: is that lowercased? 18:56:17 Keystone is a proper noun 18:56:22 yes, the doc convention is lowercase. 18:56:34 not sure why, but that's what they document. 18:56:36 the English language convention is that those are capitalized 18:56:47 ayoung: but it's also just a code name 18:57:07 https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names 18:57:11 i mentioned in the review to bring this here - because we've accepting commits to make Keystone the project and keystone the code 18:57:15 OpenStack Identity 18:57:17 dolphm, ++ 'Identity' is capitalized 18:57:21 now patch is kinda going the other way 18:57:40 the program names *are* capitalized in title case (OpenStack Identity) 18:57:55 I didn't know about the style guide until it was pointed out to me. 18:58:29 maybe they don't want code names capitalized for legal reasons, in case other companies have them trademarked (like quantum) 18:58:53 bknudson: i didn't know there was a solid recommendation on the issue until recently 18:59:06 Yeah, companies never trademark things starting with lowercase letters 18:59:18 iPhone? 18:59:21 Unless it is an i, then you need to capitalize the second letter 18:59:28 or an e 18:59:33 heh 18:59:33 gyee, unless it's cisco, then it was IPhone iirc 18:59:38 maybe we should always use the repo path, like openstack/keystone instead of Keystone or keystone 18:59:46 dolphm, ++ 18:59:51 use an URL 18:59:57 we could always use OpenStack Identity 19:00:03 http://..... 19:00:11 bknudson: but these docs are specifically referring to one project in the program 19:00:12 time is up 19:00:13 what happen to AAA? 19:00:17 bknudson: can't escape that :) 19:00:22 dolphm, care to clear the floor 19:00:24 gyee: no one outside of this group likes it 19:00:26 we're over time 19:00:30 morganfainberg: ++ 19:00:33 #endmeeting