21:05:13 <ttx> #startmeeting project
21:05:14 <markmcclain> russellb: yep filling in today
21:05:15 <openstack> Meeting started Tue Aug  5 21:05:13 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:05:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:05:18 <openstack> The meeting name has been set to 'project'
21:05:20 <ttx> Agenda for today is available at:
21:05:23 <mordred> mikal: just to be clear though - if you ever feel as if any of the people working for me actually represent the views of HP, please tell me and I'll have them whipped
21:05:28 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:05:34 <mikal> mordred: lol
21:05:39 * devananda retires from the meetings, gets some more rest, and plans to read the project meeting logs later
21:05:43 <ttx> #topic Program news
21:05:46 <david-lyle> o/
21:05:52 <ttx> We skipped 1:1 syncs today except for Nova (which was skipped last week)
21:05:57 <ttx> So the log only includes Nova this week:
21:06:03 <ttx> #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-08-05-08.04.html
21:06:11 <ttx> If you have news, you can speak now in #info lines
21:06:12 * SergeyLukjanov here
21:06:19 <ttx> Anything worth mentioning ?
21:07:16 <ttx> OK then, probably not... one single item on the agenda then
21:07:22 <ttx> #topic Nova/Neutron migration and other Neutron gaps
21:07:31 <ttx> At the TC meeting last week we reviewed progress on the integration gap coverage plans
21:07:41 <ttx> Neutron was flagged as needing extra discussion, especially where progress affects Nova
21:07:51 <ttx> So we decided to abuse a cross-project meeting to discuss that, since it's really a cross-project issue :)
21:08:11 <ttx> last week we skipped it due to nova mid-cycle meetup
21:08:16 <russellb> jay pipes started a thread about this
21:08:17 <ttx> so it's happening today
21:08:18 <russellb> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/041931.html
21:08:29 <sdague> there was also much discussion at the nova meetup about this given that markmcclain was there
21:08:37 <mikal> Yeah, it was good of him to come
21:08:43 <mikal> Very helpful
21:09:05 * eglynn joins the fun belatedly ...
21:09:32 <russellb> kind of seems best to continue that thread ... everyone has been in support of cold migration so far
21:09:41 <russellb> anyone here *not* like that?
21:10:00 <mikal> I am ok with that, noting that some people have already done hot migrations
21:10:00 <dhellmann> seems like a good approach to me, for the reasons stated in the thread
21:10:07 <markmcclain> I think that documenting cold migration makes the most sense
21:10:15 <clarkb> also worth noting that infra/qa is working on making it possible to test this stuff with grenade
21:10:25 <russellb> clarkb: fancy
21:10:26 <clarkb> markmcclain: so we may have a bit more than just documentation to give people
21:10:42 <dhellmann> cool
21:10:48 <markmcclain> clarkb: cool
21:10:55 <russellb> and as far as the TC is concerned, as long as the two projects are in agreement, we should be fine in terms of the gap
21:11:04 <russellb> as the requirements are just that a plan of some sort exists, and both projects agree to it
21:11:26 <sdague> russellb: agreed. I think it's more realistic of what people will actually do as well.
21:11:32 <russellb> agreed
21:11:35 <markmcclain> +!
21:11:39 <mikal> Heh
21:12:08 <russellb> we all just very peacefully agreed, how nice :)
21:12:26 <mikal> We can argue for a bit if you want
21:12:28 <ttx> what what
21:12:29 <dhellmann> go team! :-)
21:12:29 <mikal> :P
21:12:31 <russellb> nah.
21:12:32 <sdague> heh
21:12:36 <markmcclain> I'll update the wiki to reflect the change
21:12:47 <mikal> If someone really really needs a non-cold migration, they can help develop it
21:12:48 <russellb> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage
21:12:49 <sdague> that being said, something that was slid past was scaling issues in neutron itself.
21:12:55 <sdague> at least at the meetup
21:12:57 <russellb> i think 7 is in the biggest need of clarification
21:13:15 <russellb> i considered 7 to be the gap that was supposed to cover scaling issues
21:13:20 <sdague> and it's worth noting that we're actually finding elastic recheck bugs that we were tracking in the gate in nova show on both rax and hp cloud
21:13:22 <russellb> basically, "neutron with open source plugins needs to not suck more"
21:13:48 <russellb> i started trying to add more verbiage here: https://etherpad.openstack.org/p/neutron-gap-clarification
21:13:52 <clarkb> I will send mail about what sdague says shortly
21:13:55 <sdague> as in the reasons nodepool gets slow is that neutron falls over
21:14:06 <sdague> yeh, clarkb has all the details
21:14:15 * ttx prefers "cold migration" soon rather to "hot migration at the end of time"
21:14:21 <russellb> ttx: +1
21:14:25 <russellb> markmcclain: see that link ^^
21:14:30 <mikal> +1
21:14:33 <russellb> we really need to nail down gap 7 ...
21:14:40 <russellb> what 7 is supposed to cover i mean
21:15:22 <markmcclain> russellb: yes
21:15:48 <russellb> and would like to update the wiki with the updates to 5,6,7 once there's some consensus around it
21:16:20 <russellb> posted that to TC list, but no feedback
21:16:51 <markmcclain> gap7 is only change we might to refine further
21:17:03 <markmcclain> 'par' is too fuzzy of term
21:18:31 <russellb> markmcclain: yep, don't have anything concrete
21:18:40 <russellb> which is a problem, of course
21:19:16 <russellb> i think a write-up of known stability / scalability issues is a good place to start
21:19:26 <russellb> and that could include a summary of work done over the last release or 2 to improve things
21:19:29 <mikal> That seems like a fair approach
21:19:38 <mikal> Instead of just saying "fix everything"
21:19:38 <ttx> markmcclain: should we move to juno-3 all the juno-1 and juno-2 targets in that doc ?
21:19:45 <mikal> That could even be just a list of bugs in LP with a tag
21:19:48 <russellb> basically need to convince folks that neutron with an open source backend will be as stable and scalable as nova-network
21:19:49 <russellb> that's the key
21:19:56 <russellb> because right now a lot of people aren't convinced
21:20:03 <russellb> that's the gap i think
21:20:04 <markmcclain> ok that's fine I think we can develop the set of tested limits
21:20:10 <russellb> ok
21:20:37 <ttx> russellb: that's a good way of looking at it, yes
21:20:52 <ttx> "convince folks that neutron with an open source backend will be as stable and scalable as nova-network"
21:21:04 <russellb> yeah, maybe that's what the gap should say
21:21:28 <russellb> anyway, that's all i had for this topic i think
21:21:29 <ttx> is anyone editing the wiki page, or should I take the lock?
21:21:33 * russellb is not
21:21:37 * markmcclain is not
21:21:42 <mikal> Nope
21:21:44 <russellb> ttx: you see my proposed updates on the etherpad?
21:21:46 <ttx> ok, I'm in
21:21:59 <russellb> though some of it is stale already
21:22:32 <ttx> markmcclain: "Gap 3: Neutron as the default in devstack" -> should I move the completion taregt to j3 ?
21:22:42 <markmcclain> yes
21:23:13 <markmcclain> gap5  (DVR) is basically done with a few small cleanups in review
21:23:42 <markmcclain> discussed with others on neutron team work on better scale metrics for this milestone
21:24:26 <russellb> markmcclain: did we ever have the thread about DVR requiring OVS?
21:24:28 * russellb didn't see it
21:25:02 <ttx> markmcclain: is gap 5 done to the point where DVR can be used as eeplacement for Nova multi-host ? Or more work still in-flight to fully support that?
21:25:18 <markmcclain> ttx: it is a functional replacement for multi-host
21:25:39 <ttx> is it usable enough at this point to serve as a functional replacement?
21:25:51 <markmcclain> russellb: the first pass was implementing for OVS since that will perform the best
21:26:07 <russellb> i'm not sure anyone actually cares
21:26:10 <markmcclain> russellb: supporting linuxbridge was on the list for follow up
21:26:11 <ttx> trying to see if we can consider it closed, from the gap coverage perspective
21:26:15 <russellb> i just want to air the question so we have record to point to
21:26:25 <russellb> ttx: i think one last thread is needed
21:26:34 <ttx> ok
21:26:36 <russellb> propose that OVS is a requirement
21:26:39 <russellb> and see if anyone objects
21:26:52 <sdague> russellb: ++
21:26:57 <russellb> probably not honestly
21:27:01 <russellb> but i don't want to assume that
21:27:19 * lifeless is heartily in favour of requiring ovs ;)
21:27:20 <sdague> I would only suggest backfilling linuxbridge if people flip out, because I expect at this point most people to be getting on the ovs band wagon
21:27:29 <markmcclain> russellb: I think that linuxbridge can be feasible if we someone to test and shepard any bug fixes
21:27:42 <markmcclain> the ops that want DVR all wanted OVS
21:27:42 <ttx> ok, I edited gap5 status on the wiki
21:27:57 <sdague> markmcclain: yeh, but I think just putting a stake in the ground and saying you won't is fine as well as long as it's called out
21:28:11 <russellb> yep
21:28:18 <ttx> hmm, I should probably use your text, russellb
21:28:23 <markmcclain> sdague: I'm fine with that
21:28:52 <russellb> ttx: up to you, but it's there if you'd like to use it.  that was the intention :)
21:29:28 <ttx> russellb: if markmcclain feels like it matches his status, I'll just copy-paste it now
21:30:17 <markmcclain> that works
21:30:30 <ttx> ok, copypasting...
21:32:52 <ttx> ok saved
21:33:15 <russellb> lgtm
21:33:17 <russellb> thanks!
21:33:19 <ttx> markmcclain: feeling confident that we can close all in j3?
21:33:51 <markmcclain> I am… live migration was the one I was most worried about
21:34:00 <russellb> i'm at least feeling confident that enough good progress will have been made that we should call this cycle a success
21:34:01 <mikal> Excellent
21:34:14 <russellb> even if some bleeds into next cycle
21:34:17 <markmcclain> now that we've have another path the other options should items we can close
21:37:24 <markmcclain> ttx: looks like you've published the updated wiki?
21:37:34 <ttx> yes: <ttx> ok saved
21:37:42 <ttx> #topic Open discussion
21:37:50 <markmcclain> ttx: thanks missed that
21:39:45 <jeblair> clarkb: ping
21:41:16 <sdague> jeblair: we could proxy clarkb's request
21:41:30 <clarkb> oh pong
21:41:33 <clarkb> sorry
21:41:36 <jeblair> oh yay
21:41:44 <clarkb> so a couple related things are coming up
21:42:12 <clarkb> I am going to switch the zuul default test node type for all projects to trusty in ~2weeks
21:42:44 <clarkb> it is currently precise with a bunch of projects set to trusty. All of the integrated projects should be on trusty at this point so not a huge change there
21:43:09 <clarkb> the second thing, and I will do this at the same time is, upgrading tox to tox 1.7.2 on all of our test nodes
21:43:32 <clarkb> you have probably seen some of my hash seed overrides in tox.ini to make that happen without breaking everything
21:43:34 <jeblair> (for clarity: stable branches and other exceptions do and will still use precise as appropriate)
21:44:02 <clarkb> we need to get those hash seed override changes merged or fix the tests otherwise new tox will break you
21:44:31 <clarkb> now this is important so that we can move python3 testing to py34 on trusty as old tox doesn't grok py34. And it will allow us to go back to not caring a whole lot about which version of tox we have installed which has been annoying
21:44:40 <dhellmann> clarkb: I started running some tests for oslo last week, but didn't finish before my break. Did you do that, or should I continue that work and let you know how it goes?
21:44:40 <sdague> ttx: so specifically reviews like - https://review.openstack.org/#/c/109751/ - which you have a -2 on
21:45:12 <clarkb> dhellmann: you should continue doing that and if you give me a list of things you haven't tested yet I cna help too
21:45:44 <ttx> sdague: ack, needs merge in master first
21:46:05 <ttx> sdague: or do you mean that should go in stable/* FIRST?
21:46:06 <jeblair> ttx: i'm not sure this is the kind of change that rule needs to be applied to
21:46:09 <clarkb> I intend on sending mail to the list once I can hammer down what my schedule looks like
21:46:17 <sdague> ttx: they should go everywhere all at once
21:46:19 <jeblair> ttx: i think it can go in parallel
21:46:24 <sdague> what jeblair said
21:46:27 <clarkb> dhellmann: maybe we can coordinate on that thread and make sure everything is happy
21:46:35 <ttx> jeblair: OK, no technically a backport
21:46:43 <sdague> ttx: this is not so much a backport as a "not have everything die in a fire"
21:46:43 <jeblair> ttx: correct
21:47:36 <ttx> hrm, we have a freeze on stable/icehouse until Thursday... can that wait until then ? Or should I plead to the stable dudes?
21:47:47 <clarkb> ttx: it can probably wait until thursday
21:47:58 <ttx> i can approve the stable/havana one
21:48:08 <clarkb> ttx: I expect to do this in about 2 weeks. that should give us plenty of time to iron out and merge the things we need to merge
21:48:23 <sdague> ttx: realize that anyone trying to run the tarballs with new tox for local QA will explode
21:48:32 <sdague> so there might be value in getting it into the release
21:49:49 <ttx> sdague: ok +2/APRVed for stable/havana
21:50:26 <markmcclain> I agree with sdague and the risk is really low
21:51:09 <sdague> yeh, the risk is very low. All it does is force a python random see for unit tests
21:51:18 <sdague> because new tox randomizes that, which is good practice
21:51:24 <ttx> I removed my -2 on the stable/icehouse one... just frozen until Thursday now
21:51:28 <sdague> but a lot of our unit tests assume hash ordering
21:51:39 <sdague> which is bad
21:51:55 <ttx> So in other news, we'll have a 2014.1.2 this week
21:52:31 <ttx> #info Upcoming 2014.1.2 stable release
21:52:34 <ttx> Anything else, anyone ?
21:53:39 <ttx> guess not
21:53:40 <ttx> #endmeeting