20:02:43 #startmeeting tc 20:02:44 Meeting started Tue Jan 14 20:02:43 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:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:47 The meeting name has been set to 'tc' 20:02:52 Our agenda for today: 20:02:55 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:03:07 #topic Paris Design Summit Scheduling 20:03:12 #link http://lists.openstack.org/pipermail/openstack-tc/2014-January/000475.html 20:03:20 In summary: Tue-Fri or Wed-Sat 20:03:27 lsell needs to get back to the hotel today, so last comments and thoughts welcome 20:03:36 Felt like there was growing consensus on the ML about trying out the Wed-Sat option 20:03:44 With the possibility of trying a more relaxed format on the last day 20:03:52 I could be swayed either way - but I like the idea of trying a new thing 20:03:59 I'll be there all of those days anyway 20:04:08 she's lsell on IRC? :) 20:04:14 it's going to be a long week, but otoh it's going to be a long week in paris, so... 20:04:19 lsell: o hai 20:04:21 I like the idea of trying a new thing, but I am doubtful is all 20:04:29 hi there 20:04:30 annegentle: there's wine there 20:04:44 does relaxed mean "includes wine"? 20:04:48 mordred: makes me even more doubtful companies will send their writers :) 20:04:58 markmc: excellent idea 20:05:23 yeah, I see drawbacks and benefits in both options, no strong opinion, so I'm ok to defer to those who expressed preference for wed-sat 20:05:40 ttx: I'm also okay with that, in the spirit of experimenting 20:05:48 wed-sat is less overlap with the conf too, which i really like.. 20:05:54 ++ 20:06:18 that has been my biggest scheduling complaint 20:06:27 same here.. I'm really interested to try this format 20:06:28 so, only 1 day of overlap sounds awesome 20:06:32 with only 3 conference days and us overlapping only with one, we can be present, yes 20:06:43 yesss 20:06:55 we're going to expect some awesome technical presentations now though! 20:07:03 lsell: do you need more opinion ? sparkycollier also said he would prefer wed-sat 20:07:08 ouch, the catch 20:07:24 that's fair 20:07:25 jbryce: I'll present all of the things 20:07:25 jbryce: if only the pissing contest^W^Wcommunity vote would pick them 20:07:32 some panels of ATCs would be good 20:07:45 this is great, it's all i needed 20:07:56 jbryce: give me a full day in my own room and 12 bottles of wine and I'll make you amazing presentations on things 20:08:05 * russellb would attend 20:08:12 I can do a wine tasting session 20:08:13 assuming you're sharing the wine. 20:08:15 only 12? 20:08:20 e.g. a "what's up with Neutron?" panel 20:08:21 russellb: byob - the 12 are just for me 20:08:38 markmc: +1 20:08:43 I'm so conflicted on the scheduling question 20:08:52 lifeless: that's not allowed 20:08:54 ttx: i would say we're open to exercising some editorial oversight to create some dedicated ATC tech presentation time 20:09:04 you guys better be careful, or we're going to send you to a dry county in east texas next time! 20:09:15 lsell: definitely BYO territory then 20:09:18 lsell: I will bring my own Tito's to that countt 20:09:20 county 20:09:29 lsell: is that dig aimed at my ranch? 20:09:30 +1 for Tito's 20:09:39 jbryce: your ranch 20:09:41 jbryce: is in 20:09:48 jbryce: a DRY county??? 20:09:55 lsell: LOL 20:09:55 we're having a meetup at your ranch? 20:10:01 * mordred o_O 20:10:01 neat 20:10:06 jbryce: kittehs!! 20:10:12 we could have a design summit there, once they are separated from conference :) 20:10:18 mordred: it is. but i'm well provisioned 20:10:25 jbryce: ok. that's a relief 20:10:27 ok, folks focus 20:10:39 mordred: alcohol and firearms 20:10:46 lifeless: unless you can express your conflict with words, we can move on 20:10:48 sounds right for a ranch 20:10:49 ttx: how much other input have we gotten so far? (lsell and jbryce too) 20:11:34 annegentle: we have the feedback from last summit (in that planning session) 20:11:46 ttx: oh right 20:11:59 lsell: did you get anything useful from the survey on that front ? 20:12:15 annegentle: so you're worried about getting travel budget for the doc team? 20:12:19 ttx: lsell: also what's the communication plan for the change? (thinking to frame it with " you asked for it you got it " 20:12:33 dhellmann: always. There were only about 4 docs core members in HK 20:12:40 annegentle: will depend on how we organize the last day 20:12:47 we didn't have anything specific in the survey about staggering by one or two days. the most broad feedback we've gotten was from the design summit session 20:12:54 annegentle: we should get more of them to request financial aid this time around 20:12:55 annegentle: more cross-project ? more workshopy ? more unconference-style ? 20:13:07 annegentle: or business as usual 20:13:09 dhellmann: agreed. Oddly many docs members are in APAC already 20:13:11 annegentle: not a perfect solution, but that's why it's there 20:13:48 lsell: is the move to 3-day conference a permanent one ? 20:13:59 (compared to 4 days in HK/Atlanta/etc 20:14:01 ) 20:14:20 definitely not permanent 20:14:27 but again a trial, and the first summit in europe 20:14:30 ok 20:14:40 experimenting++ 20:14:55 anything else on that before we move on ? 20:15:28 #topic Mid-cycle incubation status review: Ironic 20:15:38 thank you for the feedback, we're going to move forward with weds - sat at the le meridien 20:15:44 The idea here is to check the current state of the project w/ the graduation requirements 20:15:49 lsell, thanks! 20:15:51 #link http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements#n56 20:15:56 hi! 20:16:03 devananda: I think you have an etherpad handy 20:16:10 yep 20:16:13 #link https://etherpad.openstack.org/p/IronicGraduationDiscussion 20:16:24 I copied the reference above and added some notes yesterday 20:17:25 digesting 20:17:40 devananda, how confident are you it'll be a working replacement for nova-bm by release? 20:17:50 (nice work btw, it's definitely coming along nicely in the past few months) 20:18:08 ++ 20:18:19 markmc: I'm not goign to say that I'm 100% confident until we have actually done that within tripleo 20:18:24 I'm super exicted about the progress, not only technically, but on dev community 20:18:54 my impression is that in general, things are all headed in the right direction 20:18:56 markmc: I'm fairly and reasonably confident. all the moving bits have come together,a nd we're getting bugs ironed out in the deploy process now() 20:19:03 and it's just the big question of, is it ready to deprecate nova-bm in time 20:19:11 devananda: As far as release management goes, we still haven't done any coordinated milestone 20:19:14 mordred: +1 20:19:17 we need to do taht for i2 20:19:20 russellb: +1 20:19:30 (even if the resulting tarball is not really usable) 20:19:30 russellb: exactly 20:19:41 russellb: there are moer things to that than just "does it work", too 20:19:53 ttx: great. let's do that for I2? 20:20:03 ok, risk mitigation question - say we graduate ironic now and it's not a viable replacement in time for icehouse? 20:20:06 devananda: ack 20:20:06 russellb, devananda : do you see being in complete parity with nova-bm a pre-req for graduation? 20:20:09 devananda: how usable will the i2 milestone be ? 20:20:19 i.e. will it be more than a process-exercise ? 20:20:36 ttx: current code can control the power state, but deploy isn't quite working yet 20:20:36 do we include it in icehouse anyway? (temporarily) de-graduate ironic? say it's still graduated, but not included in the release? 20:20:44 devananda: also how documented are you currently and do you have a doc plan (You might and I may have missed it... 20:20:47 markmc: we aren't deciding on graduation now, right? we only do that at release boundaries, don't we? 20:20:58 ah, right 20:20:59 sorry 20:20:59 markmc: it's not graduated in icehouse 20:20:59 I'd like to see parity, yes 20:21:00 ttx: and the nova "ironic" driver is still fairly early. most of the code is there, but not unit tests, and it hasn't been reviewed by Nova team yet 20:21:00 my bad 20:21:11 yeah, this is just a checkup to avoid surprises later 20:21:32 devananda: did you say "power state works" "deploy doesn't" ? 20:21:36 ttx: as a stand-alone project, it's not quite that useful in I2, mostly because we're still tying all the deploy bits together 20:21:41 jgriffith: at the moment, yes. see ^ 20:21:44 markmc: I still want it to be usable as a nova-bm replacement before graduating 20:21:51 russellb: ok, so if parity isn't reached before the icehouse release, we would not graduate ironic (or you'd prefer that we not) and revisit it during juno? 20:21:51 ttx, agree 20:21:56 dhellmann: weren't we considering ironic for a fast-tract graduation because of the nova-bm deprecation question? 20:22:00 devananda: yeah.. caught it as typing :) thanks 20:22:03 dhellmann: yes 20:22:07 ttx, other than that, looks very much on track 20:22:18 I think graduation is irrelevant at the moment 20:22:20 k 20:22:36 dhellmann: yes, i'd like to see parity before it graduates 20:22:43 annegentle: API is doc'd. we have a CLI with --help. there are some dev docs. but no deployer docs today 20:22:45 russellb: ok, I sort of like that 20:22:46 seems like everythings on track and going the right way, but if it's not ready it's not ready 20:22:50 jgriffith, I guess mid-cycle review is "what you still need to do to graduate" feedback 20:22:58 i guess we could graduate but not deprecate nova-bm yet, but that seems silly 20:22:59 markmc: yeah... like "deploy" 20:23:03 dhellmann: I'm aiming for complete parity. and I think we can achieve that. 20:23:03 So... "Project must be part of the integrated gate" 20:23:07 seems like a simple discussion to me 20:23:07 devananda: and do you expect mostly your audience is deployers? 20:23:10 devananda: cool 20:23:19 devananda: you answer "AFAIK, this is not allowed until *after* graduation" 20:23:31 devananda: or is there another person you'd target for docs 20:23:37 annegentle: yes. we need to explicitly say "DO NOT use this for baremetal-as-a-service" and "DO NOT expose ironic to end-users" 20:24:17 annegentle: for now (and the forseeable future), the users of ironic are folks who already have DC-level access. deployers, basically 20:24:26 I think tere is some misunderstanding around "Project must be part of the integrated gate" 20:24:28 devananda: got it, thanks, very helpful. 20:24:42 i think there has been some confusion between what it means to gate on the official projects (asymetrically, risking being broken by them at any time) and having the official projects gate on not-yet-graduated projects 20:24:59 annegentle: security concerns around putting untrusted tenants on bare metal are, wel.... it's just a terrible idea :) 20:25:08 fungi: ++ 20:25:16 getting the gating requirement clarified in the questionnaire would be great 20:25:21 devananda: it's a brilliant *idea*. As long as it stays an idea. 20:25:23 fungi: ++ 20:25:32 I think the idea is to be ready to be part of the gate at the flip of a switch 20:25:46 devananda, unless you're in the business of giving trusted users baremetal machines anyway - an API for that is still useful to some people 20:25:52 markmc: ++ 20:25:52 lifeless: heh. sure - if not for the current security issue, it would be a good idea :) 20:25:56 that's been my interpretation so far, just making sure it's teh party line 20:26:11 I think that 'end-users' aren't always as untrusted as they are for public clouds 20:26:13 fungi: I think that's what sean means 20:26:15 so, what does "flip of the switch" mean? tempest tests? 20:26:24 markmc: fair. but those users will stil use Nova to get them. 20:26:30 (living somewhere other than in tempest, I guess?) 20:26:31 devananda, yep 20:26:42 for private clouds, it may be fine. also, there are clearly people who offer bare metal hosting currently- and the same security concerns exist there 20:26:43 dhellmann: potentially, non-voting jobs 20:26:49 gate job running for ironic, but ready to be enabled for everyone when ready? 20:26:49 devananda: yup 20:26:51 that's why I want clarification here 20:26:52 ttx: makes sense 20:26:52 markmc: so as far as who uses Ironic's API, i dont see those trusted end-users as our audience 20:26:55 or non-voting i suppose 20:27:01 devananda: yah 20:27:06 dhellmann: project has tempest tests et cetera in its own gate pipeline and potentially in other projects experimental pipeline or as non-voting check jobs 20:27:14 but sdague is not here today 20:27:30 will tempest accept tests for an incubated project? 20:27:40 I believe so 20:27:41 #action sdague to clarify "Project must be part of the integrated gate" as a graduation requirement 20:27:43 russellb: no, we've established that before 20:27:47 russellb, it already accepts 20:27:50 fungi: i understand a bit better the way to set up asymmetric / it-votes-here-but-not-there jobs now. clarkb and I sat down at LCA and added that for our tempest API tests 20:27:57 * dhellmann is confused 20:27:58 dhellmann: I remember it differently... 20:28:07 * mordred had an idea of how to do tempest tests as plugins the other day, btw 20:28:10 dhellmann: well i knew they wouldn't accept pre-incubated project tests (stackforge stuff) 20:28:11 * mordred should code that up 20:28:14 dhellmann: I remember that not incubated - no way; incubated - yes, because integrated implies the tests exist . 20:28:19 aha, maybe that's what I'm confusing 20:28:21 russellb: we have tests in tempest already 20:28:28 ah, coo 20:28:28 l 20:28:30 russellb: they're experimental 20:28:38 mordred: the issue with tempest and external tests isn't technical. 20:28:41 russellb, the same with savanna 20:28:45 russellb: and a patch is up to put them in the check&gate as non-voting 20:28:49 neat. 20:28:51 mordred: so I think you should check with sdague before doing that, as you may just make him a sad panda 20:29:06 mordred: the issue is that tempest doesn't want to offer an externally consumed API 20:29:18 i think some sort of plugin support, or just a tempest public API for writing out of tree tests is sorely needed 20:29:19 russellb: also, fwiw, it's API integration tests. to be clear, we don't have functional tests YET but are working on it. shouldn't be long before a review is up 20:29:23 lifeless: I wasn't expecting it to 20:29:33 but yes to russellb 20:29:45 mordred: that would be the defacto consequence of any out-of-tree tests built on top of tempest though 20:30:01 FWIW I'm also in favor of tempest offering an externally consumed API 20:30:12 just proxying my recollection of sdague's concerns 20:30:20 lifeless: let me write a patch and show you what I'm thinking - I may be letting myself get hung up on the word API here 20:30:31 mordred: lifeless: in fact we had the same issue arise for devstack-gate hooks (and broke some of them through a refactor because we got rid of variables some of them had decided to use) 20:30:35 mordred: sure 20:30:38 OK, so in summary: looks good so far, main blocker is feature parity with nova-bm, need to clarify the "Project must be part of the integrated gate" requirement 20:30:59 anything I missed ? 20:31:19 question for annegentle - what do you think we'll need doc-wise? 20:31:47 #info ironic incubation looks good so far. Main blcoker to graduation is feature parity with nova-bm. Clarification requested on the integrated gate requirement 20:32:39 Morning, sorry slept in (jet lag) 20:32:46 devananda: thinking... I think API docs are a requirement for getting out of incubation, but not necessarily deployer docs yet 20:33:07 annegentle: great! we have those, and they're autobuilt 20:33:11 #link http://docs.openstack.org/developer/ironic/webapi/v1.html 20:33:31 devananda: and I'm trying to see the fit into the rest of the doc titles we have today, and install and config docs are where you'd fit in. 20:33:32 Can we move on to Marconi or Savanna ? Anything else on Ironic ? 20:33:37 sure, I'm good 20:33:50 all set here. I'll follow up with annegentle later 20:33:56 thanks! 20:35:14 I don't see kgriffs around, shall we do savanna first 20:35:25 ok 20:35:29 #topic Mid-cycle incubation status review: Savanna 20:35:35 hi all 20:35:42 SergeyLukjanov: do you have a fancy etherpad too ? 20:35:58 I've missed the idea of making the etherpad like devananda make, but I've prepared some right now 20:36:02 #link https://etherpad.openstack.org/p/savanna-graduation-status 20:36:34 the main questions was Heat usage instead of direct provisioning and clustering 20:36:48 SergeyLukjanov, kinda simple question sorry - is Heat based provisioning the default now? 20:36:55 we've already implemented support of using Heat for orchestration 20:37:14 it's not default atm, we're working on fixing some bugs and implementing minor features 20:37:36 you're planning on it being the default in icehouse, though? 20:37:37 we're planning to deprecate current code later in Icehouse or early J release 20:37:45 ok 20:37:48 thanks 20:37:58 sure, thanks for catching 20:38:21 As far as release management goes, we did icehouse-1 in coordination already 20:38:23 There is still a bit of uncertainty on the deliverables side 20:38:41 btw as for the clustering topic, it was discussed on summit and we decided that there is nothing to do atm 20:38:47 i.e. savanna-extras etc. as part of "savanna release" or not 20:39:32 ttx, it's a good question, we're still working with Hadoop folks in moving out Hadoop releated code 20:39:45 and we currently have some EDP examples in it 20:40:12 so, I still thinking about soft releases for this repo 20:40:42 for the i1 I've tagged this with i1 just to be consistent and help users find corresponding things 20:41:11 yeah 20:41:17 we'll revisit as we go 20:41:23 "large and diverse team of contributors" 20:41:41 that's 26 contributors so far 20:41:48 we have a lot of new contributors since the incubation status 20:42:13 and as you can see in mailing list one more upcoming plugin for Spark support 20:42:36 http://www.stackalytics.com/?release=icehouse&metric=commits&project_type=openstack&module=savanna-group&company=&user_id= 20:43:00 That 65% figure is a bit worrying to me 20:43:15 I don't see a significant community uptake after incubation 20:43:27 ttx, there are about 20 commits from me about hacking setup.py/tox I think 20:43:49 ttx, and commit not always shows the real efforts 20:44:11 ttx, the pie chart by contributor is fairly reassuring though 20:44:54 right, maybe i'm the only one worried here :) 20:45:04 SergeyLukjanov: ++ on "commit not always shows the real efforts" 20:45:19 ttx: the curve does drop off pretty steeply after the first few companies 20:45:20 ttx: seems like a valid point, but explanation by SergeyLukjanov makes sense as well 20:45:23 * mordred looks at his status on top of the commit lists for openstack last cycle, and wonders what real work he did 20:45:24 indeed, top 2 people are separate companies on the individuals one 20:46:22 beyong numbers, my point is I haven't seen a lot of companies dive in Savanna tha way they jumped on Heat or Ironic 20:46:39 Is that lack of interest ? 20:46:50 is that because it's more of a niche service? 20:46:57 dhellmann: probably 20:47:05 just wondering how (and if) we should fix that 20:47:09 I've agreed with dhellmann 20:47:09 mordred: you wrote bots that did commits 20:47:10 in that case, it might always be smaller -- right 20:47:44 lifeless: if only that was the case 20:48:02 * mordred agrees with dhellmann 20:48:27 there are some customers and interested but currently not public yet 20:48:36 anyway, part from that, Savanna has been the most engaged incubated project as far as release management goes 20:48:54 and I heard similar reports from other horizontal teams 20:49:03 SergeyLukjanov: the main concern about contributors is dealing with maintaining the project if some of the current members leave the team for some reason, not whether customers are interested in using it. 20:49:07 so great job here 20:49:37 any other comment ? 20:49:47 none here 20:50:12 dhellmann, I think that it's not depend on at least one person now 20:50:17 #info Savanna is in good shape too, some concerns about lack of diversity in contributors but might be a reflection of a niche project 20:50:22 SergeyLukjanov: good! :-) 20:50:24 dhellmann, it's now much more better that 3 month ago ;) 20:51:05 btw, I'll complete the etherpad with comments and send it to mailing list 20:51:22 SergeyLukjanov: that will be useful, thx 20:52:04 and I'd like to join concerns about being part of integrated gate 20:52:16 it sounds like chicken/egg problem 20:52:21 SergeyLukjanov: we'll get that clarified 20:52:48 sdague had a pretty precise idea here and I don't want to wrongly express it 20:52:57 At this point in meeting let's cover the minor changes real quick and see how much time we have left 20:53:08 #topic Minor governance changes 20:53:15 Program/project mapping (https://review.openstack.org/#/c/65096) is almost there 20:53:19 ttx, thx! 20:53:22 Two open questions about this one 20:53:29 Should openstack/requirements be in RekMgt, Infra or a true orphan (like openstack/governance) 20:53:30 ttx, did we miss Marconi ? 20:53:46 markmc: no, but likely will cover next week 20:54:01 ttx, ok, thanks 20:54:07 I think it makes sense to put it in the same box as openstack/governance (the TC box) 20:54:12 ttx: one question I had from talking to people is... let me remember... 20:54:40 Does that work for everyone ? 20:54:54 ttx: makes sense to me 20:54:56 ttx: by "the same box" do you mean call it an orphan? 20:54:57 ah. Ok. Remembered. When you are ready. 20:55:02 dhellmann: yes 20:55:17 ttx: ok, wfm 20:55:18 Second question was should tuskar-ui move from TripleO to Dashboard program 20:55:28 IMHO it should not -- as long as it's separate from Horizon it should stay in its parent program, no ? 20:55:49 are they planning to merge it into horizon at some point later? when they're integrated? 20:55:59 dhellmann: I guess yes 20:56:04 or is the horizon team supporting add-ons explicitly? 20:56:15 I think it boils down to which team works on it 20:56:33 is it tuskar/tripleO folks, or horizon team 20:56:34 yeah, it seems like it should stay with tripleo for now 20:56:36 ttx: there has been discussion to move it into the dashboard program because the code design/review doesn't align very well with tripleo 20:56:38 lifeless: ? 20:56:52 lifeless and I have been working in that direction 20:56:57 david-lyle: is the horizon team willing to own it? 20:57:06 yes, that's the key question 20:57:17 yes, but it will remain a separate repo until out of incubation 20:57:19 basically, either seems fine, but we can't just dump it on them :-) 20:57:20 ttx, it's been a fairly specialized team within tripleo who have more overlap with the horizon team 20:57:26 ttx, that's my read, at least 20:57:29 I mean, if both tripleo and horizon agree on that, I'm fine 20:57:34 ttx: ++ 20:57:42 ++ 20:57:47 just checking with lifeless it's fine by him 20:57:59 OK, will push a new change that moves openstack/requirements out of RelMgt and tuskar-ui in "Dashboard" 20:58:10 Governance docs publication (https://review.openstack.org/#/c/61380/) 20:58:12 lifeless was pushing for this AFAICS 20:58:15 This one just needs one more +1 to get in 20:58:19 Do not require team diversity at incubation time (https://review.openstack.org/#/c/65471/) 20:58:23 This one just needs one more +1 to get in 20:58:28 Mention scope expansion in incubation requirements (https://review.openstack.org/#/c/62612/) 20:58:38 This one we buried at last week meeting but it was raised from the dead by markmc 20:58:53 markmc: I suspect you think it's still warranted ? 20:59:00 markmc: did you read last week log about it ? 20:59:01 sorry, missed last weeks meeting 20:59:16 I just saw it got auto-abandoned, so fixed up the comments 20:59:19 ttx: sorry yes 20:59:22 ttx: as david-lyle says 20:59:31 lifeless: will make it happen 20:59:36 ttx, I can go back and read the logs 20:59:50 markmc: ok, happy to discuss it if you still want to revive it after that 20:59:52 ttx: oh, thanks! 20:59:57 next week 20:59:58 I have to run, sorry 21:00:00 #topic Open discussion 21:00:09 last minute - Anything else, anyone ? 21:00:16 I won't be here for the next meeting 21:00:29 we'll cover Marconi Mid-cycle incubation status review and 3rd party testing next week 21:00:33 Did we decide what we're doing about third party CI? 21:00:38 Ok 21:00:42 not enough time 21:00:46 Noting that Neutron has a deadline for third party CI near there 21:00:54 Which is why is blowing up at the moment 21:01:06 s/is/it is/ 21:01:11 I'm sure we can negociate around that 21:01:11 * mordred just assumes mikal will solve it 21:01:22 mikal is trying 21:01:26 #endmeeting