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 <r...@dslextreme.com > <mailto:r...@dslextreme.com>> 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 > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
