14:01:26 <mestery> #startmeeting networking
14:01:27 <openstack> Meeting started Tue Mar 24 14:01:26 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:31 <openstack> The meeting name has been set to 'networking'
14:01:37 <ihrachyshka> o/
14:01:38 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
14:01:42 <anteaya> swamireddy: I don't see any listing for ec2-api meeting on the meeting page: https://wiki.openstack.org/wiki/Meetings
14:01:49 <mestery> #topic Announcements
14:02:01 <mestery> We're in the feature freeze now, trying to get ready to cut an RC1
14:02:01 <swamireddy> mestery: Thanks...will take the next week slot on this. Thanks ..sorry for confusion..
14:02:20 <mestery> We'll likely spend most of the meeting going over specs which are in RC1
14:02:28 <mestery> #info RCs: April 9-23
14:02:38 <mestery> #info Kilo release: April 30
14:02:55 <mestery> So, lets move along since I think we'll need most of the time today.
14:03:08 <mestery> We'll circle back to bugs in a bit
14:03:09 <mestery> #topic Kilo-RC1
14:03:14 <mestery> #link https://launchpad.net/neutron/+milestone/kilo-rc1
14:03:14 <swamireddy> anteaya: Yet to update here https://wiki.openstack.org/wiki/Meetings, https://wiki.openstack.org/wiki/Meetings/EC2API#Agenda
14:03:17 <bryan_att> #info Bryan Sullivan
14:03:31 <mestery> bryan_att: I think you may be in the wrong meetiong, this is the neutron meeting
14:03:36 <dougwig> O/
14:03:45 <mestery> OK, lets walk through the specs we have in RC1 yet
14:03:51 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/subnet-allocation
14:04:08 <mestery> salv-orlando: In lieu of carl_baldwin being here, this one looks like it's making some progress.
14:04:15 <mestery> salv-orlando: Do you think we can land this one in the RC yet?
14:04:39 <mestery> armax: Any thoughts on this one as well?
14:04:42 <salv-orlando> mestery: I need to find pavel_bondar
14:04:48 <mestery> salv-orlando: Ack
14:04:56 <salv-orlando> I need to sync up with him and rearrange the outstanding patches
14:05:02 <armax> mestery: if I look at the list of patches pendind
14:05:07 <armax> pending
14:05:07 <armax> https://review.openstack.org/#/q/topic:bp/subnet-allocation,n,z
14:05:18 <mestery> salv-orlando: This is for subnet pool, are you thinking pluggalbe ipam?
14:05:25 <armax> which ones are deemed critical in order to have a semi-functional feature?
14:05:38 <armax> the picture doesn’t look good
14:05:54 <mestery> armax: Agree, wish carl_baldwin was here to help answer that :(
14:06:13 <mestery> OK, I've pinged carl, lets move on and circle back if he joins us in a bit.
14:06:23 <mestery> carl_baldwin: There you are!
14:06:23 <johnbelamaric> armax: subnet allocation from a subnet pool is the most critical in there
14:06:38 <mestery> carl_baldwin: We're talking subnet pools and the chances of it merging in RC1
14:06:39 <carl_baldwin> mestery: hi, sorry to be late
14:06:42 <mestery> carl_baldwin: We need your expertise here :)
14:06:42 <salv-orlando> armax, mestery: i have the full picture anyway
14:07:02 <salv-orlando> it's just that I need to speak with Pavel to check whether we can make it or not
14:07:11 * carl_baldwin reading back
14:07:17 <mestery> salv-orlando: thanks!
14:07:28 <mestery> salv-orlando: IPAM is dependent on subnet pools?
14:07:33 <salv-orlando> mestery: nope
14:07:38 <johnbelamaric> salv-orlando: last i spoke with Pavel we expect to be able to make it
14:07:40 <mestery> salv-orlando: Ack
14:07:52 <salv-orlando> I think subnet pools is fairly stable and should be able to complete
14:08:11 <salv-orlando> It's just not yet clear to me how long we are before removing the wip on the allocation patch
14:08:21 <mestery> salv-orlando: carl_baldwin may have an idea there
14:08:35 <carl_baldwin> It is getting close.
14:08:37 <salv-orlando> especially now that we've agreed to not have a feature for wildcarded gateway and allocation pools
14:08:54 <salv-orlando> mestery: rtidwell might too, but he's not around
14:09:01 <carl_baldwin> There are just a few minor things that can be cleaned up this week.
14:09:26 <mestery> carl_baldwin salv-orlando: Lets assume this one will make it then, and we can circle back next week if it still looks iffy, Sound ok?
14:09:26 <carl_baldwin> rtidwell has been travelling
14:09:40 <carl_baldwin> mestery: Yes.
14:09:52 <mestery> OK, lets move on
14:09:56 <mestery> NExt up are the IPAM BPs
14:10:02 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/neutron-ipam
14:10:08 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/reference-ipam-driver
14:10:16 <mestery> salv-orlando carl_baldwin: Back to you guys again here :)
14:11:30 <salv-orlando> so
14:11:36 * salv-orlando one second please...
14:12:12 <mestery> salv-orlando: no worries
14:12:15 <salv-orlando> the situation is fairly simple. We need to tweak again the interface
14:12:36 <ihrachyshka> :D
14:12:37 <salv-orlando> in order to allow the driver to accept contextes. I and carl_baldwin agree this should not be how it is done, so we would like to make this a transient change
14:12:38 <johnbelamaric> Earlier today pavel_bondar indicated he has resolved most test failures except OpenContrail CI - with the fix discussed on the ML
14:13:03 <carl_baldwin> salv-orlando: +1
14:13:19 <johnbelamaric> that's the fix i mean
14:13:41 <salv-orlando> now I think we can have code complete by the end of the week
14:13:55 <mestery> salv-orlando: Ack on that
14:14:00 <salv-orlando> with an optional driver, and an "experimental" interface - this would be the situation for Kilo
14:14:16 <salv-orlando> it is now up to the core team to decide whether to allow this in Kilo or not
14:14:20 <mestery> salv-orlando: Sounds tenuous here, we'd have to mark this as experimental maybe?
14:14:27 <salv-orlando> I and carl_baldwin do not have a vote here obviously ;)
14:15:12 <salv-orlando> mestery: yes definetely experimental. We probably manage to add a non-voting job using the ipam driver before the end of kilo, but I am not able to guarantee that now, because this also depends on what infra-core thinks of this
14:15:18 <salv-orlando> and I've not pinged them yet about it
14:15:30 <mestery> This all sounds like it will be hard to land in Kilo to be honest salv-orlando.
14:15:46 <ihrachyshka> salv-orlando, will we have a WARNING PLEASE DON'T USE IT in neutron.conf?
14:15:48 <carl_baldwin> mestery: I think we were headed toward making it experimental weeks ago when we decided not to replace the baked in IPAM yet.
14:15:50 <markmcclain> so I do think we have to be careful with experimental things.. our track record with experimental items has not been steller
14:16:06 <salv-orlando> ihrachyshka: see, I have to admit one thing
14:16:18 <salv-orlando> in the past I've deferred work items in the same conditions as this one
14:16:22 <mestery> Another option is to move this out of kilo, take the time to fix all of this, and land it early in liberty
14:16:24 <salv-orlando> as a core reviewer I mean
14:16:43 <dougwig> to reiterate what mark said, if we ship it experimental, and it's buggy, with our historical reputation, i don't think that experimental tag will mean much.
14:17:18 <salv-orlando> so this is why I'm saying - we can have the work done, and then it's up to you to judge. I do not want to influence in any direction, but I do not feel confident enough to say "here your pluggable IPAM driver, the code is reliable and you can use it without any worry"
14:17:18 <anteaya> salv-orlando: what opinion are you looking for from infra?
14:17:19 <ihrachyshka> what's the benefit of merging it now instead of early L? except obvious contributor frustration
14:17:39 <mestery> ihrachyshka: Contributor frustration isn't a benefit in fact, but I see what you mean there :)
14:17:41 <salv-orlando> anteaya: adding yet another non-voting job for neutron. I'm not sure you might be ok with spending another node.
14:17:45 <ihrachyshka> mestery, lol
14:17:46 <johnbelamaric> ihrachyshka: from my point of view we have several customers eagerly awaiting this...
14:17:51 <carl_baldwin> I agree with salv-orlando, I don’t think there is a way we can land this all in one shot and say it is ready.
14:18:05 <anteaya> salv-orlando: we have no policy about how many non-voting jobs a project can have
14:18:23 <mestery> So based on this input, I think we need to defer this to Liberty then. We don't need to re-approve the spec, and in fact can work to land it once the RC branch is cut.
14:18:24 <johnbelamaric> carl_baldwin: yes, it has to stay experimental
14:18:27 <salv-orlando> ihrachyshka: good point. I remember arguing with people in the past that since they were not adding any externally visible feature, there was no rush to merge their feature by a given deadline
14:18:28 <mestery> No one wants to hear that I'm sure though
14:18:36 <mestery> But it's likely where this headed
14:18:38 <salv-orlando> I'll let to carl_baldwin and johnbelamaric to explain the benefits
14:18:39 <anteaya> I can't see us wanting to police that, just use what you need
14:18:58 <salv-orlando> anteaya: thanks1
14:19:06 <anteaya> thank you
14:19:11 <dougwig> johnbelamaric: could we land it all in stackforge as an external, so those customers could get at it?
14:19:13 <ihrachyshka> we should definitely do case-by-case post mortem on why pieces targeted are not shipped...
14:19:38 <mestery> We're literally in the final weeks of Kilo.
14:19:51 <mestery> Rather than rushing a big feature like this in at the end, I think it makes sense to do this early in Liberty to be honest.
14:19:53 <ihrachyshka> dougwig, that involves base db plugin refactor, I don't know whether it's reasonable to have it in stackforge
14:19:56 <markmcclain> mestery: +1 to deferring.. we did it for IPv6 Icehouse and while frustrating I think we ended up in a better place when it landed in Juno
14:20:02 <amotoki> In my understanding, "experimental" means the minimum feature set is completed and it needs broader testing. if the expected minimum feature set is doen, it is okay to say it  experimental.
14:20:13 <johnbelamaric> dougwig: certainly that's a possibility but it complicates things, as several of these customers expect to get the code from distributors (SUSE, RedHat, etc.) which will be much easier if it's in tree
14:20:19 <anteaya> you are discussing adding an untested feature _after_ feature freeze?
14:20:32 <mestery> anteaya: When you put it that way.
14:20:39 <ihrachyshka> markmcclain, we are actually worse of letting some ipv6 pieces in icehouse at all
14:20:43 <anteaya> just doing a reality check
14:21:00 <johnbelamaric> amotoki: the minimal feature set will be ready
14:21:06 <mestery> OK, I think we need to admit we can't land this in a decent shape in the next few weeks.
14:21:16 <mestery> And to do this right, lets just land this early in Liberty.
14:21:25 <mestery> Thoughts?
14:21:48 <salv-orlando> dougwig: the way it's been done so far requires a lot of patching in db_base_plugin_v2
14:21:56 <salv-orlando> I'd rather defer than use stackforge for it
14:22:00 <dougwig> salv-orlando, johnbelamaric - understood.
14:22:02 <armax> salv-orlando: +1
14:22:03 <salv-orlando> we could put the drivers in stackforge
14:22:05 <ihrachyshka> I agree. The blame is hugely on review team
14:22:09 <markmcclain> ihrachyshka: we hid all of the IPv6 API changes because they weren't ready
14:22:11 <armax> stackforge seems more trouble than it’s worth for this
14:22:25 <mestery> armax: ++
14:22:33 <salv-orlando> ihrachyshka: nah I've been swamped by 1,000 things this release cycle and could not get my hands on it before end of January
14:22:37 <amotoki> armax: agree
14:22:39 <johnbelamaric> mestery: well, clearly this is a big disappointment if we go that way - the plan was to not enable it by default
14:22:46 <ihrachyshka> markmcclain, right, but ipv6 mode flags that were merged in I are not the best design solution, and they bite us often now
14:23:00 <carl_baldwin> I’m not seeing how stack forge will work.  The drivers could go in there, but there is code to load and use the drivers that cannot.
14:23:02 <mestery> johnbelamaric: I think the big issue is taking on new techinical debt for a feature which isn't tested yet ... in the feature freeze timeframe.
14:23:16 <anteaya> mestery: ++
14:23:23 <markmcclain> ++
14:23:31 <dougwig> mestery: if we're serious about focusing on quality, i think this has to be deferred.  i mean, we're after FF here.
14:23:34 <dougwig> ahh, beat me to it.
14:23:37 <dougwig> mestery: +1
14:23:49 <amotoki> mestery: +1
14:24:08 <mestery> I don't see a need to re-propose the spec, we can literally just move to working to land these (with adequate testing) once the RC branch is cut
14:24:21 <mestery> #info IPAM is deferred to Liberty
14:24:23 * ihrachyshka side-notes that we also need to shrink dev cycle so that those cases are not so disappointing
14:24:30 <mestery> OK, lets move on to the next one.
14:24:38 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/hyper-v-ovs-agent
14:24:38 <anteaya> ihrachyshka: good luck
14:24:43 <mestery> armax: You've been looking at this one, along with amotoki. Thouughts?
14:24:54 <amotoki> mestery: it is better you announce which blueprints are automatically approved for L. it would be nice.
14:25:03 <salv-orlando> dougwig: I have nothing to oppose to this decision. If carl_baldwin and johnbelamaric want to appeal we can discuss further on the mailing list
14:25:07 <armax> I made a couple of comments yesterday
14:25:19 <armax> but last time I chechek didn’t see any feedback from the author
14:25:19 <mestery> amotoki: Yes, we'll get to that, but I'll do that.
14:25:21 <armax> checking now
14:25:26 <amotoki> the split patch has been proposed. but ovs_lib one is still big.
14:25:46 <amotoki> ihrachyshka is checking it too.
14:25:49 <ihrachyshka> atuvenie was going to split it even more
14:25:57 <mestery> Yes, I think it needs one more split yet.
14:26:15 <amotoki> imho ovs_lib, polling, utils can be split into separate patches.
14:26:18 <ihrachyshka> there are some obvious ways to achieve it (lots of code was just moved around)
14:26:49 <amotoki> i believe we can land it soon. we alrady have all we need for hyper-v.
14:27:24 <armax> now the question becomes how confident are we that this reshuffling this late in the cycle is not going to backfire?
14:28:20 <ihrachyshka> if it's mostly line-by-line identical, I'm not too scared of actual reshuffling.
14:28:22 <mestery> We're almost halfway through the meeitng, so lets assume this one is ok for now, we can re-visit next week if needed.
14:28:24 <armax> every day it passes to get this merged makes me increasingly unease
14:28:36 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/restructure-l3-agent
14:28:38 <mestery> carl_baldwin: This one only has a few patches left
14:28:49 <mestery> carl_baldwin: I assume we can safely land these this week, so not much to discuss here. thoughts?
14:29:11 <carl_baldwin> mestery: Yes, we’re past the big ones.
14:29:20 <carl_baldwin> mestery: No, not much to discuss here.
14:29:20 <HenryG> I have been reviewing, it looks good
14:29:25 <ihrachyshka> this one is not feature-ish, so could be easily postponed. but if all is in place and not intrusive, it's also ok merge.
14:29:26 <mestery> carl_baldwin: Great! An easy one. HenryG, thanks for that!
14:29:38 <mestery> LEts move on.
14:29:38 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/ipv6-router
14:29:49 <carl_baldwin> HenryG has been doing great reviews on these BTW.  Kudos.
14:29:50 <mestery> HenryG: This one is dependent on https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes right?
14:30:09 <HenryG> Yes, but it is small (and a big bang for the LOC)
14:30:12 <absubram> mestery: yes
14:30:53 <HenryG> It needs a functional test added, I believe that is imminent
14:30:53 <mestery> HenryG: OK, I think the other one (multiple ipv6 prefixes) is not small and has lots of patche.
14:30:56 <mestery> *patches
14:31:17 <HenryG> Only one is needed for the feature
14:31:21 <absubram> mestery, HenryG: yes.. hoping to get that functional test change added by today.. was hitting a few issues with it yesterday
14:31:51 <absubram> in running the functional tests that is.. not my change :p
14:31:53 <mestery> OK, lets circle back on these later in the week, we'll need the functional test for V6 routers and HenryG you can let me know which patch is needed for multiple prefixes.
14:32:08 <mestery> The last two are LBaaS drivers which need working CI, whcih neitehr has.
14:32:14 <mestery> dougwig: What is the date on those LBaaS ones we gve them?
14:32:18 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/netscaler-lbass-v2-driver
14:32:22 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/radware-lbaas-driver
14:32:36 <dougwig> mestery: date was today, though i was going to give them until the end of the week, since they're not mainline code.
14:32:48 <mestery> dougwig: OK, lets see if htey can get the CI working.
14:33:05 <dougwig> the radware driver is really close, in particular.
14:33:12 <mestery> OK, 28 minutes left now, lets continue down the agenda, some conentiious things left.
14:33:25 <mestery> #topic MTU and vlan_transparency recovery mode
14:33:37 <mestery> armax filed two bugs to track the cleanups here
14:33:40 <mestery> #link https://bugs.launchpad.net/bugs/1434667
14:33:42 <openstack> Launchpad bug 1434667 in neutron "VLAN transparent feature cleanup" [High,Confirmed]
14:33:42 <armax> garyk is not around
14:33:44 <mestery> #link https://bugs.launchpad.net/bugs/1434671
14:33:45 <openstack> Launchpad bug 1434671 in neutron "MTU advertisement feature cleanup" [High,Confirmed]
14:33:48 <armax> too bad
14:33:52 <mestery> armax: Really? *sigh*
14:33:59 <mestery> Well, lets just see what we can do here.
14:34:20 <armax> mestery: I’ve pinged him, let see if he jumps in
14:34:38 <mestery> I was out last Friday, so armax, can you summarize for me and the meeting minutes where we stand here?
14:34:45 <armax> anyway amotoki seems to favor the approach where the vlan_transparent attribute is an extension attribute
14:34:56 <armax> and keep the mtu one as is
14:35:09 <mestery> I thought garyk was in favor of that too?
14:35:15 <mestery> and salv-orlando as well?
14:35:20 <pritesh> mestery: last time garyk agreed that he was ok with mtu one, the vlan one still needs concensus.
14:35:25 <mestery> pritesh: Ack
14:35:42 <mestery> #info Plan is to keep the MTU attribute as-is, and look to make the vlan_transparent an extension attribute
14:35:49 <garyk> hi, sorry for joining later
14:35:50 <ajo> that's my opinion on the mtu bit at least.
14:35:51 <mestery> armax: Looks like we may only need the one bug.
14:35:56 <mestery> garyk: yo
14:35:57 <ajo> (hi :) )
14:36:21 <amotoki> MTU one goes as-is without extension?
14:36:40 <armax> amotoki: do you have concerns?
14:36:43 <amotoki> I just wonder how to detect it from API perspective.
14:36:46 <garyk> i am in favor of the mtu being an extension too
14:37:03 <marun> that's the only way we have a chance of having tempest be able to test it
14:37:09 <marun> so +1 for extension from me, too
14:37:28 <amotoki> i can go into the detail thursday and friday.
14:37:40 <garyk> at the moment it is read only and driven by ml2 plugin configurations
14:37:42 <armax> I am really not that swayed one way or another
14:38:08 <mestery> Honestly, me either, but I'd like to resolve it so we can ship these in kilo. If that means extension attributes, lets just make that happen.
14:38:13 <dougwig> can we timebox this, lest we start to rehash last week?  it was going in circles.
14:38:14 <armax> we can have both as extension attributes, it’ll take more work, so let’s agree now and waste no more time
14:38:31 <salv-orlando> I think the MTU patch makes sense.
14:38:32 <mestery> #info move mtu and vlan_transparency to extension attributes
14:38:34 <marun> does anyone have alternate view about the testing?
14:38:36 <mestery> armax: Done
14:38:51 <marun> can we sanely test without detecting feature via api extension?
14:38:59 <garyk> mestery: is anyone going to take it as an action item to do?
14:39:07 <ajo> marun what's the exact issue with testing?
14:39:10 <dougwig> marun: depends on your definition of sanity.  :)
14:39:13 <ajo> (whithout extension)
14:39:13 <mestery> garyk: I was hoping htis is where pritesh would jump in :)
14:39:17 <ajo> without
14:39:23 <garyk> mestery: ok, thank
14:39:25 <armax> marun: we can’t selectively test the feeature if it wasn’t an extension
14:39:27 <amotoki> ajo: the issue is from API perspective. testing is one case.
14:39:32 <mestery> pritesh: Are you ok with refactorign these to extensions?
14:39:32 <marun> dougwig: ^^
14:39:41 <tiswanso> garyk, mestery:  I will work with pritesh as well
14:39:53 <mestery> tiswanso: Awesome!
14:39:54 <tiswanso> for the mtu
14:39:56 <garyk> tiswanso: thanks
14:39:59 <pritesh> mestery: i am ok with vlan one, mtu i thoght should remain in core.
14:40:13 <mestery> #action tiswanso and pritesh to refactor MTU and vlan_transparent into extension attributes
14:40:20 <mestery> pritesh: See marun and amotoki's concerns around testing above.
14:40:27 <tiswanso> pritesh:  +1 --- would prefer it's in core as it makes sense :-)
14:40:42 <mestery> I think we need to move forward with these quickly to refactor or risk reviving garyk's reverts if we don't solve this.
14:40:49 <salv-orlando> tiswanso, pritesh: being in core vs extension what difference makes for you?
14:40:54 <tiswanso> but defer to the more knowledgeable about test practicalities
14:41:04 <salv-orlando> just trying to make sure you do not believe that an extension is a 2nd class api
14:41:04 <marun> are we intending to start microversioning to avoid this kind of thing in L?
14:41:17 <salv-orlando> marun: indeed that why core vs extension is a moot point for me now
14:41:23 <armax> salv-orlando: agreed
14:41:35 <armax> let’s move both to be extension attributes and revisit in L
14:41:41 <salv-orlando> marun: but there's still lack of consensus on microversioning and saying good riddance to extensions
14:41:42 <mestery> OK, lets move on then.
14:41:42 <armax> I guess that’s the best we can do right now
14:41:43 <tiswanso> salv-orlando:  I don't have a strong reason... was kind of viewing as 2nd class API but need to learn more details
14:41:54 <armax> too bad we didn’t have this conversation a while back
14:41:57 <mestery> We have more to cover here, and I think the case to moving both to extension attributes has been made.
14:41:59 <pritesh> ok so do we need FFE or do we do it in the bugs filed by armax
14:42:08 <mestery> pritesh: Use the bugs please :)
14:42:09 <salv-orlando> tiswanso: do you know that floating ips and security groups are extensons as well? they don't seem 2nd class APIs to me!
14:42:16 <armax> tiswanso: this is totally the wrong way to look ait it
14:42:20 <pritesh> mestery: will do thanks.
14:42:27 <amotoki> tiswanso: having API in core or extension is not a big thing. it does not necessarily mean the 2nd class API.
14:42:32 <tiswanso> salv-orlando:  thanks for the clarification... didn't know that
14:42:51 <mestery> Folks, 18 minutes left, lets stop bike shedding and move on :)
14:42:53 <mestery> #topic Pylint -- In or out?
14:42:58 <mestery> dougwig: This is your yak to shave
14:43:02 <tiswanso> I'm fine with the group's opinion.. just wanted to give my vote :-)
14:43:02 <dougwig> oh, thanks.
14:43:28 <mestery> dougwig: 2 more items after this, so I'll hold this particular yak shaving to 6 minutes ;)
14:43:36 <dougwig> i've been hesitant reviewing pylint patches, because i know the group is split.  did we ever make a group decision on pylint?  are we full-throttle merging it in, or is it's annoyance not worth it?
14:43:39 <carl_baldwin> I think pylint has to be pinned or out.
14:44:33 <armax> I think that with the current arrangement of the jobs, keeping it unpinned it’s not a big deal
14:44:41 <ihrachyshka> pylint++
14:44:45 <armax> we can recover from a failure fairly quickly
14:44:53 <ihrachyshka> it should be on same par as pep8, no difference
14:45:05 <garyk> could it be non voting?
14:45:07 <dougwig> is it worth the trouble?  i like the idea of it, but i've been finding it's annoyance outweighs its usefulness.
14:45:10 <armax> garyk: no
14:45:21 <ihrachyshka> there is some push-back against pinning it globally, but that's just wrong and should be pushed forward to avoid random failures
14:45:33 <carl_baldwin> I’m pretty sure that pylint has cost us a couple days of gate time this cycle.
14:45:38 <ihrachyshka> garyk, non-voting == non-caring
14:45:40 <dougwig> ihrachyshka: globally in openstack there seems to be pushback against pylint in general
14:45:40 * HenryG is a fan of a voting pylint
14:45:43 <garyk> if we can fix failures then legs go with it - unless it is really blocking
14:45:47 <armax> carl_baldwin: that’s before the skip-if filter
14:45:49 <ajo> can't we pin it locally?
14:45:50 <armax> that marun did
14:45:55 <ihrachyshka> carl_baldwin, that's because it was not pinned
14:45:55 <armax> and the separate job
14:46:08 <armax> ajo: no
14:46:11 <carl_baldwin> ihrachyshka: That is why I say pinned or out.
14:46:23 <anteaya> something in global requirements pinned locally creates a mess
14:46:25 <armax> ihrachyshka: no, that’s because of the arrangement we had
14:46:27 <ajo> armax: it will be override when we take the global imports?
14:46:36 <armax> if today it broke we could disable it in tox
14:46:40 <ajo> requirements, sorry
14:46:42 <ihrachyshka> ajo, we can try too, but better handle it globally. we can back up to local pin if nothing goes globally for a month or so
14:46:58 <mestery> ihrachyshka: See comments from anteaya on local pinning of a global requirement
14:47:01 <armax> and the change to disable it will less than  10 mins to merge
14:47:10 <ihrachyshka> anteaya, what's the problem with pin?
14:47:10 <armax> with no fuss
14:47:13 * marun is not a fan of pylint.  let's spend our time writing better tests!
14:47:15 <dougwig> we have 2 minutes.  does anyone feel strongly that it should be *out* ?
14:47:15 <ajo> mestery, where? anteaya
14:47:22 <ihrachyshka> anteaya, pin as in <=current_version
14:47:43 <anteaya> any diversion from global requirements creates a mess for you
14:47:50 <anteaya> you are async to the rest of openstack
14:47:54 <armax> marun: that’s a good reason to make pylint moot
14:47:54 * ihrachyshka notes that we pin hacking locally
14:48:02 <ajo> anteaya, yes but it's a tool, not a lib..
14:48:07 <anteaya> being in sync with the rest of openstack is rather the point of global requirements
14:48:14 <armax> getting rid of pylint because of infra related problems seems like solving the wrong problem
14:48:17 <ajo> anteaya, if the problem is the global reqs transposing to local, we could fix that to read some sort of tags we set..
14:48:22 <clarkb> just put a pin in global requirements
14:48:25 <marun> anteaya: global requirements is problematic for some use cases.
14:48:32 <ajo> clarkb, that wasn't accepted
14:48:34 <marun> anteaya: we need to start supporting pinning next cycle
14:48:35 <ihrachyshka> anteaya, the point of pin is to fix new issues on our schedule
14:48:40 <marun> anteaya: but that's a debate for another time
14:48:42 <clarkb> ajo it wasnt? thats weird
14:48:44 <armax> I’d rather get rid of pylint because we write code that is so great that we no longer need it
14:48:46 <mestery> We're yak shaving on the logistics of using pylint, but I've not seen if people really *want* it in yet.
14:48:56 <clarkb> its how we do pep8 and pyflakes
14:49:10 <markmcclain> mestery: I'd like to see pylint go away
14:49:12 * carl_baldwin agrees with marun, has put his comments in the global pin patch review.
14:49:13 <ajo> clarkb: https://review.openstack.org/#/c/163506/
14:49:24 <garyk> is the yak shaving done in the bike shed?
14:49:30 <mestery> garyk: Yes
14:49:30 <ihrachyshka> ok, next stop - dropping pep8 I guess
14:49:35 <dougwig> we're at time.
14:49:37 <marun> ihrachyshka: hardly
14:49:39 <mestery> OK, lets move on, we have two more bike sheds full of yaks for htis meeting
14:49:46 <mestery> We didn't solve pylint here though.
14:49:50 <mestery> dougwig: ML perhaps?
14:49:58 <dougwig> mestery: ok
14:50:00 <mestery> #topic DVR Gate Job
14:50:08 <mestery> armax: You're up!
14:50:28 <armax> I looked at this graph
14:50:30 <armax> http://graphite.openstack.org/render/?from=-10days&height=500&until=now&width=1200&bgcolor=ffffff&fgcolor=000000&yMax=100&yMin=0&target=color(alias(movingAverage(asPercent(stats.zuul.pipeline.check.job.check-tempest-dsvm-neutron-dvr.FAILURE,sum(stats.zuul.pipeline.check.job.check-tempest-dsvm-neutron-dvr.{SUCCESS,FAILURE})),%2736hours%27),%20%27check-tempest-dsvm-neutron-dvr%27),%27orange%27)&target=color(alias(movingAverag
14:50:30 <armax> asPercent(stats.zuul.pipeline.check.job.check-tempest-dsvm-neutron-full.FAILURE,sum(stats.zuul.pipeline.check.job.check-tempest-dsvm-neutron-full.{SUCCESS,FAILURE})),%2736hours%27),%20%27check-tempest-dsvm-neutron-full%27),%27blue%27)
14:50:39 * mestery grumbles about bad paste
14:50:43 <armax> to track the reliability of the DVR job
14:50:56 <armax> http://goo.gl/jF5zBP
14:51:00 <armax> is that better?
14:51:02 <anteaya> mestery: yeah graphite urls are never short
14:51:08 <marun> huh, that's neat
14:51:09 <mestery> armax: yes
14:51:21 <marun> so we're down to a reasonable failure rate for the dvr job?
14:51:26 <salv-orlando> armax: no you could do phishing using url shorteners. and then google is evil :)
14:51:29 <armax> the long term plan is to have multi-node voting
14:51:34 <armax> swami is working on it
14:51:38 * carl_baldwin has also been tracking this graph.  Pleased with the current state.
14:51:46 <marun> that would imply actually testing dvr...
14:51:58 <armax> the question is: do we want to making the single-node voting as an interim step?
14:52:18 <mestery> armax: ++, I'm fine with that as the interim step
14:52:21 <armax> yes, making it voting means that DVR must be taken into account into any Routing feature and Testing
14:52:26 <mestery> And continuing down the multi-node tesitng path that swami is doing
14:52:42 <salv-orlando> armax: I'm fine with that either. possibly after rc1 is out?
14:52:45 <mestery> With the goal of having the multi-node job up at least non-voting soon
14:52:54 <armax> I was going to watch the job for another few days
14:53:00 <marun> armax: I'd like to see better docs so that other developers can have a clue as to how to fix problems as they occur.
14:53:04 <armax> salv-orlando: I guess we probably need to take this to the ML too
14:53:13 <salv-orlando> armax: cool
14:53:14 <marun> armax: right now, I'm pretty sure dvr is a mystery to most.
14:53:16 <armax> marun: that should be true for anything in Neutron
14:53:16 <mestery> armax: Ack, sounds like it
14:53:17 <amotoki> my vote is to make it voting once Liberty is open.
14:53:21 <anteaya> armax: can you include a shortened link to this graph in the patch to make the job voting please?
14:53:26 <armax> I don’t see why DVR should be treated differently
14:53:35 <marun> armax: dvr is an order of magnitude more complicated though, if only in implementaiton.
14:53:39 <armax> anteaya: can do
14:53:43 <anteaya> armax: thanks
14:53:48 <armax> marun: depends where you look from
14:53:55 <armax> marun: but I can see what you mean
14:54:01 <armax> HA is no piece of cake either
14:54:02 <salv-orlando> marun: not at mistery at all. everybody knows what a dvr is - the thing you used to record movies back in the '90s
14:54:05 <armax> and that doesn’t even have tests
14:54:12 <armax> besides a few functional onces
14:54:14 <armax> ones
14:54:20 <marun> armax: it has pretty good functional ones, fwiw
14:54:36 <marun> armax: but no substitute for a proper integration test.
14:54:47 * marun digresses
14:54:55 <mestery> OK, lets move on here.
14:54:58 <mestery> One item left
14:55:08 <mestery> #topic LBaaS
14:55:08 <mestery> dougwig: Is this one yours too?
14:55:10 <mestery> Or xgerman's?
14:55:14 <dougwig> xgerman's
14:55:24 <xgerman> mine
14:55:31 <mestery> xgerman: Please, go ahead.
14:55:37 <ajo> salv-orlando: lol
14:55:47 <xgerman> ok, we want to make Horizon panels for LBaaS and I was tsrating to collect some use cases
14:56:08 <xgerman> so please add them to the etherpad
14:56:20 <mestery> #link https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases
14:56:36 <anteaya> xgerman: have you talked to david_lyle about this?
14:56:51 <xgerman> not yet
14:56:53 <anteaya> horizon is getting crowded to the point of being unusable
14:57:02 <anteaya> yeah um, maybe start there
14:57:05 <amotoki> is it targetted to Liberty? right?
14:57:18 <dougwig> amotoki: yes
14:57:26 <xgerman> yes, Liberty, and we are talking to our UX designer Michael Hinnant
14:57:45 <amotoki> nice. we will deprecate LBaaS v1 API in Kilo and we need to support LBaaS v2 in L :)
14:57:55 <mestery> xgerman: Excellent, I'd make sure to talk to david-lyle as anteaya said.
14:58:00 <mestery> amotoki: Yes
14:58:03 <anteaya> some would say, and I'm amoung them that horizon is unusable now
14:58:11 <anteaya> due to overcrowding
14:58:18 <mestery> #topic Open Discussion
14:58:22 <mestery> OK, a minute or so left.
14:58:31 <anteaya> I have a question
14:58:32 <mestery> Lets keep the focus on RC BPs and bugs now.
14:58:36 <anteaya> #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/059294.html
14:58:37 <mestery> Be cautious when merging code now
14:58:58 <mestery> marun: link from anteaya is your email about moving testing to neutron
14:59:01 <anteaya> in the thrid party meeting yesterday luqas asked what if anything third party folks should test when this test moves
14:59:02 <mestery> 1 minute left too :)
14:59:08 <anteaya> I had no response to give him
14:59:15 <anteaya> what do you want third party folks to do?
14:59:22 <marun> anteaya: keep running tempest for now
14:59:34 <anteaya> thank you, and when the test moves?
14:59:38 <mestery> OK, we've gotta end this now.
14:59:41 <marun> anteaya: it will shortly be possible to have them run the tests from neutron
14:59:43 <anteaya> just keep running tempest?
14:59:44 <mestery> Lets move this to #openstack-neutron or ML thread.
14:59:47 <mestery> Thanks folks!
14:59:50 <mestery> #endmeeting