Thanh, issue confirmed fixed! > I can confirm that at least in my test environment I had to set this > parameter.
Confirmed on my side too. BR Jaime -----Original Message----- From: Thanh Ha <[email protected]> To: [email protected] Cc: [email protected] <[email protected] aylight.org>, [email protected] <[email protected] t.org> Subject: Re: [integration-dev] [sfc-dev] sfc csit failure Date: Wed, 24 Jan 2018 09:56:03 -0500 Ah that one should be fine then. As long as it has ZZCI prefix. Thanh On Wed, Jan 24, 2018 at 8:00 AM, Jaime Caamaño Ruiz <[email protected]> wrote: > Hello > > Thats great, thanks for the support! I will check it out and let you > know. > > > For the record we used "ZZCI - CentOS 7 - docker - 20180110-1659" > to > > test. I'm not sure which docker image you're using but you might > want > > to switch to using one of the ZZCI ones moving forward. > > We are using the releng defaults: > > jjb/releng-defaults.yaml: docker_system_image: ZZCI - CentOS 7 - > docker - 20180109-0346 > > I don't know what's the change between the two but maybe we should > step > this one. > > BR > Jaime. > > -----Original Message----- > From: Thanh Ha <[email protected]> > To: [email protected] > Cc: [email protected] <[email protected] > nd > aylight.org>, [email protected] <[email protected] > gh > t.org> > Subject: Re: [integration-dev] [sfc-dev] sfc csit failure > Date: Mon, 22 Jan 2018 15:04:59 -0500 > > On Mon, Jan 22, 2018 at 5:14 AM, Jaime Caamaño Ruiz <[email protected] > > > wrote: > > > - clean ip tables in B sudo iptables -F sudo > iptables > > > -t nat -FIn my testing cleaning the iptables in this way breaks > the > > > docker container's ability to route to the outside world so I > would > > > not recommend cleaning the iptables as this will make the > container > > > not be able to reach anything at all. > > > > A requirement of our test setup is that the docker container can > > reach > > the builder with no nat'ing in between. By default docker network > > does > > masquerading to the outside world and cleaning ip tables gets rid > of > > it. Is a rather rudimentary way of achieving it but worked for us. > > The > > proper way to do it is by creating a separate docker network with > the > > option com.docker.network.bridge.enable_ip_masquerade disabled. > > > > Disable masquerading also requires adding a route in the builder > back > > to the docker network. Otherwise, as you say, there wont be > > connectivity: > > > > route add -net <docker network> netmask <docker netmask> gw <docker > > host ip> > > > > Worth mentioning is that this whole setup worked for us pre cloud > > provider change. > > > > > After working with our cloud provider this morning we were able to > resolve this with this patch https://git.opendaylight.org/gerrit/6743 > 6 > to allow the docker IPs to be route-able rather than dropped by the > network. > > This should allow your csit tests to communicate between hosts and > containers now but let us know if there continues to be issues. For > the > record we used "ZZCI - CentOS 7 - docker - 20180110-1659" to test. > I'm > not sure which docker image you're using but you might want to switch > to using one of the ZZCI ones moving forward. > > I can also confirm that even calling the 2 iptables -F commands won't > break the routing with the patch above so you should be able to > continue with your existing tests that do this. > > > > > We should be setting iptables -P FORWARD ACCEPT to allow another > > host > > > to reach inside the docker container on the docker host however > > even > > > after setting this things are still unrouteable. > > > > This is one more thing that docker did by default but no longer > does. > > I > > will crosscheck if it affects us but I dont think so. Our specific > > problem is packets going out of the container towards the builder, > > being forwarded in the docker host, but getting lost somewhere > > between > > the docker host and the builder. > > > > I can confirm that at least in my test environment I had to set this > parameter. > > Regards, > Thanh > > > _______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
