20:03:37 #startmeeting tc 20:03:37 Meeting started Tue Apr 15 20:03:37 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:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:40 The meeting name has been set to 'tc' 20:03:41 stop lough'im retard 20:04:04 This is the last TC meeting for the Icehouse membership 20:04:10 Was great working with you all. 20:04:17 :) 20:04:18 Our agenda for today: 20:04:24 yeah i love you guys 20:04:30 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:04:47 #topic Integrated projects and new requirements: Gap analysis for Trove 20:04:54 horray :) 20:04:55 hub_cap: o/ 20:04:59 https://www.youtube.com/watch?v=Nf5ukMJO2cY 20:05:00 aye 20:05:03 #link https://etherpad.openstack.org/p/TroveIntegrationRequirements 20:05:04 o/ 20:05:09 https://www.youtube.com/watch?v=Nf5ukMJO2cY 20:05:17 so um, we gonan kick this guy or what? 20:05:19 *gonna 20:05:37 everyone have their nick registered? kick and mode +r ... 20:05:46 punishment is coming, jeblair on it 20:05:51 k 20:05:56 Is jeblair assembling power tools? 20:05:59 russellb: ++ 20:06:06 mikal: hes assembling devastator 20:06:07 apparently webclient gets in his way 20:06:21 ... just /ignore ? 20:06:25 im sorry guys yoiu know im love you ;((( 20:06:27 webclient was the worst deceptacon 20:06:38 uh oh, the ((( give him away!! 20:07:00 nobody like me 20:07:11 so anyway, lets talk trove 20:07:17 we have gaps, lets analyze them 20:07:35 To the gaps! 20:07:44 i will do my best to mind them 20:07:52 and make SlickNik mend them 20:08:07 * SlickNik is listening intently 20:08:29 hub_cap: who makes up your core team? 20:08:36 company wise 20:08:45 ebay, hp, rax 20:08:49 nice 20:09:04 yea, ill admit core needs to grow 20:09:14 hip hip horray 20:09:17 3 cheers for jeblair 20:09:24 heh 20:09:30 russellb / hub_cap: We definitely need to grow the core team. 20:09:32 his wrath is slow but thorough 20:09:41 HAH 20:09:42 looks like your review wait times are a little above average 20:09:49 russellb: yes a good bit 20:09:52 hub_cap: the qa gap I think is nicely identified there. Mostly trove is kind of light at the moment in that regard. 20:10:00 partially due to the core team size 20:10:08 sdague: yes its been a new thing (thx to SlickNik ) 20:10:19 in honestly sdague, we have a decent ammt of nonstandard tests we still rely on 20:10:32 so its not as if its not there, its just not in the right place, so to speak 20:10:44 hub_cap: right, it would be better to get that focus in the upstream process though 20:10:45 sdague: I'm working with a few folks to get more of the trove integration tests into Tempest. 20:10:52 SlickNik: great 20:11:03 that a priority for juno? 20:11:10 SlickNik: ? ;) 20:11:11 russellb: Yes 20:11:20 my guess is its one o the highest prios 20:11:31 since weve been bitten by the lack of them a good bit 20:12:08 Another item is figuring out the upgrade testing plan since we don't do any of that currently. 20:12:14 * hub_cap assumes people are reading the sparse wiki 20:12:16 yep, that's pretty important 20:12:38 hub_cap: do you think we can eventually get rid of reddwarf ci? 20:12:48 looks like the wiki doesn't include all of the requirements 20:12:51 like the API section, for example 20:13:02 jeblair: since day one i want to get rid of all of that ci _and_ trove-integration 20:13:08 fyi: http://summit.openstack.org/cfp/details/295 20:13:12 did you guys only include sections you had comments about? 20:13:13 a talk on test req's 20:13:27 yea im sorry for not doing it rigth russellb 20:13:35 i mustve missed that.. i did the gaps only 20:13:38 that's fine 20:13:48 assume the rest o' it is there, and stable 20:13:51 so it looks like we have the same gaps as Ceilometer (integration tests and docs) 20:14:13 as per the api, ive even backed out a change to the api that caused a "change" 20:14:14 so REST API is stable? 20:14:16 that was a while ago 20:14:20 yes, no changes in icehouse 20:14:25 you've a pretty massive list of blueprints - 122 bps open 20:14:25 hub_cap: cool; i think you've made a lot of progress; just wantod to make sure you thought it was still feasible and you are working toward it 20:14:26 k, sounds good then 20:14:27 sans the KILL XML DED part 20:14:33 how are you finding the blueprint process? 20:14:34 jeblair: 100% 20:14:44 markmc: wlel we are doing monday bp rallys 20:14:55 and we pick them and discuss them before anyone even sets a line o code down 20:14:59 hub_cap: could you give us your plans for trove-integration in Juno ? 20:14:59 are your blueprints too fine grained, too future looking, or it's a good reflection what you hope to do in the next release? 20:15:08 for instance, someone wanted to do a shadow tenant 20:15:19 and i asked him to talk to nova about managed vms, or whatever we wanted to call them 20:15:23 yeh, just on a personal note, I want to say SlickNik was super responsive in helping get all the requirements issues closed at end of cycle so we could have trove in the main job and requirements enforced 20:15:26 and there was already functionality to do something like this markmc 20:15:35 so we killed his bp, no code written.. that was, what 2 wks ago SlickNik ? 20:15:42 we have a blueprint format 20:15:48 hub_cap: Yes. 20:15:55 and we wont even look at a BP if it doesnt match the format 20:15:58 and SURE wont accept it 20:15:59 markmc: Historically we've had problems with not enough info in the bps. 20:16:09 SlickNik: that's been a common problem 20:16:10 sdague: SlickNik is the bomb 20:16:27 we are having a good cadence tho w/ them, we get thru avg 4/ meeting 20:16:31 markmc: We've moved to a template format (on the wiki) for new bp proposals. 20:16:36 so a large number of bps are coming from folks outside of the core team? 20:16:50 #link https://wiki.openstack.org/wiki/TroveBlueprint 20:17:10 nice template 20:17:22 markmc: most of them are 20:17:24 markmc: Yes, bps are coming from all contributors. 20:17:43 * devananda likes the idea of a bp template 20:17:45 we are in more of a code review / bp review / bug triage / code cycle 20:17:46 do you have an specific plans to increase the core team size? 20:17:48 in that order 20:18:03 dhellmann: we want to see more meaningful contributions, as well as meaningful reviews 20:18:04 I guess it's a pretty weird time to look at the blueprints list - i.e. not having a plan in place for juno yet 20:18:06 and then yes 20:18:08 hub_cap: could you give us your plans for trove-integration in Juno ? 20:18:19 ttx, can i defer to SlickNik for that? 20:18:25 sure 20:18:27 * hub_cap puts SlickNik on the spot! 20:18:28 looks like about 1/4 of your bugs are untriaged 20:18:33 if yall dnt konw, SlickNik is the new ptl 20:18:33 hub_cap: sure, I was selfishly asking for hints on how to attract people to do those things :-) 20:18:47 that's only 34 bugs untriaged, so should be easy to clean up 20:18:52 dhellmann: heh, if i had the answers id have a bigger core team ;) 20:19:00 hub_cap: fair point 20:19:03 russellb: yes thats something that i think very few people are doing 20:19:10 dhellmann: i admit its a weak point for trove tho 20:19:10 ttx: I'm looking to move _most_ API tests out of trove-integration into Tempest. 20:19:16 our core team is VERY small compared to others 20:19:33 should look at core team size compared to patch volume though 20:19:34 SlickNik: would the trove-integration repo become obsolete ? 20:19:52 i think the key data is being above average on review times 20:19:55 ttx: there's still some white box, system tests, that Tempest is not the right place for (imho). We might have to transition these to a different jenkins job running in openstack-ci. 20:21:16 ttx: It will take a fair bit of work with QA to get to a point where trove-integration is not needed anymore. 20:21:19 russellb: good point.. and we are below avg there 20:21:19 SlickNik: sure, a functional test job in ci is probably a possibility 20:22:18 ttx: It's a top priority and we're moving towards it, but I don't know if we will be able to get it _all_ done in Juno. 20:22:32 russellb: ++ 20:22:41 sdague: ++ 20:22:45 SlickNik, sdague: yeah, i think a functional job is great if you need it 20:22:47 OK, we should wrap up 20:22:51 SlickNik: you should check out the swift functional job at some point 20:23:04 yea last time we spoke w/ infra they wanted _some_ tempest tests first 20:23:11 and i agreed w/ their thoughts 20:23:16 ++ 20:23:17 so we kept our hobbily jenkins :P 20:23:23 :) 20:23:30 #agreed Trove needs to move integrations tests to Tempest 20:23:31 russellb: I might have to pick your brain a bit to figure out ways to achieve that. :) 20:23:32 hobbity 20:23:44 #agreed Trove needs to work on documentation during the juno cycle 20:23:54 anything else ? 20:23:57 SlickNik: if only there were magic bullets :-) but yes, more than happy to talk! 20:24:01 ttx: we do have an install patch in review, kudos for that 20:24:13 ttx: i'd like to call out deprecating reddwarf ci explicitly 20:24:30 SlickNik: we've also been doing a lot to get functinal testing for ironic into openstack-ci, happy to share what we've done 20:24:46 #agreed Trove needs to depercate reddwarf ci 20:24:55 ++ to both 20:25:20 devananda: ++ I'll touch base with you offline regarding this. 20:25:55 cool. so are we saved by the bell then? 20:26:08 we know our gaps are CI, docs, and core team growth (due to review times) 20:26:31 OK, anything else on that topic ? 20:26:49 plz feel free to blame SlickNik for anything not done in juno 20:26:59 we will. 20:27:19 eglynn, jd__: around ? 20:27:21 * SlickNik starts sweating 20:27:21 haha 20:27:23 * eglynn nods 20:27:31 #topic Integrated projects and new requirements: Review Ceilometer plan to cover gap 20:27:42 eglynn, o/ 20:27:44 Last week we did a gap anaylsis at: 20:27:48 #link https://etherpad.openstack.org/p/ceilometer-integrated-requirements 20:27:49 cool, floor is mine? 20:27:56 Three gaps were identified: program mission statement, integration tests and documentation 20:27:57 Thanks for the discussion regarding trove! 20:28:05 One concern was raised: SQLA not being recommended in production but still being the only backend tested in gate 20:28:07 another new PTL :) 20:28:13 k, here's the high-level plan to address the specific concerns raised by the TC last week 20:28:13 eglynn: what is your plan to address those gaps ? 20:28:15 #link https://etherpad.openstack.org/p/ceilometer-integration-gap-analysis-coverage-plan 20:28:31 idea is to have a designated owner to drive the actions for each specific item 20:28:39 ... and a corresponding summit session proposed if required 20:29:03 maybe go thru' the concerns one by one? 20:29:07 I approve of explicitly calling out talking to Mike Bayer on sqla 20:29:18 eglynn: no, we can read 20:29:22 yeh, that will be great 20:29:26 mordred: hat tip to ildikov on that 20:29:50 eglynn: he'll be there a couple of days, so there will be time outside of sessions, too 20:29:58 cool 20:30:10 and also many thanks to dhellmann for organizing this 20:30:17 +1 20:30:29 now.. am I the only one not knowing Mike Bayer ? 20:30:30 ... so concern #1 was straight-forward, we hacked out a formula of words on etherpad, now out for review on gerrit 20:30:36 ttx: author of sqlalchemy 20:30:37 ildikov: make sure you have notes added to https://etherpad.openstack.org/p/juno-oslo-bayer so we don't overlook it during the session 20:30:43 ttx: you know of his works ;) 20:30:45 mordred: ah. That could help 20:31:00 dhellmann: sure, will do, thanks for reminding 20:31:09 I like this plan 20:31:28 ttx: cool 20:31:33 eglynn: on the test strategies front, there was something that was proposed back in portland about having some ceilometer tests that happen around existing tests (as decorators) to track resource expectations. I think that got lost along the way. 20:31:34 Seems like the concerns are taken into account and a plan is in place to address them in Juno 20:31:43 is that somethign appropriate for the 152 session? 20:32:03 sdague: yes, good point, will add 20:32:04 otherwise, I'm pretty happy with the plan 20:32:24 note BTW that items #3 & #4 are somewhat intertwined 20:32:29 Everyone else happy with the plan as spelled ? 20:32:49 yes, this looks it covers the concerns 20:33:08 yep no concerns, seems well organized 20:33:32 looks good 20:33:46 #info Proposed plan covers identified gaps. TC will check on progress on that plan during the Juno cycle. 20:34:02 coverage looks good do we want any estimated delivery dates? 20:34:37 some of it probably OK to be just "juno" 20:34:41 markmcclain: a bit premature yet to tie to milestones, but I definitely want to frontload the tempest work 20:34:43 i'd think the QA things we'd want earlier 20:34:49 eglynn: nice :) 20:34:54 at this point, I'll take "juno" 20:35:09 cool 20:35:11 but post design summit would be good to have blueprints and milestone targets for those yes 20:35:17 ttx: ++ 20:35:23 ttx: aggreed 20:35:31 eglynn: just add to the same etherpad 20:35:40 we'll reuse it to follow progress 20:35:41 ttx: will do 20:35:57 anything else on that topic ? 20:36:32 #topic Moving projects around (jeblair) 20:36:37 #link http://lists.openstack.org/pipermail/openstack-tc/2014-April/000608.html 20:36:57 jeblair: you wanted this to be blessed by the TC ? 20:37:36 sounds fine to me 20:37:40 +1 20:37:40 +1 20:37:43 +1 20:37:47 yeah, me too 20:37:53 the gantt thing is a bit weird, but fine ... 20:37:55 +1 20:37:58 sigh @ gantt 20:38:15 i'd love to just remove it honestly 20:38:15 +1 20:38:27 and if/when a splitout happens, give it a new name 20:38:37 so it's not associated with this past effort that completely fell apart 20:38:39 sounds fine and I like your use of mothballing 20:38:42 yeah, we're trying to make it the least bad for everyone, within the constraints that we have 20:38:55 +1 20:39:12 russellb: what happened with gantt? 20:39:15 if we mothball gantt does that just mean its replacement needs a different name? 20:39:15 but one of those is don't delete history, so that approach with gantt seemed like the best way to go 20:39:17 +1 20:39:18 not enough people working on it? 20:39:34 vishy: that's part of it, yes 20:39:38 dhellmann: no, we actually want to leave it where it is but read-only so that we can reuse the name 20:39:51 don't want to get too sidetracked 20:39:52 dhellmann: we can do a keystone-lite style switcheroo 20:39:53 jeblair: right, I was responding to russellb's suggestion of deleting it 20:39:57 can give more detail later though 20:40:03 k 20:40:13 read-onlying it is probably a good first step 20:40:17 I wonder if it's going to be confusing to have another gantt in the future, but whatever 20:40:22 +1 to the plan as written 20:40:22 yep, i'm fine with the proposed plan for gantt 20:40:38 if we realize we don't need it we could -attic it 20:40:41 right 20:40:42 cool. and yeah, its not closing any doors on gantt if we change our minds later 20:41:06 jeblair: you got enough love, shall we move on to next topic ? 20:41:09 i'll go ahead and put those renames on our list for the next downtime then. thanks :) 20:41:22 #topic Cross-project workshops at the summit (russellb) 20:41:25 #link https://etherpad.openstack.org/p/JunoCrossProjectDesignSummitTrackReview 20:41:34 thanks to the folks that helped by voting on sessions 20:41:44 if you scroll to line 36 or so you'll see the proposed set 20:41:44 I think we mostly agreed anyway 20:41:57 based on the results, i went ahead and approved 1 through 17 20:42:01 and rejected 22 to the end 20:42:09 question for today is what to do with the middle ones 20:42:15 there is just a bit of uncertainty between giving 2 slots to more sessions, or accepting more 20:42:18 right 20:42:38 i think my opinion is just give 2 slots to the ones marked as such 20:42:52 russellb: I think 18 and 19 are covered if we give a double-session to 11 20:42:53 any opinions otherwise? one of the middle ones you really want to have? 20:43:05 does that leave 21 out? (python 3)? 20:43:09 ttx: yes that's a good point 20:43:12 dhellmann: yes, right now 20:43:24 if we take python 3, we have to drop the [x2] by something 20:43:45 I would like to have some sort of session so the team that is working on that will be able to land incremental patches -- moving "all at once" is not a realistic plan for the amount of work they have to do 20:43:46 maybe #9 ... 20:43:50 double slot on 16 seems a little odd, given that it wasn't strongly voted for 20:44:08 sad the python3 talk has so little in the description 20:44:08 sdague: that's just what i was thinking 20:44:16 maybe we just assume that gets sorted before the session? 20:44:23 that there will be useful stuff worth discussing? 20:44:25 sdague: yeah, my fault. I think if that session works they will need 2 slots 20:44:27 does talking longer than 40 minutes really help get decisions? 20:44:39 markmc: yeah, I can push zul and haypo on that 20:44:41 or does it help with listing tasks? 20:44:49 if it doesn't and they don't converge, probably not 20:45:26 annegentle: some topics are very broad, like SDKs / libraries / openstackclient stuff 20:45:45 ttx: k 20:45:48 same for API convergence, sortig etc 20:45:59 i think part of the idea of 16 is to try to get collaboration on projects that may not be collaborating closely right now 20:46:01 i'm fine dropping the x2 for #16 and adding Python 3, with the expectation that the details get sorted in time 20:46:19 hopefully the conversation doesn't end after the session 20:46:24 it'll at least get people connected 20:46:33 russellb: yeah, your call 20:46:33 jeblair: given we've had feedback for those project regarding their collaboration that seems like a req 20:46:52 do we know if the right people will be there? I'm a little concerned we've got a lead a horse to water problem with that session 20:47:09 sdague: which one, #16? 20:47:11 yeh 20:47:13 hopefully some of us :) 20:47:17 jgriffith: yep. the rest of that thought was that i think there will be some time spent establishing baselines 20:47:20 sdague: I rejected their "other project" sessions 20:47:25 sdague: there inlies the problem 20:47:25 next problem will be scheduling which of these can go in parallel 20:47:26 sdague: I've the same concern with pushing "17. cross project documentation" to the docs track, how do I get people there? 20:47:29 sdague: so they won't have time to talk separately 20:47:30 to make sur the right people can be in the room 20:47:43 it's their only space (Murano and Solum) 20:47:50 so I hope they will be there 20:48:02 that too 20:48:02 ttx: you reaching out to them directly on that? 20:48:02 honestly, i'm really bummed about the python3 thing, but i think i'm still not optimistic that is set up to be a productive session 20:48:11 sdague: I can 20:48:23 ttx: murano folks will be there 20:48:23 fwiw I'd be relaxed about having only one session for #16, I think 20:48:27 jeblair: but can we afford *not* to talk about it? 20:48:28 jeblair: yeah, I'm fearing it doesn't really need a session 20:48:41 I think because it's not a session anyone from those groups proposed, but you did directly, then it's probably worth making sure direct contact to them 20:48:43 especially on fuzzy goals 20:49:02 russellb: i can at least show up and report what i learned and said at the python language summit 20:49:14 there's also a sprint going on right now at pycon 20:49:16 sdague: right, that's fair. I mentioned that workshop when I rejected their "other project" session though. Will reach out directly 20:49:16 i think that may be helpful, actually 20:49:26 sdague: easier sell if they get a double-session 20:49:44 jeblair: so you think it's useful then? 20:49:51 if we want it, we have to drop some x2 slot .. 20:50:12 russellb: I guess we can drop the second UX slot 20:50:19 UX is what i was leaning toward 20:50:28 russellb: because developer exproence will better be handled in the SDk session anyway 20:50:32 let's say i've got 15 minutes of content i can share. i can start an email thread if we don't want to bet a session slot on that though. 20:50:33 ok, proposal: accept python, 1 slot for UX, 2 slots for the other 3 that have x2 by then 20:50:34 ttx: Murano team knows about this session and we are preparing to it. 20:50:35 that sound OK? 20:50:37 if we are going to put it on the agenda, can we spin it a little to be our python support story over all 20:50:43 gokrokve: good to hear 20:50:54 because it seems like we should actually discuss 2.6 deprecation at some point 20:50:59 sdague: ++ 20:51:00 russellb: +1 20:51:01 sdague: that sounds reasonable 20:51:06 sdague: ++ 20:51:09 sdague: sounding better and better 20:51:16 "Future of Python in OpenStack" 20:51:18 :) 20:51:21 perfect 20:51:24 ok, one more quick issue 20:51:33 session #1, Consistency across OpenStack REST APIs 20:51:34 ttx: port to 'go', right? :) 20:51:39 the proposer of that session is unlikely to make it 20:51:42 that sounds like there's a question whether python has a future in OpenStack :) 20:51:47 markmc: ++ 20:51:47 so we should probably line up someone to lead that one 20:51:48 jeblair: scala 20:51:52 markmc: we're rewriting it all in go 20:51:55 jeblair: +1 20:51:59 * russellb prefers bash 20:52:05 devstack got it right 20:52:15 russellb: agree- we should line up someone to lead it 20:52:18 devstack got everythign right 20:52:27 but seriously ... API session 20:52:28 I'll take it 20:52:32 * markmcclain longs for C 20:52:41 dhellmann: OK, I think that'd be perfect 20:53:01 we've had API consistency sessions several times 20:53:01 I will, however, expect jeblair and some others to show up to help :-) 20:53:10 russellb: jaypipes might be interested in leading that one 20:53:11 problem has been someone willing to drive it beyond a session 20:53:15 dhellmann: I'll probably, you know, come run my mouth 20:53:25 ttx: sure, dhellmann: can you ping jay too? 20:53:28 * dhellmann makes a note to pack his stopwatch 20:53:31 jaypipes ++ - as long as the session isn't json vs. xml 20:53:39 vs yaml 20:53:41 mordred, dhellmann: in which case i will show up and attempt to get a word in edgewise. ;) 20:53:42 russellb: wait, I was volunteering on the future of python thing, not the api thing 20:53:45 that ship has sailed 20:53:46 dhellmann: haha 20:53:50 mordred: we've got a good job killing a lot of xml this cycle :) 20:53:58 sdague: +1000 20:54:03 OK we ned to move on 20:54:09 russellb: got what you need ? 20:54:15 the time sensitive part yes 20:54:17 thanks! 20:54:24 russellb: scheduling will be unfun 20:54:30 indeed 20:54:35 everyone bring your clones 20:54:35 russellb: we can talk about it tomorrow 20:54:44 #topic Requirements changes 20:54:48 * Add Ceilometer requirements (https://review.openstack.org/85978) 20:54:48 russellb: should I file a separate item for the future of python, or do you want to reuse this one? 20:54:57 Looks like most people generally agree on this one but would prefer a more precise wording 20:55:03 dhellmann: why don't you file a new one 20:55:07 russellb: ok 20:55:14 thanks! 20:55:28 needs a few more iterations, I think 20:55:33 * add upgrade testing expectation (https://review.openstack.org/86162) 20:55:41 The latest wording on that one looks fine to me, I'll approve it once it reaches 7 YES 20:55:48 (if nobody objects) 20:56:02 Remarks on those two ? 20:56:59 #topic Minor governance changes 20:57:03