20:02:37 <ttx> #startmeeting tc
20:02:37 <openstack> Meeting started Tue Mar 25 20:02: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:02:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:40 <openstack> The meeting name has been set to 'tc'
20:02:45 <ttx> Our agenda for today:
20:02:46 <SergeyLukjanov> o/
20:02:49 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:04 <ttx> may have to adapt it since Mark asked to push back on the Neutron plan review
20:03:41 <ttx> we'll talk about future meetings in election season in the open discussion section at the end of the meeting
20:03:53 <ttx> #topic Integrated projects and new requirements: Gap analysis for Cinder
20:04:03 <ttx> jgriffith: did you prepare a base document to support our discussion ?
20:04:13 <jgriffith> ttx: no but I can, real quick
20:04:14 <jgriffith> stand by
20:04:31 <markmc> sorry
20:04:33 <russellb> o/
20:04:48 <zehicle_at_dell> ttx, can we add a sliver into the agenda to confirm the DefCore/TC meeting is on Friday?
20:05:07 <jgriffith> https://etherpad.openstack.org/p/cinder-gap-analysis
20:05:12 <ttx> zehicle_at_dell: sure, we can talk about that in open discussion at the end, but I think it's confirmed already
20:05:20 <zehicle_at_dell> thanks
20:05:22 <russellb> ttx: zehicle_at_dell other than the time
20:05:24 <vishy> o/
20:05:37 <russellb> that wasn't clear on list, it was 8pm UTC, and then "7 8 UTC"
20:06:19 <jgriffith> ttx: you copy paste faster than I :)
20:07:01 <zehicle_at_dell> russell, sorry that was just a typo.
20:07:05 <zehicle_at_dell> it's 8 UTC
20:07:13 <russellb> zehicle_at_dell: no problem, just want to make sure i'm available at the right time
20:07:16 <ttx> jgriffith: any area where you identified a gap ?
20:07:44 <russellb> not sure it's a gap, but in general there's probably better code sharing we could do between nova and cinder still
20:07:46 <jgriffith> ttx: docs
20:07:53 <jgriffith> ttx: as in documenting the items
20:08:01 <jgriffith> ttx: as russellb pointed out a month ago :(
20:08:04 <ttx> on the minor side, we also need to formalize a cinder-coresec group
20:08:07 <jgriffith> Defined scope
20:08:22 <ttx> (contact points for handling vulnerability bugs)
20:08:28 <jgriffith> I'm striking through the items that I *believe* are covered
20:08:36 <ttx> jgriffith: sounds good
20:08:37 <jgriffith> shout if I'm wrong anyone
20:08:45 <jgriffith> ttx: yes, secgropu is a gap for sure
20:08:54 <jgriffith> I've been relying on the sec team
20:08:54 <ttx> I'll strike a few for you on the release management side
20:09:20 <russellb> read through it, i don't think i have any concerns personally
20:09:27 <russellb> curious how you feel the heath of your core team is these days?
20:10:09 <russellb> reviews look more balanced than they used to be a long time ago, so seems good?
20:10:23 <jgriffith> russellb: I think it's good
20:10:27 <russellb> cool
20:10:27 <sdague> jgriffith: while clearly not a blocking item, one thing that I'd like to see in juno is some additional functional testing on the volumes code. It seems like when we get to a certain number of volumes tests we end up tripping up, and would be nice to be able to beat on it harder some how in juno.
20:10:30 <jgriffith> russellb: review balance is MUCH better
20:10:36 <russellb> awesome
20:10:47 <jgriffith> sdague: fair, and agreed
20:11:06 <jgriffith> sdague: so that's a comment to add to the analysis here?  Or a seperate topic?
20:11:07 <sdague> but honestly, I find the cinder team is very responsive to issues that we hit there
20:11:12 <ttx> sdague: add under "decent functional tests coverage" ?
20:11:24 <russellb> jgriffith: really, in general, very nice work to the whole cinder team
20:11:25 <jgriffith> now that I just crossed that setion out :)
20:11:36 <jgriffith> russellb: we've got some good dedicated folks now
20:11:37 <jgriffith> stable
20:11:45 <sdague> ttx: yeh, probably an addendum there. Honestly, things are in pretty good shape, so I could go either way about recording it there or saying "we should do more"
20:12:05 <jgriffith> I'd like to have a section for notes/suggestions at the bottom
20:12:10 <russellb> jgriffith: +1
20:12:27 <russellb> i can think of some minor things for that, but no real gaps
20:12:28 <jeblair> they're especially great at dealing with the fact that we blame them for lots of bugs because their tests happen to be the ones that actually error out.  :)
20:12:37 <sdague> heh
20:12:54 <jgriffith> jeblair: haah
20:12:59 <mordred> jeblair: ++
20:13:13 <jgriffith> oh, there's a fantastic point
20:13:15 <mordred> jeblair: dosen't that mean that they should then fix other people's bugs? if it's their tests that fail?
20:13:23 <ttx> http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt looks good to me
20:13:24 <jgriffith> "code sharing between nova and cinder"
20:13:26 <annegentle> jgriffith: my only input would be that you have a good docs bridge in thingee
20:13:27 <sdague> it would actually be interesting if we could get some high io nodes for tests to be able to beat on
20:13:46 <annegentle> jgriffith: so maybe lean on Mike to fill in the docs gaps
20:13:47 <russellb> jgriffith: that's the biggest thing i can think of, and it's not a huge deal
20:13:59 <jgriffith> annegentle: I have been :)  Don't want to take advantage of him
20:14:06 <annegentle> jgriffith: yup :)
20:14:56 <ttx> http://www.stackalytics.com/?release=icehouse&metric=commits&project_type=all&module=cinder-group&company=&user_id= looks sane too
20:15:18 <russellb> nice balance there
20:15:58 <russellb> jgriffith: you guys going to push for driver CI?
20:16:03 <russellb> just curious really
20:16:33 <jgriffith> russellb: indeed
20:16:36 <jgriffith> russellb: we are
20:16:43 <jgriffith> russellb: but there's already some angst
20:16:47 <russellb> heh, i'm sure
20:16:56 <jgriffith> I'm leaning towards opt in for Juno and see how it goes
20:17:12 <jgriffith> I'd like to think folks will step up on their own
20:17:13 * mordred predicts it will not go anywhere until it's mandatory, based on past experience
20:17:16 <jgriffith> no threats etc
20:17:18 <ttx> jgriffith: so it looks like gap is just public docs and coresec team
20:17:27 * mordred hopes jgriffith is right
20:17:28 <ttx> the remaining ones are just recommendations
20:17:29 <jgriffith> ttx: I can live with that
20:17:45 <jgriffith> yeah, probably shouldn't turn it into a design summit session :)
20:17:47 <ttx> jgriffith: what would be your plan to tackle both ?
20:18:00 <jgriffith> The doc part is easy
20:18:06 <ttx> I guess we can solve cinder-coresec in a matter of days
20:18:09 <jgriffith> wiki page with the official stuff
20:18:16 <ttx> just find a couple volunteers we can hassle
20:18:20 <jgriffith> coresec that's sort of hard
20:18:28 <jgriffith> ^^  the volunteers part :)
20:18:33 <russellb> just make it you :-p
20:18:43 <ttx> I have names I can suggest from the past :)
20:18:43 <jgriffith> russellb: might not be very secure
20:18:55 <jgriffith> ttx: that would be great
20:18:59 <ttx> anyway, I think we can even solve that one prerelease
20:19:04 <dhellmann> jgriffith: it's just an initial contact, right? you can pull in help
20:19:04 <ttx> will be in touch
20:19:22 <jgriffith> dhellmann: I would hope so yes
20:19:25 <ttx> yes, it's just the set of folks we add to bugs in the first step
20:19:28 <russellb> yep that's the idea
20:19:38 <jgriffith> dhellmann: but I would like to have folks that are more security minded than I keeping an eye on things
20:19:38 <ttx> then those can add more to the ACL
20:19:44 <dhellmann> jgriffith: sure
20:19:47 <sdague> mordred: it will be interesting data to see if voluntary works
20:20:05 <ttx> "doc part is easy": do you have an ETA on that ? pre-release ? juno-1 ?
20:20:09 <russellb> nobody did it for nova until it was mandatory
20:20:11 <sdague> and actually really good to have data on the various approaches for driver testing from nova, neutron, and cinder
20:20:11 <russellb> fwiw
20:20:15 <jgriffith> sdague: I'm not sure I want to do a blast call for volunterrs
20:20:24 <mordred> sdague: ++
20:20:32 <ttx> #info two gaps identified: public docs and cinder-coresec team
20:20:56 <ttx> jgriffith: "doc part is easy": do you have an ETA on that ? pre-release ? juno-1 ?
20:21:08 <jgriffith> Monday
20:21:18 <ttx> ok, pre-release
20:21:24 <jgriffith> I'll quit putting it off finally
20:21:29 <ttx> #info Both gaps shall be addressed before icehouse release
20:21:55 <ttx> OK, I think that covers it for me. More comments/suggestions ?
20:22:20 <jgriffith> thanks for the input everyone
20:22:34 <jgriffith> I'd like to focus on some of those suggestions for juno
20:23:26 <annegentle> doc deadlines are good! :)
20:23:30 <ttx> Last question on this: any suggestion on which project we should cover next ?
20:23:46 <ttx> we emptied our list of TC+PTL projects
20:24:01 <ttx> (although we still need to reveiw and bless neutron's plan)
20:24:23 <russellb> python -c 'import random ; print random.choice['swift', 'ceilometer', ...]'
20:24:46 <russellb> syntax fail
20:24:48 <sdague> heh
20:25:00 <russellb> how about ceilometer?
20:25:00 <ttx> ok, nothing urgent ? I heard some people wanting we do ceilometer next
20:25:05 <russellb> there we go :)
20:25:26 <ttx> OK
20:25:31 <sdague> well, what about asking existing PTLs for volunteers
20:25:38 <lifeless> crickets
20:25:48 <sdague> because there will need to be prep work for a bunch of them
20:25:52 <dhellmann> yeah, it's going to take some time to put together the docs, we should give them a heads-up
20:26:00 <ttx> sdague: there is a bit of a timing issue with PTL elections, which we'll discuss in open discussion at the end of meeting
20:26:03 <sdague> and making sure they are able to schedule the prep work would be good
20:26:09 <sdague> ttx: sure
20:26:16 <ttx> ok, let's go back to this at end of meeting
20:26:19 <ttx> #topic New graduation / post-graduation requirements
20:26:24 <ttx> This has been split into three separate changes:
20:26:29 <ttx> * Add API graduation/post-graduation requirements (https://review.openstack.org/#/c/68258/)
20:26:34 <ttx> * Add Heat integration post-graduation expectation (https://review.openstack.org/#/c/81773/)
20:26:41 <ttx> * Add Horizon integration post-graduation expectation (https://review.openstack.org/#/c/81774/)
20:27:02 <ttx> I think they all "officialize" defacto policy
20:27:06 <ttx> I'm personally fine with all of those. Any more discussion needed on that ?
20:27:29 <mordred> I think they're great- except I think that the horizon one is too vague/loose
20:27:44 <dhellmann> is the plan to list each project like that? for example, should jd__ or I propose one to add ceilometer?
20:27:58 <mordred> not enough to suggest a change - just saying, I think it's too friendly
20:27:59 <sdague> I'm still a little skeptical on heat at this point, just because even though it's integrated, it's really minimally tested and documented compared to other projects
20:28:16 <annegentle> I still feel like we have a lost opportunity for better user experience by better defining the Dashboard or CLI requirements from an end-user perspective
20:28:26 <ttx> dhellmann: if you think ceilometer integration should be a post-graduation pre-release thing, yes
20:28:28 <russellb> we can always make it more strict later
20:28:35 <russellb> the heat/horizon stuff is listed as post-graduation right now
20:28:38 <russellb> better than not listed at all
20:28:40 <annegentle> so yea, concerns with vagarity, but are we actually relying too heavily on Horizon the project when there's a larger design need?
20:28:44 <sdague> I'm personally bootstrapping on heat right now to help on the testing front, and you run into walls pretty quick unless you go and read the heat source code
20:29:28 <devananda> not to be pedantic, but I'd like to understand what determines whether a given project "makes sense" to integrate with existing projects (heat, ceilometer, horizon, etc)
20:30:26 <ttx> mordred, devananda: so you'd rather keep case-by-case intgegration guidelines ?
20:30:54 <ttx> mordred, devananda: because there is no one-size-fits-all wrt integration ?
20:31:01 <devananda> ttx: or perhaps merely be more explicit about when it is / isn't expected
20:31:01 <mordred> I'm not saying that at all
20:31:17 <mordred> I'm saying "projects should have support in horizon" not "projects should be supported in horizon if it makes sense"
20:31:24 <devananda> ttx: if "it makes sense to teh TC at the time the project applies to incubation" is clearer, taht's fine.
20:31:30 <mordred> I think "if it makes sense" makes the statement meaningless
20:31:58 <devananda> eg, heat integration for ironic does not make sense /to me/, because I think we get that via nova
20:32:20 <dhellmann> that goes to what markmc said in  one of the review comments about requiring an API and tripleo -- it feels weird to me to say that only API projects are integrated, especially if that means our deployment tool won't be
20:32:45 <dhellmann> at the same time, I don't know if tripleo needs to be integrated with horizon, so...
20:32:58 <dhellmann> (at least not in the sense that we mean for these other projects)
20:33:00 <sdague> devananda: ironic is never expected to be called directly without nova?
20:33:02 <ttx> dhellmann: I wouldn't call tripleo a deployment tool, but I see your underlying point
20:33:07 <devananda> but the current wording does not specify to whom a given project integration should make sense
20:33:32 <mordred> I think I could reword my opposition to the current wording based on what devananda just said
20:33:32 <devananda> sdague: not never -- but it makes no sense to me for heat to do node enrollment
20:33:41 <dhellmann> devananda: isn't it implied that judgement is left up to the TC?
20:33:51 <markmc> dhellmann, the idea is definitely for tripleo to be integrated with horizon - i.e. as a UI for managing OpenStack itself
20:34:05 <devananda> dhellmann: the whole point of these changes is to make explicit what is currently implicit :)
20:34:15 <dhellmann> markmc: so there will be a horizon UI page to talk to tripleo?
20:34:22 <markmc> dhellmann, right
20:34:26 <lifeless> dhellmann: 'tuskar' specifically
20:34:29 <dhellmann> ah
20:34:31 <lifeless> dhellmann: which is one of the projects under tripleo.
20:34:38 <markmc> the "makes sense" part was mostly about whether Heat integration always "makes sense"
20:34:48 <lifeless> dhellmann: tuskar builds on heat/nova/neutron/glance
20:34:52 <markmc> e.g. is there any resource in ceilometer that should be provisionable via Heat
20:35:08 <lifeless> dhellmann: and tuskar-ui - the horizon code to do this - is *already* in the horizon programme
20:35:11 <mordred> I could also see there being horizon integration for ironic that makes sense
20:35:12 <dhellmann> lifeless: ok, I'm behind in my tracking of tripleo so thanks for filling that in :-)
20:35:34 <lifeless> its not in the main repo yet AIUI but thats because tuskar isn't incubated yet
20:35:51 <lifeless> horizon pages for Ironic totally makes sense
20:35:52 <markmc> for me, the precise wording isn't a big deal
20:35:53 <lifeless> for admins
20:35:55 <sdague> so maybe my concerns will all be addressed when we do the heat project review and get a gap plan in place
20:36:05 <mordred> markmc: wasn't there an idea that ceilometer would inform heat about things to be able to make scaling decisions on things?
20:36:10 <markmc> it's about getting it onto the radar of prospective projects that we will look at their level of heat and horizon integration
20:36:13 <sdague> mordred: it does that
20:36:16 <ttx> sdague: we should do heat next!
20:36:22 <dhellmann> mordred: alarms are already implemented, yes
20:36:28 <mordred> yah. so that woudl be the ceilometer heat integration, no?
20:36:41 <markmc> mordred, yeah, that's different from the kind of integration described by the requirement, though
20:36:57 <mordred> perhaps calling out explicitly that integrated projects should integrate with each other, rather than enumeration or specific projects then?
20:37:10 <ttx> timeboxing this to 4 more minutes, then we should continue discussion on the review itself
20:37:21 <mordred> ttx: I can shut up and move this offline
20:37:25 <markmc> I think we're over-thinking this :)
20:37:27 <dhellmann> mordred: I thought about that too, but we need a matrix *somewhere* for the reviews, so might as well put it here
20:37:29 <mordred> I'm mostly happy with the sentiment
20:37:36 <mordred> dhellmann: kk
20:37:38 <sdague> I'm 100% good with openstack stuff should integrate well with other openstack stuff. Like the fact that glance and cinder use swift when appropriate (and would expect other things that want to store data to do the same)
20:37:40 <ttx> mordred: no no 4 more minutes is fine :)
20:37:51 <sdague> do we really want to call out only heat and horizon in this regard
20:38:07 <markmc> we're calling out some obvious/likely integration points, that's all
20:38:11 <sdague> ok
20:38:21 <mordred> sdague: I think that's the question - do we want to make a matrix? or do we want to perhaps make a list at incubation time of things we expect a project to integrate with?
20:38:33 <ttx> sdague: I think the idea was to acknowledge that horizon panels won't land in horizon until the project is graduated and in the integration cycle
20:38:35 <mordred> so that it's custom-fit for each project at a time
20:38:37 <dhellmann> sdague: I'd like to add ceilometer, at least for metering resources managed by the project -- where appropriate
20:38:39 <markmc> what else would be on the list?
20:38:50 <devananda> ttx: that seems backwards
20:38:53 <markmc> as obvious integration points that most projects should consider?
20:38:59 <dhellmann> mordred: a list at incubation time is another good way to handle it
20:39:08 <devananda> ttx: eg, nova.virt.ironic has to land befoer ironic graduates. why would a horizon ironic panel have to land *after* graduation?
20:39:36 <ttx> devananda: it's different, because you're replacing functionality that exists in nova
20:39:45 <devananda> ah
20:39:51 <ttx> so you fall under the "replacing stuff" guidelines
20:39:58 <dhellmann> devananda: the work might be done before graduation, but not committed until after
20:40:04 <mordred> I think that, since it's possible to have external horizon panels
20:40:13 <ttx> dhellmann: it's usually done before and shipped as an add-on
20:40:16 <mordred> that one could argue that having a horizon panel could be a graduation requirement
20:40:24 <dhellmann> ttx: right, I meant committed to horizon
20:40:25 <mordred> but having it inside of horizon is a post-graduation action
20:40:27 <ttx> mordred: it actually is. As an add-on
20:40:38 <mordred> right. I'm saying as a policy clarification
20:40:41 <devananda> right. otherwise, I'll postpone work on integration with horizon until after Juno, which seems to be the opposite of what this change says
20:40:42 * dhellmann loves it when we all agree
20:40:51 <ttx> awesome, let's move on then :)
20:40:57 <mordred> horizon panel good. four legs bad
20:41:00 <devananda> :)
20:41:06 <ttx> continue on the review if needed
20:41:12 <sdague> so I think there was something else that got lost previously as well about upgrade jobs
20:41:12 <ttx> #topic Add the requirements repo to the release program
20:41:18 <sdague> I'll propose that as another review
20:41:24 <ttx> #link https://review.openstack.org/#/c/82167/
20:41:29 <ttx> This was proposed following the discussion from last week
20:41:43 <ttx> I'm fine with it but since it used to be an orphaned project under the TC supervision, I'll wait for this to reach the normal approval threshold (7 YES) before approving it
20:41:53 <ttx> Comments on that one ?
20:42:26 <dhellmann> one point that was raised was what this would do to the list of people who vote on the release manager position
20:42:27 <jeblair> it has >7 yes now.  :)
20:42:32 <ttx> jeblair: dammit
20:42:34 <mordred> ttx: does that mean that you're now the person who nominates and manages core?
20:42:45 <dhellmann> I don't think that matters myself, but I wanted to point it out
20:42:55 <ttx> mordred: I delegated that to dhellmann successfully :)
20:43:00 <mordred> ttx: nicely done
20:43:02 <jeblair> nice
20:43:13 * dhellmann feels tricked
20:43:34 <ttx> mordred: I don't feel comfortable editing and suggesting with my petty number of requirements-core reviews
20:43:41 <ttx> arguably I wasn't even core myself a week ago
20:43:57 <ttx> I'm happy to select the right person though
20:44:14 <dhellmann> I've only proposed removing a few inactive members, with no response afaict
20:44:14 <annegentle> oh good point, hadn't thought of that
20:44:17 <ttx> i'm also happy that we get requirements patch authors to vote in the release management program PTL election now
20:44:29 <annegentle> yeah sounds like ttx has himself a core team
20:44:32 <ttx> adds a bit of diversity
20:44:49 <ttx> dhellmann: cool, nuke'em
20:44:55 <anteaya> #link https://wiki.openstack.org/wiki/Release_Cycle_Management
20:44:55 <dhellmann> ok
20:45:04 <mordred> woot! I get to vote on ttx
20:45:04 <anteaya> for release cycle electorate
20:45:17 <russellb> go go ttx
20:45:30 <ttx> we also consider PTLs as release program members fwiw
20:45:51 <ttx> (integrated projects ptls)
20:46:01 <ttx> Anyway.. next topic then
20:46:04 <ttx> #topic Minor governance changes
20:46:11 <ttx> * Add nova-specs to the Compute program [https://review.openstack.org/#/c/81374/]
20:46:15 <ttx> Russell +1ed so I'll approve now unless someone objects
20:46:21 <ttx> * Add ironic-python-agent to Ironic program [https://review.openstack.org/#/c/82157/]
20:46:26 <ttx> Devananda +1ed so i'll approve now unless someone objects
20:46:35 <ttx> * Adds incubated and integrated release names to programs.yaml [https://review.openstack.org/#/c/81859/]
20:46:45 <ttx> I think this one needs a few format changes and iterations before landing
20:47:06 <ttx> annegentle: feel free to rebut my rebuttal.
20:47:16 <dhellmann> annegentle: thanks, I updated the wiki page
20:47:29 <dhellmann> oops, I mean anteaya
20:47:36 <anteaya> dhellmann: thanks
20:47:49 <anteaya> we get each others mail all the time
20:47:52 <annegentle> heh
20:48:04 <dhellmann> auto-complete fails again
20:48:05 <ttx> #topic Open discussion
20:48:15 <ttx> Wanted to quickly discuss whether we should hold TC meetings during the PTL election season, which starts Friday
20:48:24 <ttx> We still have two potential meetings before the TC election process starts
20:48:33 <anteaya> #link election timing: http://lists.openstack.org/pipermail/openstack-dev/2014-March/030444.html
20:48:39 <ttx> But I wonder if we should have more "integrated projects vs. new requirements" reviews while the PTL elections are running
20:48:56 <mordred> ttx: I'd say yes - we can still review current state
20:48:56 <ttx> markmcclain asked that we postpone the plan review until mid-April
20:49:08 <jeblair> i think so, we have so many of those to do i don't want to get further behind
20:49:15 <ttx> so that would be for the new committee
20:49:22 <mordred> and running for PTL isn't exactly like running for president in the US
20:49:28 <lifeless> meetings should keep going IMO
20:49:32 <lifeless> we have a full plate
20:49:39 <dhellmann> +1 to continuing
20:49:40 <markmc> and we should be nervous if a new PTL means a radically different direction for a project
20:49:45 <mordred> ++
20:49:45 <ttx> OK, so let's continue during the PTL election season
20:49:50 <jeblair> if you are running for president in the us, i think we can excuse you from the meetings.
20:50:03 <russellb> markmc: +1
20:50:04 <ttx> we'll still skip the two weeks of the TC election process, right ?
20:50:06 <mordred> jeblair: bah. an hour a week is not that much time to ask :)
20:50:10 <mordred> ttx: why?
20:50:23 <ttx> mordred: dunno, that's what we used to do in the past
20:50:28 <ttx> tradition, you know
20:50:31 <mordred> ttx: we skipped meetings a lot in the past
20:50:31 <russellb> i think we have too much to do
20:50:33 <ttx> like killing turkeys
20:50:37 <mordred> I think we should potentially meet more, not less
20:50:42 <russellb> +1
20:50:49 * dhellmann has some patches mordred could write if he needs more to do
20:50:50 <sdague> yeh, might as well push forward
20:50:56 <russellb> keep pushing through, if the group changes the next week, so be it
20:50:59 <russellb> but push forward
20:51:03 <sdague> agree
20:51:06 <russellb> we can't skip 4 weeks every 6 months
20:51:07 <russellb> IMO
20:51:14 <sdague> at least 6 of us will be here through it anyway
20:51:19 <ttx> OK, I just didn't want having TC meetings during election giving undue exposure to current members seeking reelection
20:51:21 <dhellmann> sdague: good point
20:51:41 <ttx> but if everyone is fine with that, let's just do it
20:51:43 <dhellmann> ttx: anyone can come to these meetings, right?
20:51:50 <ttx> dhellmann: yes
20:52:05 <annegentle> ttx: yeah continuity is valuable
20:52:13 <mordred> ++
20:52:23 <ttx> ok, great. That's all I had
20:52:25 <sdague> I think if people have a grudge against a tc member, it's not going to dramatically get better or worse during election week
20:52:36 <ttx> anything else anyone ?
20:52:59 <ttx> zehicle_at_dell: did you get all the clarification you wanted for the defcore meeting time ?
20:53:16 <zehicle_at_dell> ttx, yes
20:53:32 <ttx> zehicle_at_dell: I'll miss it, I have a real-life city council to attend
20:53:48 <jeblair> russellb: did you get the clarification you wanted for the meeting time?
20:53:55 * ttx is elected to too many official positions
20:53:55 <russellb> yes
20:53:57 <russellb> 8pm UTC
20:54:28 <ttx> zehicle_at_dell: you have 6minutes if you want to quickly expose defcore progress. From what I saw you made great progress recently
20:54:50 <ttx> mikal is absent but I think annegentle could corroborate
20:54:53 <annegentle> real life city council!
20:55:00 <ttx> annegentle: small city.
20:55:12 <annegentle> I do apologize for derailing the email thread there.
20:55:12 <zehicle_at_dell> ttx, ok
20:55:39 <zehicle_at_dell> Basically, we've almost completed the first pass on the capabilities scoring
20:55:40 <ttx> zehicle_at_dell: what do you think about the suggestion to hold all the discussion on defcore list ?
20:55:50 <zehicle_at_dell> I think that's one of the critical things for people to review
20:55:52 <ttx> cross-posting to TC list makes it a bit weird to follow
20:56:04 <ttx> especially with delayed moderation :)
20:56:07 <zehicle_at_dell> because it gives early guidenance about some of the must-pass categories and gaps
20:56:47 <zehicle_at_dell> I've been trying to add people to the DefCore list w/o moderation if I get to the request first
20:57:15 <ttx> zehicle_at_dell: that's great -- I think we can remove openstack-tc from the cc: now
20:57:29 <zehicle_at_dell> +1
20:57:55 <sdague> zehicle_at_dell: any chance of getting some sample data for the tests off of real clouds in the near term. I feel like that would help inform the rest of the conversation with seeing what the wilds actually look like right now
20:58:14 <zehicle_at_dell> yes, we're working actively on that w/ RefStack
20:58:24 <zehicle_at_dell> that's the idea w/ TCUP
20:58:32 <zehicle_at_dell> and uploading the results to RefStack as a site
20:58:44 <sdague> yep, just curious if you had an ETA for some initial sample set
20:59:07 <zehicle_at_dell> sdague, soonest possible.  we're working on it.  merging some code together
20:59:26 <russellb> uploading to a site?
20:59:28 <russellb> curious what that means
20:59:55 <russellb> collection of results for all these different things it has been run against?
21:00:04 <russellb> looks like we're out of time
21:00:06 <ttx> ok, time is up...
21:00:06 <russellb> can talk friday
21:00:11 <ttx> more on friday!
21:00:18 <ttx> Thanks everyone
21:00:22 <annegentle> thanks all
21:00:25 <ttx> #endmeeting