14:01:05 <mestery> #startmeeting networking
14:01:06 <openstack> Meeting started Tue Mar 10 14:01:05 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:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:10 <gongysh_> hi
14:01:10 <openstack> The meeting name has been set to 'networking'
14:01:17 <salv-orlando> Ialoha!
14:01:18 <mestery> We've got a packed meeting today, so lets get to it!
14:01:20 <salv-orlando> aloha!
14:01:22 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
14:01:29 <mestery> #topic Announcements
14:01:50 <mestery> We passed FPF last week, and only a handful of BPs had no code. So, the good news is we have a lot to review! The bad news is, we have a lot to review.
14:01:54 <obondarev> hi
14:01:59 <mestery> #info Feature, String, and Dependency Freeze: March 19
14:02:01 <mestery> #info RCs: April 9-23
14:02:05 <mestery> #info Kilo release: April 30
14:02:13 <mestery> #link https://launchpad.net/neutron/+milestone/kilo-3
14:02:29 <mestery> Any questions on dates for the end of Kilo?
14:02:50 <mestery> I also wanted to highlight the OpenStack Client weekly meeting
14:02:59 <mestery> #info OpenStack Client weekly meeting Thursdays at 19:00 UTC in #openstack-meeting
14:03:09 <mestery> #link https://wiki.openstack.org/wiki/Meetings/OpenStackClient#Next_Meeting_Agenda
14:03:21 <mestery> It would be great if we could get someone to represent Neutron there as we look to deprecate the client in Liberty
14:03:47 <mestery> OK, lets move on as we have a packed agenda today.
14:03:50 <mestery> #topic Bugs
14:03:53 <mestery> enikanorov: Hello!
14:04:00 <mestery> enikanorov_: Also hello
14:04:05 <enikanorov_> mestery: hi
14:04:19 <garyk> hi
14:04:25 <enikanorov_> not much of updates from me this week. we have one critical issue
14:04:26 <enikanorov_> q-agent-notifier-tunnel-update_fanout_e7932584281b4eaca12007d4db921da1
14:04:29 <enikanorov_> oops
14:04:31 <enikanorov_> not this one!
14:04:37 <mestery> lol
14:04:40 <enikanorov_> https://bugs.launchpad.net/neutron/+bug/1323658
14:04:40 <openstack> Launchpad bug 1323658 in OpenStack Compute (nova) "Nova resize/restart results in guest ending up in inconsistent state with Neutron" [Critical,Confirmed]
14:04:55 <enikanorov_> that is hanging for quite a while now...
14:05:31 <mestery> enikanorov_: Yes, it's been around for a long while, and unfourtanetly I had no time to dig into this the past week, I should have some time later this week yet.
14:05:44 <salv-orlando> enikanorov_: what's the gate hit rate in the past 7 days?
14:06:25 <enikanorov_> salv-orlando: i didn't look at it, sorry
14:06:26 <anteaya> o/
14:06:56 <enikanorov_> https://bugs.launchpad.net/neutron/+bug/1382064
14:06:56 <openstack> Launchpad bug 1382064 in neutron "Failure to allocate tunnel id when creating networks concurrently" [High,In progress] - Assigned to Eugene Nikanorov (enikanorov)
14:06:57 <salv-orlando> enikanorov_: np. I was just considering whether it was serious enough to preempt our current work and jump on it
14:07:10 <markmcclain> o/
14:07:17 <enikanorov_> for this one I've updated the fix with oslo.db wrapper introduced in 1.5.0
14:07:29 <mestery> enikanorov_: Nice!
14:07:30 <enikanorov_> hopefully this will allow us to merge multiple API/RPC workers patch
14:07:54 <enikanorov_> that's all from me
14:08:07 <mestery> enikanorov_: Thanks! Any other bugs anyone wants to bring up with the broader team here?
14:08:58 <mestery> OK, lets move along.
14:09:01 <mestery> #topic Docs
14:09:09 <mestery> emagana: Hi there, you here this morning?
14:09:35 <markmcclain> mestery: he's the ops summit right?
14:09:41 <mestery> markmcclain: Good call
14:09:42 <mestery> #undo
14:09:43 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x96a5310>
14:09:51 <mestery> Lets move on
14:09:53 <emagana> I am here!
14:09:59 <mestery> #topic Docs
14:10:01 <mestery> emagana: Ha! Hi there! :)
14:10:06 <mestery> Quick docs update?
14:10:08 <emagana> sorry,... at the operators meetup
14:10:24 <mestery> emagana: OK, so no docs update?
14:10:40 <emagana> gerrit review on the nova-network to neutron migration: https://review.openstack.org/#/c/155947/
14:11:00 <mestery> emagana: Nice!
14:11:05 <mestery> #link https://review.openstack.org/#/c/155947/
14:11:05 <emagana> funny, we just discussed at the operators two things:
14:11:26 <emagana> 1. more volunteers for the networking guide!  We got four or five volunteers!!!!  yeah!!
14:11:38 <markmcclain> emagana: awesome
14:11:49 <anteaya> emagana: the nova-net to enutron migration docs patch is on hold, yes?
14:12:07 <mestery> emagana: That is great!
14:12:12 <anteaya> emagana: pending anne's approval to move ahead once networking docs transistion to rst files?
14:12:12 <ajo> :-)
14:12:18 <emagana> 2. how positive is nova-network to neutron migration for production cloud operators... These are the bad news...  No good feedback yet.
14:12:21 <anteaya> emagana: is this not true?
14:12:45 <anteaya> emagana: what do you mean bad news
14:12:52 <emagana> anteaya: Yes, it is in hold but just based on the location and format... so, yes you are correct
14:13:03 <anteaya> emagana: what feedback have you gotten?
14:13:21 <anteaya> btw I wasn't expecting _any_ good news on the migrtion to come from the ops meetup
14:13:28 <emagana> anteaya: I will love to provide it right now but it will consume a lot of time, mestery should I go ahead?
14:13:35 <anteaya> so the fact you haven't gotten any is in line with my expectations
14:13:45 <anteaya> it is kind of important to me
14:13:50 <anteaya> unless mestery disagrees
14:13:55 <emagana> anteaya: we can discuss offline!
14:13:58 <anteaya> and the point wasn't really to get feedback
14:14:04 <anteaya> it was to inform them of our work
14:14:10 <mestery> anteaya: Ack
14:14:43 <emagana> anteaya: bottom line is that even with a easier migration neutron still needs to provide 100% parity and people running IPv6 multihost are not seeing it yet
14:15:08 <anteaya> so this is a neutron parity issue corrent?
14:15:21 <anteaya> based on what you are hearing from those still running nova net?
14:15:35 <salv-orlando> I knew about the multihost things... but what's specific about ipv6?
14:15:36 <mestery> carl_baldwin: For IPV6 multihost, we'll need IPV6 support in DVR I believe
14:15:46 <mestery> armax: ^^^
14:15:47 <anteaya> and scine when did nova net grow ipv6 ability?
14:15:50 <emagana> mestery: that is correct!
14:16:05 <carl_baldwin> mestery: ack
14:16:09 <salv-orlando> anteaya: my recollection as well
14:16:14 <carl_baldwin> mestery: obviously not there yet
14:16:20 <mestery> Yup
14:16:29 <mestery> #info Operators asked about IPV6 DVR support at the Ops Mid-Cycle
14:16:35 <anteaya> emagana: so please get some names if you can from your feedback
14:16:37 <armax> mestery: there may be issues with DVR and IPv6, but at least from a a testing perspective, what works for legacy routing works for DVR too
14:16:47 <anteaya> as right now what you are saying makes no sense to me
14:17:20 <emagana> there was an interesting conversation about how Ipv6 works with nova-network and sc68cal had interesting questions about it.. Internet2 project is the operator asking for it
14:17:37 <mestery> Those blasted internet researchers
14:17:38 <mestery> ;)
14:18:25 <ajo> :)
14:18:29 <mestery> OK, this is all good data emagana, but it looks like you and anteaya should sync up post Ops Meetup.
14:18:35 <salv-orlando> emagana: that's good to know the requirement. I still wonder however whether is a requirement for neutron or a lack of parity
14:18:47 <salv-orlando> but I guess that's just pointless speculation
14:18:58 <mestery> OK, anything else emagana?
14:19:05 <ajo> salv-orlando: it's a good question
14:19:08 <emagana> mestery: not really!
14:19:15 <anteaya> yeah, we need to follow what the tc said on this, not just make somtehting up based on what one person said or is doing
14:19:17 <mestery> emagana: Thanks, and enjoy the rest of the Ops Meetup!
14:19:33 <emagana> I think we should have a session Ops with Neutron team
14:19:33 <mestery> #action emagana and anteaya to sync post Ops Meetup around nova-network to neutron migration discussions
14:19:46 <mestery> emagana: Also makes sense
14:20:13 <mestery> OK, lets move along, thanks emagana!
14:20:16 <emagana> mestery: my feeling is that they may do not have all the information and maybe confused on how they work with Neutron  ;-)
14:20:21 <emagana> sure!!!
14:20:46 <mestery> #action Team to look at having an Ops/Neutron session in Vancouver at the Design Summit
14:20:52 <mestery> #topic Should the *aas repos be depending on neutron HEAD?
14:20:59 <mestery> Not sure who put this on the agenda ...
14:21:04 <ihrachyshka> marun, ?
14:21:04 <dougwig> marun added this.
14:21:11 <mestery> marun: Floor is yorus!
14:21:41 <dougwig> his idea was to pin the unit tests to specific commits of neutron, to prevent them from constantly breaking with breaking neutron commits.  this  moves the break further away from the break, but also doesn't randomly break the *aas gates.
14:21:46 <HenryG> Same question applies to the vendor repos?
14:21:59 <mestery> HenryG: Good point
14:22:18 <ihrachyshka> HenryG, even more relevant there since neutron team does not track them
14:22:24 <marun> I mainly wanted to raise the profile of this idea.
14:22:28 <armax> HenryG: pinning on a specific hash is only feasbile once the decomp is complete
14:22:29 <salv-orlando> HenryG, dougwig: I deliberately decided to not pint stackforge/vmware-nsx on any neutron commit, because this would make the whole point of 3rd party CI vain.
14:22:33 <amuller> If Neutron is now a library, well, you normally use a specific version of a library and not just pull it from Git
14:22:45 <salv-orlando> not sure if that can apply also to the *ass repos
14:22:53 <marun> salv-orlando: there should be a difference between pinning and 3rd party ci
14:23:03 <dougwig> doing this would require an automated job (possible via mechanical turk at first) to keep bumping the commit revision.
14:23:08 <marun> salv-orlando: 3rd party ci *should* test against latest
14:23:12 <armax> salv-orlando: you can have the CI determine whether you can move the pin forward
14:23:26 <pc_m> dougwig: +1
14:23:28 <ajo> CI may test against HEAD
14:23:31 <marun> salv-orlando: but I would expect repos to pin so that development and stabilization could proceed independently
14:23:37 <dougwig> if jenkins and 3rd party test against different commit revisions, people will ignore 3rd party even more than they do today.
14:23:44 <mestery> dougwig: ++
14:23:46 <dougwig> we have to eat our own dogfood, not set up those CIs for failure.
14:24:00 <marun> dougwig: everyone ignores non-voting ci, except when they have a reason not to
14:24:16 <salv-orlando> marun: the thing is that the goal of CI for a plugin is to detect breakages induced in your system from the dependent library. And indeed should test against latest, as you say. Now... if I pin neutron I won't be able to test against latest anymore.
14:24:16 <marun> dougwig: non-voting is delibertatly non-forcing - it's just communication
14:24:18 <dougwig> heck, i even ignore the voting ones.  and as a third-party CI operator, I should know better.
14:24:44 <salv-orlando> marun: ignore my point, finish first your discussion with dougwig. No need to cross wires.
14:25:15 <mestery> marun: I see your point here, but I think salv-orlando's point is valid as well and I don't know how to reconcile the two.
14:25:28 <marun> it's simply an option
14:25:49 <dougwig> mestery - i would assume that the 3rd party CIs would test against the same revision as jenkins, via the tox.ini setting.
14:25:50 <mestery> marun: OK
14:25:57 <salv-orlando> If I had a chance to run two jobs I might be ok with having a "stable" voting job against a pinned neutron
14:26:04 <marun> if folks in any given dependent project want to conjoin development and stabilization against dependencies, they can continue to do so.
14:26:07 <salv-orlando> and another non-voting job against latest neutron
14:26:10 <marun> I think it sucks, personally.
14:26:17 <dougwig> i'm really quite torn on this idea. on the one hand, it reduces the gate breakages that happen pretty often.  on the other, it just moves the problem away further in time.
14:26:37 <mestery> I like marun's idea of separating development and stabilization here
14:26:39 <mestery> It's a solid idea
14:26:54 <marun> It does require dedicated resources to stabilize, though.
14:26:54 <mestery> It does kick the can down the road, but it has a lot of benefits as well
14:26:59 <mestery> Right
14:27:00 <salv-orlando> marun: I think marun has a good point. We can work around that. At the end of the day is trying to make people developing *asses easier
14:27:01 <marun> It doesn't make less work, it just partitions it.
14:27:12 <mestery> Yes
14:27:15 <dougwig> hopefully, something like proposal bot can keep that commit hash pretty current.
14:27:28 <marun> dougwig: that would be the hope.
14:27:37 <marun> dougwig: falling permanently behind isn't an option.
14:27:56 <dougwig> right.  by 'hopefully', i meant, 'dougwig is going to make sure there is a bot, for his own sanity.'
14:28:05 <marun> I would hope we could experiment with this in the small, here.
14:28:15 <marun> With an eye towards doing it for all of openstack in the very distant future.
14:28:22 <mestery> ++
14:28:27 <marun> We have the same problem between the 'integrated core'
14:28:27 <pc_m> ++
14:28:33 <ajo> sounds good
14:28:47 <mestery> So, lets try it out with LBaaS or VPNaaS, taht would be my proposal
14:28:49 <mestery> And see how it goes
14:28:58 <dougwig> lbaas can be the guinea pigs.
14:28:59 <mestery> Thoughts?
14:29:08 <dougwig> i'm curious how it turns out myself.
14:29:08 <ajo> dougwig++
14:29:10 <mestery> #info LBaaS to try out the new pinning approach presented here
14:29:15 <salv-orlando> nope, I am happy to extend the experiment to stackforge/vmware-nsx
14:29:15 <marun> I would like to participate, to see how we can structure things to make it work.
14:29:31 <mestery> #info stackforge/vmare-nsx to try pinning from a vendor side as well
14:29:34 <marun> Getting down and dirty is the only real way to see how to make it work.
14:29:39 <mestery> marun: Can you work with dougwig and salv-orlando then?
14:29:40 <mestery> :)
14:29:49 <marun> mestery: definitely.
14:29:49 <mestery> #info marun to work closely with dougwig and salv-orlando on the pinning strategy
14:29:51 <mestery> Sweet!
14:29:53 <dougwig> sweet.
14:29:56 <dougwig> i think.  :)
14:29:59 <mestery> Consensus! :)
14:29:59 <mestery> Group hug
14:29:59 <marun> heh
14:30:02 <pc_m> nice.
14:30:03 <carl_baldwin> +1
14:30:04 <ajo> marun++, dougwig++, salv-orlando++
14:30:11 <mestery> Shall we move on in the agenda?
14:30:33 <mestery> marun: Do we need to discuss Xen and OVS support still?
14:30:42 <marun> mestery: maybe?
14:30:43 <salv-orlando> mestery: one of us could be byzantine. You need a fourth person to establish a consensus ;)
14:30:50 <mestery> #topic The Future of Xen and OVS Support
14:30:53 <mestery> salv-orlando: lol
14:30:59 <mestery> marun: Go ahead please!
14:31:16 <marun> Does anyone know of dedicated resources maintaining/testing Xen support?
14:31:26 <marun> Bob Ball seems to be working on 3rd party CI
14:31:37 <marun> But I haven't seen any developers working on the project.
14:31:44 <marun> Anyone else?
14:31:44 <mestery> Me either
14:32:01 <marun> The question is, how can we justify Xen support without someone stepping up to work on it?
14:32:05 <ihrachyshka> marun, on FOSDEM, I talked to someone from Xen, and they were not that happy about the idea of voting for all neutron patches at that time. is it changed now?
14:32:26 <anteaya> bobball works with xen
14:32:32 <anteaya> does ops on the ci system
14:32:37 <ihrachyshka> though I also think manual check trigger would be enough
14:32:37 <anteaya> has anyone talked to him?
14:32:38 <marun> anteaya: I'm not sure that's enough
14:32:49 <anteaya> oh I'm not saying it would be
14:32:50 <mestery> anteaya: Yes, he replied to the thread on the ML
14:32:50 <marun> anteaya: there was a conversation on the mailing list
14:32:59 <anteaya> mestery: great
14:33:01 <marun> anteaya: But only on the issue of 3rd party ci
14:33:07 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/058211.html
14:33:33 <marun> Even if we did have 3rd party CI, I'm not sure that Xen support belongs in-tree.
14:33:37 <mestery> So, I think unless someone steps up soon and a CI starts running validating patches (especially on the OVS agent), we may need to look at deprecating support for Xen.
14:33:49 <marun> There's nothing stopping it from being done out-of-tree.
14:33:57 <mestery> marun: ++
14:33:58 <marun> The support is mainly at the agent level anyway
14:34:19 <mestery> marun: Can you reply on that thread again with this info? Lets start moving it in that direction.
14:34:24 <salv-orlando> mestery, marun: there isn't. the only point is... does nova's xenapi driver still work with nova-network
14:34:33 <salv-orlando> otherwise we should look at a combined deprecation
14:34:41 <salv-orlando> and see also what's johnthetubaguy opinion on it is
14:34:44 <mestery> salv-orlando: Good call, that can be on the ML thread as well
14:34:48 <marun> salv-orlando: hmmm, more questions...
14:35:03 * johnthetubaguy wonders if he can help, reads scrollback
14:35:08 <mestery> I do see Xen CI running against nova nad devstack
14:35:10 <mestery> But not neutron patches
14:35:41 <salv-orlando> johnthetubaguy: we realized XenAPI + OVS support has not been maintained for ages in Neutron. We're considering deprecation.
14:35:49 <johnthetubaguy> ah, right, gotcha
14:36:06 <johnthetubaguy> I think Citrix are working on a CI for that, the current CI is testing nova-network
14:36:36 <marun> johnthetubaguy: CI is fine, but in the absence of development resources it's not clear how detected breakage would get fixed
14:36:39 * mestery sees BobBall join the channel now
14:36:42 <johnthetubaguy> I think its passing, but it has all the neutron related races libvirt used to have, because its missing the event callback logic in Nova, I think, it could be something else
14:36:46 <salv-orlando> johnthetubaguy: good. As long as we're still sure the nova-network support still works we can keep our discussion contained to neutron.
14:37:01 <johnthetubaguy> BobBall: howdy, XenAPI neutron CI, hows that going?
14:37:05 <salv-orlando> johnthetubaguy: since I know the guy who did that support I was highly skeptical it worked ;)
14:37:20 <johnthetubaguy> salv-orlando: :)
14:37:32 <anteaya> BobBall: thanks
14:37:38 <BobBall> You're right that we're seeing races that we haven't been able to resolve yet - so we don't have a stable environment we can then convert to a CI
14:38:01 <anteaya> BobBall: I think the bigger question is can neutron expect more resources in addition to yourself
14:38:06 <marun> BobBall: Did you happen to read my most recent reply on the ml?
14:38:09 <BobBall> Those may be, as John said, similar to those that were seen in libvirt, but we've not yet tested that theory.
14:38:21 <anteaya> since I admire what you do and think you do great work, but you are on ly one person
14:38:46 <johnthetubaguy> salv-orlando: my take is, as long as deprecation is reversible, it could be the right thing to do
14:38:53 <BobBall> Absolutely 100% yes in the medium term, but in the short term we don't have additional resources to add on it.
14:39:13 <BobBall> I did marun - but didn't have much more to add.
14:39:40 <BobBall> My perspective is that I agree that a CI is a pre-requisite to being able to ensure continued support of XenAPI+OVS in Neutron
14:39:41 <marun> BobBall: Do you think continued support for Xen in Neutron is justified under the current circumstances?
14:39:54 <johnthetubaguy> I want to get the quark plugin that we use with XenServer more tested against upstream, etc, but honestly, that effort has not started yet, but its something I want to make happen if possible
14:40:23 <BobBall> I don't want Neutron to drop this support, but I can't justifiably argue for it until we have an automated way of testing it upstream.
14:40:41 <johnthetubaguy> marun: its an interesting twist with the nova-network deprecation talk, but that shouldn't change things
14:40:59 <mestery> I'm sensing we may need to deprecate it in the short term then, or at least move it out of tree into a stackforge repo.
14:41:12 <mestery> It coudl exist in stackforge in it's current state until someone takes it up and fixes it. Thoughts?
14:41:23 <johnthetubaguy> mastery: thats my take on this too
14:41:32 <marun> I think if Citrix/the Xen community wanted to provide Xen support for Neutron, they could do so out of tree relatively easily.
14:41:46 <BobBall> In terms of nova-network deprecation it is understood that XenAPI will have to work with Neutron+OVS, including an upstream CI, and we are aware of that as a requirement moving forward.
14:42:02 <salv-orlando> mestery: I seem to recall that the XenAPI support for OVS is tightly coupled with the OVS agent. I'm not sure if it can be split out, but it's surely worth trying
14:42:11 <mestery> #info Xen Support in Neutron to move out of tree into stackforge if possible
14:42:17 <mestery> OK, I think we can close on this subject here now.
14:42:24 <mestery> BobBall johnthetubaguy, thanks for attending with us here!
14:42:39 <mestery> Lets move on in the agenda now, 17 minutes left
14:42:43 <johnthetubaguy> no worries, sorry its not a better answer, but sounds like a good way forward
14:42:50 <amotoki> perhaps out of tree development allows xen folks to avoid continueous CI posting and they can pin neutron version to stabilize their developemnet
14:42:59 <mestery> #topic Report on progress of "MTU selection and advertisement" blueprint implementation.
14:43:00 <mestery> Does anyone know who put this on the agenda?
14:43:01 <amotoki> (though it is tihgtly coupled with ovs-agent)
14:43:13 <mestery> HenryG: ^^^^
14:43:32 <salv-orlando> ijw-ubuntu, I thin?
14:43:51 <HenryG> Hi
14:44:07 <HenryG> I would say the implementation is going fine. It will not be a lot of code.
14:44:13 <mestery> HenryG: OK, is that the updatE? :)
14:44:22 <mestery> HenryG: Have we merged the spec patch yet? That's been there for at least 10 days I think
14:44:51 <HenryG> I don't have +A on specs.
14:44:59 <mestery> HenryG: I'll take care of that post-meeting
14:45:04 <mestery> Thanks for the update HenryG!
14:45:07 <mestery> Moving right along ...
14:45:19 <mestery> #topic Proposal to remove py3* from the default tox envlist for now to address "fail blindness"
14:45:23 <mestery> gus: This is you I think :)
14:45:33 <mestery> And maybe dougwig too
14:45:45 <ihrachyshka> well, just +1 on making 'tox' actually pass. Is it controvercial?
14:45:50 <mestery> #link https://review.openstack.org/137516
14:45:56 <markmcclain> the target exists for everyone else right?
14:45:59 <mestery> ihrachyshka: I think so, thus why gus put it here
14:46:05 <mestery> markmcclain: Yes, I think so
14:46:25 <dougwig> i am about +20000000 on this.  i hate that we put something in broken, to attempt social engineering.  when it actual fact, it trains the opposite behavior, and frustrates newbies.
14:46:43 <markmcclain> dougwig: agreed
14:47:00 <markmcclain> generally we've gotten push back from the folks that really want py3 support now
14:47:03 <mestery> I am +2 on that patch until it works as well dougwig.
14:47:13 <dougwig> it is like this is all the integrated projects, so i'm not sure if we should do this in neutron (heck yes we should) or if we need to fight a larger battle.
14:47:19 <ajo> +1
14:47:26 <ihrachyshka> markmcclain, we're like ~3-4 cycles from there I guess.
14:47:35 <mestery> dougwig: We control our own destiny in neutron, we can win that battle then fight the larger war :)
14:47:40 <salv-orlando> dougwig: I think we're in control of our own tox.ini
14:47:41 <dougwig> if they want it now, submit the code to support py3.  i'd like it to work...  that's not my beef.
14:47:50 <dougwig> then here comes a +a
14:47:51 <mestery> dougwig: Well said
14:47:53 <markmcclain> ihrachyshka: I know.. wish we were much closer
14:48:10 <ihrachyshka> markmcclain, we're blocked by eventlet. main obstacle.
14:48:14 <salv-orlando> I think this change is doing nothing. Just avoiding failures for tests people probably don't even expect to run
14:48:20 <markmcclain> ihrachyshka: eventlet has py3 support
14:48:24 <salv-orlando> so it's harmless, imho
14:48:28 <markmcclain> (it's brand new)
14:48:38 <markmcclain> I'm +2 on this
14:48:42 <ihrachyshka> markmcclain, well, not for long (it's very fresh, and afaik still bugs are found)
14:49:35 <salv-orlando> ihrachyshka: so do reckon it's not feasible to achieve 3.x compatibility in Liberty?
14:50:00 <ihrachyshka> salv-orlando, hah, in dreams - maybe
14:50:02 <dougwig> even if it's reachable in two weeks, shouldn't the tox env be added in the patch that enables py3?
14:50:24 <dougwig> if we submitted code to enable something broken for *anything else*, would anyone here approve it?
14:50:26 <ihrachyshka> I don't know why we discuss the matter for 5 mins already
14:50:29 <markmcclain> salv-orlando: it's going to take a good deal of work dive into the dependency hole and fix the odd cases where it doesn't work
14:50:31 <marun> dougwig: nope
14:50:51 <dougwig> ihrachyshka: because religion.
14:51:35 <ihrachyshka> ok, the patch is +A'd, no way back, can we move on? :)
14:51:38 <mestery> OK, shall we move on?
14:51:46 <dougwig> please
14:51:47 <mestery> Lets move on.
14:51:48 <salv-orlando> ihrachyshka: there is always a way back!
14:51:59 <mestery> #topic Open Discussion
14:52:00 <salv-orlando> unless you jump off a cliff. In that case there isn't
14:52:04 <mestery> 8 minutes left, Open discussion time!
14:52:25 <ihrachyshka> I have oslo.log patch for kilo that breaks all CI for split vendors
14:52:38 <ihrachyshka> I wonder whether we're ok with merging it as-is, knowingly breaking them
14:52:45 <armax> ihrachyshka: link?
14:52:53 <ihrachyshka> (breakage is because they use neutron.openstack.common.log)
14:53:03 <ihrachyshka> #link https://review.openstack.org/159638
14:53:08 <markmcclain> ihrachyshka: can we not leave a shim there?
14:53:18 <amotoki> we need to remove logging from oslo-incubator.
14:53:20 <marun> markmcclain: via sys.modules hacks?
14:53:23 <salv-orlando> ihrachyshk, armax: I think one of the reasons of the decomposition is to not waste time with vendor incompatibilities
14:53:24 <ihrachyshka> markmcclain, libraries are mutual exclusive
14:53:30 <ihrachyshka> markmcclain, because of conflicting options
14:53:31 <marun> markmcclain: it may break pylint though ;)
14:53:42 <markmcclain> marun: haha
14:53:45 <mestery> lol
14:53:53 <sripriya> armax: mestery: May I request you to please take a look at https://review.openstack.org/#/c/159056/ for brocade vyatta vendor decomposition and provide your review.
14:54:04 <salv-orlando> so what do you reckon if we just send a warning on the mailing list, wait 48 hours for vendor repos to adapt, and then merge it?
14:54:20 <salv-orlando> without going into hacks.
14:54:25 <ihrachyshka> all in all, vendors should follow some kind of guidelines for their code and packages released, and I started a new wiki page for that
14:54:30 <ihrachyshka> #link https://wiki.openstack.org/wiki/Neutron/VendorSplitPackaging#Neutron_Vendor_split:_Packager_perspective
14:54:34 <ihrachyshka> please take a look and review
14:54:48 <ihrachyshka> salv-orlando, I'm ok with sending the email
14:54:52 <armax> salv-orlando, ihrachyshka: I think we whould not delete openstack/common log
14:54:58 <armax> ihrachyshka: until everyone is moved over
14:55:04 <ihrachyshka> salv-orlando, we just need to review the patch quickly enough because of dep freeze
14:55:11 <armax> ihrachyshka: if we can avoid breaking the world, I think we should
14:55:28 <marun> Maybe we need a dedicated communication mechanism for intentional breakage?
14:55:36 <ihrachyshka> armax, I already mentioned conflicting options, that's a common issue for oslo graduations
14:55:37 <amotoki> http://lists.openstack.org/pipermail/openstack-dev/2015-March/058610.html (oslo.log information)
14:56:10 <ihrachyshka> amotoki, right, that's what I would expect them to see if they use both versions
14:56:36 <dougwig> this is the "problem" with putting oslo in non-leaf nodes of the dependency tree, really.  you start having the same kind of backwards compatibility issues that we have with other neutron entry points that are being used in a library like fashion.
14:56:39 <ihrachyshka> marun, + for communication channel. some [new-tag] for openstack-dev?
14:56:53 <armax> ihrachyshka: ok
14:57:24 <marun> ihrachyshka: either that or a wiki page/file in tree that lists successive, timestamped breaking changes
14:57:44 <marun> ihrachyshka: so when breakage is detected, that is the first thing to check
14:57:51 <marun> ihrachyshka: rather than having to search ml
14:58:05 <ihrachyshka> understood. wiki is probably more dynamic for the use case
14:58:06 <amotoki> single entry point for information is nice.
14:58:36 <ihrachyshka> I'll create the page and give a heads-up in ML
14:58:41 <marun> ihrachyshka: sounds good
14:58:43 <dougwig> ihrachyshka: this becomes a real pain for having the same out-of-tree code support both kilo and earlier releases.
14:58:45 <ihrachyshka> (and reviews are welcome)
14:59:07 <mestery> OK, thanks folks!
14:59:19 <mestery> Don't forget about Kilo-3 reviews :)
14:59:22 <mestery> See you next week!
14:59:24 <mestery> #endmeeting