20:02:39 <ttx> #startmeeting tc
20:02:40 <openstack> Meeting started Tue Apr 22 20:02:39 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:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:43 <openstack> The meeting name has been set to 'tc'
20:02:53 <jeblair> o/
20:02:53 <ttx> So... This time it's *really* the last TC meeting for the Icehouse membership :)
20:02:59 <hub_cap> lies ;)
20:03:04 <ttx> Our agenda for today:
20:03:05 <mordred> ttx: you say that every week
20:03:13 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:14 <mikal> Heh
20:03:22 <markmcclain> o/
20:03:30 <ttx> this time I MEAN IT
20:03:43 <ttx> #topic Integrated projects and new requirements: Review Neutron plan to cover gap
20:03:51 <ttx> So... One month ago we went through the gap analysis for Neutron
20:04:11 <ttx> (compared to current integration requirements)
20:04:15 <ttx> This was documented at:
20:04:19 <ttx> #link https://etherpad.openstack.org/p/neutron-nova-parity
20:04:30 <ttx> Now we need to have a clear plan to address those gaps during the Juno cycle
20:04:42 <ttx> Since it's been a few cycles that we are talking about closing the gap, we need a detailed plan with actionable deadlines that the TC can check
20:05:01 <ttx> mestery: hi!
20:05:06 <mestery> ttx: hi!
20:05:07 <devananda> so o/
20:05:22 <mestery> markmcclain and I both going to talk about this.
20:05:25 <mestery> #link https://etherpad.openstack.org/p/neutron-nova-parity-gap-analysis-coverage-plan
20:05:29 <ttx> I know markmcclain had been working with neutron-core on getting a plan together
20:05:35 * ttx reads
20:05:37 <mestery> ttx: yes
20:05:57 <mestery> markmcclain and I spent some time coming up with this plan for Juno.
20:06:46 <sdague> mestery: I feel like the db migration issue is a big enough deal that it probably warrants it's own called out it
20:06:48 <sdague> item
20:07:12 <mestery> sdague: I agree, I will rework this to include that as it's own issue here. Thanks for bringing that up!
20:07:49 <dhellmann> are you talking about a different issue than the one on line 12?
20:07:54 <russellb> with tempest, it's not just missing test cases, right?
20:08:05 <sdague> and in reality #3 is going to come after a lot of the rest is done, because we don't want to make the defaults for people in devstack regress
20:08:09 <mestery> dhellmann: The one on line 12 is a symptom of the actual issue.
20:08:27 <sdague> dhellmann: no, it's the same issue, but it's a big architectural issue
20:08:33 <ttx> mestery: do you think you could set a milestone target for each of those ? juno-1, juno-2, juno-3 ? They will be roughly the 3 thirds of the cycle
20:08:46 <mestery> russellb: The initial gap was around missing tests, but expanded coverage there and in functional testing is also important.
20:08:53 <lifeless> o
20:08:58 <markmc> "Neutron Replacement for Multi-Host Functionality - OVS will be minimum requirement"
20:09:03 <lifeless> o/ - doing breakfast for the family but msotly here
20:09:03 <russellb> not just missing tests, but not running all of the existing tests
20:09:05 <dhellmann> sdague, mestery : ok, I think you're agreeing and that I understand
20:09:05 <mestery> ttx: Yes, that makes sense.
20:09:13 <markmc> nova-network parity will require Open vSwitch? that's a bit of a head-scratcher
20:09:31 <russellb> markmc: true, not exactly parity
20:09:39 <ttx> (juno-1 mid-June, juno-2 second half of July, juno-3 start of September)
20:10:00 <mestery> The DVR solution being developed to close the multi-host gap is targeted at OVS right now.
20:10:07 <mestery> DVR=Distributed Virtual Router (FYI)
20:10:12 <sdague> on the tempest front, I haven't looked recently, but the gaps are really pretty small
20:10:18 <russellb> sdague: cool.
20:10:21 <ttx> that would give a general indication of how late in the cycle each of those are expected, and give us sync points to see if anything is going over
20:10:28 <mestery> sdague: That's thanks to the great work of mlavalle and team!
20:10:30 <russellb> ttx: yes, that'd be nice
20:10:36 <sdague> russellb: yeh, a lot of work done in icehouse to close that
20:10:41 <russellb> and i really can't emphasize how important i think actually closing all of these gaps is ...
20:10:55 <russellb> or else we really need to re-evaluate neutron's status in openstack
20:11:08 <markmcclain> sdague: right we should be able to enable the full job voting right about.. salv-orlando was working on that
20:11:38 <sdague> mestery: so there is no way to do something as simple as the existing bridge model in n-net? ovs does seem like a big requirement jump.
20:11:39 <mestery> russellb: Absolutely. It's neutron's top priority in Juno.
20:11:42 <markmcclain> so for gaps 1,2,4,5 anticipate Juno-1
20:11:46 <russellb> i think enabling the full job, and it running successfully / stable, should be listed explicitly
20:11:48 <ttx> adding milestones to the plan
20:11:53 <markmcclain> for 3,6,7 anticipate J-2
20:12:23 <markmcclain> russellb: ok will update plan
20:12:56 <markmcclain> I think we forgot to share that I'll be point of contact leading the parity effort for Juno
20:12:59 <mestery> sdague: The ML2 plugin does support LB, but the work to do DVR is all based on OVS at the moment.
20:13:11 <mestery> Yes, thanks markmcclain for volunteering for that!
20:13:29 <ttx> I think (2) needs to be completed by j-2 if we want it to be useful for release work
20:13:44 <sdague> mestery: right, but if we are talking about a migration path from existing n-net, it feels like that should support the existing model. Otherwise it's not much of a migration path.
20:13:44 <markmcclain> ttx: agreed
20:13:52 <markmcclain> I hedged a bit because the migration issue right now
20:14:09 <russellb> so the OVS requirement ... this may be more of a nova question, but I guess that doesn't cover everything you can do with nova-network today
20:14:25 <russellb> I'd like to see that explicitly discussed with the nova team
20:14:29 <markmcclain> russellb: it should
20:14:42 <markmcclain> OVS just makes it easier to do a few things on the control plane
20:14:43 <mestery> russellb: OK, I agree, a wider discussion is good there.
20:14:45 <ttx> mestery: I added milestones to the etherpad, you should check them. No idea for (4)
20:14:47 <sdague> is there a design summit session that it fits into?
20:14:53 <jeblair> is neutron in icehouse at a sufficient point that it can be used as a base for a grenade upgrade test to juno?
20:14:55 <mikal> I can see adding OVS to existing deploys making upgrades a lot more complicated
20:14:55 <russellb> as in, is nova willing to deprecate/remove nova-network, even if neutron *requires* OVS, when nova-network did not (to get the same features)
20:15:02 <mestery> ttx: Someone beat me to it :)
20:15:27 <mikal> If there's no appropriate summit session we can make one, right?
20:15:47 <ttx> mestery: ok, sounds all optimistic but then juno-3 is pretty light so we can cover any missed target
20:15:50 <mestery> mikal: We have a DVR session, it woudl be good to discuss it there
20:16:14 <mikal> mestery: what days do neutron run on? Nova is a three day thing, so if its up against a nova thing that's hard
20:16:15 <mestery> ttx: Yes, exactly!
20:16:21 <markmcclain> this is problem we've encountered multiple times already
20:16:23 <jeblair> or will closing the grenade gap involve work on stable/icehouse and juno-master?
20:16:28 <mestery> mikal: Neutron is Wed, part of thur, part of Friday
20:16:29 <markmcclain> the requirements keep changing a bit
20:16:36 <sdague> jeblair: grenade neutron jobs don't work today, due to the issue around neutron migrations
20:16:38 <mikal> mestery: yeah, we directly clash
20:16:48 <mikal> mestery: unless we shut down the nova stream for a session to walk over there
20:16:54 <russellb> do a session in the nova track, while neutron is off
20:16:55 <mikal> mestery: which I think this is important enough to do
20:16:59 <russellb> neutron isn't the whole time
20:17:02 <mestery> mikal: Lets work together to find an appropriate slot.
20:17:07 <ttx> mikal: or find an orthogonal topic to discuss in Nova while this is running
20:17:10 <mestery> russellb: +1 to that!
20:17:19 <russellb> or what ttx said
20:17:32 <mikal> Yeah, we could for example have a sesison Thursday arvo
20:17:34 <ttx> mikal: you need to work on your cloning strategy
20:17:36 <mikal> I will start a mail thread
20:17:43 <mestery> mikal: Thanks!
20:17:43 <mikal> ttx: and my napping strategy
20:17:49 <russellb> mikal: enjoy :-p
20:18:03 <markmcclain> so the OVS thing is new… this was on the original etherpad from a month ago
20:18:06 <mikal> russellb: :P
20:18:11 <markmcclain> why is it now a problem?
20:18:25 <russellb> it's not the TC's call IMO
20:18:33 <russellb> i just want to make sure the nova crowd is OK with it
20:19:02 <mikal> I worry about deploys who can't do OVS for some reason
20:19:07 <markmc> markmcclain, only just noticed now, I guess
20:19:08 <russellb> TC requirement is that nova is OK with deprecating/removing nova-network
20:19:17 <ttx> yes, the TC cares about the existence of a plan to cover the gap and the deadliens in it... not really the details of the plan
20:19:23 <sdague> markmcclain: some times these things come in layers, and things dont' get noticed when other thigns are in the way
20:19:26 <ttx> which are more internal nova-neutron stuff
20:19:29 <markmc> markmcclain, could wind up just being a question of explaining the need for the new req in simple terms
20:19:41 <sdague> we also need to play for a migration grenade job
20:19:52 <sdague> icehouse n-net -> juno neutron
20:20:00 <russellb> yeah, could be fine ... but better have it written out very explicitly on list now, than debate it late juno, when the stakes are higher
20:20:00 <mestery> sdague: Yes, agreed, I think that will be critical as well.
20:20:21 <dhellmann> russellb: ++
20:20:22 <sdague> and that's going to demonstrate some of the challenges in the hop that not one has noticed yet
20:20:22 <jeblair> sdague: in addition to or instead of icehouse neutron -> juno neutron?
20:20:28 <sdague> jeblair: yes
20:20:37 <sdague> in addition
20:20:48 <markmcclain> sdague: yeah agree a grenade update might make sense
20:20:58 <russellb> sdague: ooh, that's a cool idea
20:21:01 <ttx> sdague: should we add db migration as its own gap (like Gap 0) so that the plan is complete and can be blessed by the TC today ?
20:21:07 <sdague> I think for whenever we are deciding that "now is when we expect people to move" we should demonstrate that we can do it
20:21:21 <mordred> sdague: ++
20:21:34 <russellb> i like that
20:21:39 <sdague> ttx: yes, I think we should call that out
20:21:53 <ttx> sdague: care to word it out and add it as Gap 0 ?
20:22:22 <ttx> mestery: check that you agree with sdague's gap 0
20:22:31 * mestery waits for sdague to finish typing
20:22:54 <jeblair> i've added a note on gap2 about the 2 grenade tests
20:23:01 <russellb> jeblair: ++
20:23:29 <markmcclain> jeblair: so which grenade tests nova-net to neutron should be validated?
20:23:29 <ttx> markmcclain: is j-2 still reasonable given the two goals on grenade test ?
20:23:52 <sdague> mestery: ok, I'll let you propose solution
20:23:57 <russellb> also, which nova-net modes for grenade?
20:23:58 <markmcclain> ttx: yes depending on what matrix of testing is desired
20:24:02 <russellb> just one?  all of them?
20:24:09 <russellb> markmcclain: yes, that :)
20:24:11 <mestery> sdague: Thanks! Really, we need to discuss this one a bit more as a neutron team with input from the broader community I think.
20:24:14 <sdague> russellb: we have to pick on
20:24:21 <mestery> sdague: We've discussed a bit on ML and on the bug so far, FYI.
20:24:25 <sdague> pick one, we don't test *every* mode
20:24:38 <sdague> mestery: yep, just want that called out as needed to be solved
20:24:46 <mestery> sdague: agreed
20:25:01 <mestery> sdague: I'll mark myself as owner for now on this one.
20:25:02 <annegentle> russellb: is a mode like flat/flatdhcp?
20:25:16 <markmcclain> annegentle: yes
20:25:17 <markmc> this gap 0 is in https://etherpad.openstack.org/p/neutron-nova-parity ?
20:25:27 <annegentle> k thanks
20:25:27 <ttx> Got a design summit session about that grenade testing ?
20:25:31 <mestery> markmc: It fell out of #2 there.
20:25:44 <sdague> markmc: not that I know of, it was only recently uncovered
20:25:57 <sdague> ttx: there is a grenade general session in qa track
20:25:57 <mestery> ttx: We have a general testing session right now, not a grenade specific one at the moment. But good point.
20:26:16 <sdague> http://summit.openstack.org/cfp/details/381
20:26:24 <ttx> sdague: maybe we should make sure it doesn't happen during Neutron slots
20:26:35 <mestery> ttx: +1
20:26:36 <ttx> sdague: topic for next meeting
20:26:50 <sdague> ttx: sure
20:27:58 <ttx> OK, I think this looks good
20:28:01 <ttx> More comments ?
20:28:16 <ttx> i propose that the next TC reviews progress on that at every milestone
20:28:26 <markmcclain> ttx: +1
20:28:34 <russellb> +1
20:28:34 <mikal> Sounds good to me
20:28:36 <jeblair> ++
20:28:37 <ttx> making sure we are still on track
20:28:38 <mordred> ++
20:29:03 <dhellmann> +1
20:29:09 <ttx> mestery, markmcclain: nice work on the plan
20:29:17 <ttx> SlickNik, hub_cap: around ?
20:29:24 <SlickNik> here
20:29:32 <mestery> thanks ttx!
20:29:34 <ttx> #topic Integrated projects and new requirements: Review Trove plan to cover gap
20:29:42 <SlickNik> #link https://etherpad.openstack.org/p/TroveIntegratedGapPlan
20:29:47 <ttx> At the meeting last week we went through Trove's gaps there ^
20:29:53 <ttx> #link https://etherpad.openstack.org/p/TroveIntegrationRequirements
20:30:04 * ttx reads again
20:30:14 <SlickNik> whoops, sorry ttx posted the plan before you posted the gaps.
20:30:33 <ttx> I'm so predictable
20:30:52 <mordred> SlickNik: so, it just came to my attention that trove only supports nova-network - given the previous discussion, is this something that needs to be called out for this cycle and tracked?
20:31:29 <SlickNik> mordred: We're already working on this and it's a top priority for Juno.
20:31:44 <ttx> mordred: ha?
20:32:01 <mordred> SlickNik: yes - I've just heard that as well - thought I'd bring it up here because I'm guessing none of us thought to ask if you supported neutron
20:32:11 <mordred> I know I didn't
20:32:12 <lifeless> ttx: its due to the neutron namespaced network feature
20:32:12 <SlickNik> mordred: It's complicated. There is limited support, but no tests around it.
20:32:13 * ttx wonders why Trove cares, but hides his ignorance behind silence
20:32:19 <russellb> mordred: good point, sounds like something that should be tracked specifically
20:32:20 * lifeless knew
20:32:29 <ttx> lifeless: ah.
20:32:35 <SlickNik> mordred: And I'm of the view that if it's not tested, we can't claim to support it.
20:32:39 <sdague> ttx: because trove manages provisioning as well
20:32:43 <mordred> SlickNik: I agree with that view
20:32:55 <mordred> :)
20:32:57 <sdague> SlickNik: that seems big enough to call out as a separate item
20:33:02 <russellb> yep
20:33:06 <SlickNik> mordred: So we're adding tests, and have found a couple of issues as part of it already.
20:33:15 <ttx> yes, we missed it during the gap analysis, obviously
20:33:28 <SlickNik> ++ to calling it out officially in the gap and plan.
20:33:30 <ttx> mordred: care to add it as Concern #5 ?
20:33:35 <mordred> ttx: sure
20:34:43 <SlickNik> I can fill in the actions
20:35:21 <SlickNik> but basically - 1. we're adding tests for provisioning with neutron ports / networks
20:35:41 <russellb> tests in tempest?
20:36:15 <ttx> SlickNik: could you fill target milestones in the document ? i.e. the rough dates you expect that work to bne completed (juno-1, juno-2, juno-3 ?)
20:36:38 <SlickNik> russellb: Tests in our functional test system (rdjenkins) for now since the tempest effort is going on in parallel.
20:36:46 <ttx> (juno-1 mid-June, juno-2 second half of July, juno-3 start of September)
20:36:47 <mordred> if we have trove enabled in all of the d-g jobs, then shouldn't we pick up coverage of the different modes since e have nova-network config and neutron-config - as long as there are tests which exercise things/
20:37:09 <SlickNik> russellb: So there is some amount of work to ensure that tempest is also testing this.
20:37:10 <russellb> SlickNik: OK.  I think for the gap to be considered filled, it should be in openstack-infra
20:37:35 <SlickNik> russellb: Yes, there is that overlap between #5 and #3
20:37:54 <russellb> yeah, noted
20:38:40 <SlickNik> mordred: I think that's true. However the trove tempest coverage is pretty poor right now and we're working on getting that up.
20:38:45 <sdague> mordred: yes, but the trove tests are very minimal
20:38:57 <SlickNik> ttx: Will add the milestones
20:39:10 <mordred> yup. I think 3 + 5 == happy bunnies
20:39:12 <ttx> SlickNik: if you add them now we could bless the plan
20:39:24 <SlickNik> Ah, okay
20:40:10 <mordred> annegentle: on point #2 - is that what we're doing with API docs now across the board?
20:40:46 <SlickNik> ttx, added
20:40:52 <ttx> SlickNik: OK, looks optimistic, but I'll take those :)
20:40:52 <annegentle> mordred: so long story, last summit we had a session where we said we wanted to move all <project>-api repos into a <project>/doc/api area
20:41:00 <annegentle> mordred: that move never happened
20:41:18 <mordred> annegentle: k. but it's desired by docs?
20:42:07 <ttx> Plan looks good to me -- other comments ?
20:42:26 <sdague> nope, lgtm
20:42:35 <annegentle> mordred: ttx: wait I'm trying to understand where point #2 is spelled out?
20:43:08 * ttx wonders if we should move those plans somewhere less volatile, like a wiki page
20:43:30 <dhellmann> ttx: it would be nice to have edit history
20:43:30 <mordred> annegentle: concern #2: "    - Currently in the process of moving them over to the trove repository for better locality so it makes it easier to update"
20:43:43 <ttx> dhellmann: right
20:43:46 <mikal> ttx: something more discoverable would be good
20:43:47 <russellb> ttx: could at least snapshot the etherpad
20:43:54 <dhellmann> ttx: also, these colors make my eyes cross :-)
20:44:01 <russellb> so you get a record of its state when we discussed it
20:44:10 <ttx> mestery, SlickNik: do you mind if I copy those etherpads and make them wiki pages ? (tomorrow) ?
20:44:14 <annegentle> mordred: ah. Yes the thinking is that the API specs are a place for devs to discuss changes to the API
20:44:15 <russellb> we could have this proposed to governance ...
20:44:21 <russellb> maybe that's too much
20:44:29 <ttx> russellb: yeah, I think that would be a bit too much
20:44:30 <mestery> ttx: That is fine by me, thanks!
20:44:31 <SlickNik> ttx: be my guest.
20:44:36 <russellb> k
20:44:43 <annegentle> mordred: ideally we'd get all projects to do API docs the same way, we had agreement last summit but the work didn't happen
20:44:49 <ttx> #action ttx to move gap coverage plans somewhere discoverable on the wiki
20:46:13 <ttx> annegentle: does this have to be resolved for the plan to be blessed ?
20:46:25 <ttx> or can it be discussed offline / at design summit ?
20:46:33 <annegentle> ttx: nope I'm fine with the plan
20:46:53 <SlickNik> annegentle: So for #2, grapex is driving the effort and I'll work with him and you to make sure what we're thinking is good with the docs team.
20:47:27 <ttx> OK, so we'll do the same as for Neutron, review progress on the plan at every milestone
20:47:35 <annegentle> gogo grapex
20:47:53 <ttx> #topic Incubation/integration requirements changes
20:48:04 <ttx> * Add upgrade expectations (https://review.openstack.org/87234)
20:48:11 <SlickNik> Sounds good. Thanks all!
20:48:18 <ttx> This looks good to me, will approve once it reaches the threshold
20:48:21 <russellb> SlickNik: thanks, and good luck :)
20:48:22 <ttx> SlickNik: thx!
20:48:48 <ttx> * Add Ceilometer requirements (https://review.openstack.org/85978)
20:48:58 <ttx> There are a few objections to this one, in particular jog0 raises an interesting point...
20:49:09 <ttx> ... that such a requirement looks premature until Ceilometer is more extensively tested at the gate
20:49:16 <ttx> Do you think that's a valid objection, or that it's an orthogonal concern ?
20:49:21 <markmc> I think that's orthogonal
20:49:31 <russellb> +1
20:49:33 <markmc> it's integrated now, we should require projects integrate with it
20:49:40 <markmc> where it makes sense, of course
20:49:46 <sdague> I think we could generalize this whole section of "should use heat, should use horizon, should use ceilometer"
20:49:55 <dhellmann> yeah, it's an integrated project -- we want more testing, but that shouldn't block other projects
20:50:06 <ttx> OK. The wording still needs to be fixed anyway
20:50:14 <ttx> so it's not really ready
20:50:17 <jeblair> markmc, sdague, dhellmann: +1
20:50:25 <dhellmann> sdague: we did think about that, but there may be specific points of integration
20:50:26 <sdague> to something about "we expect projects to use integrated projects for the functions they provide"
20:50:32 <ttx> just wanted to make sure we still wanted it on the drawing board$
20:51:01 <dhellmann> someone also mentioned that having a checklist would help, rather than having to make that list each time we review a project
20:51:19 <russellb> sdague: it goes the other way, too.  we expect the project to work with other projects to consume this one, where it makes sense.
20:51:21 <russellb> or something like that
20:51:27 <sdague> russellb: yep, sure
20:51:45 <russellb> i think listing each project is still OK for now
20:51:49 <sdague> I just think we'd do ourselves a favor by making it more general, and not having every project push in a line for their projects
20:51:59 <russellb> the first case you mentioned is covered by "don't duplicate stuff"
20:52:23 <devananda> fwiw, i agree that general is better here, and require it to be identified when the project enters incubation
20:52:30 <ttx> agree there is room for generalization. We'll see which change gets in first
20:52:44 <ttx> #topic Minor governance changes
20:52:51 <ttx> * Begin conversion to rst (https://review.openstack.org/87579)
20:53:11 <ttx> This one is moving the ball forward on doc publication, it's more a technical change than a policy change so I'll approve it after the meeting, unless someone objects (and posts a -1)
20:53:27 <annegentle> ttx: do you need seven or eight +1s?
20:53:40 <ttx> annegentle: no, i'll just abuse my power
20:53:48 <jgriffith> I just gave the 8'th anyway :)
20:53:55 <ttx> jgriffith: hah!
20:53:58 <annegentle> ttx: ha ha
20:54:03 <ttx> * Add project mission statement for Ceilometer (https://review.openstack.org/87526)
20:54:11 <ttx> This one is still being disputed, so it might need a few more iterations
20:54:21 <ttx> * Adds integrated and incubated release names to programs.yaml (https://review.openstack.org/81859)
20:54:22 <lifeless> I've thrown a -1 up there
20:54:28 <lifeless> for the upgrade one
20:54:38 <ttx> There is good progress here... I think we settled on the format, so now it's just about getting the content right.
20:54:53 <ttx> annegentle: you left out one of my suggestions... was it on purpose ?
20:55:08 <annegentle> ttx: looking
20:55:17 <ttx> I just -1ed your latest
20:56:03 <annegentle> ttx: ah I see, yeah just missed it. Though one Q I did have, does this doc record when the TC meeting occurred? (I thought that was one of the early inputs)
20:56:42 <ttx> annegentle: for future entries it will record when the change was made...
20:56:58 <ttx> but that clearly doesn't work for old entries
20:57:45 <ttx> annegentle: we can always add more keys to that dictionary over time
20:57:52 <annegentle> ttx: ok right.
20:57:59 <ttx> like incubated-in-tc-meeting: 2014-04-10
20:58:08 <ttx> if we really want to track additional data
20:58:18 <ttx> #topic Open discussion
20:58:21 <ttx> * Joint BoD/TC meeting agenda
20:58:29 <ttx> I worked with Alan on defining the content for the joint TC/BoD meeting in Atlanta.
20:58:38 <ttx> Most of the items we proposed for discussion are present in the agenda draft I've seen
20:58:50 <ttx> I think Alan shall post it really soon now, i'll make sure it's sent to openstack-tc as well
20:59:06 <ttx> * TC elections: voting under way
20:59:20 <ttx> We have elections under way, please encourage everyone to vote -- we actually need good participation scores if we want to lecture others on election systems :)
20:59:29 <ttx> Anything else, anyone ?
20:59:51 <anteaya> 26% voter turnout so far
20:59:55 <annegentle> vote vote vote!
20:59:55 <anteaya> talk up voting
20:59:57 <markmc> wow, is that all?
21:00:01 <anteaya> so far
21:00:02 <russellb> ouch
21:00:07 <ttx> We had 31% last time
21:00:08 <anteaya> I think easter weekend cut into it
21:00:09 <sdague> anteaya: when do polls close?
21:00:16 <sdague> we do have > 1000 ATCs
21:00:17 <anteaya> Friday when I wake up
21:00:22 <anteaya> 1510 atcs
21:00:23 <jeblair> ttx: i got the impression the board wasn't very interested in talking about the CLA
21:00:37 <anteaya> after 1300utc
21:00:41 <ttx> jeblair: I asked that it is added to the agenda though.
21:00:45 <jeblair> which is disappointing because i think we are interested, and we're seeing new issues come up
21:00:55 <jeblair> ttx: okay good
21:00:59 <ttx> it's in the current agenda draft, fwiw
21:01:13 <ttx> OK, time is up
21:01:19 <jeblair> it's just reared its head again on the -legal list, based on two recent events
21:01:37 <ttx> Thanks everyone, been a privilege working with you all for this last cycle
21:01:39 <mordred> I loved the "why can't they just sign the CLA, IBM has" response
21:01:55 <jeblair> ttx: seconded!
21:01:58 <annegentle> ttx: thanks for running efficient meetings :)
21:02:02 <mikal> Lovely typing near you all
21:02:04 <ttx> #endmeeting