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