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