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 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


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 r...@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 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
 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-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 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
 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