The root cause is the same. Could you try the latest code from the trunk and see if problem has gone away? If it has not then it is really a different issue.
Thanks, Eugene. On Mon, Jan 6, 2014 at 8:00 PM, rezroo <[email protected]> wrote: > Eugene, > Bug 1254555 seems to be the opposite of what I'm observing in Havana > devstack. The bug states: > > " I see that the ext-net network is not available after I do all of the > above router/subnet creation. It does become available to tenants as soon > as I restart neutron-server." > > But in the case below the external net is available until I kill and > restart neutron-server. Then after it remains unavailable no matter what > neutron daemon is killed and restarted - you cannot get anything from > "*neutron > net-external-list*" unless you make the external network shared. > > So how are the two bugs related? > Thanks, > Reza > > > On 01/05/2014 02:16 AM, Eugene Nikanorov wrote: > > Hi rezoo, > > This is a known bug for HAavana, which has been fixed (but was not > backported), please see: > https://bugs.launchpad.net/neutron/+bug/1254555 > > Thanks, > Eugene. > > > On Sun, Jan 5, 2014 at 1:25 AM, rezroo <[email protected]> wrote: > >> Hi all, >> I'm testing the Havana devstack and I noticed that after killing and >> restarting the neutron server public networks are not returned when queried >> via horizon or command line, which in Grizzly devstack the query returns >> the external network even after a quantum-server restart: >> >> Basically, before killing neutron-server, executing the below command as >> demo/demo/nova we have: >> >> *stack@host1:~$ neutron net-external-list * >> >> *+--------------------------------------+--------+------------------------------------------------------+* >> *| id | name | >> subnets |* >> >> *+--------------------------------------+--------+------------------------------------------------------+* >> *| 16c986b3-fa3d-4666-a6bd-a0dd9bfb5f19 | public | >> f0895c49-32ce-4ba2-9062-421c254892ec 172.24.4.224/28 >> <http://172.24.4.224/28> |* >> >> *+--------------------------------------+--------+------------------------------------------------------+* >> *stack@**host1:~$ * >> >> After killing and restarting neutron-server we have: >> >> *stack@**host1:~$ neutron net-external-list * >> >> *stack@**host1:~$ * >> >> >> I can get around this problem by making the "public" network/subnet >> shared then everything starts working, but after that I'm not able to >> revert it back to private again. In checking with grizzly version the >> external "public" network is listed for all tenants even when it is not >> shared, so making it shared is not a solution, only verification of what >> the problem is. >> >> First, I think this is a neutron bug, and want to report it if not >> reported already. I didn't find a bug report, but if you know of it please >> let me know. >> >> Second, I am looking for documentation that explains the security policy >> and permissions for external networks. Although by checking legacy and >> current behaviour it seems that all tenants should be able to list all >> external networks even if they aren't shared, I'm looking for documentation >> that explains the thinking and reasons behind this behaviour. Also >> confusing is if by default all tenants can see external networks then what >> is the purpose of the "shared" flag, and why once a network/subnet is >> shared it cannot be undone. >> >> Thanks in advance. >> >> >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > _______________________________________________ > OpenStack-dev mailing > [email protected]http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
