Re: [openstack-dev] [neutron][external networks] "neutron net-external-list" returns empty list after restart of neutron-server

2014-01-06 Thread Eugene Nikanorov 
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  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  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
>>  |*
>>
>> *+--++--+*
>> *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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> ___
> OpenStack-dev mailing 
> listOpenStack-dev@lists.openstack.orghttp://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

Re: [openstack-dev] [neutron][external networks] "neutron net-external-list" returns empty list after restart of neutron-server

2014-01-06 Thread rezroo 
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  > 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
>  |//
> 
> //+--++--+//
> //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
> 
> 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

Re: [openstack-dev] [neutron][external networks] "neutron net-external-list" returns empty list after restart of neutron-server

2014-01-05 Thread Eugene Nikanorov 
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  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
>  |*
>
> *+--++--+*
> *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
> 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] [neutron][external networks] "neutron net-external-list" returns empty list after restart of neutron-server

2014-01-04 Thread rezroo 

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 |//
   
//+--++--+//
   //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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev