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