14:03:42 <szilard> #startmeeting Weekly Fuel BGS Meeting 14:03:42 <collabot> Meeting started Thu Jul 30 14:03:42 2015 UTC. The chair is szilard. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:42 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic. 14:03:42 <collabot> The meeting name has been set to 'weekly_fuel_bgs_meeting' 14:03:47 <szilard> #info Szilard Cserey 14:03:54 <mskalski> #info Michal Skalski 14:04:10 <szilard> #topic Opendaylight Plugin 14:04:40 <szilard> #info Michal is working on l3 in lithium + kilo 14:04:48 <szilard> #info behaviour of odl is not deterministic 14:04:53 <mskalski> #info for now Eeast-West traffic looks stable in lithium + kilo 14:05:07 <mskalski> #info problematic is North-South 14:06:02 <mskalski> that is all from my side 14:06:08 <szilard> what specific problem have you met 14:06:43 <mskalski> #info flows on bridge for external communication are not created 14:06:59 <szilard> okay, thanks Michal 14:07:03 <mskalski> #info floating IPs also doesnt work 14:07:08 <szilard> aham 14:08:09 <szilard> okay then I will change to the next topic 14:08:23 <mskalski> of course we talking here about l3 from odl 14:08:52 <mskalski> if we use neutron agent for l3 like we do until now then it is ok 14:09:13 <szilard> hmm 14:10:16 <szilard> Michal how did you find out this issue, what basic test did you run ? 14:11:09 <mskalski> So I created 3 networks net1, net2 and external and activated l3 inside odl controller 14:11:30 <mskalski> I can ping vms from net1 and net2 each other 14:11:41 <mskalski> but cant reach external network from them 14:12:05 <mskalski> or reach them by assigned floating IP 14:12:42 <mskalski> and I see that in the same scenarios ODL sometimes create flows on br-floating sometimes not 14:13:34 <mskalski> Now Im investigating devstack script for odl-networking 14:13:42 <mskalski> to see if I miss something 14:14:07 <szilard> aha, very wise 14:14:56 <mskalski> but on the devstack N-S traffic also doesnt work for me;) but I will need to investigate this 14:18:43 <szilard> I'm having some problems with OVS bridging in Fuel 14:21:05 <szilard> #topic Autodeployer support for Fuel 6.1 and Fuel plugin installation (Opendaylight) 14:21:33 <szilard> #info I just pushed a new patch regarding this => https://gerrit.opnfv.org/gerrit/#/c/1094/ 14:21:45 <szilard> #info everybody is welcomed to review it 14:23:06 <mskalski> woo large change:) 14:24:10 <szilard> #info I'm having some issues when I tell Fuel to use OVS bridges instead of Linux Bridges 14:24:18 <szilard> Michal what do you suggest ? 14:25:03 <mskalski> why do want to change linux bridges to ovs in the first place? 14:27:05 <mskalski> plugin acctualy expect that we have standard fuel network so there is a mix of linux bridges (which are good for bonding) and ovs bridges when odl can create flows 14:27:05 <szilard> it gives more flexibility, and Fuel 6.1 supports it according to documentation 14:27:59 <szilard> Everything is Okay when I use Linux bridges only 14:28:31 <szilard> - action: add-br 14:28:31 <szilard> name: br-fw-admin 14:28:42 <mskalski> hmm are you sure that you use only lnx bridges? 14:28:58 <szilard> - action: add-port 14:28:58 <szilard> bridge: br-fw-admin 14:28:58 <szilard> name: eth0 14:28:58 <szilard> - action: add-port 14:28:59 <szilard> bridge: br-mgmt 14:28:59 <szilard> name: eth0.101 14:29:12 <szilard> I checked it 14:29:19 <mskalski> br-floating for example is a ovs bridge 14:29:30 <mskalski> the same for br-int 14:29:33 <mskalski> br-tun 14:29:47 <szilard> True, But when I start mixing up LXN with OVS, then deployment starts to fail 14:30:19 <szilard> for example recently I did this: 14:30:27 <mskalski> hmm, this mix of bridges should work this is how it was designed in 6.1 14:30:57 <szilard> yes that's what I also read in https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/l23network 14:31:25 <szilard> - action: add-br 14:31:25 <szilard> name: br-eth0 14:31:25 <szilard> - action: add-port 14:31:25 <szilard> bridge: br-eth0 14:31:26 <szilard> name: eth0 14:31:35 <szilard> - action: add-br 14:31:35 <szilard> name: br-fw-admin 14:31:35 <szilard> provider: ovs 14:31:50 <szilard> - action: add-patch 14:31:50 <szilard> bridges: 14:31:50 <szilard> - br-fw-admin 14:31:51 <szilard> - br-eth0 14:31:51 <szilard> trunks: 14:31:51 <szilard> - 0 14:31:51 <szilard> provider: ovs 14:32:09 <szilard> so I configured this setup, but it failed during deployment 14:32:20 <szilard> I created a linux bridge br-eth0 14:32:36 <szilard> and then I created OVS bridge br-fw-admin 14:32:46 <szilard> and patched those bridges together 14:33:03 <szilard> during deployment, suddenly nodes become unavailable 14:33:24 <szilard> fuel-master is not able to reach the nodes on network 10.20.0.0/24 14:33:41 <szilard> initially 10.20.0.x is assigned to eth0 14:33:57 <szilard> but during deployment this IP address is moved and assigned to br-fw-admin 14:34:07 <szilard> and then the connection is broken 14:34:20 <szilard> I have to investigate further 14:34:44 <szilard> I'm not saying that I want to stick to this setup, which we used in 6.0 14:34:56 <szilard> I am well please using only the LNX bridges 14:34:58 <szilard> but 14:35:37 <szilard> I also need to find out how to use OVS bridges if we need them in the future 14:36:05 <szilard> I was playing around with a complete OVS setup for learning purposes, but as I said I got a lot of issues 14:36:41 <szilard> now I continue to go forward with the default bridging setup: with LNX bridges + that 2 extra OVS bridges 14:36:44 <mskalski> but I think that maybe it is not a good idea to reinvent network_scheme 14:37:37 <mskalski> Im mean that this standard deployment when we have a linux bridges an ovs bridges together is enough flexible for our purpouses 14:38:38 <mskalski> this is for example linux bridges from controller: 14:38:45 <szilard> aha 14:38:54 <mskalski> root@node-1:~# brctl show 14:38:54 <mskalski> bridge name bridge id STP enabled interfaces 14:38:54 <mskalski> br-ex 8000.02118b73aefe no br-ex-hapr 14:38:56 <mskalski> br-ex-vrouter 14:38:58 <mskalski> eth1 14:39:00 <mskalski> p_br-floating-0 14:39:02 <mskalski> br-fw-admin 8000.0eb1598f6172 no eth0 14:39:04 <mskalski> br-mesh 8000.5e767e32b22b no eth4 14:39:06 <mskalski> br-mgmt 8000.12ca01b2598a no br-mgmt-hapr 14:39:08 <mskalski> br-mgmt-vrouter 14:39:10 <mskalski> eth3 14:39:12 <mskalski> mgmt-conntrd 14:39:14 <mskalski> br-storage 8000.8e9b6be1be4c no eth2 14:39:20 <mskalski> and on top of them we have ovs bridges: 14:39:49 <mskalski> br-tun, br-floating, br-int which can be managed by ODL 14:40:08 <mskalski> for now I don't see why do we need to change this 14:40:17 <szilard> so that was the reason why these ones were kept as OVS 14:40:28 <szilard> for ODL 14:40:40 <mskalski> maybe not for odl 14:41:05 <mskalski> but as alredy send you a link there were problem if we have only ovs bridges 14:41:17 <mskalski> and we wanted to use bonding 14:41:34 <mskalski> so what we see in 6.1 is acctuly improvment 14:41:44 <szilard> so how can bonding be implemented in 6.1 14:41:51 <szilard> do you have suggestion 14:42:19 <mskalski> bonding is implemented on linux bridges that was the point of this change 14:42:31 <szilard> aha 14:43:14 <szilard> good 14:44:44 <szilard> Thanks Michal for the explanation, I don't have further question at this moment 14:44:54 <mskalski> ok 14:44:55 <mskalski> btw 14:44:59 <szilard> yepp 14:45:44 <mskalski> I saw that Daniel is prepering some presentation on Openstack Summit in Tokyo about what we do here, do you now maybe some details? 14:46:16 <mskalski> https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/presentation/5415 14:47:23 <szilard> Yes, he is working with the ODL Service Function Chaining feature, I think he will present something related to that 14:47:51 <mskalski> ok understand 14:49:39 <szilard> well Michal, thanks man for joining this meeting :) I will then close it soon 14:50:09 <mskalski> ok thank you Szilard:) 14:50:30 <szilard> have a good evening and keep up the good work! ;) 14:50:41 <mskalski> bye:) 14:50:53 <szilard> bye Michal :) 14:51:36 <szilard> God Bless You all !!! 14:51:42 <szilard> 3 14:53:07 <szilard> 2 14:55:20 <szilard> by everybody, see you next week on Tuesday 16:00 CEST !!! 14:55:21 <szilard> 1 14:55:30 <szilard> #endmeeting