20:03:04 #startmeeting tc 20:03:05 Meeting started Tue May 27 20:03:04 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:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:07 o/ 20:03:08 The meeting name has been set to 'tc' 20:03:09 Morning 20:03:18 Here is our agenda for today: 20:03:22 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:03:32 david-lyle: around? 20:03:35 o/ 20:03:38 #topic Integrated projects and new requirements: Gap coverage plan for Horizon 20:03:44 Last week we did a gap analysis for Horizon 20:03:49 #link https://etherpad.openstack.org/p/horizon-gap-analysis 20:03:54 A number of gaps were identified: 20:03:59 * Scope needs to be documented 20:04:03 * Refresh of horizon-coresec needed 20:04:08 * Integration test framework tied to gate 20:04:13 * Non-standard test/packaging/translation tooling due to combined projects in one repo 20:04:20 Two non-blocking remarks were made: 20:04:27 * A major architectural change is planned (split of repo into toolkit and django app) 20:04:32 * Would be nice to have a listing of API calls not available in GUI per service 20:04:38 david-lyle: Do you have a plan to address the gaps in the near future ? 20:04:41 https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Horizon_Gap_Coverage 20:04:56 missed the non-standard tooling item 20:05:03 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Horizon_Gap_Coverage 20:05:11 will have to amend 20:05:26 well, in the last meeting rdopiera came to talk about splitting the horizon repo 20:05:45 o/ 20:06:22 david-lyle: plan looks good to me 20:06:22 so i'm optimistic that will get better soon, though it doesn't necessarily follow that everything will become more standard 20:06:28 nicely done david-lyle 20:06:46 Any objection on the proposed plan ? 20:07:06 david-lyle: where will you document the gaps? 20:07:13 jeblair: there is a larger issue in the community regarding nodejs 20:07:23 ttx: lgtm 20:07:46 annegentle: good question, likely on w.o.o 20:08:31 I think it's too transient to put anywhere in the code base 20:08:52 what is "Exhaustive list of API calls not supported"? Is that calls into other projects that horizon doesn't use anywhere? 20:09:04 #info Gap coverage plan looks sane, will review for progress after milestones 20:09:16 david-lyle: sounds good to me, was going to suggest wiki 20:09:49 dhellmann, the goal is find areas where Horizon doesn't match features exposed by the CLI 20:10:04 that is a common complaint against Horizon 20:10:29 Anything else on that topic ? 20:10:33 ok, maybe consider rephrasing that gap in the way you just said it because it wasn't obvious what was meant by the current wording 20:11:00 we're hoping to fill those gaps, so users aren't forced to switch to CLI to accomplish certain tasks 20:11:05 dhellmann: sure 20:11:28 david-lyle: I'd also suggest maybe breaking out into subsets for each project 20:11:30 otherwise it all looks good 20:11:43 OK then, let's move on to next topic 20:11:51 david-lyle: many thanks! 20:11:52 markmcclain: yes 20:11:58 zehicle_at_dell: around? 20:12:20 o/ 20:12:23 #topic "TC direction" 0.5 scores refinement on Defcore scoring page 20:12:34 #link https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf 20:13:02 So we wanted to double-check the scoring on that page, especially the "TC direction" column and those 0.5 scores 20:13:07 DefCore meeting last week also wanted to get TC input on how to handle scoring going into the future 20:13:11 zehicle_at_dell: FWIW I formally contacted the PTLs to help on those unscored lines 20:13:14 that's likely a dedicated meeting topic 20:13:20 ttx, thanks 20:13:22 zehicle_at_dell: yes 20:13:30 let me know how we can help. I'll make myself available 20:13:50 I looked at the current scores in htat column and they make sense to me 20:13:56 We're making a point of finding a good time for mikal at the next meeting 20:13:57 Anyone would like to suggest different scores for any of those ? 20:14:18 zehicle_at_dell: I haven't gotten around to that yet, but I think I'll want to sit down with you to work through the nova ones some time in the next week 20:14:30 zehicle_at_dell: I will also reply to the meeting time email today 20:14:43 ttx, was wondering how the TC wanted to collect feedback about scores that need discussion. was thinking gerrit like process 20:14:54 but happy to do it more interactive if that's the preference 20:15:20 zehicle_at_dell: trying to determine how much we need to tweak them 20:15:38 zehicle_at_dell: I should know this, but how can I get a deeper description of a capability, such as compute-auth? 20:15:45 zehicle_at_dell: in tempest itself? 20:15:47 ttx, we starting thinking ahead into the Icehouse & Juno reviews. Assuming that we start from Havana and then need to discuss line by line 20:15:59 definitely would be good to have a way of tracking the discussion that went into any particular score 20:16:05 but it is looking fairly reasonable to me 20:16:17 #link https://github.com/stackforge/refstack/tree/master/defcore/havana 20:16:31 I think we can do hte havana one interactively but yes, some more gerrit-driven approach would sclae better for future occurences 20:16:33 annegentle, we want to add more detail to the capability json file 20:17:00 ttx, +1 on that. would like to get a discussion about that on a future TC agenda then 20:17:15 hopefully, next releases are just deltas 20:17:19 annegentle: the answer *should* be in tempest itself, however our docs aren't what they should be either. 20:17:32 annegentle: so it would mostly involve reading code at this point 20:17:49 sdague, that's why we need to roll up into capabilities 20:17:59 #action ttx to schedlue discussion on future scoring process at a future TC meeting 20:18:05 even getting short descriptions into that capabilities.json would be a great step for users 20:18:15 zehicle_at_dell: yep. We also talked a lot about new doc standards in tempest that would go a long way here 20:18:34 zehicle_at_dell: looks like the current scoring is good enough. That only leaves the unscored lines 20:18:36 honestly, random folks using tempest need this info too, so I'd love to get it baked back i nthere 20:18:44 ++ 20:18:49 sdague, +1 20:19:04 zehicle_at_dell: for the unscored lines you should try to extract data frmo PTLs first 20:19:15 zehicle_at_dell: we can get involved if that process gets stuck, I guess 20:19:34 ttx, yes. was going that route. was hoping to collaborate on it w/ TCs 20:19:35 totally happy to do it in a way that would make it easily / machine extractable for defcore 20:19:39 zehicle_at_dell: did any of the PTLs conact you yet ? 20:19:45 zehicle_at_dell, mapping to tempest tests here: https://github.com/stackforge/refstack/blob/master/defcore/havana/capabilities.json 20:19:46 Swift 20:19:51 sorry, that was for annegentle 20:19:59 notmyname, has been pretty engaged 20:20:18 zehicle_at_dell: I suspect mikal will engage at the next meeting if he can make it 20:20:26 (which brings up the other topics we need help with - designated sections) mikal is working with us on that 20:20:26 zehicle_at_dell: that leaves jgriffith 20:20:40 Yes, mikal feels guilt about this and means to get to it ASAP 20:20:50 yes, jgriffith (thinking @notmyname twitter) 20:21:20 mikal, I'm working on a blog about designated sections. Would be happy to co-author with you. I'll send you a link 20:21:51 zehicle_at_dell: cool, let's talk about it in email 20:21:57 zehicle_at_dell: looks like those 0.5 scores actually reflect reality after all 20:22:01 thanks markmc zehicle_at_dell 20:22:08 zehicle_at_dell: anything more you need at this point ? 20:22:34 timeframe? 20:22:43 I'd like everyone on board w/ timing 20:23:02 since we'd like to have the advisory Havana list compelete for community review by 7/4 20:23:11 so that we can have the board approve it at the OSCON meeting 20:23:34 that means all the .5s, the missing sections and (ideally) designated code for the impacted projects 20:24:13 ttx: zehicle_at_dell I can help with the Cinder sections, but had some q's for zehicle_at_dell 20:24:16 zehicle_at_dell: you mean we shouldn't leave any 0.5 ? I think they were acceptable scores ? 20:24:20 maybe after the meeting? 20:24:29 jgriffith: yes 20:24:41 ttx, we were trying to make it binary for now 20:25:00 ttx, AIUI 0.5 == FIXME :) 20:25:01 zehicle_at_dell: ah! sorry, totally missed that. 20:25:05 we were using .5 as a place holder for revuew needed. yes 20:25:24 Hmm, then I think we'll have to come up with a formal proposal 20:25:29 and Gerrit it 20:25:47 any TC member up for drafting a binary proposal for the TC direction column ? 20:25:49 ttx, we have the tests in gerrit now 20:25:59 I could add the scores to that json file and then let them go under review 20:26:14 that's not a process, just the doc 20:26:18 I would do it if I weren't traveling all week 20:26:32 but it would let you address individual scores per test/capability 20:26:59 zehicle_at_dell: let's try to make a proper TC resolution on that 20:27:16 ttx: I can do it 20:27:25 mordred: cool, thx 20:27:35 +1 20:27:44 #action mordred to draft binary proposal for the "TC direction" column scores 20:28:06 happy to have a smaller or 1x1 meeting about it. we spent some time in DefCore talking about exactly that 20:28:08 ttx: for completeness, I think it should be the whole column, yeah? 20:28:13 zehicle_at_dell: then for the missing lines, if you don't get what you need frmo PTLs we can escalate to TC mid-June so that you're still on time for OSCON 20:28:19 mordred: indeed 20:28:26 thanks. yes 20:28:43 Anything more on that topic ? 20:29:04 are we assuming that once they are defined in https://github.com/stackforge/refstack/blob/master/defcore/havana/capabilities.json a given capability's definition won't change? 20:29:04 mordred, yes. since any change to the row can impact the whole score. it's a single unit for review 20:29:31 dhellman_, release by release they will likely change 20:29:54 small source of confusion > we're using capabilities as proxies for the tests right now. in next releases, we really should consider the tests 20:30:10 because a capability _may_ have some that are not required yet 20:30:22 it was just too much work to do it from the bottom up 20:30:29 so capabilities were a good compromise 20:30:32 sure 20:31:07 I'm just trying to reconcile the idea the the TC is going to vote on a definition of "compute-volume" and that definition will be changing later in a repo where we don't get a re-vote 20:31:21 zehicle_at_dell: so in an ideal world, is there a capability level grouping in tempest that we are missing? I sort of thought the capabilities here mapped to tempest directories, but now I'm not quite so sure 20:31:37 sdague, yes. Ideally, it would be managed there 20:32:17 zehicle_at_dell: ok, so if there is feedback on restructures to make that clearer in the tempest, that would be appreciated. I think that team would be receptive to it. 20:32:20 mainly we did not expect DefCore to take long term ownership of that. it was needed to move forward this cycle 20:32:24 dhellman_: we get to revote at each release actually 20:32:45 zehicle_at_dell: yep, all good. Just want to use the feedback to make things better for everyone. 20:32:54 I think users would appreciate a consistent capabilities set even if we change some of the tests inside them 20:33:05 ttx: ok 20:33:27 +1000 20:33:29 ok, I think we can move on 20:33:36 zehicle_at_dell: agreed. And I think it's a good way of "consuming" the information out of tempest, which has become pretty vast 20:33:36 +1 20:33:55 sdague, I'm working on specs for refstack to help w/ visualization 20:34:04 zehicle_at_dell: great 20:34:08 #topic K release naming 20:34:16 We need to come up with a short list of 3-5 names to submit to a public poll (after trademark checks) 20:34:22 Last time we used a Condorcet TC members poll to select that short list out of a larger pool of candidates 20:34:30 The candidate names (following the naming rules) are up at: 20:34:35 #link https://wiki.openstack.org/wiki/ReleaseNaming 20:34:52 Which ones from this list would you like to see on the Condorcet for the short list? 20:34:53 Can we have another mutiny over names? 20:34:58 kepler 20:34:58 mikal: NO 20:35:01 so after talking with mikal, I'd like to apply for a grizzly class exception :) 20:35:03 I'd like to see Kilo / Kilogramme added to that list 20:35:09 why do I get the suspicion that kyoto will win? 20:35:12 Personally I'd pick Kepler, Kleber, Kossuth, Kourou, Kyoto 20:35:12 Its in Paris, and its a cool name 20:35:20 mikal: ++ :) 20:35:28 yeah, we should definitely not put names commonly associated with other places on the list 20:35:30 kerity, klang, or kepler -- if we stick to that list 20:35:44 devananda: the "havana" boat already sailed ;) 20:35:52 mikal: Kilo doesn't mean anything and Kilogramme is WAYY too long. Furthermore, we don't need an exception :) 20:36:11 But its out big chance to make fun of those non-metric people 20:36:13 And Kepler is an awesome dude, too 20:36:21 ++ 20:36:28 ++kepler 20:36:52 * dhellman_ will be voting for Klébér because he wants unicode characters in all the package names 20:36:59 Furthermore the refeence kilogram is NOT EVEN in Paris 20:37:17 kindwiller isn't bad 20:37:18 ttx: !!? 20:37:31 It's in Sevres. Not Paris. Close. But not Paris. 20:38:08 ++kepler 20:38:15 ttx: and Juno is not in Atlanta 20:38:18 we need a few choices 20:38:23 The IPK and its six sister copies are stored at the International Bureau of Weights and Measures (known by its French-language initials BIPM) in an environmentally monitored safe in the lower vault located in the basement of the BIPM’s Pavillon de Breteuil in Sèvres on the outskirts of Paris. 20:38:37 Its in a vault in Paris 20:38:40 Whch is awesome 20:38:52 key word is "outskirts" :) 20:38:56 rule is state - not city 20:38:56 mordred: I'm sad, I can't find a place named Kraken in France 20:38:57 Sigh. Dude. 20:39:01 keryado 20:39:05 None of us know the edge of Paris 20:39:12 Its just a big blob of Frenchyness to us 20:39:12 ttx is right, though - 'kilo' is not 'kilogram' 20:39:16 kepler it is 20:39:17 mikal: I object to that 20:39:24 #info names to include i poll 20:39:42 #info Kepler, Kleber, Kossuth, Kourou, Kyoto 20:39:44 kepler is a good name though 20:39:51 #info kerity, klang 20:39:59 keryado? 20:40:00 keller ? 20:40:11 I don't think that is hard to figure out how to pronounce 20:40:17 why not KILLEM? :) 20:40:25 killem is pretty neat 20:40:25 no no no 20:40:36 Is it too late to argue to Koala? 20:40:41 * mikal is mostly trolling 20:40:42 i would like to see kilo on the list, though i would probably vote for kepler over it 20:40:44 mikal: stick to the rules! 20:41:06 anteaya: is keryado a french city? 20:41:12 it is on the list 20:41:20 #info keryado 20:41:42 markmcclain: want killem on the short list condorcet poll ? 20:41:53 #info keller 20:42:02 http://en.wikipedia.org/wiki/Helen_Keller 20:42:28 kepler ftw 20:42:37 interesting that almost all the city names beginning with a K are German... 20:42:46 ttx: sure 20:42:52 that struck me as odd too, history of conquest, I suppose 20:42:53 zaneb: yes, Alsacian region 20:42:58 the other half are Brittany 20:43:07 Ker* stuff 20:43:15 Ker meaning village there 20:43:21 ah, interesting 20:43:37 if killem makes the list I want kindwiller 20:43:40 anyway, I'll set up the condorcet poll so that TC members can pick a short list of 5 20:43:42 I assume K is not a popular letter at the beginning of a word in French 20:43:48 #info kindwiller 20:44:01 you assume correctly 20:44:15 then we'll submit the list for cursory trademark checks 20:44:32 and the resulting list of 3-4 will be pushed on a public poll 20:45:21 #action ttx to set up the condorcet poll for TC members to pick the short list 20:45:52 I like the sound of Kirchberg. reminds me of Bavaria :) 20:46:22 #topic Requirements changes 20:46:35 * Add Ceilometer requirements (https://review.openstack.org/85978) 20:47:21 I'm tempted to abandon this one 20:47:41 this it doesn't get enough attention from proposer and clogs the meeting every week 20:47:52 on the ceilometer bit, I'd kind of like to pull out that + heat + horizon statements and do a more general "integrated projects should integrate with other projects" 20:47:57 in a more general way 20:48:20 sdague: sounds like a good proposal that would make that one obsolete 20:48:28 which I'm happy to propose if there is some agreement on that direction 20:48:38 ok, will take as a todo 20:48:48 sdague: that said, I think that's where we started from 20:48:52 and then people got more specific 20:49:13 yeh, let me take a whack at language changes and see if people like it 20:49:14 i also remember there being concern at leaving it too generic 20:49:15 sdague: +1 but example don't hurt either 20:49:16 we did, because we wanted to list the expected ways that integration should happen, at a high level 20:49:32 right, so I remember correctly 20:49:40 I think general with examples works well. Before it was just general, with no examples 20:49:51 give some direction so that future TCs don't miss necessary items in their pre-graduation gap analysis 20:49:54 that's how I was redoing the upgrade language 20:50:10 the problem with general is it doesn't provide a checklist for reviewing integration proposals; we need the checklist *somewhere* 20:50:19 +1 to checklist 20:50:20 dhellman_: ++ 20:50:33 perhaps we should actually just checklist against /all/ projects 20:50:37 dhellman_: honestly, checklists for graduation requirements are overrated I think 20:50:46 because there is *so* much context behind these 20:50:59 and we've seen substantial confusion on the lists so far 20:51:01 which is, itself, a general statement 20:51:14 #action ttx to talk to jd__ about his proposal and threaten to abandon it if it doesn't get more love 20:51:19 * add upgrade expectations (https://review.openstack.org/87234) 20:51:25 I'm all for talking to future TCs 20:52:10 I think the latest version of that one should be good to go, just missing fresh votes 20:52:30 much appreciation to devananda and eglynn-afk for catching all my typos 20:52:30 ttx, I'm rebasing it now 20:52:31 will approve when it gets 7 YES 20:52:55 #topic Minor governance changes 20:53:00 sdague: er 20:53:02 https://review.openstack.org/#/c/85978/3 20:53:03 * Add project mission statement for Ceilometer (https://review.openstack.org/87526) 20:53:10 sdague: This requirement becomes relevant after the first stable release that 199 a project ships in 20:53:26 sdague: so it's not really a graduation requirement, it's a post-graduation requirement? 20:53:33 jeblair: correct 20:53:47 One more approval and this one is good to go 20:53:59 jeblair: it's in the First Integrated Cycle Expections section 20:54:06 sdague: is there any aspect of that we would want to consider before the graduation vote? 20:54:08 The other 3 are housecleaning, and will be approved unless someone screams really soon: 20:54:13 * removed openstack/database-api from programs (https://review.openstack.org/95416) 20:54:17 * Add infra-specs to infra program (https://review.openstack.org/94896) 20:54:22 * add oslo-specs to oslo program (https://review.openstack.org/95226) 20:54:40 #topic Open discussion 20:54:49 jeblair: I'd love to nudge projects there, which is the reason for this language 20:54:52 " 198 20:54:52 This requirement becomes relevant after the first stable release that 199 20:54:52 a project ships in, however projects are encouraged to incorporate a 200 20:54:52 culture of upgradability early in their project lifecycle." 20:55:06 sdague: so maybe we can expand on that question of specific vs. general guidelines 20:55:06 sdague: yeah, i think that's really clear. ++ 20:56:22 ttx: on open discussion, yay for designate incubation proposal! 20:56:28 happy to be discussing that next week 20:56:29 yaaaay! 20:56:46 finally glad it's back 20:56:49 sdague: are they up to snuff on the QA side ? Haven't looked at it yet 20:56:51 I have some concerns with designate, but I've mentioned them to the team 20:57:05 ttx: haven't yet, will do this week 20:57:17 For example, they have an API rewrite planned 20:58:06 i continue to have some concerns about ceilometer's scope, but that seems to be overridden by the majority, and i think we've got good progress on the mission statement. 20:58:19 awaiting feedback from eglynn on my last suggestion 20:59:12 devananda: just looking at that, I'd be happy to resubmit with those suggested changes 20:59:15 * ttx looks up devananda's concerns 20:59:40 fwiw i also think the 'avoid examples in mission statement' is a good point 21:00:05 eglynn: if you're going to make more changes, that "reliably" bit seems redundant (we want all of the openstack projects to be reliable, don't we?) 21:00:30 dhellman_: reliably was inserted early in response to feedback 21:00:37 (from jogo IIRC) 21:00:38 ttx: gathering billing data vs gathering performance data vs gathering performance data of the tenant's application (eg, for Heat scaling) 21:00:42 ok, time is up. Looks like that ceilo mission statement could use one more patchset 21:00:49 ttx: three separate things IMO 21:01:03 devananda: feel free to -1 it to block it :) 21:01:11 devananda: gathering similar data for multiple purposes 21:01:12 ok, one more roundtrip to the well :) 21:01:20 #endmeeting