Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140106/f0e146a7/attachment.html>