Open Stack

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 <reza at dslextreme.com> 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 <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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://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/b39fd938/attachment-0001.html>