21:00:47 <mestery> #startmeeting networking
21:00:48 <openstack> Meeting started Mon Feb  2 21:00:47 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:52 <openstack> The meeting name has been set to 'networking'
21:00:55 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:01:01 <mestery> #chair armax
21:01:02 <openstack> Current chairs: armax mestery
21:01:08 * mestery makes armax chair in case his connection dies
21:01:22 * armax sits down
21:01:23 <mestery> So, we have a heavily focused Kilo-2 agenda today, so lets get at it!
21:01:31 <mestery> #topic Announcements
21:01:40 <mestery> Kilo-2 is this week! If things aren't in the merge queue Wednesday, they won't make Kilo-2.
21:01:46 <mestery> Even if they are in the merge queue, they could miss.
21:01:48 <carl_baldwin> pong
21:02:06 <mestery> Note: PLEASE BE CAUTIOUS WHEN MERGING CODE THIS WEEK.
21:02:23 <mestery> Be cautious every week, but especially when we're about to tag and release something. :)
21:02:47 <mestery> I've been yak shaving the Kilo-2 LP page, I expect to remove more things from Kilo-2 tomorrow.
21:02:50 <kevinbenton_> Who tests the tagged releases mid cycle?
21:03:02 <mestery> kevinbenton_: All of our users. I hope. :)
21:03:10 <mestery> kevinbenton_: Seriously, I think distros may do some testing.
21:03:37 <marun> kevinbenton_: isn't the integrated gate assurance enough? ;)
21:03:48 <mestery> o_O
21:04:00 <kevinbenton_> Ah. Most people I encounter are running master devstack if they want to try kilo
21:04:23 <mestery> Lets move on now.
21:04:24 <mestery> #topic Bugs
21:04:27 <kevinbenton_> Sorry for derailing. Was just curious who runs the tagged releases of a dev version
21:04:27 <mestery> enikanorov_ enikanorov__: Hi!
21:04:29 <enikanorov_> hi
21:05:07 <enikanorov_> nothing major this week. few high-priority bugs were fixed like race with subnet deletion and DVR job failures
21:05:44 <enikanorov_> the remaining important bugs are on meeting wiki page
21:05:45 <mestery> enikanorov_: Excellent!
21:05:48 <enikanorov_> mostly unchanged
21:05:54 <mestery> enikanorov_: Thank you.
21:06:06 <mestery> rkukura: Did you want to bringup your bugs around ML2 port binding here now?
21:06:13 <rkukura> sure
21:06:54 <rkukura> Thanks to help from both armax and matrohon, we tracked down why the HPB patches were failing the DVR tempest tests.
21:07:37 <armax> rkukura: not sure I have any merit in this, but the patch it’s on my backlog
21:07:43 <rkukura> I filed two bugs, and https://review.openstack.org/#/c/151913/ fixes both and is also the 1st step of the DVR ML2 schema/logic cleanup.
21:08:24 <rkukura> I think getting this patch (if not the two remaining HPB patches which I’ll update tonight) in for kilo-2 would be ideal.
21:09:06 <rkukura> This patch is also critical for any attempt to use the DVR VLAN support with ML2 mechanism drivers that manage switch based on port bindings.
21:09:40 <mestery> Thanks for the update rkukura.
21:09:40 <rkukura> Aynway, if any cores can look at it, I’d appreciate it.
21:10:11 <markmcclain> rkukura: I was planning to look at it
21:10:20 <rkukura> markmcclain: thanks
21:10:32 <mestery> Thanks markmcclain, armax, since this is DVR related, may be good to get you to eyeball that first patch (https://review.openstack.org/#/c/151913/) as well.
21:10:53 <armax> mestery: yup it’s on my backlog, Vivek also looked at it, which is reassuring
21:11:01 <mestery> armax: ++, thanks!
21:11:16 <mestery> Any other bugs the team should discuss here today?
21:11:30 <armax> there was an interesting turn of events on the DHCPNAK bug
21:11:39 <armax> #link https://review.openstack.org/#/c/152080/
21:12:12 <sc68cal> +1 for that review - I wonder if that also has impact on the big thread kevinbenton_ started about dhcp lease times?
21:13:09 <mestery> armax: Yikes, lots to digest there. Do yo uahve a good summary for us here
21:13:33 <armax> mestery basically we have two compenting proposals
21:13:49 <armax> https://review.openstack.org/#/c/152080/ and https://review.openstack.org/#/c/108272/
21:14:00 <armax> the latter is more complex and it’s been in review for a while
21:14:12 <armax> the former is the underdog, it’s supertrivial and it does look it fixes the problem
21:14:38 <armax> it’s almost too good to be true…so we’re being cautious, carl_baldwin may want to expand a bit, but that’s the gist of it
21:14:46 <markmcclain> we originally made a conscious decision to not use init when we move the functionality over from nova
21:15:11 <carl_baldwin> I think armax covered it.
21:15:39 <carl_baldwin> markmcclain: What was the reason for that?
21:15:49 <markmcclain> complexity
21:16:01 <mestery> 152080 certainly looks cleaner, looks like haleyb has an email out to the dnsmasq list for some guidance here
21:16:08 <markmcclain> required a 2nd level of scripting hooks
21:16:09 <mestery> haleyb: Any word back yet?
21:16:47 <carl_baldwin> markmcclain: I think we’ve boiled a lot of complexity out of 108272.  However, if there is no problem with 152080 then it will be the clear winner.
21:16:54 <mestery> Regardless, sounds like we'll need to wait to hear back before making a decision here.
21:16:59 <mestery> carl_baldwin: ++
21:17:01 <markmcclain> mestery: ++
21:17:34 <mestery> OK, one more opening for bugs today before we move on. Any other bugs to discuss today?
21:18:13 <mestery> #topic Docs
21:18:18 <mestery> sc68cal: Hi! Thanks for subbing for emagana.
21:18:23 <sc68cal> np
21:18:49 <sc68cal> For those interested, the meeting notes from the networking guide meeting are here
21:18:56 <sc68cal> #link http://lists.openstack.org/pipermail/openstack-docs/2015-January/005776.html Networking guide meeting notes
21:19:22 <sc68cal> We have a number of scenarios that we have put together, and it would be great for neutron folk to review, especially the DVR stuff
21:19:40 <sc68cal> make sure all the packet flows are correct and everything is technically sound
21:20:01 <mestery> #info Please review the networking guide and provide feedback
21:20:21 <sc68cal> #link https://github.com/ionosphere80/openstack-networking-guide Networking guide scenarios
21:20:29 <armax> sc68cal: Swami is your man
21:20:45 <sc68cal> agree - he's been attending the meetings iirc
21:20:50 <Swami> armax: mestery : I have already reviewed the alpha version.
21:21:01 <mestery> Awesome!
21:21:02 <armax> Swami: nice
21:21:17 <sc68cal> that's all I have,
21:21:23 <mestery> sc68cal: Thanks!
21:21:34 <mestery> #topic Plugin Decomposition Status and Updates
21:21:43 <mestery> This is a standing item
21:21:52 <mestery> For people to discuss issues around plugin decomposition
21:21:59 <mestery> And for armax to provide us with other udpates here :P
21:22:08 <mestery> Last week, we spent a lot of time here.
21:22:09 <armax> I have a linked spreadsheet on the bp page
21:22:15 <armax> https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition
21:22:20 <anteaya> we had a question in infra earlier today about a spec for testing
21:22:33 <armax> which I use to capture the status updates
21:22:33 <anteaya> we redirected the querent to -neutron
21:22:44 <mestery> #link https://docs.google.com/spreadsheets/d/1OQN0VlKzKC1gYlxgalQXKDTGGWogWFRtD3S5OpepsX4/edit?pli=1#gid=0
21:23:01 <mestery> This is great, thanks armax!
21:23:08 <salv-orlando> anteaya: I'm sorry I must have missed that part? was the question about testing decomposed plugins?
21:23:16 <anteaya> salv-orlando: yes
21:23:17 <armax> I update it as soon as I get to the related reviews that are in my pipeline
21:23:36 <mestery> Looks like we ahve three completely done now (Mellanox, Midokura, and ODL).
21:23:39 <armax> so the current snapshot may not be necessarily updated to the minute
21:23:49 <mestery> #status 3 Plugins completely decomposed (Mellanox, Midokura, and OpenDaylight)
21:23:53 <mestery> OK
21:23:55 <salv-orlando> anteaya: what cluss of tests exactly?
21:23:56 <dougwig> how many to go?
21:24:01 <salv-orlando> dougwig: 200
21:24:03 <mestery> #info 3 Plugins completely decomposed (Mellanox, Midokura, and Op
21:24:08 <mestery> lol
21:24:13 <anteaya> salv-orlando: that was what we didn't know, hence the redirect
21:24:14 <dougwig> :)
21:24:26 <armax> mestery: there may be still loose ends
21:25:05 <salv-orlando> anteaya: I see. From our perspective I have seen different teams setting up unit tests and integration tests on 3rd party repos
21:25:21 <anteaya> salv-orlando: http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2015-02-02.log 2015-02-02T11:44:09  <nfedotov> Hello all! Sorry if I missed something. There is a blueprint https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition What is going to happen with Third Party CIs? Will they continue to test patchsets in openstack/neutron or they should start
21:25:22 <anteaya> testing patchsets of appropriate repo at stackforge?
21:25:37 <armax> anteaya: the decomp should not change that
21:25:38 <mestery> anteaya: they need to keep testing neutron patches
21:25:41 <mestery> armax: ++
21:25:47 <anteaya> they can use our testing system for stackforge repos
21:25:56 <anteaya> but what to test comes from neutron
21:25:59 <salv-orlando> anteaya: This is what I'm doing with vmware plugins - even if decomp is not completed - test all that can affect my plugin in openstack/neutron and report there
21:26:00 <armax> anteaya: 3rd party CI system are supposed to test whatever change impacts the solution they are meant to validate
21:26:08 <salv-orlando> plus test everything that goes in the plugin repo
21:26:23 <anteaya> armax: great, is there some documentation we can point them to in future?
21:26:27 <armax> salv-orlando is right, as a matter of fact when I was in charge of the VMware CI, I was even testing Tempest changes
21:26:36 <armax> not sure if salv-orlando is continuing the tradition
21:26:48 <salv-orlando> armax: meh meh meh gneh gneh gneh
21:26:58 <armax> anteaya: it’s in the blueprint spec, if I recall correctly
21:27:03 <armax> salv-orlando: is that a no?
21:27:10 <anteaya> okay I will look thanks
21:27:16 <armax> salv-orlando: or is it your cat typing?
21:27:24 <salv-orlando> armax: that's a "armax want to moan and whine because that's what he does best"
21:27:35 * dougwig is feeling the vmware love.
21:27:41 <armax> salv-orlando: ah, ok, thanks for claryfing this for the sake of others :)
21:27:44 <salv-orlando> tempest and devstack are still tested with the same paths you specified
21:27:56 <armax> salv-orlando: oh, ya, devstack too
21:28:03 <armax> salv-orlando: good lad
21:28:04 <rms_13> From the packaging perspective, does it make easier if the vendor plugin stays on stackforge? Or it should not matter!
21:28:22 <salv-orlando> rms_13: I think it doesn't, but I'm not a packager
21:28:27 <armax> rms_13: it does not matter
21:28:33 <salv-orlando> I think packagers are happy as long as they can git pull the stuff
21:28:49 <mestery> Or even pull a released tarball
21:29:14 <rms_13> Technically yes, but not sure if we has a community have a feedback from redhats or canonical
21:29:36 <mestery> rms_13: ihar provided this type of feedback on the spec
21:29:36 <salv-orlando> rms_13: asking on the ML won't hurt
21:29:37 <armax> one reminder I have for people is to co-reference the bp/core-vendor-decomposition on the changes they post to gerrit
21:29:59 <armax> so that that gets captured on the Launchpad BP page and it does not get lost
21:30:18 <rms_13> armax: sounds good
21:30:38 <mestery> Any other questions around plugin decomposition from anyone?
21:30:42 <mestery> Good or bad experiences?
21:30:46 <armax> mestery: I am not completed with the devref
21:30:47 <mestery> Anyone send armax flowers yet? :)
21:30:51 <mestery> armax: lol
21:30:53 <mestery> whoops
21:31:03 <salv-orlando> mestery: not flower, but perhaps bullets in an envelope
21:31:07 <salv-orlando> or pigs' heads
21:31:11 <mestery> lol
21:31:16 <armax> mestery: so long as I don’t see dubious packages out my front door, I am happy
21:31:34 <salv-orlando> so I had a little question
21:31:36 <mestery> armax: Hint, if you open the door to a paper bag on fire, don't step on it.
21:31:46 <mestery> :)
21:31:58 <armax> mestery, salv-orlando thanks for the colorful description of the packages I was alluding
21:32:02 <Sukhdev> You guys are having too much fun :-)
21:32:13 <salv-orlando> some decomposed repos have very little patch traffic compared wiht openstack/neutron
21:32:25 <mestery> salv-orlando: As it should be, no?
21:32:37 <salv-orlando> and some do not implement periodic CI checks, mostly because there is no translation patch for them!
21:32:43 <salv-orlando> or requirements patch for that patter
21:32:51 <salv-orlando> this means that when the release day comes
21:33:06 <salv-orlando> we might have plugin repos which have not done a CI run in like 7 or 10 days
21:33:12 <salv-orlando> what do we do about that?
21:33:20 <armax> salv-orlando: as we mentioned earlier, the CI is supposed to test the Neutron changes
21:33:26 <armax> salv-orlando: just as it used to
21:33:37 <rms_13> salv-orlando: In my opinion it should be reported
21:33:41 <salv-orlando> armax: correct, sorry about that. In a perfect world that it correct.
21:33:48 <salv-orlando> in a real world, we will have such plugins.
21:33:51 <salv-orlando> what do we do?
21:33:54 <salv-orlando> deprecate anyway?
21:34:02 <marun> we need periodic jobs
21:34:13 <rms_13> CI should remain unchanged otherwise plugin and vendor compatibility will be out of date
21:34:16 <mestery> salv-orlando: Well, we'd have to let the plugin users know the status of their plugin backend at release.
21:34:24 <mestery> So what about a page listing the last known good CI run?
21:34:25 <marun> anteaya: is this is something supported by infra at this time?
21:34:27 <mestery> At release?
21:34:29 <kevinbenton_> marun: i don't see why. we should just enforce that they test neutron changes
21:34:31 <Sukhdev> salv-orlando: Arista code is out of neutron tree - but, our CI is testing every neutron patch - is that not sufficient?
21:34:40 <kevinbenton_> Sukhdev: +1
21:34:49 <armax> a deprecation decision needs to be taken on a case by case basis,
21:34:50 <salv-orlando> Sukhdev: I am not blaming A or B or C
21:34:55 <rms_13> Sukhdev: +1
21:34:59 <markmcclain> periodic jobs work from openstack/* so I'm assuming the smae machinery is in place for stackforge/*
21:34:59 <anteaya> marun: sweston is working on a tool called radar
21:35:01 <marun> kevinbenton_: um, race conditions?
21:35:02 <kevinbenton_> salv-orlando: what about D?
21:35:06 <anteaya> but it is in development
21:35:11 <salv-orlando> Can't understand what those +1s are for?
21:35:17 <marun> anteaya: cool
21:35:23 <anteaya> so doubtful it will meet your needs in time
21:35:26 <salv-orlando> well it sound like I'm appearing stupid
21:35:32 <salv-orlando> and ignorant, which I probably am
21:35:33 <marun> anteaya: well, better late than never
21:35:34 <kevinbenton_> salv-orlando: no
21:35:42 <armax> but it’s not certainly something we’re thinking of right now…this is a larger discussion that needs to happen regardless of the decomp
21:35:50 <kevinbenton_> salv-orlando: just wondering why testing neutron changes wasn't good enough
21:35:58 <kevinbenton_> but maruns point about a race condition is valid
21:36:04 <salv-orlando> armax: so that is not regulated by the spec?
21:36:08 <anteaya> markmcclain: yes stackfore can use our periodic pipeline
21:36:23 <salv-orlando> kevinbenton_: because some CIs might either fail in doing periodic jobs, or might be failing at all ;)
21:36:48 * salv-orlando hopes he's found a loophole in the spec
21:36:55 <armax> the correctness of a 4rd party CI sytem goes beyond the decomp
21:36:56 <kevinbenton_> salv-orlando: right, but how can we tell where a 3rd party is doing periodic jobs?
21:36:59 <armax> *3rd
21:37:20 <kevinbenton_> armax: decomp just says they have to test all neutron patches, right?
21:37:57 <salv-orlando> kevinbenton_: that is my question too. I guess we have to police those. It's probably not that different from before.
21:37:58 * armax pulls the exact wording
21:38:13 <salv-orlando> armax: that's not necessary, we're wasting precious time.
21:38:14 * mestery hands salv-orlando and kevinbenton_ their neutron CI police badges
21:38:23 <armax> 3rd Party CI will continue to validate vendor integration with Neutron via Tempest (e.g. functional testing); 3rd Party CI is a communication mechanism. This objective of this mechanism is threefold:
21:38:30 * anteaya applaudes
21:38:30 <armax> …
21:38:31 <salv-orlando> mestery: emagana already has that role
21:38:38 <mestery> salv-orlando: He needs some deputies
21:38:46 <armax> salv-orlando: you go read the reast
21:38:47 * anteaya nods
21:38:48 <armax> rest :)
21:38:55 <kevinbenton_> mestery: conflict of interest for both salv-orlando and myself, can't do it ;)
21:38:59 <armax> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html
21:39:01 <mestery> lol
21:39:16 <armax> bottom line is: if a CI system goes tits up
21:39:17 <salv-orlando> by the way, while armax show again that the system is perfect and the people are the issue, I simply suggest that where in the previous versions we had full control over non-CI compliant plugins
21:39:22 <armax> that has nothing to do with the decomp
21:39:34 <armax> why?
21:39:43 <salv-orlando> now we probably need to act differently, or perhaps not?
21:40:02 <armax> we have full control because of the neutron in-tree vendor integration part
21:40:04 <kevinbenton_> salv-orlando: well we can still kick the integration point out of the tree :)
21:40:05 <salv-orlando> I guess at the end of the day we just remove from tree the integration library for
21:40:16 <salv-orlando> the plugins which are not running CI or are evidently broken?
21:40:22 <mestery> salv-orlando: ++
21:40:30 <salv-orlando> ok let's say it's sorted then
21:40:31 <mestery> That's the stick salv-orlando
21:40:34 <armax> if and when folks want to take everything out, they are on their own, just as it is right now
21:41:16 <mestery> armax: Right, decomp doesn't change that.
21:41:17 <salv-orlando> mestery, armax: It's not like I want to be an annoying moron, but I've realized that the decompisition increases plugin breakage chances
21:41:36 <salv-orlando> I was indeed considering tweaking VMware CI to post also unit tests results on openstack/neutron
21:41:45 <armax> salv-orlando: no, it increases the change of transitionary breakages
21:41:52 <armax> salv-orlando: that’s different
21:41:54 <armax> :)
21:41:59 <armax> subtle difference
21:42:19 <salv-orlando> armax: thanks for the explanation. Again the system is perfect, humans and their terrible usage of words are the problem
21:42:31 <marun> salv-orlando: we're done nannying.
21:42:38 <armax> salv-orlando: no system is perfect
21:42:49 <armax> just like humans
21:42:54 <dougwig> (as an aside: if any unit test changes as a result of a different plugin, i'd think that was a broken unit test.)
21:42:57 <armax> who designed the system in the first place
21:43:06 <mestery> lol
21:43:31 <mestery> OK, lets move on.
21:43:33 <mestery> We've beaten this horse to death now I think.
21:43:33 <salv-orlando> meh I don't anything to add
21:43:36 <armax> salv-orlando: thanks for the opportunity to reflect on this phylosofical matter
21:43:39 <kevinbenton> dougwig: not from a different plugin change, but a core change
21:43:54 <mestery> salv-orlando: I appreciate your thoughts, especially as it relates to agitating armax. :)
21:44:00 <dougwig> right, but jenkins covers that?  i'm missing the point of running those outside.
21:44:07 <salv-orlando> mestery: are you accusing me of trolling
21:44:08 <dougwig> i'm happy to move on, though
21:44:10 <mestery> OK, lets move on to the next topic now.
21:44:13 <mestery> salv-orlando: :P
21:44:19 <salv-orlando> I can bring trolling to whole different levels if you want ;)
21:44:27 <mestery> #topic Status of DVR test job and update from jogo on multi-node devstack
21:44:29 <marun> salv-orlando: we can trust you on that one!
21:44:32 <mestery> On the fly agenda item!
21:44:34 <mestery> From jogo!
21:44:40 <jogo> and clarkb
21:44:42 <mestery> lol
21:44:48 <mestery> We're nothing if not adaptive to change here
21:44:55 * armax has a halo
21:45:01 <mestery> jogo clarkb: We can do multi-node now for DVR job?
21:45:22 <jogo> so clarkb and I have been working on getting multi node devstack gate working. we have tempest smoke passing
21:45:44 <anteaya> yay multi-node
21:45:47 <mestery> jogo clarkb: Yay!
21:45:50 <jogo> so the question is as mestery said, should we  switch the DVR job to multinode or is that premature being single node doesn't work
21:45:59 <Swami> great!! +1
21:46:01 <mestery> armax: ^^^ :)
21:46:18 <clarkb> jogo: I have a feeling figuring it out on single node will make things much easier to switch to multinode
21:46:42 <clarkb> jogo: just having wrestled with a lot of the networking going on in multinode I expect that half working will only get worse under weird network setup
21:46:50 <jogo> clarkb: possible but single node DVR as you said isn't very useful and there have seen odd edge cases that only happen on single node in the past
21:46:50 <armax> jogo: single node DVR works fine
21:46:50 <clarkb> jogo: easier to debug these things in isolation
21:47:24 <marun> armax: define 'fine' ;)
21:47:27 <salv-orlando> can I troll here too? I think multi node might expose failure modes of which we have no idea at the moment, so it is useful regardless of single-node failures. On the other hand, if the issue is consumption of testing resource, that;'s another matter
21:47:38 <mestery> lol
21:47:53 <clarkb> salv-orlando: no thats not the issue. The big issue so far has been lots of things break when we go to multinode
21:47:55 <marun> armax: I think we should add a multinode job non-voting once the single node is safe to allow to vote
21:48:08 <marun> and then we can replace single node with multinode when mn becomes stable
21:48:14 <clarkb> I have spent a few months now unbraeking them and if dvr doesn't work reliably in single node we should just make that work first to avoid even more broken
21:48:23 <armax> either way, people should just pay attention to non-voting jobs just as much as the voting ones
21:48:24 <marun> clarkb: agreed
21:48:24 <jogo> marun: we can also add multinode to experimental if that helps
21:48:24 <clarkb> if it does work then great
21:48:26 <armax> just saying..
21:48:30 <marun> jogo: +1
21:48:41 <mestery> armax: ++
21:48:47 <marun> armax: I'm not sure that's reasonable.
21:48:52 <salv-orlando> armax: I chased people breaking the full job for 6 months. It's your turn now ;)
21:49:13 <marun> unless the chance of false-positives is extremely low (and I'm not sure how anyone could argue that for dvr)
21:49:21 <jogo> side note: tempest-full multi node fails for neutron
21:49:27 <armax> salv-orlando: that’s fine…I am just making a point
21:49:41 <salv-orlando> jogo: can I see logs for that
21:49:47 <armax> jogo: is it in the experimental queue?
21:49:51 <mestery> So, looks like we should focus on making the existing job working flawlessly before going muilti-node?
21:50:00 <salv-orlando> if tempest-full mn fails for neutron it's likely to fails for DVR as well
21:50:03 * mestery tries to summarize the discussion
21:50:07 <jogo> salv-orlando: http://logs.openstack.org/04/136504/14/experimental/check-tempest-dsvm-neutron-aiopcpu/d700407/
21:50:16 <marun> mestery: +1
21:50:24 <clarkb> mestery: I don't think it needs to be flawless but it should have reliability that lines up with not dvr
21:50:27 <armax> jogo: do you know what aiopcu stands for?
21:50:32 <salv-orlando> mestery: for your summary, we need also to fix the full job on multi node possibly as a precondition for the DVR job
21:50:37 <salv-orlando> thanks jogo
21:50:44 <jogo> all in one p*? CPU
21:50:47 <jogo> plus*
21:50:54 <armax> jogo: thanks for the update
21:50:57 <dougwig> flawless.  openstack.  that's quite the bar to new tests.
21:51:04 <mestery> salv-orlando: Good point
21:51:17 * mestery realizes flawless was the wrong word here
21:51:21 <jogo> so sounds like the conclusion here is, hold off on even setting up a multi node DVR
21:51:23 <mestery> How about equal footing to the non-DVR job?
21:51:25 <mestery> Better?
21:51:34 <jogo> still a lot of work to do with single node first
21:51:49 <jogo> mestery: is that accurate? ^
21:52:14 <mestery> jogo: Well, there is work, not sure on the level.
21:52:19 * salv-orlando got so addicted to faulty openstack that I've installed cyanogenmod on my phone just to see it reboot from time to time
21:52:31 <mestery> salv-orlando: lol
21:53:01 <mestery> OK, lets move on now.
21:53:03 <mestery> Tahnks all
21:53:06 <jogo> mestery: cool, once you guys are ready for multi node DVR as experimental ping me or clarkb and we can  set it up
21:53:08 <jogo> thanks
21:53:11 <mestery> #topic nova-network to neutron migration
21:53:16 <mestery> anteaya markmcclain: Hi!
21:53:21 <anteaya> jogo: guys -> y'all
21:53:24 <armax> I think it would make sense to have multi-node on the check queue
21:53:24 <anteaya> mestery: hey
21:53:32 <armax> the experimental queue takes forever to execute
21:53:34 <mestery> anteaya: Any updates for us today?
21:53:41 <anteaya> so status report
21:53:45 <anteaya> #link https://review.openstack.org/#/c/147723/
21:53:51 <anteaya> has a new patchset
21:54:01 <mestery> nice
21:54:02 <anteaya> that is the parent of the two part spec
21:54:16 <anteaya> we are arguing our way closer to something that can merge
21:54:26 <anteaya> reviews appreciated
21:54:35 <anteaya> we also have prototype code
21:54:46 <anteaya> #link https://review.openstack.org/#/c/150490/
21:54:49 <anteaya> is the proxy
21:55:01 <anteaya> #link https://review.openstack.org/#/c/148260/4
21:55:06 <anteaya> is the db migration
21:55:34 <mestery> Lots going on here it appears anteaya.
21:55:35 <anteaya> thanks to salv-orlando and assaf and obondarev and jlibosav here
21:55:35 <salv-orlando> that sounds good to me... btw is obondarev around?
21:55:47 <sc68cal> He's sick
21:55:52 <anteaya> mestery: there is movement which is good to see yes
21:55:57 <anteaya> so please review
21:56:13 <anteaya> I would like to get part one of the spec merged soon
21:56:14 <salv-orlando> sc68cal: thanks for the info (troll me would have said: "are you his doctor?")
21:56:24 <mestery> rofl
21:56:28 <sc68cal> :)
21:56:37 <anteaya> and then work on the wip patches which are needed to get nova agreemtn around the second part of the spec
21:56:40 <marun> armax: it would be pretty costly, though, to add 2 dsvm nodes per check patch
21:56:40 <anteaya> any questions?
21:56:41 <mestery> OK, I encourage folks who are interested in helping with the migration work to reach out to anteaya and attend the weekly meeting
21:56:47 <anteaya> thank you
21:56:47 <salv-orlando> I think we should start playing around with the migration part and see whether there is any obvious hiccup there
21:56:49 <anteaya> done
21:56:56 <anteaya> salv-orlando: yes, please
21:56:58 <mestery> Thanks anteaya.
21:57:01 <mestery> #topic Open Discussion
21:57:06 <armax> marun: you already know what I’d tell you…drop the non-sensical -2 mirror jobs :P
21:57:08 <mestery> Feel free to let your ideas flow for 3 minutes
21:57:09 <mestery> :)
21:57:10 <haleyb> mestery: sorry i was late, picked a bad time to shovel show, but heard back from Simon on dnsmasq option, will pass it along to people via reviews/bug
21:57:17 <marun> armax: +100 from me on that one
21:57:24 <armax> marun: and get some nodes repurposed to do something more useful
21:57:24 <mestery> haleyb: ++, thanks!
21:57:41 <marun> armax: maybe that's good enough ammunication?:
21:57:45 <marun> ammunition, sorry
21:58:01 <salv-orlando> marun: for the -2 jobs I'd say now they're there more for historical reasons when we needed 4 runs to have some confidence in a neutron patch
21:58:07 <armax> marun: meaning drop the -2 clone jobs in favor of multi-host?
21:58:19 <armax> salv-orlando: now I am the one trolling...
21:58:23 <armax> those jobs are useless
21:58:29 <salv-orlando> the other side of the question is: does the rest of the community feel like they can trust a patch with only 2 jobs passing?
21:58:33 <armax> and you know it as much as I do
21:58:34 <marun> salv-orlando: lol
21:58:37 <marun> salv-orlando: still trolling, eh?
21:58:39 <mestery> lol
21:58:46 <marun> salv-orlando: there are 8 jobs, anyway
21:58:56 <otherwiseguy> mestery: I only have one more OVSD API left method to implement for the native OVSDB interface for ovs_lib. I plan on having something reviewable for it tonight.
21:58:58 <marun> salv-orlando: so it would be 'only 6 jobs passing'
21:59:06 <mestery> otherwiseguy: Thank you sir! :)
21:59:13 <armax> frankly the -2 jobs become as useless as the non-voting ones
21:59:17 * mestery starts to worry when we get down to 5 jobs
21:59:40 <mestery> OK folks, thanks for attending the meeting today!
21:59:43 <salv-orlando> marun: methinks we can remove them
21:59:48 <mestery> Please, please, please focus on Kilo-2 reviews for the next two days!
21:59:53 <pc_m> mestery: Just wanted to point out that we are seeing issues where neutron changes break *aaS repo tests.
21:59:53 <mestery> And enjoy your week!
21:59:55 <marun> salv-orlando: who do we talk to?
21:59:58 <armax> even if they do unveil races, no-one pays attention to them
22:00:01 <mestery> #endmeeting