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