I agree that if this occurred it is a bug. Please open a bug for us in launchpad and include your controller worker logs and amphora-agent log from the impacted amphora.
Thanks, Michael On Wed, Jun 1, 2016 at 9:55 AM, Stephen Balukoff <step...@balukoff.com> wrote: > Hello Yong Sheng Gong! > > Apologies for the lateness of my reply (I've been intermittently available > over the last month and am now just catching up on ML threads). Anyway, did > you get your question answered elsewhere? It looks like you've discovered a > bug in the behavior here-- when you created the member on server_subnet2, an > interface should have been added to the amphora in the amphora-haproxy > namespace. If you haven't yet filed a bug report on this, could you? > > In any case, the behavior you're seeing (which is not correct in this case) > is that if the amphora doesn't have a directly-connected interface is that > it will use its default route to attempt to reach the member. > > Stephen > > On Tue, May 10, 2016 at 12:01 AM, 龚永生 <gong.yongsh...@99cloud.net> wrote: >> >> Hi, Stephen, >> >> By running following commands: >> neutron lbaas-pool-create --lb-algorithm ROUND_ROBIN --loadbalancer >> 85800051-31fb-4ca0-962d-8835656a61ef --protocol HTTP --name pool2 >> >> neutron net-create server_net2 >> >> neutron subnet-create server_net2 10.20.2.0/24 --name server_subnet2 >> >> neutron lbaas-member-create --subnet server_subnet2 --address 10.20.2.10 >> --protocol-port 8080 pool2 >> >> neutron lbaas-l7policy-create --name policy1 --action REDIRECT_TO_POOL >> --redirect-pool pool2 --listener 8ec3a2e5-8cb5-472e-a12c-f067eefa4b7a >> >> neutron lbaas-l7rule-create --type PATH --compare-type STARTS_WITH --value >> "/api" policy1 >> >> >> I found there is no interface on server_subnet2 in namespace >> amphora-haproxy on amphora: >> ubuntu@amphora-86359e7c-f473-41c3-9531-c8bf129ec6b7:~$ sudo ip netns exec >> amphora-haproxy ip a >> 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state >> UP group default qlen 1000 >> link/ether fa:16:3e:5f:4c:c1 brd ff:ff:ff:ff:ff:ff >> inet 10.20.0.33/24 brd 10.20.0.255 scope global eth1 >> valid_lft forever preferred_lft forever >> inet 10.20.0.32/24 brd 10.20.0.255 scope global secondary eth1:0 >> valid_lft forever preferred_lft forever >> inet6 fe80::f816:3eff:fe5f:4cc1/64 scope link >> valid_lft forever preferred_lft forever >> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state >> UP group default qlen 1000 >> link/ether fa:16:3e:8a:3d:f5 brd ff:ff:ff:ff:ff:ff >> inet 10.20.1.5/24 brd 10.20.1.255 scope global eth2 >> valid_lft forever preferred_lft forever >> inet6 fe80::f816:3eff:fe8a:3df5/64 scope link >> valid_lft forever preferred_lft forever >> >> Is L7 policy using "Routed (layer-3) connectivity"? >> >> Thanks >> yong sheng gong >> -- >> 龚永生 >> 九州云信息科技有限公司 99CLOUD Co. Ltd. >> 邮箱(Email):gong.yongsh...@99cloud.net >> 地址:北京市海淀区上地三街嘉华大厦B座806 >> Addr : Room 806, Tower B, Jiahua Building, No. 9 Shangdi 3rd Street, >> Haidian District, Beijing, China >> 手机(Mobile):+86-18618199879 >> 公司网址(WebSite):http://99cloud.net > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev