20:03:41 #startmeeting tc 20:03:42 Meeting started Tue Jul 15 20:03:41 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:45 The meeting name has been set to 'tc' 20:03:55 Agenda for today is: 20:04:00 mordred is actually still in north america I believe 20:04:08 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:04:22 looks like markmcclain is around too 20:04:25 o/ 20:04:30 #topic Core Capabilities TC scoring 20:04:35 #link https://review.openstack.org/100722 20:04:51 I got a bit of clarification on what to do when the capability name doesn't really match the set of underlying tests, and around the meaning of "complete": 20:04:56 ttx: do you want a new draft with the references to the ML discussion included, or is having those links in the review history good enough? 20:05:01 #link http://lists.openstack.org/pipermail/defcore-committee/2014-July/000247.html 20:05:09 no I think it's good enough 20:05:14 ok 20:05:15 With that clarification, I think the currently-proposed scoring for havana is as good as any 20:05:26 We just need to gather enough +1s on it now 20:05:33 agree 20:05:36 Unless someone questions a specific score and wants us to discuss it here 20:06:00 so we need 4 more +1s to pass it 20:06:30 Thank you all for getting the scoring complete! 20:06:38 if all the attendance is ok with it, we could pass it now 20:07:03 if there is anything blocking you from +1ing it, we can discuss it now 20:07:23 annegentle: o/ 20:07:25 zehicle_at_dell: thanks for the clarifications 20:07:42 annegentle: we are discussing https://review.openstack.org/100722 and trying to get the last +1s on it 20:07:46 russellb, thanks. Let me know if I should update the source materials too 20:07:53 happy to take suggestions to update there 20:08:14 ttx, +1ed 20:08:22 biggest thing i think is what we discussed before ... a text description of each capability 20:08:29 because it's not always obvious what it's covering 20:08:36 russellb: or a link to a doc 20:08:50 russellb: that will also let us suggest better tests to cover that capbility 20:09:00 ttx: indeed 20:09:14 i submitted one pull request to the list to fix one issue :) 20:09:21 russellb, I'd love to have collaboration on that. I'm updating the json source and we'd take pull to fix them 20:09:38 russellb: was that the mis-placed test or the name of compute-auth? or was that the same issue? 20:09:47 i put a patch up for the mis-placed test 20:09:53 vishy, annegentle: let me know if there is anything blocking your +1 on that one 20:09:58 didn't fix compute-auth yet, because we didn't have the clarification yet 20:10:05 as in ... was the name right, or the test right 20:10:09 right 20:10:24 based on the clarifications, sounds like the list of tests was the important part, and we could suggest a better name 20:10:30 DefCore's expectation was the technical community owns which tests are in the capabilities 20:10:41 orly... 20:10:48 you will not get push back from changes like that 20:11:14 ttx: I still would like an explanation for a 0.5 20:11:24 ttx: in the text itself, but I won't block because of it 20:11:27 annegentle: hm? 20:11:32 annegentle_: 0.5 was DefCore's way of saying "we don't know" 20:11:33 which 0.5s? 20:11:37 oh, you want that added... 20:11:41 annegentle: you mean, what 0.5 would mean ? There shouldn't be any left 20:11:44 yes 20:11:47 ttx: on https://review.openstack.org/#/c/100721/3/resolutions/20140617-defcore-capabilities-scoring.rst 20:11:54 that's exactly right. We don't want them in the final 20:11:58 right 20:12:01 annegentle: oh on the original version? 20:12:22 that was just the import, to make it easier to then see the specific changes we were making 20:12:23 I think that original version was just a convenient way to get proposed scores up. We shouldn't block on that 20:12:39 0.5 was basically like "??" asking for feedback 20:12:50 right original version. but it's also okay to bring it in as it was without an explanation for 0.5s 20:12:55 ttx, +1 20:12:56 that's right, I imported the data from the spreadsheet exactly as it came in so the 2nd patch could show the diff 20:13:07 ttx: and all I wanted was an explanation of what 0.5 meant 20:13:08 yeah, at this point I wouldn't block it on that 20:13:14 can we add that as a follow-up patch? 20:13:18 ttx: fair enough 20:13:19 then we won't lose existing +1s on that point 20:13:28 russellb: that makes sense esp. if it's a full-on exactly copy import 20:13:29 annegentle_: line 36 of https://review.openstack.org/#/c/100721/3/resolutions/20140617-defcore-capabilities-scoring.rst 20:13:30 but can still add it to clarify i suppose 20:13:46 dhellmann: ah there we go! 20:14:08 ah, it's already there :) 20:14:16 yay 20:14:25 woo 20:14:57 so do we have +1s from everyone here? 20:15:10 annegentle_ hasn't voted on https://review.openstack.org/#/c/100722/ 20:15:14 no vishy and no annegentle yet 20:15:32 anyway I'll confirm the vote tomorrow, to give a chance for people not present at the meeting to scream 20:15:44 but this sounds like 99% there 20:15:45 ah, makes sense :) 20:15:59 yea, those changes LGTM 20:16:13 devananda: hi! 20:16:19 ttx: hi :) 20:16:24 cool, let's move on 20:16:24 on it, thanks ttx, voted 20:16:30 #topic Integrated projects and new requirements: Gap analysis for Heat 20:16:34 zaneb: o/ 20:16:38 We are left with two projects in this analysis: Swift and Heat 20:16:40 hola 20:16:48 I tried to get Swift on the agenda for today but John wasn't available 20:17:02 #link https://etherpad.openstack.org/p/heat-gap-analysis 20:17:06 Zane accepted that we do Heat instead, so here we go ^ 20:17:16 thanks for the last minute run :) 20:17:37 np, it turned out to be less work than I expected 20:17:59 ok, let's go through that 20:18:32 zaneb: so you'll need to propose the mission statement for addition to the governance repo 20:18:33 sounds like the biggest (only?) thing is more functional test coverage? 20:18:33 zaneb: for "leverage existing functionality" on line 78, does heat still use ceilometer alarms to trigger operations? 20:18:46 #info Gap: missing mission statement 20:18:50 dhellmann: yes 20:19:11 zaneb: ok, I added a note about that 20:19:18 thanks :) 20:19:53 * russellb thinks Heat has done an excellent job 20:20:31 i think we just need to add #info Gap: need increased functional test coverage 20:20:36 thanks russellb :) 20:21:00 Well, and the mission statement thing 20:21:06 right, that was noted above 20:21:15 yep, and the grenade stuff is in progress, but it wouldn't hurt to track it 20:21:23 Ahhh, I see, you're proposing an #info, not summarizing 20:21:27 #info Gap: need increased functional test coverage 20:21:33 d'oh, missed the grenade one 20:21:34 \o 20:21:41 zaneb: was the name "Heat" checked for TM conflicts? 20:21:42 russellb: right at the bottom 20:21:47 yep see it now 20:21:49 devananda: not that I know of 20:21:50 I have a question about how backwards compatibility for Identity API v2.0 is handled 20:21:56 zaneb: i see your comment regarding "OpenStack Orchestration" bu tI think taht line refers to the short name as well 20:22:02 or if it is already and I missed it 20:22:14 ttx: #info Gap: need upgrade testing using grenade 20:22:16 zaneb: what does good unit test coverage work out to be? 20:22:16 (numberically) 20:22:45 zaneb: so that seems like it should be done 20:22:49 russellb: I think you can #info yourself 20:22:55 do we need to do the marketing team review of the name (line 253)? 20:22:55 ttx: orly ... thought chair had to 20:23:00 #info Gap: need upgrade testing using grenade 20:23:10 russellb: we'll see that : 20:23:19 dhellmann: i think we need to check for potential TM conflicts now 20:23:20 #info Gap: need upgrade testing using grenade (regression check) 20:23:24 ha 20:23:40 eg, to avoid havign to change the project's codename 20:23:50 devananda: right 20:23:53 annegentle_: we have a shim to for the Keystone v2 API to the extent that it contains the features we need. we plan to keep it around until the v2 api is removed 20:24:02 was assuming that was done long ago? the TM check that is 20:24:11 russellb: yes it was done 20:24:12 russellb: the etherpad implies maybe not 20:24:41 dhellmann: that requirement is mostly n/a for existing projects 20:24:41 ttx: ah, OK. I wasn't aware that it was done 20:24:50 unless a challenge comes 20:24:52 ttx: ok 20:25:01 and the challenger can claim previous usage 20:26:55 Is there anything to do around docs ? (the three kinds of docs note) 20:27:27 there have been some discussions with annegentle about where the template authoring guide should live 20:27:36 I don't know that there's been a conclusion yet 20:27:58 Not sure I would count that as a gap though 20:28:05 does it live somewhere now and you want to move it, or does it not exist yet? 20:28:17 dhellmann: yes, it lives in the developer documentation 20:28:27 which is a somewhat odd place for it 20:28:32 ok, at least it's there *somewhere* then :-) 20:28:57 fwiw I'd say that Heat development is going quite well, especially considering that it's the 2nd or 3rd largest Openstack project in terms of activity 20:29:16 depending on the way you twist stackalytics data 20:29:36 Any other gap worth mentioning ? 20:29:52 sorry catching up after getting dropped off wifi 20:30:18 We have a blueprint that we're doing details on to try to integrate a hot template guide into the user guide 20:30:30 I never did find any Dashboard docs 20:30:33 good discussion earlier about integration 20:30:42 zaneb: the dashboard is documented in the user guide 20:30:45 possibly because I am just clueless 20:31:07 zaneb: that's because you instinctively keep away from user guides 20:31:25 annegentleontheb: including the Heat part of the dashboard? 20:31:29 #link http://docs.openstack.org/user-guide/content/ 20:31:48 zaneb: you can certainly add it, that's where it goes 20:31:59 http://docs.openstack.org/user-guide/content/dashboard_stacks.html 20:32:05 it appears it is :) ^ 20:32:13 zaneb: pretty much that's organized by use case, ah there you go 20:32:35 zaneb: how are your API docs doing? I see updates so that's good 20:33:23 annegentleontheb: they're pretty good, but could use more examples 20:33:35 wow, the internetz are not in good shape today 20:33:36 zaneb: sure 20:33:46 my internetz are not, sorry. :( 20:34:05 zaneb: where do you sit w.r.t. the recent discussions around Tempest testing vs. in-project testing? I ask because there's a call out for lack of functional testing right now 20:34:05 annegentle: not you, been net splitting all day 20:34:09 and maybe longer descriptions 20:34:13 anteaya: whew. 20:34:18 looks like markmcclain and dhellmann are sharing your wifi hotspot 20:34:49 * dhellmann bypassed his bouncer when everyone else started having problems 20:35:22 OK, anything else ? That makes 3 gaps so far 20:35:28 that's all I had 20:35:58 nah… I'm on a tether but the nearest cell tower is barely in range out here 20:36:01 ttx: I dont see any other gaps. just curious about their testing plans 20:36:05 zaneb: for a future meeting (not necessarily next week) you should build a wiki page with a plan to address the gap in the near future 20:36:19 ok, can do 20:36:21 models are linked from https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:36:36 Like https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage 20:36:45 only a lot shorter :) 20:37:02 whew ;) 20:37:17 * markmcclain will be happy when that list is complete 20:37:35 last week helped 20:37:40 zaneb: when the gap coverage plan is ready we'll quickly bless it at the meeting, then after each milestone we'll review progress towards completing it 20:38:10 Any other comment on that ? Or can we move to next topic ? 20:38:45 I'll take that as a NO 20:38:50 and a YES 20:38:51 zaneb: thanks! 20:39:20 pleasure! :) 20:39:26 #topic Election behavior guidelines redux 20:39:39 dhellman_ posted a new proposal after the last meeting: 20:39:46 * 2014-07-11 Election Activities (https://review.openstack.org/106557) 20:39:54 I'm fine with this one 20:40:04 but then I'm also fine with the latest versions of the others, since I think they all reach the goal of communicating expected behavior 20:40:16 so imho whichever reaches majority vote first shall be picked 20:40:37 let's go with doug's, markmc likes it 20:40:44 I don't think we need to discuss this forever, so if by the next TC meeting we can't get majority to approve on one, I propose we use regular rules (>=5 "+1" and <=4 "-1") to approve one 20:40:59 So please +1 the versions you support asap :) 20:41:33 or if you want to get a quick --amend in, now is the time to ask for it 20:42:40 eglynn does have one good comment on patch 1 on my version about clarifying how the subset of the TC overseeing the election gets involved if something happens before an election actually starts 20:42:53 I just saw it, so I don't have a good fix, yet 20:43:39 dhellmann: could that be clarified in some other doc, like https://wiki.openstack.org/wiki/Election_Officiating_Guidelines ? 20:43:40 6 +1's already :) 20:43:54 ttx: sure, that's a good way to handle it 20:44:16 ttx: should I reword to refer to that doc, or is a comment enough? 20:44:39 * ttx reads the comment 20:44:55 dhellmann: ttx: do you expect the election officials to report it to the ED or not? 20:45:08 * annegentle looking at line 54 20:45:16 I can comment inline too 20:45:32 annegentle: keep reading :) 20:45:35 2 paragraphs later 20:45:36 annegentle: only in extreme cases (line 67) 20:45:55 and then only if the active TC members decide that is necessary 20:46:03 dhellmann: ok... not sure I am +1 on that, seems like we are trying to protect "our own" (one possible perception) 20:46:20 dhellmann: but yours does seem the most close to what we want 20:46:22 annegentle: do don't forget that someone feels that we are 20:46:25 the point is to have a way to say "hey, knock it off" without having it go on someone's permanent record 20:46:25 i just read it as likely unnecessary 20:46:26 actually I see it as a spectrum 20:46:30 dhellmann: I think it's pretty obvious that the TC is involved, except the TC members that happen to run for said election 20:46:30 they always have the community right to report directly 20:46:31 first stop is tc 20:46:51 markmcclain: true, fair enough 20:46:54 dhellmann: you could imagine a PTL election where a TC member is running 20:47:32 dhellmann: for such case, I'd expect all the TC members that are not running on that election to be involved in resolving issues 20:47:36 pretty sure "extreme" will vary widely in definition 20:47:39 ttx: good point 20:47:45 dhellmann, annegentle: how about "in the case of an alleged violation of the Community Code of Conduct" rather than "In an especially extreme case"? 20:48:07 annegentle: I'm also trying to indicate that I trust the future elected group to decide what that is, but that it should not be the way we handle things by default 20:48:15 zaneb: if that's the intent... extreme could mean "wide reaching" or "got to the press" 20:48:25 annegentle: and of course, as anteaya has pointed out, there's nothing preventing any foundation member from reporting to the ED directly 20:48:38 if they feel the election officials or TC aren't doing their jobs properly 20:48:42 dhellmann: so I guess that could use a clarification that doesn't talk about "active members of the TC" but rather "members of the TC that are not candidates in the election involved" 20:48:53 dhellmann: yeah I still sense the ED should take the brunt of investigation I guess, rather than TC, since we're so close to it 20:48:54 zaneb: my $0.02 ... s/violation/infringement/ (the former is a little loaded) 20:49:05 zaneb: I don't want to imply that every report is going to the ED 20:49:22 ttx: ok, I can add that 20:49:37 annegentle: we should be mostly self-sufficient though, as long as the CCoC is not invoked 20:49:48 annegentle: in previous meetings we've talked about the community dealing with its own issues, without bringing the foundation into every little discussion 20:49:58 dhellmann: fair enough. after years of reading RFCs the difference between MAY and MUST is quite clear in my mind, maybe more so than in the general population ;) 20:50:05 ttx: ok, that's true, and the electorate should be comfortable reaching out to at least one TC member 20:50:22 and I agree with dhellmann that the CCoC/ED can always be involved in case that doesn't work 20:50:23 dhellmann: ok 20:50:31 zaneb: fair point 20:50:58 so let me make sure I know what wording needs to change... 20:51:09 ok I can vote +1 after extreme is reworded 20:51:17 is it just clarifying that anyone involved in the election is not going to be involved? 20:51:43 or should I change the "extreme" part to just say "in some cases"? 20:52:06 or should that explicitly mention the CoC? 20:52:08 at the discretion of the consulted tc 20:52:31 I think "extreme" is the correct adjective for it 20:52:42 the TC doesn't necessarily have to be the ones to refer it to the ED 20:52:50 hmm, that sentence already uses CoC 20:53:01 the reporter could go ahead and do that even if the TC didn't feel it necessary 20:53:17 markmc: true, does it need to say that? 20:53:21 could just say it's up to the reporter to refer it? 20:53:38 oh yes, missed that 20:53:39 dunno, don't love that option either 20:53:43 markmc: +1 20:54:00 markmc: I think having something in there makes it clear that the TC can decide to refer it without asking further permission from the reporter 20:54:02 "In extreme cases, community members always have the option to refer..." 20:54:24 ttx the option exists extreme or not 20:54:26 the TC will be holding all the information though 20:54:29 zaneb: right, that was my intent -- saying what we might do, not constraining what the community can do 20:54:35 e.g. where multiple people reported the issue 20:54:37 zaneb: that would raise the stakes of reporting unnecessarily I think 20:54:54 markmc: in that case, I would expect the ED to ask the TC for details 20:54:58 yeah 20:55:02 eglynn: yeah, it's a double edged sword. but at least it makes the position clear 20:55:06 * markmc shrugs 20:55:08 "Community members always retain the option to refer..." ? 20:55:18 I don't think we need to decide up front how it would work 20:55:21 escalation, I mean 20:55:26 yeah 20:55:27 just that it can happen 20:55:28 ttx that wording it more consistent with reality, for me 20:55:38 either via the reporter or the TC 20:55:41 "Note that community members always retain the option to refer..." ? 20:55:56 dhellmann: agreed 20:56:07 the CoC has instructions for reporting violations, right? do we need to reiterate the community's rights to follow those instructions here? 20:56:21 dhellmann: I think it helps to do it yes 20:56:25 ok, I'll add that 20:56:30 people just don't know what options they have 20:56:57 if we write such a resolution, we really need to mention that option... we just need to make it a bit off-track 20:56:57 sure, that's a good point 20:57:26 "retain the option" is a good way to mention it without overly encouraging it 20:57:41 dhellmann: I agree, "retain the option" is fine 20:58:02 ok, so we should have a new patchset for this one, but let's try to get it adopted -- I'm getting tired of nitpicking it to death 20:58:15 #topic Pending governance changes 20:58:21 * Adding Horizon mission statement (https://review.openstack.org/102050) 20:58:33 This one is still short of one "+1" before reaching majority voting 20:58:42 * Add translation support requirement (https://review.openstack.org/97872) 20:58:45 I propose we WIP this one until tests are implemented. 20:58:46 +1 20:58:47 ttx, yeah, agree on tired of this - feels like rough consensus, and the details now don't matter so much 20:59:03 (it's a requirements change and those can only reflect consensual rules) 20:59:18 let me know if that works for you 20:59:23 #topic Open discussion 20:59:32 "K" release naming poll still going at https://www.surveymonkey.com/s/openstack-k-naming 20:59:38 Results shall be announced early Thursday 20:59:47 Who is at OSCON next week? 20:59:53 new draft of https://review.openstack.org/#/c/106557 is up 20:59:54 I'll be there fri-sun 20:59:56 Should we skip next week meeting ? 21:00:03 I'm at OSCON tuesday and wednesday 21:00:07 then at the tripleo meetup mon-thu 21:00:20 morded and I are giving a talk starting 40 minutes into the TC meeting 21:00:27 unclear whether we'll make the meeting 21:00:39 also, 2 weeks after that I'm on vacation so missing the meetings 21:00:40 I'm fine with skipping it 21:00:41 apols for that 21:00:46 wfm 21:00:48 since I have no idea where I'll be 21:00:52 also it's j2 week 21:00:54 Sounds like we should skip it 21:00:54 not at oscon 21:01:13 probably skip, yeah 21:01:16 + skip 21:01:16 so the meeting after that we'll have the post-j2 gap coverage progress 21:01:19 skip fine with me since so many folks are out 21:01:22 +skip 21:01:36 and then the meetign after that we'll have the Swift gap analysis 21:01:54 Looks like we might complete that this cycle after all 21:02:13 OK, i'll propose we skip next week 21:02:13 https://etherpad.openstack.org/p/swift_gap_analysis 21:02:18 Thanks everyone 21:02:25 #endmeeting