20:02:41 #startmeeting tc 20:02:41 Meeting started Tue May 20 20:02: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:02:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:44 The meeting name has been set to 'tc' 20:02:52 Here is our agenda for today: 20:03:02 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:03:07 david-lyle: around? 20:03:14 ttx: o/ 20:03:19 #topic Integrated projects and new requirements: Gap analysis for Horizon 20:03:31 david-lyle prepared a gap analysis: 20:03:37 #link https://etherpad.openstack.org/p/horizon-gap-analysis 20:03:57 I picked Horizon on short notice, as i don't expect it to raise major issues 20:04:08 * mordred giggles 20:04:22 o/ 20:05:18 but stil a few interesting things in there 20:05:34 so the note about "Split of repo planned into toolkit and django application." is nice because it's one of the things that makes horizon difficult to deal with from an infra pov (having 2 projects in 1 repo requires special one-off tooling) 20:05:34 #info Scope needs to be documented 20:05:40 Actually horizon still needs a mission statement right? 20:05:56 annegentle_: yes 20:06:05 #info Major architectural change planned: split of repo into toolkit and django app 20:06:45 the repo essentially already contains two distinct pieces in one place 20:06:54 for those of us less familiar with horizon code base, what's the toolkit contain roughly? 20:06:56 this is more a formalization of that split 20:07:30 david-lyle: timeframe around that split? 20:07:47 the toolkit is the widgets and framework for the dashboards, panels, tables, etc 20:07:47 #info Refresh of horizon-coresec needed 20:07:48 Also, django apparently necessitates non-standard translation tooling 20:08:09 That's all I spotted from the doc... TC members, feel free to add more #info 20:08:14 the openstack_dashboard component is the actual django application that implements the toolkit 20:08:42 jeblair: I don't have admin on that, missed in transition 20:08:55 #info Nice-to-have: listing of API calls not available in GUI per service 20:08:57 jaypipes: juno-1 to juno-2 20:09:19 we've been planning it since the icehouse summit, but got delayed 20:09:20 david-lyle: is horizon tested in the gate, does that make even sense ? Or is selenium/unittesting considered enough due to the consumer position ? 20:09:26 david-lyle: I'd also like to see a statement in your scope about the addition timing of integrated projects 20:09:50 david-lyle: k, thx 20:10:06 ttx: Horizon has one tempest job, that is a selenium test that tests login 20:10:15 david-lyle: ok 20:10:23 other than that it's purely unit test and selenium 20:10:41 ack 20:10:50 beyond that we have started building an integration test framework and can run against devstack 20:11:35 we want to grow the test suite there and maybe eventually tie it into the gate, as we are uniquely positioned to insure non-breaking changes in the python-*clients 20:11:45 * mordred is in support of that 20:11:55 ++ 20:12:03 that is - of "ensure non-breaking changes in python-*clients" 20:12:10 mordred: but would you consider that a "gap" ? 20:12:22 that obviously requires some work with infra once we have a better test suite 20:12:25 ++ to integration test framework 20:12:47 yes. the level to which we've tested horizon thusfar I think is less than any of us are happy about 20:12:55 but it seems the plans moving forward are good ones 20:13:19 david-lyle: uniquely? ;) 20:13:22 #info Integration test framework tied to gate 20:13:34 david-lyle: while we're on testing - has anyone done any thinking about testr and horizon? 20:13:52 OK, any other gap ? 20:13:53 zaneb: maybe not as uniquely as we used to be, apologies 20:13:54 last time I looked in to it, I gave up and deferred to later 20:14:14 david-lyle: no worries, I'm just kidding :) 20:14:18 david-lyle: i see the call out for docs on the developer site. what about in openstack-manuals? 20:14:48 mordred, we looked into it briefly, there was some issues with nose, but that was early last cycle, we could revisit 20:14:48 heat has it's own issues with tempest coverage 20:15:03 zaneb: talking about which... 20:15:18 Would you be up for next week ? :) 20:15:18 david-lyle: it's not urgent yet - main thing is we _want_ to do some subunit processing in the gate itself, so want to make sure we don't have blocker projects if we get to that point 20:15:46 devananda: david-lyle: for integration, those are the minimum docs... for a core project also install/config docs (which are in openstack-manuals) 20:16:02 david-lyle: OK, I think we have all gaps documented in #info in the logs 20:16:09 +1 to subunit 20:16:14 mordred, we'll look again 20:16:18 annegentle_: that's what I thought, but I dont see any mention of those in the etherpad 20:16:25 david-lyle: would be good to have a coverage plan -- how you plan to address those in the future 20:16:33 devananda: yep, because those docs aren't listed as a requirement in this gap analysis 20:16:39 ah 20:16:43 david-lyle: could you prepare one for next week ? 20:16:57 ttx: you might have to twist my arm ;) 20:17:29 ttx: code coverage? 20:17:41 david-lyle: no, gap coverage 20:17:49 david-lyle: I listed gaps in #info in the meeting logs 20:17:54 ttx: sure 20:18:01 david-lyle: would be good to have a clear action plan on addressing those 20:18:13 See https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage for an example 20:18:39 TC members: any other remark on that topic ? Other gaps ? 20:18:41 absolutely 20:19:06 my favorite line "Dashboard would be circular and thus frowned upon." 20:19:41 ttx: did you note the non-standard tooling due to combined projects as a gap? 20:20:03 jeblair: nope, be my guest :) 20:20:37 #info Non-standard test/packaging/translation tooling due to combined projects in one repo 20:20:50 OK, if that is all, let's move to next topic 20:20:55 david-lyle: thanks! 20:21:09 thanks david-lyle! 20:21:23 my pleasure 20:21:23 Agreed, thanks for coming along 20:21:32 o/ 20:21:34 on very short notice 20:21:39 #topic Defcore update: Scoring the Havana capabilities 20:21:53 zehicle_at_dell: floor is temporarily yours 20:21:56 The board approved the 12 scoring critieria in the last meeting 20:22:08 and that let us post the advisory Havana score card 20:22:19 BUT it's got gaps and requests for TC input all over the place 20:22:31 so I was hoping to work with you to fill in the gaps 20:22:47 it's likely 2-4 hours of interactive work 20:22:48 zehicle_at_dell: link? 20:23:06 #link https://wiki.openstack.org/wiki/Governance/CoreCriteria 20:23:27 zehicle_at_dell: what's the deadline? 20:23:32 #link http://robhirschfeld.com/2014/05/08/defcore-scorecard/ 20:23:37 OSCON 20:23:51 we'd like to have the board adopt the Havana sc ore card at OSCON 20:24:02 it's ADVISORY for Havana 20:24:21 but it's sets a trendline for the next I & J 20:24:33 zehicle_at_dell: so you need input on all the 0.5 in TC direction @ https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf ? Or more ? 20:24:34 and we're still trying to complete those by Paris 20:24:42 ttx, yes 20:24:51 and also filling in the gaps 20:25:03 gap = red lines ? 20:25:05 which will then raise the question of % of designated code in Swift 20:25:08 yes 20:25:14 zehicle_at_dell: so July 20th or earlier than that to allow for formatting? 20:25:18 ttx, the unscored ones in the center 20:25:26 annegentle_, yes 20:25:34 we could work on formatting earlier 20:25:34 zehicle_at_dell: which? 20:25:40 zehicle_at_dell: I think for the red lines it would be good to get the PTL input first 20:25:42 zehicle_at_dell: July 15? 20:25:55 TC can help with the 0.5 cells 20:26:00 annegentle_, sorry. yes 7/15. 20:26:07 ttx: which PTL? The Havan PTL of the current one? 20:26:08 annegentle_, we can get the formatting done in parallel 20:26:17 PTLs affectd by red lines are notmyname, jgriffith and mikal 20:26:28 I'd say current one 20:26:29 #link https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf 20:26:29 ttx, yes. would be good to ahve the relevant PTLs 20:26:47 we are getting help from John D on Swift capabilities grouping too 20:26:52 zehicle_at_dell: if they fail to provide input we can help fill, but that seems like the logical first step 20:27:01 ideally, PTLs would also help on cabilities groups, but that's another topic 20:27:15 #info Request from board for TC input on the red rows in https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf by July 15th 20:27:15 ttx, agree. was hoping to have TC formalize the request 20:27:30 zehicle_at_dell: so I suggest we take those 0.5 home as homework for the week, and come up with proposals for next week meeting 20:27:32 zehicle_at_dell: how should the input come back? 20:27:40 +1 20:27:42 zehicle_at_dell: in the mean time I'll forward your request on red lines to affected PTLs 20:27:49 thanks! 20:27:50 ttx: I don't see 0.5? where is that? 20:27:57 the yellow cells 20:28:03 zehicle_at_dell: ah got it 20:28:05 zehicle_at_dell: is every project integrated in havana included in that matrix? 20:28:07 annegentle_: 0.5 cells in Future Tc direction column 20:28:12 #link http://robhirschfeld.com/2014/05/09/openstack-defcore-matrix-cheet-sheet/ 20:28:21 I made a cheat sheet to help understand the grid 20:28:22 zehicle_at_dell: as in, you don't know if the 0.5 is accurate unless you ask more people? 20:28:29 would accept help in formatting to make it easier to understand 20:28:36 zehicle_at_dell: (I see orch-stacks for heat, but nothing obvious for ceilometer) 20:28:39 annegentle_, there should be no .5s. those are place holders 20:28:48 #action TC members to look at 0.5 cells in "future TC direction" column in http://robhirschfeld.com/2014/05/09/openstack-defcore-matrix-cheet-sheet/ and prepare proposed score for next meeting 20:28:52 eglynn, we can only score items with tests 20:28:57 zehicle_at_dell: ok 20:29:03 so no tests = no capabililites 20:29:20 #action ttx to reach to affected PTLs for red lines at https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf 20:29:23 annegentle_, would be good to have a new perspective to help explain it. I'm way too close to the material 20:29:35 zehicle_at_dell: how old is the list of tests, just out of curiosity? 20:29:41 zehicle_at_dell: I'm good at asking dumb questions :) 20:29:46 #action ttx to schedule gap coverage plan approval for Horizon for next meeting 20:29:49 zehicle_at_dell: based on Tempest coverage? 20:29:55 * zaneb was pretty sure we had more than one ;) 20:29:59 eglynn, yes 20:30:06 zaneb: not in havana :) 20:30:07 zehicle_at_dell: btw - have you guys been tracking branchless-tempest? 20:30:23 mordred, yes!!! we are planning to move to that 20:30:36 great. it's just a thing that would clearly affect you :) 20:30:40 there was lots of refstack<->tempest discussion on that topic at the summit 20:30:41 mordred, even for Havana and just suck up that there's some slop 20:30:45 hmm fixing action link 20:30:45 sdague: oh, Havana was not the one we just released :) 20:30:54 too many releases 20:31:00 zehicle_at_dell: have you guys started looking at the differential with branchless at icehouse and havana tempest? 20:31:03 #action TC members to look at 0.5 cells in "future TC direction" column in https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf and prepare proposed score for next meeting 20:31:08 because the overall test count did double 20:31:24 and I'm curious how much of the analysis is going to need to rev after those new functional areas come in 20:31:32 sdague, yes but I think thats OT for here 20:31:48 zehicle_at_dell: another dumb question, why concentrate on Havana as opposed to Icehouse? 20:32:20 eglynn, so people can digest the impact 20:32:27 * eglynn asks as the first ceilometer tempest coverage dates from the Icehouse cycle 20:32:41 eglynn: gives deployers some time to test and then act/iterate 20:32:45 eglynn, this needs time to settle and get feedback - it will change commercial products 20:32:52 annegentle_, +1 20:33:19 eglynn, turning the ship...slowly 20:33:49 zehicle_at_dell: OK, I think we have an action plan here 20:33:56 zehicle_at_dell: anything else ? 20:33:59 no 20:34:00 zehicle_at_dell: fair enough, though /me is eager for the lack of tempest coverage for ceilo in Havana not to exclude ceilo completely from the analysis 20:34:25 ... just sayin' 20:34:26 eglynn: is your question aimed at whether ceilometer will be considered for core capability? 20:34:33 annegentle_: yep 20:34:41 eglynn, putting pressure on community to add tests is part of the objective 20:34:57 eglynn, pressure on the commercial interests that pay people 20:34:59 zehicle_at_dell: perhaps the question is how often do we expect this analysis to be revised? 20:35:07 zaneb, every release 20:35:12 ok 20:35:16 eglynn: is there a subset of ceilo api that is user facing? 20:35:20 zehicle_at_dell: k, got it ... we plan to expand this further over Juno 20:35:22 but with a 6 month lag? 20:35:28 eglynn, zaneb: feel free to continue discussion with zehicle off-meeting 20:35:38 sure 20:35:41 vishy: the API is in a sense, consumed by the metering dashboard for example 20:35:46 ttx: roger that! 20:35:48 zaneb, no. we want to be zero day. We are trying to get to 0. will hopefully be there for K if not J 20:35:55 ok, cool :) 20:36:11 #topic New requirements 20:36:19 eglynn: seems like the surface is pretty small for users. Mostly used by admins operators 20:36:19 * add upgrade expectations (https://review.openstack.org/87234) 20:36:30 vishy: fair point 20:36:32 thanks everyone!' 20:36:39 zehicle_at_dell: thank you sir! 20:36:45 This one could need another +1. There was a comment from lifeless tat was a -1 but he left the TC 20:36:53 zehicle_at_dell: thx! 20:37:08 ttx: I think lifeless and I are actually at violent agreement on the idea, it was a language clarity question 20:37:12 so now it's a random comment, but his question should still be adressed 20:37:18 ok 20:37:24 so basically I'd see if people find his language or mine more clear 20:37:31 and I'll propose with whatever people believe 20:37:47 ok, so all make a last pass on this one, will approve if it gets 7 +1s 20:37:49 I think mine wasn't legally sealed, but I think less confusing 20:37:53 sdague: agreed 20:38:02 or more exactly..; if it still has 7 +1s by tomorrow :) 20:38:06 For upgrade expectations, did anyone address the "from first integrated release" expectation? 20:38:37 don't want to -1 unless I'm missing something 20:38:44 sdague, lifeless: I actually think both of you are wrong 20:38:47 annegentle_: good point 20:38:50 yay! 20:38:59 mordred: ok, alternate wording? 20:39:01 mordred: yay!. 20:39:24 ok -1 from me 20:39:27 on the "from any arbitrary point..." line, perhaps some wording that this doesn't imply a direct upgrade - which seems to be the point lifeless' comment is making 20:39:43 sdague: will work on it - I thnk you're closest 20:40:07 mordred: ok. I think the intent between all of us is clear, but would be best to make it easy to understand by new projects 20:40:08 annegentle_: my reading is that "stable release" means integarted, but yes, more precision could help 20:40:15 so they don't get surprised 20:40:29 hmmm… technically the item has passed 20:40:31 I do think calling out "after initial integrated release" is fair point to make clear 20:40:39 OK, so this needs a few more iterations 20:40:43 sdague: perhaps we should enumerate what we expect to be testable 20:40:43 do we need folks to switch their +1s to 0/-1? 20:40:46 sdague: +1 20:40:52 markmcclain: well, sdague hasn't formally cast his vote :) 20:41:04 ttx: I vote on my own proposals? 20:41:11 * markmcclain counts again 20:41:13 sdague: it's a grey area. 20:41:17 because we dont' do anything with 'arbitrary' points in time - and if it's not tested, it's broken 20:41:28 i usually count the proposer in favor, yes 20:41:28 7 for -1 against 20:41:33 mordred: fair, I was trying to capture the spirit of the CD case 20:41:36 sdague: yah 20:41:39 * mordred may be wrong 20:41:40 because we don't test it 20:41:49 but we do call people out on it 20:41:55 like when they reorder db migrations 20:42:01 good point 20:42:04 markmcclain: oh, someone just added a +1 20:42:16 sdague: maybe we should figure out how to test for that ... 20:42:35 I do think clarification is needed just wondering what the procedure is in this case… I assume voting it still open so folks can their positions 20:42:37 maybe not in this meeting 20:42:40 mordred: probably, though I doubt it will be this cycle 20:42:55 markmcclain: anyway, I only fasttrack approvals when there are 7 +1s and no objection. Everything else requires a 'final vote' to be called after two meetings of non consensus 20:43:13 ttx: ah good to know 20:43:16 markmcclain: agree that proposer can vote on his own 20:43:30 I usually count proposer as a +1, but we could be more formal 20:43:32 so lets do this. annegentle_'s point is something we should fix, will do. I'm open to clearer language if someone proposes it. 20:43:52 ok, let's give it another week then 20:43:55 ++ 20:43:57 * Add Ceilometer requirements (https://review.openstack.org/85978) 20:43:59 sdague: so shall I patch this one with different wording? 20:44:00 I can honestly go less "legally", and more example oriented 20:44:18 annegentle_: sure, or leave a comment with the proposed wording 20:44:35 This one is pretty stuck 20:44:59 Not sure if we should ping proposer, vote -1 to remove it or just let it auto-abandon 20:45:13 yeah seems no prospect of agreement on current version, shall I punt it back to jd for another round of wordsmithing? 20:45:45 eglynn: if it's still in same shape next week I'll probably cahse down -1s so that we kill it 20:45:46 ttx: oh we don't auto-abandon anymore; do you have an abandon button? 20:45:59 ttx: k, understood 20:46:05 jeblair: we haven't set rules for such cases yet 20:46:14 jeblair: I'm fine with the ultimatum I just gave 20:46:39 i.e. give it another week, and kill it softly with a pack of -1s if it's still around 20:46:41 ttx: yeah, though i'm specifically asking if you personally have an abandon button in gerrit on the governance repo. :) 20:46:45 mordred: +1 on enumerating things that should work. 20:46:49 mordred: and things that shouldn't.[6~ 20:46:54 jeblair: yes I do 20:46:57 cool 20:47:24 #info If that one is not improved by next week, it will probably be abandoned 20:47:31 #topic Minor governance changes 20:47:36 * Render member list in HTML output (https://review.openstack.org/91450) 20:48:36 I guess I can approve that one as non-policy 20:48:47 ttx: ^^ do we need full TC vote on patches like that? non-policy patches seem like something that 2 positive votes should be good on 20:48:49 unless someone complains rreally soon 20:49:01 mordred; yep 20:49:06 do the docs build now? if so, we should start gating 20:49:09 #info will approve tomorrow unless someone -1s 20:49:17 * Update sphinx doc formatting and toctrees (https://review.openstack.org/91422) 20:49:22 Same for this one 20:49:27 jeblair: ++ 20:49:30 I think two +2s should work for non-policy 20:49:43 #info will approve tomorrow unless someone -1s 20:49:57 * Add project mission statement for Ceilometer (https://review.openstack.org/87526) 20:50:08 (should we pep8 the python in the governance repo?) 20:50:10 * mordred hides 20:50:20 I think that one just needs a few more +1s 20:50:55 I prefer to have one in and have people suggest better words afterwards 20:51:03 i think we gave ttx blanket non-policy rights (eg, i don't think he needs even 2 +2s, but can wait for them at his discretion) 20:51:21 #info Will approve whenever it reaches 7 +1s 20:51:29 jeblair: ok 20:52:00 jeblair: for those one I wanted to make sure this use of the governance repo was ok with everyone 20:52:07 but I think they are 20:52:19 * Add oslo.db to the Oslo program (https://review.openstack.org/90127) 20:52:35 This one depends on: 20:52:41 * add oslo.i18n to Oslo program (https://review.openstack.org/92429) 20:53:12 Both are approved by PTL 20:53:24 no objection... OK if I approve them now ? 20:53:43 ttx: yeah go ahead 20:53:59 I may trigger a few rebasees but hey, that's life 20:54:18 do it 20:54:21 ttx: +1 20:55:17 ok done 20:55:19 for both 20:55:32 #topic Open discussion 20:55:37 o/ 20:55:44 anteaya: go for it 20:55:47 thanks 20:56:05 so I just want folks to know that soon I want to talk about some election stuff 20:56:21 one item is do we have the right criteria for the electorate? 20:56:35 the ptl elections seem to be healthy with at least 43% voting 20:56:38 ttx: I have a q next 20:56:45 I hope I'll have my analysis of TC election ready soon, so that we can revisit the "proportional" option 20:56:47 the tc election needs some evaluation 20:56:59 we had 29.7% participation 20:57:13 I think we need a better % of participation 20:57:13 Do we think that people had election fatigue at that point? 20:57:18 so that is coming up 20:57:23 Many people had probably voted in several elections by then 20:57:24 no, I don't percieve fatigue 20:57:29 I percieve long tail 20:57:39 anteaya: do we have comparisons to past TC elections? 20:57:39 anteaya: I think it's a good topic. Ideally we would raise it on openstack-dev first to gather more input 20:57:40 450 electorate for nova 20:57:47 1500 electorate for tc 20:57:50 like for all resolutions 20:58:08 yes, so just by way of heads up, I would like to have this discussion 20:58:12 sdague: it was around 30% last time as well 20:58:20 I will get numbers and comparisons as they are requested 20:58:32 anteaya: ok, thxc for heads-up 20:58:33 annegentle_: go for your question 20:58:36 the second item dealing with elections is campagn messageing 20:58:44 * mordred has been thinking about revisiting the 1-vote==ATC criteria 20:58:46 we don't have any and I think we should ahve some 20:58:49 okay done 20:58:51 anteaya: ack 20:58:52 do we need to elect a tc chair? Or did we and I forgot it already? 20:59:05 mordred: yes, we may want to revisit that, but I wonder if bylwas let us do that 20:59:06 annegentle_: we did it already 20:59:16 ttx: I think it's in our charter, no? 20:59:22 sdague: ha I missed it 20:59:28 annegentle_: https://review.openstack.org/#/c/92461/ 20:59:35 mordred: I'll have to check how much we are constrained by the ATC definition in the bylways 20:59:43 ttx: we all think the foundation is crazy for having too-lax membership qualifications, so it seems like if we're having low voter turnout ... 20:59:49 which lives in some appendix 20:59:59 then perhaps we should address qualifications for being part of the electorate 21:00:03 annegentle_: was last meeting 21:00:12 since we have, you know, math at our disposal and are not afraid to use it 21:00:23 * jeblair is a little afraid of math 21:00:33 behold the power of math 21:00:33 mordred: if the uninformed voters are self-selecting out anyway... is there a need? 21:00:52 zaneb: quorum becomes a possible issue with low turnout 21:00:54 ok, time is up 21:01:12 thanks everyone! 21:01:18 markmcclain: for the foundation yes; I don't think there is a quorum for TC elections though 21:01:19 :) 21:01:20 zaneb: quoruum 21:01:44 #action ttx to check how much control we have on electorate definition for the Technical Committee 21:01:44 zaneb: it plays a role in the effectiveness of any election 21:01:52 #endmeeting