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 <jcaam...@suse.de> 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 <thanh...@linuxfoundation.org> > To: jcaam...@suse.de > Cc: integration-...@lists.opendaylight.org <integration-dev@lists.opend > aylight.org>, sfc-dev@lists.opendaylight.org <sfc-dev@lists.opendayligh > 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 <jcaam...@suse.de> > 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/67436 > 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 sfc-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/sfc-dev
