[Yahoo-eng-team] [Bug 1747167] [NEW] Neutron driver handles incorrectly 404 errors

[Cedric Brandily]

Public bug reported:

Neutronclient transforms errors using exception_handler_v20[1].
In particular, it transforms 404 responses into:
 1) [2] neutronclient.common.exceptions.Client if response body contains 
a type attribute (with value , type examples: NetworkNotFound, 
PortNotFound) and Client exists
 2) [3] neutronclient.common.NotFound otherwise

Nova neutron driver[4] supports mostly 1) but not 2).
But Neutron in case of 404 returns the following body:

  {"message": "The resource could not be found.\n\n\n",
"code": "404 Not Found", "title": "Not Found"}

and we end in 2) and Nova Neutron driver doesn't catch the error
correctly and raises a 500

You can reproduce it indirectly using:
 openstack server add fixed ip  

which queries:
 nova-base-url/os-networks/

assuming it would return the network or a 404 but it returns 500.


This trouble can be solved by catching NotFound instead of
NetworkNotFoundClient/PortNotFoundClient as there are subclasses of
NotFound.


[1] 
https://github.com/openstack/python-neutronclient/blob/6a2112e1824980af1bc9216441fa58a7dfd00988/neutronclient/v2_0/client.py#L47-L93
[2] 
https://github.com/openstack/python-neutronclient/blob/6a2112e1824980af1bc9216441fa58a7dfd00988/neutronclient/v2_0/client.py#L71
[3] 
https://github.com/openstack/python-neutronclient/blob/6a2112e1824980af1bc9216441fa58a7dfd00988/neutronclient/v2_0/client.py#L85
[4] nova.network.neutronv2.api

** Affects: nova
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: ocata-backport-potential pike-backport-potential

** Changed in: nova
 Assignee: (unassigned) => Cedric Brandily (cbrandily)

** Description changed:

- Neutronclient transforms errors using exception_handler_v20[1]. 
+ Neutronclient transforms errors using exception_handler_v20[1].
  In particular, it transforms 404 responses into:
-  1) [2] neutronclient.common.exceptions.Client if response body 
contains a type attribute (with value , type examples: NetworkNotFound, 
PortNotFound) and Client exists
-  2) [3] neutronclient.common.NotFound otherwise
+  1) [2] neutronclient.common.exceptions.Client if response body 
contains a type attribute (with value , type examples: NetworkNotFound, 
PortNotFound) and Client exists
+  2) [3] neutronclient.common.NotFound otherwise
  
  Nova neutron driver[4] supports mostly 1) but not 2).
  But Neutron in case of 404 returns the following body:
  
-   {"message": "The resource could not be found.\n\n\n",
+   {"message": "The resource could not be found.\n\n\n",
  "code": "404 Not Found", "title": "Not Found"}
  
  and we end in 2) and Nova Neutron driver doesn't catch the error
  correctly and raises a 500
  
+ You can reproduce it indirectly using:
+  openstack server add fixed ip  
  
- You can reproduce it indirectly using:
-  openstack server add fixed ip  
+ which queries:
+  nova-base-url/os-networks/
  
- which queries: 
-  nova-base-url/os-networks/
- 
- assuming it would return the network or a 404 but it returns 500
+ assuming it would return the network or a 404 but it returns 500.
  
  
  This trouble can be solved by catching NotFound instead of
  NetworkNotFoundClient/PortNotFoundClient as there are subclasses of
  NotFound.
  
  
+ 
  [1] 
https://github.com/openstack/python-neutronclient/blob/6a2112e1824980af1bc9216441fa58a7dfd00988/neutronclient/v2_0/client.py#L47-L93
  [2] 
https://github.com/openstack/python-neutronclient/blob/6a2112e1824980af1bc9216441fa58a7dfd00988/neutronclient/v2_0/client.py#L71
  [3] 
https://github.com/openstack/python-neutronclient/blob/6a2112e1824980af1bc9216441fa58a7dfd00988/neutronclient/v2_0/client.py#L85
  [4] nova.network.neutronv2.api

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1747167

Title:
  Neutron driver handles incorrectly 404 errors

Status in OpenStack Compute (nova):
  New

Bug description:
  Neutronclient transforms errors using exception_handler_v20[1].
  In particular, it transforms 404 responses into:
   1) [2] neutronclient.common.exceptions.Client if response body 
contains a type attribute (with value , type examples: NetworkNotFound, 
PortNotFound) and Client exists
   2) [3] neutronclient.common.NotFound otherwise

  Nova neutron driver[4] supports mostly 1) but not 2).
  But Neutron in case of 404 returns the following body:

    {"message": "The resource could not be found.\n\n\n",
  "code": "404 Not Found", "title": "Not Found"}

  and we end in 2) and Nova Neutron driver doesn't catch the error
  correctly and raises a 500

  You can reproduce it indirectly using:
   openstack server add fixed ip  

  which queries:
   nova-base-url/os-netwo

[Yahoo-eng-team] [Bug 1691831] [NEW] VM evacuation is broken with shared torage if VM console.log is not owned by nova

[Cedric Brandily]

Public bug reported:

On my Ocata deployment (with a shared storage between my KVMs hypervisors), the 
following worflow is failing:
 * stop nova-compute on a KVM hypervisor
 * stop a VM on the KVM hypervisor using virsh destroy
 * evacuate the VM ... which fails with the stacktrace:

ERROR nova.compute.manager [req-dcb547e3-5f98-488e-8dbf-ad4453ce82ac 
7e6f47b9c6cf4994bb38a2eb3ad6243f 920a4480938349eca2651c140ce33fdd - - -] 
[instance: a129ab8f-c224-4df2-8134-6716cfe89acf] Setting instance vm_state to 
ERROR
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf] 
Traceback (most recent call last):
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf]   
File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 6717, in 
_error_out_instance_on_exception
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf] 
yield
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf]   
File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2751, in 
rebuild_instance
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf] 
bdms, recreate, on_shared_storage, preserve_ephemeral)
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf]   
File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2795, in 
_do_rebuild_instance_with_claim
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf] 
self._do_rebuild_instance(*args, **kwargs)
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf]   
File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2910, in 
_do_rebuild_instance
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf] 
self._rebuild_default_impl(**kwargs)
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf]   
File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2673, in 
_rebuild_default_impl
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf] 
block_device_info=new_block_device_info)
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf]   
File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 2689, 
in spawn
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf] 
self._ensure_console_log_for_instance(instance)
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf]   
File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 2961, 
in _ensure_console_log_for_instance
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf] 
libvirt_utils.file_open(console_file, 'a').close()
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf]   
File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/utils.py", line 350, 
in file_open
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf] 
return open(*args, **kwargs)
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf] 
IOError: [Errno 13] Permission denied: 
'/var/lib/nova/instances/a129ab8f-c224-4df2-8134-6716cfe89acf/console.log'
ERROR nova.compute.manager [instance: a129ab8f-c224-4df2-8134-6716cfe89acf]


After some investigation:

_ensure_console_log_for_instance[1] ensures console.log existence. A
change[2] updated this method in order to succeed if the file exists
without nova being able to open it by ignoring EPERM erros (errno 1,
"operation not permitted") but it should ignore EACCES errors (errno 13,
"permission denied").


 >>> open('/etc/shadow')
 Traceback (most recent call last):
   File "", line 1, in 
 IOError: [Errno 13] Permission denied: '/etc/shadow'


EACCES errors are raised when you cannot do something because of insufficient 
permissions, EPERM are raised when you cannot do something (even with root 
account).


[1] nova.virt.libvirt.driver
[2] https://review.openstack.org/392643

** Affects: nova
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1691831

Title:
  VM evacuation is broken with shared torage if VM console.log is not
  owned by nova

Status in OpenStack Compute (nova):
  New

Bug description:
  On my Ocata deployment (with a shared storage between my KVMs hypervisors), 
the following worflow is failing:
   * stop nova-compute on a KVM hypervisor
   * stop a VM on the KVM hypervisor using virsh destroy
   * evacuate the VM ... which fails with the stacktrace:

  ERROR nova.compute.manager [req-dcb547e3-5f98-488e-8dbf-ad4453ce82ac 
7e6f47b9c6cf4994bb38a2eb3ad6243f 920a4480938349eca2651c140ce33fdd - - -] 
[instance: a129ab8f-c224-4df2-8134-6716cfe89acf] Setting instance vm_state to 
ERROR
  ERROR nova.compute.manager [instance: 

[Yahoo-eng-team] [Bug 1622460] Re: neutron-server report 'FirewallNotFound' when delete firewall under l3_ha mode

[Cedric Brandily]

*** This bug is a duplicate of bug 1658060 ***
https://bugs.launchpad.net/bugs/1658060

** This bug has been marked a duplicate of bug 1658060
   FirewallNotFound exceptions when deleting the firewall in FWaaS-DVR

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1622460

Title:
  neutron-server report 'FirewallNotFound' when delete firewall under
  l3_ha mode

Status in neutron:
  Confirmed

Bug description:
  When we delete a firewall under l3-ha mode, some neutron-servers
  reports error logs: 'FirewallNotFound':

  Environment:
  * Openstack Kilo version
  * Three neutron servers using ha-proxy in balance roundrobin mode, and 
provides VIP (keepalived)
  * l3_ha=True is set in neutron-servers to provide L3 HA.
  * Three l3-agents on 3 network nodes

  We found 2 out of 3 neutron-servers print the following error logs

  ---
  Error logs:
  ===
  2016-09-12 14:33:34.250 22722 DEBUG oslo_messaging._drivers.amqp [-] unpacked 
context: {u'read_deleted': u'no', u'project_name': u'zhaoyi', u'user_id': 
u'5f228382dd8d4001bd079cfab624e870', u'roles': [u'_member_', u'Member', 
u'user', u'admin'], u'tenant_id': u'd3147020bd1f4a709654b7e62885bd9f', 
u'auth_token': u'***', u'request_id': 
u'req-89116778-b4fb-4232-8249-500f1db5d3f8', u'is_admin': True, u'user': 
u'5f228382dd8d4001bd079cfab624e870', u'timestamp': u'2016-09-12 
06:33:33.570294', u'tenant_name': u'zhaoyi', u'project_id': 
u'd3147020bd1f4a709654b7e62885bd9f', u'user_name': u'zhaoyi', u'tenant': 
u'd3147020bd1f4a709654b7e62885bd9f'} unpack_context 
/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqp.py:203
  2016-09-12 14:33:34.253 22722 DEBUG 
neutron_fwaas.services.firewall.fwaas_plugin 
[req-89116778-b4fb-4232-8249-500f1db5d3f8 ] firewall_deleted() called 
firewall_deleted 
/usr/lib/python2.7/site-packages/neutron_fwaas/services/firewall/fwaas_plugin.py:62
  2016-09-12 14:33:34.260 22722 DEBUG neutron_fwaas.db.firewall.firewall_db 
[req-89116778-b4fb-4232-8249-500f1db5d3f8 ] delete_firewall() called 
delete_firewall 
/usr/lib/python2.7/site-packages/neutron_fwaas/db/firewall/firewall_db.py:362
  2016-09-12 14:33:34.303 22759 DEBUG keystoneclient.session [-] RESP: [200] 
content-length: 3084 x-subject-token: 
{SHA1}fb0b83f9b5d3a4b459a1f2845c1a1bd4bba3c008 vary: X-Auth-Token date: Mon, 12 
Sep 2016 06:33:34 GMT content-type: application/json x-openstack-request-id: 
req-38cd15ab-f193-4d04-80bd-088638497b26
  RESP BODY: {"token": {"methods": ["password", "token"], "roles": [{"id": 
"9fe2ff9ee4384b1894a90878d3e92bab", "name": "_member_"}, {"id": 
"bf49f6a34f5b4ec8843efee8a840a8b3", "name": "Member"}, {"id": 
"a104bc435a5d4031b9712dd702cb8672", "name": "user"}, {"id": 
"11b9aa45b311407ba9460b95eb1534c2", "name": "admin"}], "expires_at": 
"2016-09-12T07:03:12.00Z", "project": {"domain": {"id": "default", "name": 
"Default"}, "id": "d3147020bd1f4a709654b7e62885bd9f", "name": "zhaoyi"}, 
"catalog": "", "extras": {}, "user": {"domain": {"id": "default", 
"name": "Default"}, "id": "5f228382dd8d4001bd079cfab624e870", "name": 
"zhaoyi"}, "audit_ids": ["Q9kbnQe8SzOcZ7ig6_-2ew", "guy9k1VsThmCGwfavbmvjw"], 
"issued_at": "2016-09-12T06:03:12.784462"}}
   _http_log_response 
/usr/lib/python2.7/site-packages/keystoneclient/session.py:224
  2016-09-12 14:33:34.307 22759 DEBUG neutron_fwaas.db.firewall.firewall_db 
[req-b354359e-4536-43bd-a0ca-6ffc27ef72d7 ] get_firewall_rules() called 
get_firewall_rules 
/usr/lib/python2.7/site-packages/neutron_fwaas/db/firewall/firewall_db.py:534
  2016-09-12 14:33:34.322 22759 INFO neutron.wsgi 
[req-b354359e-4536-43bd-a0ca-6ffc27ef72d7 ] 10.65.0.99,10.65.0.99 - - 
[12/Sep/2016 14:33:34] "GET /v2.0/fw/firewall_rules.json HTTP/1.1" 200 6555 
0.163946
  2016-09-12 14:33:34.447 22722 ERROR oslo_messaging.rpc.dispatcher 
[req-89116778-b4fb-4232-8249-500f1db5d3f8 ] Exception during message handling: 
Firewall 6278942e-6485-4ceb-92e5-8ddfa9fb4d25 could not be found.
  2016-09-12 14:33:34.447 22722 TRACE oslo_messaging.rpc.dispatcher Traceback 
(most recent call last):
  2016-09-12 14:33:34.447 22722 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 142, 
in _dispatch_and_reply
  2016-09-12 14:33:34.447 22722 TRACE oslo_messaging.rpc.dispatcher 
executor_callback))
  2016-09-12 14:33:34.447 22722 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 186, 
in _dispatch
  2016-09-12 14:33:34.447 22722 TRACE oslo_messaging.rpc.dispatcher 
executor_callback)
  2016-09-12 14:33:34.447 22722 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 130, 
in _do_dispatch
  2016-09-12 14:33:34.447 22722 TRACE oslo_messaging.rpc.dispatcher result 
= func(ctxt, **new_args)
  2016-09-12 14:33:34.447 22722 TRACE 

[Yahoo-eng-team] [Bug 1520152] Re: _allocate_vr_id not working as expected because of REPEATABLE READ transactions

[Cedric Brandily]

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1520152

Title:
  _allocate_vr_id not working as expected because of REPEATABLE READ
  transactions

Status in neutron:
  Fix Released

Bug description:
  The method _allocate_vr_id[1] uses the pattern:

   for count in range(MAX_ALLOCATION_TRIES):
 try:
   
   
   return candidate
 except DBDuplicateEntry:
   pass

  Because of REPEATABLE READ transactions, the selected candidate is
  always the same, so if first try fails then next tries will also fail.


  [1] neutron.db.l3_hamode

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1520152/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1664294] [NEW] Netlink solution not enough mature for Ocata

[Cedric Brandily]

Public bug reported:

neutron-fwaas replaced conntrack-tools by netlink + pyroute2[1] in order
to delete faster conntrack entries when the rules associated to a
firewall (through a policy) are updated.


This change highlights many warnings:
1) the code readability should be improved:
** it embeds dead code/unused constants[2]
** it uses non-meaningful variable names[3] ("h", "ct")
** it uses hardcoded values instead of existing constants[3]
** it miss docstrings/comments for tricky parts[2][3]

2) the change tricky part[3] is untested

3) the code seems unhealthy, 
** nothing ensures that file descriptors/objects are correctly closed/destroyed 
if an exception is raised[3]
** pyroute2.netns.setns use[3] seems not (green)thread-safe. It seems a 
(green)thread can move the process in $netns2 when a concurrent greenthread is 
"working" in $netns1. It can be solved by a lock.

4) the change should highlight if and why nfct and libc C libraries used
in the change are eventlet-friendly.

5) the change uses pyroute2.netns.setns in [3] which moves the current process 
to a specific netns
** it seems that when we enter the netns, the process seems to never go back in 
the root netns[9].  Is it an acceptable limitation?
** When the process is in a netns, every network action is done in the netns 
including rpc calls, remote sylog which won't work because they should be done 
in the root namespace.


1) => we can live on the short term with it (easy to address)
2) => we can address it (costly)
3) => we can address it (easy to solve)
4) => i don't know how to get an answer to this question
5) => it seems to imply that we have to dedicate specific(s) process(es) moving 
between netns to list/kill/flush_entries like as it's done in oslo.rootwrap 
daemon mode (very costly by required)


These warnings are based on my understanding of the netlink feature, perhaps i 
miss something.


[1] https://review.openstack.org/389654
[2] 
https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/common/netlink_constants.py
[3] 
https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/privileged/netlink_lib.py
[9] Code used to test pyroute2:
import os, pyroute2, pyroute2.netns

root_ifs = {x.get_attr('IFLA_IFNAME') for x in pyroute2.IPRoute().get_links()}
fd = pyroute2.netns.setns('taz')
ns_ifs = {x.get_attr('IFLA_IFNAME') for x in pyroute2.IPRoute().get_links()}
os.close(fd)
last_ifs = {x.get_attr('IFLA_IFNAME') for x in pyroute2.IPRoute().get_links()}

if root_ifs == ns_ifs:
print 'Add a new interface in root netns with ip tuntap a mode tap'
elif last_ifs == root_ifs:
print 'OK: we ended in root netns'
elif root_ifs != last_ifs == ns_ifs:
print 'KO: we ended in taz netns'
else:
print 'Something is wrong'

** Affects: neutron
     Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: fwaas ocata-rc-potential

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1664294

Title:
  Netlink solution not enough mature for Ocata

Status in neutron:
  New

Bug description:
  neutron-fwaas replaced conntrack-tools by netlink + pyroute2[1] in
  order to delete faster conntrack entries when the rules associated to
  a firewall (through a policy) are updated.

  
  This change highlights many warnings:
  1) the code readability should be improved:
  ** it embeds dead code/unused constants[2]
  ** it uses non-meaningful variable names[3] ("h", "ct")
  ** it uses hardcoded values instead of existing constants[3]
  ** it miss docstrings/comments for tricky parts[2][3]

  2) the change tricky part[3] is untested

  3) the code seems unhealthy, 
  ** nothing ensures that file descriptors/objects are correctly 
closed/destroyed if an exception is raised[3]
  ** pyroute2.netns.setns use[3] seems not (green)thread-safe. It seems a 
(green)thread can move the process in $netns2 when a concurrent greenthread is 
"working" in $netns1. It can be solved by a lock.

  4) the change should highlight if and why nfct and libc C libraries
  used in the change are eventlet-friendly.

  5) the change uses pyroute2.netns.setns in [3] which moves the current 
process to a specific netns
  ** it seems that when we enter the netns, the process seems to never go back 
in the root netns[9].  Is it an acceptable limitation?
  ** When the process is in a netns, every network action is done in the netns 
including rpc calls, remote sylog which won't work because they should be done 
in the root namespace.

  
  1) => we can live on the short term with it (easy to address)
  2) => we can address it (costly)
  3) => we can address it (easy to solve)
  4) => i don't know how to get an answer to this question
  5) => it seems to imply that we have to dedicate specific(s) process(es) 
moving between net

[Yahoo-eng-team] [Bug 1658817] [NEW] _make_firewall_dict_with_rules gets FW rules one by one from db

[Cedric Brandily]

Public bug reported:

_make_firewall_dict_with_rules returns a firewall and its rules by
calling get_firewall, get_firewall_policy and get_firewall_rule for each
rule ... which implies a db query for each rule and slowness (on my
deploiement 12s to get a firewall with 1000 rules).

It seems possible to get all FW rules in one db query.

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: fwaas mitaka-backport-potential newton-backport-potential

** Tags added: mitaka-backport-potential newton-backport-potential

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1658817

Title:
  _make_firewall_dict_with_rules gets FW rules one by one from db

Status in neutron:
  New

Bug description:
  _make_firewall_dict_with_rules returns a firewall and its rules by
  calling get_firewall, get_firewall_policy and get_firewall_rule for
  each rule ... which implies a db query for each rule and slowness (on
  my deploiement 12s to get a firewall with 1000 rules).

  It seems possible to get all FW rules in one db query.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1658817/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1587418] Re: router-create takes first parameter as name

[Cedric Brandily]

This bug affects neutronclient not neutron

** Changed in: neutron
   Status: Incomplete => Invalid

** Also affects: python-neutronclient
   Importance: Undecided
   Status: New

** Changed in: python-neutronclient
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1587418

Title:
  router-create takes first parameter as name

Status in neutron:
  Invalid
Status in python-neutronclient:
  Incomplete

Bug description:
  While creating a router the following situation occurred:

  [root@Mitaka5 ~(keystone_admin)]# neutron router-create --description "This 
is a bug" router_one
  Created a new router:
  +-+--+
  | Field   | Value|
  +-+--+
  | admin_state_up  | True |
  | availability_zone_hints |  |
  | availability_zones  |  |
  | description | router_one   |
  | distributed | False|
  | external_gateway_info   |  |
  | ha  | False|
  | id  | 7aecee37-b665-4ab2-aad0-1ce58b388004 |
  | name| This is a bug|
  | routes  |  |
  | status  | ACTIVE   |
  | tenant_id   | 9d56bfe003a341fea149442236760e0f |
  +-+--+

  
  Here the description is considered as name and name is considered as 
description.

  Summary:
  The first field is always taken to be name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1587418/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1583266] Re: watch_log_file = true badness

[Cedric Brandily]

*** This bug is a duplicate of bug 1583270 ***
https://bugs.launchpad.net/bugs/1583270

This bug is an oslo.log bug not a neutron one as watch_log_file=True on
linux platforms use oslo_log.watchers.FastWatchedFileHandler which
depends on select.poll which is not eventlet-friendly

** Changed in: neutron
   Status: New => Invalid

** Also affects: oslo.log
   Importance: Undecided
   Status: New

** This bug has been marked a duplicate of bug 1583270
   watch-file=True causes blocking

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1583266

Title:
  watch_log_file = true badness

Status in neutron:
  Invalid
Status in oslo.log:
  New

Bug description:
  We had:
  watch_log_file = true

  Set on our neutron agents. We have DVR enabled and were seeing
  significant slowdowns on fip changes. Kevin Benton and I narrowed it
  down to watch_log_file = true. It seems to be using blocking calls
  that prevent eventlet from performing asyncio properly. Setting it to
  false immediately resolved the issue.

  Can:
   1. The bug be fixed
   2. The gate checks be updated to set watch_log_file = true by default so 
that its tested in the future?

  Please?

  
  Further details:
  Mitaka RDO on CentOS 7.2. DVR enabled, L3HA disabled.

  Thanks,
  Kevin

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1583266/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1557785] [NEW] auto_allocated_topology migration generates inconsistent external networks with PostgreSQL

[Cedric Brandily]

Public bug reported:

auto_allocated_topology migration[1] adds the column nullable boolean column 
is_default to externalnetworks table. MySQL sets is_default to False during the 
migration (wtf?) where PostgreSQL sets is_default to NULL. It implies Neutron 
with PostgreSQL returns is_default == null for external-networks migrated from 
Liberty to Mitaka and is_default == 
False for non is_default external-networks created after Mitaka migration.


[1] 
neutron/db/migration/alembic_migrations/versions/mitaka/expand/19f26505c74f_auto_allocated_topology.py

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: db l3-ipam-dhcp mitaka-rc-potential

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1557785

Title:
  auto_allocated_topology migration generates inconsistent external
  networks with PostgreSQL

Status in neutron:
  In Progress

Bug description:
  auto_allocated_topology migration[1] adds the column nullable boolean column 
is_default to externalnetworks table. MySQL sets is_default to False during the 
migration (wtf?) where PostgreSQL sets is_default to NULL. It implies Neutron 
with PostgreSQL returns is_default == null for external-networks migrated from 
Liberty to Mitaka and is_default == 
  False for non is_default external-networks created after Mitaka migration.

  
  [1] 
neutron/db/migration/alembic_migrations/versions/mitaka/expand/19f26505c74f_auto_allocated_topology.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1557785/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1557757] [NEW] Fix add_is_default_to_subnetpool migration in PostgreSQL

[Cedric Brandily]

 File 
"/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py",
 line 200, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
  File 
"/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1139, in _execute_context
context)
  File 
"/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py",
 line 450, in do_execute
cursor.execute(statement, parameters)
oslo_db.exception.DBError: (psycopg2.IntegrityError) column "is_default" 
contains null values
 [SQL: 'ALTER TABLE subnetpools ADD COLUMN is_default BOOLEAN NOT NULL']

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: db mitaka-rc-potential

** Tags added: mitaka-rc-potential

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1557757

Title:
  Fix add_is_default_to_subnetpool migration in PostgreSQL

Status in neutron:
  New

Bug description:
  add_is_default_to_subnetpool migration[1] is not working on PostgreSQL
  with a non empty because it adds a new column non-nullable with no
  default value and PostgreSQL cannot deduce it.

  It could affect  also MySQL.

  
  [1] 
neutron/db/migration/alembic_migrations/versions/mitaka/expand/13cfb89f881a_add_is_default_to_subnetpool.py
  [2] stacktrace

  user@host:/opt/stack/neutron$ neutron-db-manage --config-file ~/a upgrade head
  No handlers could be found for logger "oslo_config.cfg"
  INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
  INFO  [alembic.runtime.migration] Will assume transactional DDL.
Running upgrade for neutron ...
  INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
  INFO  [alembic.runtime.migration] Will assume transactional DDL.
  INFO  [alembic.runtime.migration] Running upgrade 34af2b5c5a59 -> 
59cb5b6cf4d, Add availability zone
  INFO  [alembic.runtime.migration] Running upgrade 59cb5b6cf4d -> 
13cfb89f881a, add is_default to subnetpool
  Traceback (most recent call last):
File "/opt/stack/neutron/.tox/py27/bin/neutron-db-manage", line 10, in 

  sys.exit(main())
File "/opt/stack/neutron/neutron/db/migration/cli.py", line 749, in main
  return_val |= bool(CONF.command.func(config, CONF.command.name))
File "/opt/stack/neutron/neutron/db/migration/cli.py", line 225, in 
do_upgrade
  desc=branch, sql=CONF.command.sql)
File "/opt/stack/neutron/neutron/db/migration/cli.py", line 127, in 
do_alembic_command
  getattr(alembic_command, cmd)(config, *args, **kwargs)
File 
"/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/command.py",
 line 174, in upgrade
  script.run_env()
File 
"/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/script/base.py",
 line 397, in run_env
  util.load_python_file(self.dir, 'env.py')
File 
"/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/util/pyfiles.py",
 line 81, in load_python_file
  module = load_module_py(module_id, path)
File 
"/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/util/compat.py",
 line 79, in load_module_py
  mod = imp.load_source(module_id, path, fp)
File "/opt/stack/neutron/neutron/db/migration/alembic_migrations/env.py", 
line 126, in 
  run_migrations_online()
File "/opt/stack/neutron/neutron/db/migration/alembic_migrations/env.py", 
line 120, in run_migrations_online
  context.run_migrations()
File "", line 8, in run_migrations
File 
"/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/runtime/environment.py",
 line 797, in run_migrations
  self.get_context().run_migrations(**kw)
File 
"/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/runtime/migration.py",
 line 312, in run_migrations
  step.migration_fn(**kw)
File 
"/opt/stack/neutron/neutron/db/migration/alembic_migrations/versions/mitaka/expand/13cfb89f881a_add_is_default_to_subnetpool.py",
 line 36, in upgrade
  nullable=False))
File "", line 8, in add_column
File "", line 3, in add_column
File 
"/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/operations/ops.py",
 line 1535, in add_column
  return operations.invoke(op)
File 
"/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/operations/base.py",
 line 318, in invoke
  return fn(self, operation)
File 
"/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/operations/toimpl.py",
 line 123, in add_column
  schema=schema
   

[Yahoo-eng-team] [Bug 1546762] [NEW] 8a6d8bdae39_migrate_neutron_resources_table is not postgres compliant

[Cedric Brandily]

alchemy/engine/base.py",
 line 1146, in _execute_context
context)
  File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1337, in _handle_dbapi_exception
util.raise_from_cause(newraise, exc_info)
  File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py",
 line 200, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
  File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1139, in _execute_context
context)
  File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py",
 line 450, in do_execute
cursor.execute(statement, parameters)
oslo_db.exception.DBError: (psycopg2.ProgrammingError) column 
"standard_attr_id" is of type bigint but expression is of type integer[]
LINE 1: UPDATE ports SET standard_attr_id=ARRAY[1] WHERE ports.id = ...

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: db

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1546762

Title:
  8a6d8bdae39_migrate_neutron_resources_table is not postgres compliant

Status in neutron:
  New

Bug description:
  8a6d8bdae39_migrate_neutron_resources_table.py[1] is not postgres-
  compliant[3] and perhaps not working with non empty tables because
  generate_records_for_existing assumes that
  session.execute(...).inserted_primary_key is a value BUT it's a
  list[2]!

  [1] in package 
neutron.db.migration.alembic_migrations.versions.mitaka.contract
  [2] 
http://docs.sqlalchemy.org/en/rel_1_0/core/connections.html?highlight=inserted_primary_key#sqlalchemy.engine.ResultProxy.inserted_primary_key
  [3]
  # Starting with a liberty neutron db
  #$ neutron-db-manage upgrade head

  
  No handlers could be found for logger "oslo_config.cfg"
  INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
  INFO  [alembic.runtime.migration] Will assume transactional DDL.
Running upgrade for neutron ...
  INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
  INFO  [alembic.runtime.migration] Will assume transactional DDL.
  INFO  [alembic.runtime.migration] Running upgrade 34af2b5c5a59 -> 
59cb5b6cf4d, Add availability zone
  INFO  [alembic.runtime.migration] Running upgrade 59cb5b6cf4d -> 
13cfb89f881a, add is_default to subnetpool
  INFO  [alembic.runtime.migration] Running upgrade 13cfb89f881a -> 
32e5974ada25, Add standard attribute table
  INFO  [alembic.runtime.migration] Running upgrade 4af11ca47297 -> 
1b294093239c, Drop embrane plugin table
  INFO  [alembic.runtime.migration] Running upgrade 1b294093239c, 32e5974ada25 
-> 8a6d8bdae39, standardattributes migration
  Traceback (most recent call last):
File "/home/user/projects/os/neutron/.tox/py27/bin/neutron-db-manage", line 
10, in 
  sys.exit(main())
File "/home/user/projects/os/neutron/neutron/db/migration/cli.py", line 
744, in main
  return_val |= bool(CONF.command.func(config, CONF.command.name)) 
File "/home/user/projects/os/neutron/neutron/db/migration/cli.py", line 
220, in do_upgrade
  desc=branch, sql=CONF.command.sql)
File "/home/user/projects/os/neutron/neutron/db/migration/cli.py", line 
127, in do_alembic_command
  getattr(alembic_command, cmd)(config, *args, **kwargs)
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/command.py",
 line 174, in upgrade
  script.run_env()
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/script/base.py",
 line 397, in run_env
  util.load_python_file(self.dir, 'env.py')
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/util/pyfiles.py",
 line 81, in load_python_file
  module = load_module_py(module_id, path)
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/util/compat.py",
 line 79, in load_module_py
  mod = imp.load_source(module_id, path, fp)
File 
"/home/user/projects/os/neutron/neutron/db/migration/alembic_migrations/env.py",
 line 126, in 
  run_migrations_online()
File 
"/home/user/projects/os/neutron/neutron/db/migration/alembic_migrations/env.py",
 line 120, in run_migrations_online
  context.run_migrations()
File "", line 8, in run_migrations
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/runtime/environment.py",
 line 797, in run_migrations
  self.get_context().run_migrations(**kw)
File 
"/home/user/projec

[Yahoo-eng-team] [Bug 1546731] [NEW] 1df244e556f5_add_unique_ha_router_agent_port_bindings revision is not postgres compliant

[Cedric Brandily]

n/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1139, in _execute_context
context)
  File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py",
 line 450, in do_execute
cursor.execute(statement, parameters)
oslo_db.exception.DBError: (psycopg2.ProgrammingError) column 
"ha_router_agent_port_bindings.port_id" must appear in the GROUP BY clause or 
be used in an aggregate function
LINE 1: SELECT ha_router_agent_port_bindings.port_id AS ha_router_ag...
   ^
 [SQL: 'SELECT ha_router_agent_port_bindings.port_id AS 
ha_router_agent_port_bindings_port_id, ha_router_agent_port_bindings.router_id 
AS ha_router_agent_port_bindings_router_id, 
ha_router_agent_port_bindings.l3_agent_id AS 
ha_router_agent_port_bindings_l3_agent_id \nFROM ha_router_agent_port_bindings 
GROUP BY ha_router_agent_port_bindings.router_id, 
ha_router_agent_port_bindings.l3_agent_id \nHAVING count(*) > %(count_1)s'] 
[parameters: {'count_1': 1}]

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: db

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1546731

Title:
  1df244e556f5_add_unique_ha_router_agent_port_bindings revision is not
  postgres compliant

Status in neutron:
  New

Bug description:
  1df244e556f5_add_unique_ha_router_agent_port_bindings.py[1] is not
  postgres-compliant[2] because it uses GROUP BY incorrectly:

  column "ha_router_agent_port_bindings.port_id" must appear in the
  GROUP BY clause or be used in an aggregate function

  
  [1] in package neutron.db.migration.alembic_migrations.versions.mitaka.expand
  [2]
  # Starting with a liberty neutron db
  #$ neutron-db-manage upgrade head

  
  INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
  INFO  [alembic.runtime.migration] Will assume transactional DDL.
  Traceback (most recent call last):
File "/home/user/projects/os/neutron/.tox/py27/bin/neutron-db-manage", line 
10, in 
  sys.exit(main())
File "/home/user/projects/os/neutron/neutron/db/migration/cli.py", line 
744, in main
  return_val |= bool(CONF.command.func(config, CONF.command.name))
File "/home/user/projects/os/neutron/neutron/db/migration/cli.py", line 
218, in do_upgrade
  run_sanity_checks(config, revision)
File "/home/user/projects/os/neutron/neutron/db/migration/cli.py", line 
726, in run_sanity_checks
  script_dir.run_env()
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/script/base.py",
 line 397, in run_env
  util.load_python_file(self.dir, 'env.py')
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/util/pyfiles.py",
 line 81, in load_python_file
  module = load_module_py(module_id, path)
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/util/compat.py",
 line 79, in load_module_py
  mod = imp.load_source(module_id, path, fp)
File 
"/home/user/projects/os/neutron/neutron/db/migration/alembic_migrations/env.py",
 line 126, in 
  run_migrations_online()
File 
"/home/user/projects/os/neutron/neutron/db/migration/alembic_migrations/env.py",
 line 120, in run_migrations_online
  context.run_migrations()
File "", line 8, in run_migrations
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/runtime/environment.py",
 line 797, in run_migrations
  self.get_context().run_migrations(**kw)
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/runtime/migration.py",
 line 303, in run_migrations
  for step in self._migrations_fn(heads, self):
File "/home/user/projects/os/neutron/neutron/db/migration/cli.py", line 
719, in check_sanity
  script.module.check_sanity(context.connection)
File 
"/home/user/projects/os/neutron/neutron/db/migration/alembic_migrations/versions/mitaka/expand/1df244e556f5_add_unique_ha_router_agent_port_bindings.py",
 line 57, in check_sanity
  res = get_duplicate_l3_ha_port_bindings(connection)
File 
"/home/user/projects/os/neutron/neutron/db/migration/alembic_migrations/versions/mitaka/expand/1df244e556f5_add_unique_ha_router_agent_port_bindings.py",
 line 70, in get_duplicate_l3_ha_port_bindings
  .having(sa.func.count() > 1)).all()
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py",
 line 2588, in all
  return list(self)
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py

[Yahoo-eng-team] [Bug 1493422] Re: Remove partial fix of bug #1274034

[Cedric Brandily]

Solved by
https://review.openstack.org/#q,I61e38fc0d8cf8e79252aabc19a70240be57e4a32,n,z

** Changed in: neutron
   Status: New => Fix Released

** Changed in: neutron
 Assignee: (unassigned) => Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1493422

Title:
  Remove partial fix of bug #1274034

Status in neutron:
  Fix Released

Bug description:
  2 changes[1] have been merged in order to enable #1274034 fix. But the
  2 remaining changes[2] have not been merged and an alternative
  solution has been found so the 2 first changes[2] introduced dead
  code.

  
  [1] https://review.openstack.org/141130 
https://review.openstack.org/157097 
  [2] https://review.openstack.org/157634
https://review.openstack.org/158491

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1493422/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1493422] Re: Remove partial fix of bug #1274034

[Cedric Brandily]

Honestly, i don't understand why it ended in OSSN: it wasn't correspond
to my intention

** Project changed: ossn => neutron

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1493422

Title:
  Remove partial fix of bug #1274034

Status in neutron:
  Fix Released

Bug description:
  2 changes[1] have been merged in order to enable #1274034 fix. But the
  2 remaining changes[2] have not been merged and an alternative
  solution has been found so the 2 first changes[2] introduced dead
  code.

  
  [1] https://review.openstack.org/141130 
https://review.openstack.org/157097 
  [2] https://review.openstack.org/157634
https://review.openstack.org/158491

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1493422/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1538952] Re: Creat a port with ip address which is not the address pool in subnet

[Cedric Brandily]

** Changed in: neutron
   Status: New => Opinion

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1538952

Title:
   Creat a port with ip address which is not the  address pool in subnet

Status in neutron:
  Opinion

Bug description:
  version: 2015.1.2

  step:
  * create a port by the restapi
  *  {
"port": {
  ..
  "fixed_ip": [
{
 "subnet_id": "***"
 "ip_address": "***"
 }
  ]
}
 
  *  create port is successful although the ip_address is not in the allocation 
pool

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1538952/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1538767] [NEW] Users cannot create extra-routes with nexthop on ext-net

[Cedric Brandily]

Public bug reported:

Non-admin users cannot create extra-routes on a router with a nexthop on
ext-net subnet:

  # With admin user
  neutron net-create pub --router-:external
  neutron subnet-create pub 192.168.0.0/16

  # With non-admin user
  neutron router-create router
  neutron router-gateway-set router pub
  neutron router-update router --routes 
nexthop=192.168.0.99,destination=10.10.10.0/24
  >> Invalid format for routes: [{u'destination': u'10.10.10.0/24', u'nexthop': 
u'192.168.0.99'}], the nexthop is not connected with router

But it succeeds with an admin user.

nexthop validation gets all ports connected to the router to check if
nexthop is on a subnet connected to the router BUT non-admin users are
only allowed to get internal ports!

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: l3-ipam-dhcp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1538767

Title:
  Users cannot create extra-routes with nexthop on ext-net

Status in neutron:
  New

Bug description:
  Non-admin users cannot create extra-routes on a router with a nexthop
  on ext-net subnet:

# With admin user
neutron net-create pub --router-:external
neutron subnet-create pub 192.168.0.0/16

# With non-admin user
neutron router-create router
neutron router-gateway-set router pub
neutron router-update router --routes 
nexthop=192.168.0.99,destination=10.10.10.0/24
>> Invalid format for routes: [{u'destination': u'10.10.10.0/24', 
u'nexthop': u'192.168.0.99'}], the nexthop is not connected with router

  But it succeeds with an admin user.

  nexthop validation gets all ports connected to the router to check if
  nexthop is on a subnet connected to the router BUT non-admin users are
  only allowed to get internal ports!

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1538767/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1536176] Re: network owner cannot get all subnets

[Cedric Brandily]

"""
steps:
1, demo tenant create a network net1
2, demo tenant create a subnet sn1 in net1
3, admin create a subnet sn2 in net1
4, demo tenant run "neutron subnet-list"
expected: command output should contains sn1 and sn2
observed: only sn1 can be seen.
"""

And it seems to be the expected behavior



** Changed in: neutron
   Status: In Progress => Opinion

** Tags added: access-control

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1536176

Title:
  network owner cannot get all subnets

Status in neutron:
  Opinion

Bug description:
  steps:
  1, demo tenant create a network net1
  2, demo tenant create a subnet sn1 in net1
  3, admin create a subnet sn2 in net1
  4, demo tenant run "neutron subnet-list"
  expected: command output should contains sn1 and sn2
  observed: only sn1 can be seen.

  in policy.json
  [1]"create_subnet": "rule:admin_or_network_owner",
  [2]"get_subnet": "rule:admin_or_owner or rule:shared",
  from [1], since only admin and network owner can create subnet on tenant 
network, it should make sense to allow network owner to get all subnets on 
her/his network.

  with rbac, after demo tenant add rbac access_as_shared rule for alt_demo 
tenant.
  alt_demo tenant run "subnet-list" can get sn1 and sn2.
  That's very interesting, rbac allowed tenant can get all subnets, but not 
network owner.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1536176/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1535542] Re: Resource that does not belong to tenant cannot be created.

[Cedric Brandily]

AFAIK, OpenStack resources are always associated to a tenant otherwise
we don't know who can manage them. More precisely neutron uses user's
tenant_id when no tenant_id is provided in the body. SO it seems we
won't fix this bug (remark: the http query provided doesn't look like a
neutron query).

** Changed in: neutron
   Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1535542

Title:
  Resource that does not belong to tenant cannot be created.

Status in neutron:
  Won't Fix

Bug description:
  Resource that does not belong to tenant cannot be created.

  Creating resource that does not belong to tenant, 400 error had occurred.
  According to code, tenant_id is populated before calling create_XXX methods.
  Then failing with validation.
  I assume that it shouldn't be blocked when the resource does not belong to 
tenant.

  Example of error as follows.

  ubuntu@instance15:~$ curl -si -X POST -H "Content-type: application/json" 
http://172.16.1.16:9696/v2.0/gw/gateway_devices/197d5dae-6e3d-4e0b-b785-56bc2219303f/remote_mac_entries
 -H "X-AUTH-TOKEN:${TOKEN}" -d '{"remote_mac_entry":{"vtep_address": "2.2.2.2", 
"mac_address":"aa:aa:aa:aa:aa:aa", "segmentation_id":1000}}'
   HTTP/1.1 400 Bad Request
   Content-Length: 110
   Content-Type: application/json; charset=UTF-8
   X-Openstack-Request-Id: req-0a578855-187e-4109-b762-39e8b209020e
   Date: Thu, 07 Jan 2016 02:53:33 GMT

  {"NeutronError": {"message": "Unrecognized attribute(s) 'tenant_id'",
  "type": "HTTPBadRequest", "detail": ""}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1535542/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1373153] Re: Unit tests for ML2 drivers use incorrect base class

[Cedric Brandily]

https://review.openstack.org/125894 + plugin split fix the bug

** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1373153

Title:
  Unit tests for ML2 drivers  use incorrect base class

Status in neutron:
  Fix Released

Bug description:
  In unit tests for several ML2 mechanism drivers (listed below) the
  NeutronDbPluginV2TestCase class instead of Ml2PluginV2TestCase which
  is derived from that class is used:

  Unit tests for ML2 mechanism drivers in neutron/tests/unit/ml2:
 drivers/cisco/nexus/test_cisco_mech.py
 drivers/brocade/test_brocade_mechanism_driver.py
 test_mechanism_fslsdn.py 
 test_mechanism_ncs.py
 test_mechanism_odl.py

  In other cases, such as tests in drivers/test_bigswitch_mech.py some
  unit tests from the corresponding monolithic driver is reused and
  therefor Ml2PluginV2TestCase class is not used.

  This prevents specialization needed for testing ML2 specific
  implementations.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1373153/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1520581] Re: TypeError at /project/network_topology/

[Cedric Brandily]

I don't understand how this bug is related to neutron, this error is
raised in Horizon and according the stacktrace the error is raised more
precisely when using manila-ui or manilaclient ... it seems you are
mixing incorrect horizon/manila-ui/manilaclient version

** Changed in: neutron
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1520581

Title:
  TypeError at /project/network_topology/

Status in neutron:
  Invalid

Bug description:
  I installed latest Devstack, but got below error when tried to open
  network topology on Dashboard. Anyone met this issue? or is this a
  devstack build bug?

  TypeError at /project/network_topology/
  Client() got multiple values for keyword argument 'api_version'
  Request Method:   GET
  Request URL:  http://10.109.194.114/dashboard/project/network_topology/
  Django Version:   1.8.7
  Exception Type:   TypeError
  Exception Value:  
  Client() got multiple values for keyword argument 'api_version'
  Exception Location:   /opt/stack/manila-ui/manila_ui/api/manila.py in 
manilaclient, line 65
  Python Executable:/usr/bin/python
  Python Version:   2.7.6
  Python Path:  
  ['/opt/stack/horizon/openstack_dashboard/wsgi/../..',
   '/opt/stack/keystone',
   '/opt/stack/swift',
   '/opt/stack/glance',
   '/opt/stack/cinder',
   '/opt/stack/neutron',
   '/opt/stack/nova',
   '/opt/stack/heat',
   '/opt/stack/barbican',
   '/opt/stack/python-barbicanclient',
   '/opt/stack/sahara',
   '/opt/stack/manila',
   '/opt/stack/python-manilaclient',
   '/opt/stack/manila-ui',
   '/home/dev/devstack/src/horizon',
   '/opt/stack/tempest',
   '/usr/lib/python2.7',
   '/usr/lib/python2.7/plat-x86_64-linux-gnu',
   '/usr/lib/python2.7/lib-tk',
   '/usr/lib/python2.7/lib-old',
   '/usr/lib/python2.7/lib-dynload',
   '/usr/local/lib/python2.7/dist-packages',
   '/usr/lib/python2.7/dist-packages',
   '/opt/stack/horizon/openstack_dashboard']
  Server time:  Fri, 27 Nov 2015 13:48:04 +

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1520581/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1518776] [NEW] Deprecate router_id option

[Cedric Brandily]

Public bug reported:

The l3-agent router_id option has been defined in order to associate a
l3-agent to a specific router when use_namespaces=False. use_namespaces
option has been removed in Mitaka, so router_id option is no more needed

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: l3-ipam-dhcp usability

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1518776

Title:
  Deprecate router_id option

Status in neutron:
  In Progress

Bug description:
  The l3-agent router_id option has been defined in order to associate a
  l3-agent to a specific router when use_namespaces=False.
  use_namespaces option has been removed in Mitaka, so router_id option
  is no more needed

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1518776/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1046121] Re: dhcp should never be enabled for a router external net

[Cedric Brandily]

Technically speaking, nothing disallows to deploy vms on ext-nets even
if i doubt that's the aim of ext-nets.

According to the discussion, i update the bug status to invalid

** Changed in: neutron
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1046121

Title:
  dhcp should never be enabled for a router external net

Status in neutron:
  Invalid
Status in openstack-manuals:
  Confirmed

Bug description:
  it doesn't make sense in the existing model, as the router IPs and the
  floating IPs allocated from an external net never make DHCP requests.

  I don't believe there is any significant additional harm caused by
  this though, other than unneeded CPU churn from DHCP agent and
  dnsmasq, and a burned IP address allocated for a DHCP port.

  One tricky issue is that DHCP is enabled by default, so the question
  is whether we should fail if the user does not explicitly disable it
  when creating a network, or if we should just automatically set it to
  False.  Unfortunately, I don't think we can tell the difference
  between a this value default to true and it being explicitly set to
  true, so it seems that if we want to prevent it from being set to true
  in the API, we should require it to be set to False.  We also need to
  prevent it from being set to True on an update.

  Another option would be to ignore the value set in the API and just
  have the DHCP agent ignore networks for which router:external =True.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1046121/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1514548] [NEW] Cleanup linuxbridge_neutron_agent

[Cedric Brandily]

Public bug reported:

Cleanup  linuxbridge_neutron_agent:

 * move bridge related features to bridge_lib
 * cleanup tests

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: linuxbridge

** Tags added: linuxbridge

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1514548

Title:
  Cleanup linuxbridge_neutron_agent

Status in neutron:
  In Progress

Bug description:
  Cleanup  linuxbridge_neutron_agent:

   * move bridge related features to bridge_lib
   * cleanup tests

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1514548/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1512969] Re: DHCP-HA-RFE- there is no command that show us with network node is the DHCP proviider

[Cedric Brandily]

According to discussion, the rfe seems invalid as the feature already
exists

** Changed in: neutron
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1512969

Title:
  DHCP-HA-RFE- there is no command that show us with network node is the
  DHCP proviider

Status in neutron:
  Invalid

Bug description:
  version : 
  [root@cougar16 ~(keystone_admin)]# rpm -qa |grep neutron
  python-neutronclient-3.1.1-dev1.el7.centos.noarch
  python-neutron-7.0.0.0-rc2.dev21.el7.centos.noarch
  openstack-neutron-7.0.0.0-rc2.dev21.el7.centos.noarch
  openstack-neutron-ml2-7.0.0.0-rc2.dev21.el7.centos.noarch
  openstack-neutron-common-7.0.0.0-rc2.dev21.el7.centos.noarch
  openstack-neutron-openvswitch-7.0.0.0-rc2.dev21.el7.centos.noarch

  When deploying HA environment we have HA of DHCP  service . 
  There is no command that gave us information about which network node is 
provide the DHCP service.
  The only way to get this info is by search in /var/log/messages  which 
network node sent ack for DHCP request.

  I think that we need to add neutron command that show  which network node is 
providing DHCP services.
  for example 
  $ neutron dhcp-show

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1512969/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1513048] Re: the container can not be pinged via name space, after 860 tenants/networks/container created

[Cedric Brandily]

Incomplete seems better as we need more information in Liberty.

** Changed in: neutron
   Status: Invalid => Incomplete

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1513048

Title:
  the container can not be pinged via name space, after 860
  tenants/networks/container created

Status in neutron:
  Incomplete

Bug description:
  [Summary]
  the container can not be pinged via name space, after 860 
tenants/networks/container created

  [Topo]
  1 controller, 2 network nodes, 6 compute nodes, all in ubuntu 14.04
  (openstack version is 2015.1.2, linux kernel version is 3.19.0-31)
  root@ah:~# uname -a
  Linux ah.container13 3.19.0-31-generic #36~14.04.1-Ubuntu SMP Thu Oct 8 
10:21:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
  root@ah:~# 
  root@ah:~# dpkg -l | grep neutron
  ii  neutron-common  1:2015.1.2-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - common
  ii  neutron-plugin-ml2  1:2015.1.2-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - ML2 plugin
  ii  neutron-server  1:2015.1.2-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - server
  ii  python-neutron  1:2015.1.2-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - Python 

  library
  ii  python-neutron-fwaas2015.1.2-0ubuntu2~cloud0  
all  Firewall-as-a-Service driver for OpenStack Neutron
  ii  python-neutronclient1:2.3.11-0ubuntu1.2~cloud0
all  client - Neutron is a virtual network service for Openstack
  root@ah:~#

  [Description and expect result]
  the container should be pinged via name space

  [Reproduceable or not]
  reproducible intermittently when large number of tenant/network/instance 
configed

  [Recreate Steps]
  1)use script to create: 860 tenants, 1 network/router in each tenant, 1 
cirros container in each network, all containers are associate to FIP

  2)create one more tenant, 1 network/contaier in the tenant, the
  container can be in Active state, but can not be pinged via name space
  ISSUE

  
  [Configration]
  config files on controller/network/compute are attached

  [logs]
  instance can be in Active state:
  oot@ah:~# nova --os-tenant-id 73731bbaf2db48f89a067604e3556e05 list
  
+--+-+++-++
  | ID   | Name| Status 
| Task State | Power State | Networks   
|
  
+--+-+++-++
  | d5ba18d5-aaf9-4ed6-9a2b-71d2b2f10bae | mexico_test_new_2_1_net1_vm | ACTIVE 
| -  | Running | mexico_test_new_2_1_net1=10.10.32.3, 172.168.6.211 
|
  
+--+-+++-++
  root@ah:~# keystone tenant-list | grep test_new_2_1
  | 73731bbaf2db48f89a067604e3556e05 | mexico_test_new_2_1 |   True  |
  root@ah:~# neutron net-list | grep exico_test_new_2_1_net1
  | a935642d-b56c-4a87-83c5-755f01bf0814 | mexico_test_new_2_1_net1 | 
bed0330f-e0ea-4bcc-bc75-96766dad32a7 10.10.32.0/24  |
  root@ah:~#

  on network node:
  root@ah:~# ip netns | grep a935642d-b56c-4a87-83c5-755f01bf0814
  qdhcp-a935642d-b56c-4a87-83c5-755f01bf0814
  root@ah:~# ip netns exec qdhcp-a935642d-b56c-4a87-83c5-755f01bf0814 ping 
10.10.32.3
  PING 10.10.32.3 (10.10.32.3) 56(84) bytes of data.
  From 10.10.32.2 icmp_seq=1 Destination Host Unreachable
  From 10.10.32.2 icmp_seq=2 Destination Host Unreachable
  From 10.10.32.2 icmp_seq=3 Destination Host Unreachable
  From 10.10.32.2 icmp_seq=4 Destination Host Unreachable>>>ISSUE

  [Root cause anlyze or debug inf]
  high load on controller and network node

  [Attachment]
  log files on controller/network/compute are attached

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1513048/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1513048] Re: the container can not be pinged via name space, after 860 tenants/networks/container created

[Cedric Brandily]

It seems an explanation is required when updating the bug status

** Changed in: neutron
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1513048

Title:
  the container can not be pinged via name space, after 860
  tenants/networks/container created

Status in neutron:
  Incomplete

Bug description:
  [Summary]
  the container can not be pinged via name space, after 860 
tenants/networks/container created

  [Topo]
  1 controller, 2 network nodes, 6 compute nodes, all in ubuntu 14.04
  (openstack version is 2015.1.2, linux kernel version is 3.19.0-31)
  root@ah:~# uname -a
  Linux ah.container13 3.19.0-31-generic #36~14.04.1-Ubuntu SMP Thu Oct 8 
10:21:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
  root@ah:~# 
  root@ah:~# dpkg -l | grep neutron
  ii  neutron-common  1:2015.1.2-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - common
  ii  neutron-plugin-ml2  1:2015.1.2-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - ML2 plugin
  ii  neutron-server  1:2015.1.2-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - server
  ii  python-neutron  1:2015.1.2-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - Python 

  library
  ii  python-neutron-fwaas2015.1.2-0ubuntu2~cloud0  
all  Firewall-as-a-Service driver for OpenStack Neutron
  ii  python-neutronclient1:2.3.11-0ubuntu1.2~cloud0
all  client - Neutron is a virtual network service for Openstack
  root@ah:~#

  [Description and expect result]
  the container should be pinged via name space

  [Reproduceable or not]
  reproducible intermittently when large number of tenant/network/instance 
configed

  [Recreate Steps]
  1)use script to create: 860 tenants, 1 network/router in each tenant, 1 
cirros container in each network, all containers are associate to FIP

  2)create one more tenant, 1 network/contaier in the tenant, the
  container can be in Active state, but can not be pinged via name space
  ISSUE

  
  [Configration]
  config files on controller/network/compute are attached

  [logs]
  instance can be in Active state:
  oot@ah:~# nova --os-tenant-id 73731bbaf2db48f89a067604e3556e05 list
  
+--+-+++-++
  | ID   | Name| Status 
| Task State | Power State | Networks   
|
  
+--+-+++-++
  | d5ba18d5-aaf9-4ed6-9a2b-71d2b2f10bae | mexico_test_new_2_1_net1_vm | ACTIVE 
| -  | Running | mexico_test_new_2_1_net1=10.10.32.3, 172.168.6.211 
|
  
+--+-+++-++
  root@ah:~# keystone tenant-list | grep test_new_2_1
  | 73731bbaf2db48f89a067604e3556e05 | mexico_test_new_2_1 |   True  |
  root@ah:~# neutron net-list | grep exico_test_new_2_1_net1
  | a935642d-b56c-4a87-83c5-755f01bf0814 | mexico_test_new_2_1_net1 | 
bed0330f-e0ea-4bcc-bc75-96766dad32a7 10.10.32.0/24  |
  root@ah:~#

  on network node:
  root@ah:~# ip netns | grep a935642d-b56c-4a87-83c5-755f01bf0814
  qdhcp-a935642d-b56c-4a87-83c5-755f01bf0814
  root@ah:~# ip netns exec qdhcp-a935642d-b56c-4a87-83c5-755f01bf0814 ping 
10.10.32.3
  PING 10.10.32.3 (10.10.32.3) 56(84) bytes of data.
  From 10.10.32.2 icmp_seq=1 Destination Host Unreachable
  From 10.10.32.2 icmp_seq=2 Destination Host Unreachable
  From 10.10.32.2 icmp_seq=3 Destination Host Unreachable
  From 10.10.32.2 icmp_seq=4 Destination Host Unreachable>>>ISSUE

  [Root cause anlyze or debug inf]
  high load on controller and network node

  [Attachment]
  log files on controller/network/compute are attached

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1513048/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1513041] Re: need to wait more than 30 seconds before the network namespace can be checked on network node when creating network(with 860 tenant/network/instance created)

[Cedric Brandily]

It seems an explanation is required when updating the bug status

** Changed in: neutron
   Status: New => Opinion

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1513041

Title:
  need to wait more than 30 seconds before the network namespace can be
  checked on network node  when creating network(with 860
  tenant/network/instance created)

Status in neutron:
  Opinion

Bug description:
  [Summary]
  need to wait more than 30 seconds before the network namespace can be checked 
on network node  when creating network(with 860 tenant/network/instance 

  created)

  [Topo]
  1 controller, 2 network nodes, 6 compute nodes, all in ubuntu 14.04
  (openstack version is 2015.1.2, linux kernel version is 3.19.0-31)
  root@ah:~# uname -a
  Linux ah.container13 3.19.0-31-generic #36~14.04.1-Ubuntu SMP Thu Oct 8 
10:21:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
  root@ah:~# 
  root@ah:~# dpkg -l | grep neutron
  ii  neutron-common  1:2015.1.2-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - common
  ii  neutron-plugin-ml2  1:2015.1.2-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - ML2 plugin
  ii  neutron-server  1:2015.1.2-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - server
  ii  python-neutron  1:2015.1.2-0ubuntu1~cloud0
all  Neutron is a virtual network service for Openstack - Python 

  library
  ii  python-neutron-fwaas2015.1.2-0ubuntu2~cloud0  
all  Firewall-as-a-Service driver for OpenStack Neutron
  ii  python-neutronclient1:2.3.11-0ubuntu1.2~cloud0
all  client - Neutron is a virtual network service for Openstack
  root@ah:~#

  [Description and expect result]
  the network namespace can be checked on network node immidiately when 
creating network

  [Reproduceable or not]
  reproducible when large number of tenant/network/instance configed

  [Recreate Steps]
  1)use script to create: 860 tenants, 1 network/router in each tenant, 1 
cirros container in each network, all containers are associate to FIP

  2)create one more network, the name space of this network can only be
  checked on network node 30 seconds later ISSUE

  
  [Configration]
  config files for controller/network/compute are attached

  [logs]
  Post logs here.

  [Root cause anlyze or debug inf]
  high load on controller and network node

  [Attachment]
  log files attached

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1513041/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1375519] Re: Cisco N1kv: Enable quota support in stable/icehouse

[Cedric Brandily]

** Changed in: neutron/icehouse
   Status: New => Fix Released

** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1375519

Title:
  Cisco N1kv: Enable quota support in stable/icehouse

Status in networking-cisco:
  New
Status in neutron:
  Fix Released
Status in neutron icehouse series:
  Fix Released

Bug description:
  With the quotas table being populated in stable/icehouse, the N1kv
  plugin should be able to support quotas. Otherwise VMs end up in error
  state.

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-cisco/+bug/1375519/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1511234] [NEW] Decompose fully mlnx ml2 driver

[Cedric Brandily]

Public bug reported:

Nothing requires to have mlnx ml2 driver defined in neutron so let's
move it networking-mlnx

** Affects: networking-mlnx
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Cedric Brandily (cbrandily)

** Also affects: networking-mlnx
   Importance: Undecided
   Status: New

** Changed in: networking-mlnx
 Assignee: (unassigned) => Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1511234

Title:
  Decompose fully mlnx ml2 driver

Status in Mellanox backend  integration with Neutron (networking-mlnx):
  New
Status in neutron:
  New

Bug description:
  Nothing requires to have mlnx ml2 driver defined in neutron so let's
  move it networking-mlnx

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-mlnx/+bug/1511234/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1510579] Re: [Firewall] Different behavior during creating firewall with empty router in CLI and Horizon

[Cedric Brandily]

This bug affects horizon or/and python-neutronclient BUT not neutron as
neutron does what you ask him to do!

Considering that python-neutronclient is the reference client for
neutron, the behavior of Horizon should be aligned to python-
neutronclient one.

** Tags removed: firewall neutron
** Tags added: sg-fw

** Changed in: neutron
   Status: Confirmed => Invalid

** Also affects: horizon
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1510579

Title:
  [Firewall] Different behavior during creating firewall with empty
  router in CLI and Horizon

Status in OpenStack Dashboard (Horizon):
  New
Status in neutron:
  Invalid

Bug description:
  
  Steps to reproduce:
  1) Create allow icmp rule
  2) Create policy with this rule
  3) Create firewall with the policy and empty router in Horizon
  Result: new firewall is in Inactive state
  4) Create new rulw
  5) Create new policy with this rule
  6) Create firewall in cli without router
  Result: new firewall is created with all routers in tenant in Active state

  We need the same reaction

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1510579/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1511578] [NEW] Remove deprecated external_network_bridge option

[Cedric Brandily]

Public bug reported:

The l3-agent option external_network_bridge has been deprecated in
Liberty[1] because when non-empty the l3-agent ignores network provider
properties. It also ensures to handle in the same way internal and
external networks.


[1] https://bugs.launchpad.net/neutron/+bug/1491668

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: l3-ipam-dhcp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1511578

Title:
   Remove deprecated external_network_bridge option

Status in neutron:
  New

Bug description:
  The l3-agent option external_network_bridge has been deprecated in
  Liberty[1] because when non-empty the l3-agent ignores network
  provider properties. It also ensures to handle in the same way
  internal and external networks.

  
  [1] https://bugs.launchpad.net/neutron/+bug/1491668

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1511578/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1511198] [NEW] Decompose ovsvapp ml2 driver

[Cedric Brandily]

Public bug reported:

It's time to decompose ovsvapp ml2 driver[1] from neutron

[1] neutron.plugins.ml2.drivers.ovsvapp

** Affects: networking-vsphere
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New

** Changed in: networking-vsphere
 Assignee: (unassigned) => Cedric Brandily (cbrandily)

** Also affects: neutron
   Importance: Undecided
   Status: New

** Changed in: neutron
 Assignee: (unassigned) => Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1511198

Title:
  Decompose ovsvapp ml2 driver

Status in networking-vsphere:
  New
Status in neutron:
  New

Bug description:
  It's time to decompose ovsvapp ml2 driver[1] from neutron

  [1] neutron.plugins.ml2.drivers.ovsvapp

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-vsphere/+bug/1511198/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1509890] [NEW] Linux bridge agent "interface_exists_on_bridge" can be optimized

[Cedric Brandily]

Public bug reported:

Currently, when lb agent needs to check if an interface exists on a
bridge, it will get all interfaces on the bridge and looks for the
interface:

 for filename in os.listdir(BRIDGE_INTERFACES_FS):
   if filename == interface:
 return True
   return False

when we can directly check os.path.join(BRIDGE_INTERFACE_FS, interface)
existence.

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: linuxbridge loadimpact low-hanging-fruit

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1509890

Title:
   Linux bridge agent "interface_exists_on_bridge" can be optimized

Status in neutron:
  New

Bug description:
  Currently, when lb agent needs to check if an interface exists on a
  bridge, it will get all interfaces on the bridge and looks for the
  interface:

   for filename in os.listdir(BRIDGE_INTERFACES_FS):
 if filename == interface:
   return True
 return False

  when we can directly check os.path.join(BRIDGE_INTERFACE_FS,
  interface) existence.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1509890/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1509092] [NEW] Remove deprecated nova_* options

[Cedric Brandily]

Public bug reported:

nova_admin_* and nova_url options have been deprecated in kilo[1][2].

Removing these options will simplify neutron code and configuration AND
remove a warning in unittest[3].


[1] https://bugs.launchpad.net/neutron/+bug/1403686
[2] https://review.openstack.org/142366
[3] 2015-10-22 22:29:59,269  WARNING [neutron.notifiers.nova] Authenticating to 
nova using nova_admin_* options is deprecated. This should be done using an 
auth plugin, like password

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: low-hanging-fruit usability

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1509092

Title:
  Remove deprecated nova_* options

Status in neutron:
  New

Bug description:
  nova_admin_* and nova_url options have been deprecated in kilo[1][2].

  Removing these options will simplify neutron code and configuration
  AND remove a warning in unittest[3].


  [1] https://bugs.launchpad.net/neutron/+bug/1403686
  [2] https://review.openstack.org/142366
  [3] 2015-10-22 22:29:59,269  WARNING [neutron.notifiers.nova] Authenticating 
to nova using nova_admin_* options is deprecated. This should be done using an 
auth plugin, like password

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1509092/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1508188] [NEW] Remove deprecated use_namespaces option

[Cedric Brandily]

Public bug reported:

dhcp/l3 agent use_namespaces option has been deprecated in Liberty[1].

Now kernels property support namespaces, removing this option allow to
simplify agent code and remove an option (use_namespaces == False) not
functionally tested.

[1] https://bugs.launchpad.net/neutron/+bug/1435382

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: l3-ipam-dhcp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1508188

Title:
  Remove deprecated use_namespaces option

Status in neutron:
  New

Bug description:
  dhcp/l3 agent use_namespaces option has been deprecated in Liberty[1].

  Now kernels property support namespaces, removing this option allow to
  simplify agent code and remove an option (use_namespaces == False) not
  functionally tested.

  [1] https://bugs.launchpad.net/neutron/+bug/1435382

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1508188/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1508189] [NEW] Remove deprecated namespace deletion options

[Cedric Brandily]

Public bug reported:

dhcp/router_delete_namespaces[1] options have been defined as a
workaround to an iproute2 limitation[1] corrected 2 years ago.

That's why it's to remove them after their deprecation in Liberty.

[1]
https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=58a3e8270fe72f8ed92687d3a3132c2a708582dd

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: l3-ipam-dhcp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1508189

Title:
  Remove deprecated namespace deletion options

Status in neutron:
  New

Bug description:
  dhcp/router_delete_namespaces[1] options have been defined as a
  workaround to an iproute2 limitation[1] corrected 2 years ago.

  That's why it's to remove them after their deprecation in Liberty.

  [1]
  
https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=58a3e8270fe72f8ed92687d3a3132c2a708582dd

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1508189/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1506862] [NEW] VethFixture: smart veth delete

[Cedric Brandily]

Public bug reported:

VethFixture cleanup tries to delete veths from their namespaces even if
they don't exist (without crashing the cleanup), it implies an extra
trace if an error is raised which can be confusing:

Command: ['sudo', '-n', 'ip', 'netns', 'exec', 
'test-ddc6fc89-5159-44e2-ba15-099a10adf5bc', 'ip', 'link', 'del', 
'test-veth114005']
Exit code: 1
Stdin: 
Stdout: 
Stderr: Cannot open network namespace 
"test-ddc6fc89-5159-44e2-ba15-099a10adf5bc": No such file or directory

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: functional-tests low-hanging-fruit

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1506862

Title:
  VethFixture: smart veth delete

Status in neutron:
  In Progress

Bug description:
  VethFixture cleanup tries to delete veths from their namespaces even
  if they don't exist (without crashing the cleanup), it implies an
  extra trace if an error is raised which can be confusing:

  Command: ['sudo', '-n', 'ip', 'netns', 'exec', 
'test-ddc6fc89-5159-44e2-ba15-099a10adf5bc', 'ip', 'link', 'del', 
'test-veth114005']
  Exit code: 1
  Stdin: 
  Stdout: 
  Stderr: Cannot open network namespace 
"test-ddc6fc89-5159-44e2-ba15-099a10adf5bc": No such file or directory

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1506862/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1503852] [NEW] Do not use SQL IN on empty sequence

[Cedric Brandily]

Public bug reported:

According to a log warning[1] and logstash[2], neutron uses SQL IN
operator on an empty list:

SAWarning: The IN-predicate on "ports.id" was invoked with an empty
sequence. This results in a contradiction, which nonetheless can be
expensive to evaluate.  Consider alternative strategies for improved
performance.'

which seems to have an effect on performance.

[1] 
http://logs.openstack.org/82/228582/13/check/gate-neutron-python34/5b36c34/console.html
[2] 
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOiBcIlNBV2FybmluZzogVGhlIElOLXByZWRpY2F0ZSBvbiBcIiBBTkQgbWVzc2FnZTogXCJ3YXMgaW52b2tlZCB3aXRoIGFuIGVtcHR5IHNlcXVlbmNlXCIgQU5EIHByb2plY3Q6IFwib3BlbnN0YWNrL25ldXRyb25cIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiMTcyODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQ0NDI0NzYwOTI4NH0=

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: db

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1503852

Title:
  Do not use SQL IN on empty sequence

Status in neutron:
  New

Bug description:
  According to a log warning[1] and logstash[2], neutron uses SQL IN
  operator on an empty list:

  SAWarning: The IN-predicate on "ports.id" was invoked with an empty
  sequence. This results in a contradiction, which nonetheless can be
  expensive to evaluate.  Consider alternative strategies for improved
  performance.'

  which seems to have an effect on performance.

  [1] 
http://logs.openstack.org/82/228582/13/check/gate-neutron-python34/5b36c34/console.html
  [2] 
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOiBcIlNBV2FybmluZzogVGhlIElOLXByZWRpY2F0ZSBvbiBcIiBBTkQgbWVzc2FnZTogXCJ3YXMgaW52b2tlZCB3aXRoIGFuIGVtcHR5IHNlcXVlbmNlXCIgQU5EIHByb2plY3Q6IFwib3BlbnN0YWNrL25ldXRyb25cIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiMTcyODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQ0NDI0NzYwOTI4NH0=

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1503852/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1503415] Re: We should not bypass bytes decode/encode

[Cedric Brandily]

This bug also affects neutron.agent.linux/windows.utils.execute

** Also affects: neutron
   Importance: Undecided
   Status: New

** Changed in: neutron
 Assignee: (unassigned) => Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1503415

Title:
  We should not bypass bytes decode/encode

Status in neutron:
  New
Status in python-neutronclient:
  In Progress

Bug description:
  The commit fcf289797c063088f9003359dfd1c7d4f41ed5ef[1] introduces the
  pattern:

if six.PY3:
  if isinstance(line, bytes):
try:
  line = line.decode(encoding='utf-8')
except UnicodeError:
  pass
   # concat line with a string

  which is not working if a UnicodeError is raised: in such case line is
  not decoded and line is not converted in a string and the
  concatenation with the string fails. We should ensure that line is
  converted to a string

  [1] 
https://github.com/openstack/python-neutronclient/commit/fcf289797c063088f9003359dfd1c7d4f41ed5ef
  [2] 
https://github.com/openstack/python-neutronclient/blob/db7eb557403da7c0e1eca7e12f6ddab6bc0d1fc1/neutronclient/tests/unit/test_cli20.py#L77-L81

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1503415/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1503212] Re: pylint fails when signature changed by decorator

[Cedric Brandily]

** Changed in: neutron
   Status: In Progress => Invalid

** Changed in: neutron
 Assignee: Bogdan Tabor (bogdan-tabor) => (unassigned)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1503212

Title:
  pylint fails when signature changed by decorator

Status in neutron:
  Invalid

Bug description:
  Pylint is not able to recognize mocked method's argument, when there
  are normal arguments already present.

  reproduction steps
  --
  1) Change whatever in neutron.tests.unit.agent.l3.test_agent.py
  2) run tox -v -e pep8 HEAD~1

  visible consequence
  ---
  Running pylint...
  You can speed this up by running it on 'HEAD~[0-9]' (e.g. HEAD~1, this change 
only)...
  * Module neutron.tests.unit.agent.l3.test_agent
  E:1033, 8: No value for argument 'IPDevice' in method call 
(no-value-for-parameter)
  ERROR: InvocationError: '/usr/bin/sh ./tools/coding-checks.sh --pylint HEAD~1'
  ERROR:   pep8: commands failed

  It will cause Jenkins gate fail, thus preventing merge

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1503212/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1104001] Re: Wrong default values when creating HealthMonitor

[Cedric Brandily]

This bug is > 365 days without activity. We are unsetting assignee and
milestone and setting status to Incomplete in order to allow its expiry
in 60 days.

If the bug is still valid, then update the bug status.

** Changed in: neutron
   Status: In Progress => Invalid

** Changed in: neutron
 Assignee: Avishay Balderman (avishayb) => (unassigned)

** Changed in: neutron
   Status: Invalid => Incomplete

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1104001

Title:
  Wrong default values when creating HealthMonitor

Status in neutron:
  Incomplete

Bug description:
  in quantum/extensions/loadbalancer.py we set default values to 3 attributes 
of HealthMonitor.
  Code:
  health_monitors': {
...
  'http_method': {'allow_post': True, 'allow_put': True,
  'validate': {'type:string': None},
  'default': 'GET',
  'is_visible': True},
  'url_path': {'allow_post': True, 'allow_put': True,
   'validate': {'type:string': None},
   'default': '/',
   'is_visible': True},
  'expected_codes': {'allow_post': True, 'allow_put': True,
 'validate': {
 'type:regex':
 '^(\d{3}(\s*,\s*\d{3})*)$|^(\d{3}-\d{3})$'},
 'default': '200',
 'is_visible': True},
  ...

  Those default values are OK only the the 'type' attribute is HTTP/S. 
  So it looks like there should be no defaults values and the values in the DB 
should be null unless the user specified the values.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1104001/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1236621] Re: Disable H803: git commit title should not end with period

[Cedric Brandily]

** Changed in: neutron
   Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1236621

Title:
  Disable H803: git commit title should not end with period

Status in hacking:
  Opinion
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in neutron:
  Won't Fix

Bug description:
  I think it's a total waste of reviewing time and gating resources for
  patches to be failing because of a period at the end of a commit
  title. This makes no difference at all to readability. I propose we
  disable the check.

  See here for an example:
  https://review.openstack.org/#/c/50167

To manage notifications about this bug go to:
https://bugs.launchpad.net/hacking/+bug/1236621/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1503055] [NEW] Use AssertIsNone

[Cedric Brandily]

Public bug reported:

Neutron should use the specific assertion:

  self.assertIs(Not)None(observed)

instead of the generic assertion:

  self.assert(Not)Equal(None, observed)

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: low-hanging-fruit unittest

** Description changed:

  Neutron should use the specific assertion:
  
-   self.assertIs(Not)None(observed)
+   self.assertIs(Not)None(observed)
  
- when instead of the generic assertion:
+ instead of the generic assertion:
  
-   self.assert(Not)Equal(None, observed)
+   self.assert(Not)Equal(None, observed)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1503055

Title:
  Use AssertIsNone

Status in neutron:
  In Progress

Bug description:
  Neutron should use the specific assertion:

    self.assertIs(Not)None(observed)

  instead of the generic assertion:

    self.assert(Not)Equal(None, observed)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1503055/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1484690] Re: Incorrect metadata proxy route via router ip

[Cedric Brandily]

*** This bug is a duplicate of bug 1483939 ***
https://bugs.launchpad.net/bugs/1483939

** This bug has been marked a duplicate of bug 1483939
   Allow host route injection of metadata server IP via DHCP

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1484690

Title:
  Incorrect metadata proxy route via router ip

Status in neutron:
  In Progress

Bug description:
  A change [1] injected a direct route to metadata ip through a subnet's
  default gateway to avoid Windows mac resolution[2].

  Such change breaks the following usecase (typically used to separate 
admin/management traffic and user traffic):

  enable metadata on dhcp agents
  disable metadata on l3 agents
  create a subnet subnet-usr with a gateway and bind it to a router
  create a subnet subnet-adm without a gateway
  create VMs with an interface on each subnet

  because VMs get from subnet-adm the route:

   destination=169.254.169.254,nexthop=dhcp-ip

  and from subnet-usr the route:

   destination=169.254.169.254,nexthop=router-ip

  so VMs have 2 routes to 169.254.169.254:

if they use subnet-run route then they get no response (metadata disabled 
on routers)
if they use subnet-nsb route then they get a response (metadata enabled on 
dhcps)

  
  [1] https://review.openstack.org/187431
  [2] https://bugs.launchpad.net/neutron/+bug/1460793

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1484690/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1482633] Re: requests to SSL wrapped sockets hang while reading using py3

[Cedric Brandily]

** Also affects: oslo.service
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1482633

Title:
  requests to SSL wrapped sockets hang while reading using py3

Status in Manila:
  New
Status in neutron:
  Confirmed
Status in oslo.service:
  New

Bug description:
  If we run unit tests using py3 then we get following errors:

  ==
  FAIL: manila.tests.test_wsgi.TestWSGIServer.test_app_using_ssl
  tags: worker-0
  --
  Empty attachments:
pythonlogging:''
stdout

  stderr: {{{
  Traceback (most recent call last):
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/hubs/hub.py",
 line 457, in fire_timers
  timer()
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/hubs/timer.py",
 line 58, in __call__
  cb(*args, **kw)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/greenthread.py",
 line 214, in main
  result = function(*args, **kwargs)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/wsgi.py",
 line 823, in server
  client_socket = sock.accept()
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 333, in accept
  suppress_ragged_eofs=self.suppress_ragged_eofs)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 88, in __init__
  self.do_handshake()
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 241, in do_handshake
  super(GreenSSLSocket, self).do_handshake)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 106, in _call_trampolining
  return func(*a, **kw)
File "/usr/lib/python3.4/ssl.py", line 805, in do_handshake
  self._sslobj.do_handshake()
  ssl.SSLWantReadError: The operation did not complete (read) (_ssl.c:598)
  }}}

  Traceback (most recent call last):
File 
"/home/vponomaryov/Documents/python/projects/manila/manila/tests/test_wsgi.py", 
line 181, in test_app_using_ssl
  'https://127.0.0.1:%d/' % server.port)
File "/usr/lib/python3.4/urllib/request.py", line 153, in urlopen
  return opener.open(url, data, timeout)
File "/usr/lib/python3.4/urllib/request.py", line 455, in open
  response = self._open(req, data)
File "/usr/lib/python3.4/urllib/request.py", line 473, in _open
  '_open', req)
File "/usr/lib/python3.4/urllib/request.py", line 433, in _call_chain
  result = func(*args)
File "/usr/lib/python3.4/urllib/request.py", line 1273, in https_open
  context=self._context, check_hostname=self._check_hostname)
File "/usr/lib/python3.4/urllib/request.py", line 1232, in do_open
  h.request(req.get_method(), req.selector, req.data, headers)
File "/usr/lib/python3.4/http/client.py", line 1065, in request
  self._send_request(method, url, body, headers)
File "/usr/lib/python3.4/http/client.py", line 1103, in _send_request
  self.endheaders(body)
File "/usr/lib/python3.4/http/client.py", line 1061, in endheaders
  self._send_output(message_body)
File "/usr/lib/python3.4/http/client.py", line 906, in _send_output
  self.send(msg)
File "/usr/lib/python3.4/http/client.py", line 841, in send
  self.connect()
File "/usr/lib/python3.4/http/client.py", line 1205, in connect
  server_hostname=server_hostname)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 362, in _green_sslcontext_wrap_socket
  return GreenSSLSocket(sock, *a, _context=self, **kw)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 88, in __init__
  self.do_handshake()
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 241, in do_handshake
  super(GreenSSLSocket, self).do_handshake)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 116, in _call_trampolining
  timeout_exc=timeout_exc('timed out'))
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/hubs/__init__.py",
 line 162, in trampoline
  return hub.switch()
File 

[Yahoo-eng-team] [Bug 1502061] [NEW] Remove deprecated neutron.agent.linux.utils.ensure_dir

[Cedric Brandily]

Public bug reported:

ensure_dir implementation has been moved from neutron.agent.linux.utils
to neutron.common.utils during Liberty. A deprecated ensure_dir wrapper
still exists in neutron.agent.linux.utils, it should be removed in
Mitaka

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: low-hanging-fruit

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1502061

Title:
  Remove deprecated neutron.agent.linux.utils.ensure_dir

Status in neutron:
  In Progress

Bug description:
  ensure_dir implementation has been moved from
  neutron.agent.linux.utils to neutron.common.utils during Liberty. A
  deprecated ensure_dir wrapper still exists in
  neutron.agent.linux.utils, it should be removed in Mitaka

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1502061/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1119119] Re: firewall driver uses abstracemethod without metaclass set

[Cedric Brandily]

That's the opposite: FirewallDriver is an abstract class using the
pattern:

 def method(...):
raise NotImplementedError

instead of:

 @abstractmethod
 def method(...):
   pass

** Changed in: neutron
   Status: Won't Fix => Confirmed

** Summary changed:

- firewall driver uses abstracemethod without metaclass set
+ firewall driver is an abstract class not using abstractmethod

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1119119

Title:
  firewall driver is an abstract class not using abstractmethod

Status in neutron:
  Confirmed

Bug description:
  FirewallDrifver uses @abstractmethod decorator, but it doesn't set its
  metaclass to ABCMeta.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1119119/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1037562] Re: Different secgroups can't be applied to different interfaces

[Cedric Brandily]

This bug concerns at most nova as neutron is able to handle secgroup per
port.

Moreover nova is able to boot a vm using existing neutron ports (with
specific secgroups) so this bug seems invalid fro nova also

** Changed in: neutron
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1037562

Title:
  Different secgroups can't be applied to different interfaces

Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  With the coming of quantum it's quite reasonable to start an interface
  attached to multiple network segments with different purposes.  But
  there's only one security group for the whole machine, so I can't
  define different firewalling for the internal and external interfaces
  of a VM, for example.

  secgroups should apply to interfaces, not machines as a whole.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1037562/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1119119] Re: firewall driver uses abstracemethod without metaclass set

[Cedric Brandily]

** Changed in: neutron
 Assignee: Isaku Yamahata (yamahata) => (unassigned)

** Changed in: neutron
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1119119

Title:
  firewall driver is an abstract class not using abstractmethod

Status in neutron:
  Confirmed

Bug description:
  FirewallDrifver uses @abstractmethod decorator, but it doesn't set its
  metaclass to ABCMeta.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1119119/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1282374] Re: neutron tests require pysqlite

[Cedric Brandily]

** Changed in: neutron
 Assignee: YAMAMOTO Takashi (yamamoto) => (unassigned)

** Changed in: neutron
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1282374

Title:
  neutron tests require pysqlite

Status in neutron:
  Invalid

Bug description:
  neutron's test-requirements.txt lacks pysqlite.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1282374/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1496586] [NEW] Avoid the pattern sql select/delete

[Cedric Brandily]

Public bug reported:

The following pattern:

 obj = query.filter(...).one()
 context.session.delete(obj)

 is racy because obj can be deleted between the select and the delete,
we should prefer when possible the pattern:

 count = query.filter(...).delete(synchronize_session=False)
 if not count:
   raise NotFound

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: db

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1496586

Title:
  Avoid the pattern sql select/delete

Status in neutron:
  New

Bug description:
  The following pattern:

   obj = query.filter(...).one()
   context.session.delete(obj)

   is racy because obj can be deleted between the select and the delete,
  we should prefer when possible the pattern:

   count = query.filter(...).delete(synchronize_session=False)
   if not count:
 raise NotFound

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1496586/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1491824] [NEW] neutron.tests.unit.test_wsgi.JSONDictSerializerTest.test_json_with_utf8

[Cedric Brandily]

Public bug reported:

neutron.tests.unit.test_wsgi.JSONDictSerializerTest.test_json_with_utf8
is not py3K compliant

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: unittest

** Changed in: neutron
 Assignee: (unassigned) => Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1491824

Title:
  neutron.tests.unit.test_wsgi.JSONDictSerializerTest.test_json_with_utf8

Status in neutron:
  New

Bug description:
  neutron.tests.unit.test_wsgi.JSONDictSerializerTest.test_json_with_utf8
  is not py3K compliant

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1491824/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1487598] [NEW] Remove vendor AGENT_TYPE_* constants

[Cedric Brandily]

Public bug reported:

Neutron defines in neutron.common.constants vendor AGENT_TYPE_*
constants BUT there are only used by currently or future out-of-tree
code ... such constants should be moved to out-of-tree repos

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1487598

Title:
  Remove vendor AGENT_TYPE_* constants

Status in neutron:
  New

Bug description:
  Neutron defines in neutron.common.constants vendor AGENT_TYPE_*
  constants BUT there are only used by currently or future out-of-tree
  code ... such constants should be moved to out-of-tree repos

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1487598/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1486277] [NEW] Remove VIF_TYPES constants

[Cedric Brandily]

Public bug reported:

Neutron defines in neutron.extensions.portbindings VIF_TYPES but is only
used by bigswitch out-of-tree code ... such constant should be moved to
bigswitch repo

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: bigswitch

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1486277

Title:
  Remove VIF_TYPES constants

Status in neutron:
  New

Bug description:
  Neutron defines in neutron.extensions.portbindings VIF_TYPES but is
  only used by bigswitch out-of-tree code ... such constant should be
  moved to bigswitch repo

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1486277/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1486279] [NEW] Remove vendor VIF_TYPE_* constants

[Cedric Brandily]

Public bug reported:

Neutron defines in neutron.extensions.portbindings vendor VIF_TYPE_*
constants BUT there are only used by currently or future out-of-tree
code ... such constants should be moved to out-of-tree repos

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1486279

Title:
  Remove vendor VIF_TYPE_* constants

Status in neutron:
  New

Bug description:
  Neutron defines in neutron.extensions.portbindings vendor VIF_TYPE_*
  constants BUT there are only used by currently or future out-of-tree
  code ... such constants should be moved to out-of-tree repos

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1486279/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1484690] [NEW] Incorrect metadata proxy route via router ip

[Cedric Brandily]

Public bug reported:

A change [1] injected a direct route to metadata ip through a subnet's
default gateway to avoid Windows mac resolution[2].

Such change breaks the following usecase (typically used to separate 
admin/management traffic and user traffic):
  
enable metadata on dhcp agents
disable metadata on l3 agents
create a subnet subnet-usr with a gateway and bind it to a router
create a subnet subnet-adm without a gateway
create VMs with an interface on each subnet

because VMs get from subnet-adm the route:

 destination=169.254.169.254,nexthop=dhcp-ip

and from subnet-usr the route:

 destination=169.254.169.254,nexthop=router-ip

so VMs have 2 routes to 169.254.169.254:

  if they use subnet-run route then they get no response (metadata disabled on 
routers)
  if they use subnet-nsb route then they get a response (metadata enabled on 
dhcps)


[1] https://review.openstack.org/187431
[2] https://bugs.launchpad.net/neutron/+bug/1460793

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: l3-ipam-dhcp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1484690

Title:
  Incorrect metadata proxy route via router ip

Status in neutron:
  New

Bug description:
  A change [1] injected a direct route to metadata ip through a subnet's
  default gateway to avoid Windows mac resolution[2].

  Such change breaks the following usecase (typically used to separate 
admin/management traffic and user traffic):

  enable metadata on dhcp agents
  disable metadata on l3 agents
  create a subnet subnet-usr with a gateway and bind it to a router
  create a subnet subnet-adm without a gateway
  create VMs with an interface on each subnet

  because VMs get from subnet-adm the route:

   destination=169.254.169.254,nexthop=dhcp-ip

  and from subnet-usr the route:

   destination=169.254.169.254,nexthop=router-ip

  so VMs have 2 routes to 169.254.169.254:

if they use subnet-run route then they get no response (metadata disabled 
on routers)
if they use subnet-nsb route then they get a response (metadata enabled on 
dhcps)

  
  [1] https://review.openstack.org/187431
  [2] https://bugs.launchpad.net/neutron/+bug/1460793

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1484690/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1472725] [NEW] Pidfile.unlock checks responses of avoid function

[Cedric Brandily]

Public bug reported:

Pidfile.unlock[1] implementation uses fcntl.flock response as a
condition but fcntl.flock is a void function.

[1] neutron.agent.linux.daemon

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1472725

Title:
  Pidfile.unlock checks responses of avoid function

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  Pidfile.unlock[1] implementation uses fcntl.flock response as a
  condition but fcntl.flock is a void function.

  [1] neutron.agent.linux.daemon

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1472725/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1468059] [NEW] Extend default setenv instead of replacing it in tox.ini

[Cedric Brandily]

Public bug reported:

Some tox jobs[1] define their own setenv without extending/referencing
default setenv, it disallows to define environment variables shared by
all jobs.

[1] (dsvm-)functional/fullstack

** Affects: neutron
 Importance: Undecided
 Status: New

** Description changed:

  Some tox jobs[1] define their own setenv without extending/referencing
  default setenv, it disallows to define environment variables shared by
  all jobs.
+ 
+ [1] (dsvm-)functional/fullstack

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1468059

Title:
  Extend default setenv instead of replacing it in tox.ini

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Some tox jobs[1] define their own setenv without extending/referencing
  default setenv, it disallows to define environment variables shared by
  all jobs.

  [1] (dsvm-)functional/fullstack

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1468059/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1468128] [NEW] Brocade plugin unittests are broken

[Cedric Brandily]

Public bug reported:

Brocade plugin unittests are broken because brocade plugin and
associated tests try to set a read-only attribute

http://logs.openstack.org/85/194785/2/check/gate-neutron-
python27/9447976/testr_results.html.gz

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1468128

Title:
  Brocade plugin unittests are broken

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  Brocade plugin unittests are broken because brocade plugin and
  associated tests try to set a read-only attribute

  http://logs.openstack.org/85/194785/2/check/gate-neutron-
  python27/9447976/testr_results.html.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1468128/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1467020] [NEW] Stop using oslo-incubator uuidutils

[Cedric Brandily]

Public bug reported:

The module uuidutils in now available in oslo_utils.

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1467020

Title:
  Stop using oslo-incubator uuidutils

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  The module uuidutils in now available in oslo_utils.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1467020/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1465614] Re: --protocol None is rejected in security-group-rule-create

[Cedric Brandily]

It's a neutronclient limitation not a neutron bug

** Changed in: neutron
   Status: In Progress = Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1465614

Title:
  --protocol None is rejected in security-group-rule-create

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  When invalid protocol specified in security-group-rule-create, neutron
  server returns protocol values [None, 'tcp', 'udp', 'icmp', 'icmpv6']
  are supported as below:

  % neutron security-group-rule-create --protocol foo bar
  Security group rule protocol foo not supported. Only protocol values [None, 
'tcp', 'udp', 'icmp', 'icmpv6'] and integer representations [0 to 255] are 
supported.

  However, neutron-server rejects None for protocol.

  % neutron security-group-rule-create --protocol None bar
  Security group rule protocol None not supported. Only protocol values [None, 
'tcp', 'udp', 'icmp', 'icmpv6'] and integer representations [0 to 255] are 
supported.

  I think this behavior is confusing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1465614/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1459844] [NEW] Ensure no neutron.tests.functional.agent tests are skipped in the gate

[Cedric Brandily]

Public bug reported:

Some neutron.tests.functional.agent tests are skipped[1] if the system
doesn't support some feature they require.

We should ensure that these tests are not skipped in the gate.


[1]
* neutron.tests.functional.agent.test_ovs_flows 
 use a sanity check to check if ARP header matching is supported
* neutron.tests.functional.agent.linux.test_ovsdb_flows 
 check manually that ovsdb-client is installed and can be invoked without 
password

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: functional-tests

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1459844

Title:
  Ensure no neutron.tests.functional.agent tests are skipped in the gate

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Some neutron.tests.functional.agent tests are skipped[1] if the system
  doesn't support some feature they require.

  We should ensure that these tests are not skipped in the gate.

  
  [1]
  * neutron.tests.functional.agent.test_ovs_flows 
   use a sanity check to check if ARP header matching is supported
  * neutron.tests.functional.agent.linux.test_ovsdb_flows 
   check manually that ovsdb-client is installed and can be invoked 
without password

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1459844/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1451576] [NEW] subnetpool allocation not ensuring non-overlapping cidrs

[Cedric Brandily]

Public bug reported:

_get_allocated_cidrs[1] locks only allocated subnets in a subnetpool
(with mysql/postgresql at least) which ensures we won't allocate a cidr
overlapping with existent cidrs but nothing disallows a concurrent
subnet allocation to create a subnet in the same subnetpool.

[1]:
https://github.com/openstack/neutron/blob/5962d825a6c98225c51bc6dd304b5c1ac89035etef/neutron/ipam/subnet_alloc.py#L40-L44

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: l3-ipam-dhcp

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1451576

Title:
  subnetpool allocation not ensuring non-overlapping cidrs

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  _get_allocated_cidrs[1] locks only allocated subnets in a subnetpool
  (with mysql/postgresql at least) which ensures we won't allocate a
  cidr overlapping with existent cidrs but nothing disallows a
  concurrent subnet allocation to create a subnet in the same
  subnetpool.

  [1]:
  
https://github.com/openstack/neutron/blob/5962d825a6c98225c51bc6dd304b5c1ac89035etef/neutron/ipam/subnet_alloc.py#L40-L44

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1451576/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1451558] [NEW] subnetpool allocation not working with postgresql

[Cedric Brandily]

 neutron.api.v2.resource compiled_sql, 
distilled_params
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py, line 1070, 
in _execute_context
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource context)
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/compat/handle_error.py,
 line 261, in _handle_dbapi_exception
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource e, statement, 
parameters, cursor, context)
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py, line 1267, 
in _handle_dbapi_exception
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource 
util.raise_from_cause(newraise, exc_info)
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/compat.py, line 199, 
in raise_from_cause
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource 
reraise(type(exception), exception, tb=exc_tb)
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py, line 1063, 
in _execute_context
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource context)
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py, line 
442, in do_execute
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource 
cursor.execute(statement, parameters)
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource DBError: 
(NotSupportedError) FOR UPDATE cannot be applied to the nullable side of an 
outer join
2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource  'SELECT 
subnets.tenant_id AS subnets_tenant_id, subnets.id AS subnets_id, subnets.name 
AS subnets_name, subnets.network_id AS subnets_network_id, 
subnets.subnetpool_id AS subnets_subnetpool_id, subnets.ip_version AS 
subnets_ip_version, subnets.cidr AS subnets_cidr, subnets.gateway_ip AS 
subnets_gateway_ip, subnets.enable_dhcp AS subnets_enable_dhcp, subnets.shared 
AS subnets_shared, subnets.ipv6_ra_mode AS subnets_ipv6_ra_mode, 
subnets.ipv6_address_mode AS subnets_ipv6_address_mode, ipallocationpools_1.id 
AS ipallocationpools_1_id, ipallocationpools_1.subnet_id AS 
ipallocationpools_1_subnet_id, ipallocationpools_1.first_ip AS 
ipallocationpools_1_first_ip, ipallocationpools_1.last_ip AS 
ipallocationpools_1_last_ip, dnsnameservers_1.address AS 
dnsnameservers_1_address, dnsnameservers_1.subnet_id AS 
dnsnameservers_1_subnet_id, subnetroutes_1.destination AS 
subnetroutes_1_destination, subnetroutes_1.nexthop AS subnetroutes_1_nexthop,
  subnetroutes_1.subnet_id AS subnetroutes_1_subnet_id \nFROM subnets LEFT 
OUTER JOIN ipallocationpools AS ipallocationpools_1 ON subnets.id = 
ipallocationpools_1.subnet_id LEFT OUTER JOIN dnsnameservers AS 
dnsnameservers_1 ON subnets.id = dnsnameservers_1.subnet_id LEFT OUTER JOIN 
subnetroutes AS subnetroutes_1 ON subnets.id = subnetroutes_1.subnet_id \nWHERE 
subnets.subnetpool_id = %(subnetpool_id_1)s FOR UPDATE' {'subnetpool_id_1': 
u'2ee02a0f-863a-41d6-a5cb-7c629395b9da'}

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: db l3-ipam-dhcp postgresql

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1451558

Title:
  subnetpool allocation not working with postgresql

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  The following is working with mysql but not with postgresql

  
  #$ neutron subnetpool-create pool --pool-prefix 10.0.0.0/8 
--default-prefixlen 24
  #$ neutron net-create net
  #$ neutron subnet-create net --name subnet --subnetpool pool

  
  The last command raises a 501 with postgresql with the stacktrace[2] in 
neutron-server, because _get_allocated_cidrs[1] performs a SELECT FOR UPDATE 
with a JOIN on an empty select! (allowed with mysql, not postgresql).



  [1]: 
https://github.com/openstack/neutron/blob/5962d825a6c98225c51bc6dd304b5c1ac89035ef/neutron/ipam/subnet_alloc.py#L40-L44
query = session.query(models_v2.Subnet).with_lockmode('update')
subnets = query.filter_by(subnetpool_id=self._subnetpool['id'])

  
  [2]: neutron-server stacktrace
  2015-05-04 21:47:01.939 ERROR neutron.api.v2.resource 
[req-a6c14f61-bdb2-4273-a231-df0a85fb33d8 demo 
b532b7a9302c45b18f06f68b41869ffa] create failed
  2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource Traceback (most recent 
call last):
  2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/api/v2/resource.py, line 83, in resource
  2015-05-04 21:47:01.939 TRACE neutron.api.v2.resource result = 
method(request

[Yahoo-eng-team] [Bug 1451559] [NEW] subnetpool allocation not working with multiples subnets on a unique network

[Cedric Brandily]

Public bug reported:

The following scenario is not working:

#$ neutron subnetpool-create pool --pool-prefix 10.0.0.0/8 --default-prefixlen 
24
#$ neutron net-create net
#$ neutron subnet-create net --name subnet0 10.0.0.0/24
#$ neutron subnet-create net --name subnet1--subnetpool pool
 returns a 409

Last command fails because neutron tries to allocate to subnet1 the 1st
unallocated cidr from 10.0.0.0/8 pool = 10.0.0.0/24 but subnet net as
already 10.0.0.0/24 as cidr (subnet0) and overlapping cidrs are
disallowed on the same network!

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: l3-ipam-dhcp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1451559

Title:
  subnetpool allocation not working with multiples subnets on a unique
  network

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  The following scenario is not working:

  #$ neutron subnetpool-create pool --pool-prefix 10.0.0.0/8 
--default-prefixlen 24
  #$ neutron net-create net
  #$ neutron subnet-create net --name subnet0 10.0.0.0/24
  #$ neutron subnet-create net --name subnet1--subnetpool pool
   returns a 409

  Last command fails because neutron tries to allocate to subnet1 the
  1st unallocated cidr from 10.0.0.0/8 pool = 10.0.0.0/24 but subnet
  net as already 10.0.0.0/24 as cidr (subnet0) and overlapping cidrs are
  disallowed on the same network!

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1451559/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1435743] Re: fwaasrouterinsertion extension information are available in Horizon

[Cedric Brandily]

** Changed in: horizon
   Status: In Progress = Invalid

** Changed in: horizon
 Assignee: Cedric Brandily (cbrandily) = (unassigned)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1435743

Title:
  fwaasrouterinsertion extension information are available in Horizon

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  fwaasrouterinsertion extension allows to set/unset which routers
  implement a firewall on create/update.

  http://specs.openstack.org/openstack/neutron-specs/specs/kilo/fwaas-
  router-insertion.html#rest-api-impact

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1435743/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1435743] [NEW] fwaasrouterinsertion extension information are available in Horizon

[Cedric Brandily]

Public bug reported:

fwaasrouterinsertion extension allows to set/unset which routers
implement a firewall on create/update.

http://specs.openstack.org/openstack/neutron-specs/specs/kilo/fwaas-
router-insertion.html#rest-api-impact

** Affects: horizon
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1435743

Title:
  fwaasrouterinsertion extension information are available in Horizon

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  fwaasrouterinsertion extension allows to set/unset which routers
  implement a firewall on create/update.

  http://specs.openstack.org/openstack/neutron-specs/specs/kilo/fwaas-
  router-insertion.html#rest-api-impact

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1435743/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1427261] Re: Improve create instance without volume service

[Cedric Brandily]

correctly between Juno and Kilo

** Changed in: horizon
   Status: In Progress = Invalid

** Changed in: horizon
 Assignee: Cedric Brandily (cbrandily) = (unassigned)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1427261

Title:
  Improve create instance without volume service

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  Currently an error notification is raised when creating an instance on an 
OpenStack deployment without volume service.
  
  This change avoids the error notification as volume service is not required 
to boot an instance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427261/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1427261] [NEW] Improve create instance without volume service

[Cedric Brandily]

Public bug reported:

Currently an error notification is raised when creating an instance on an 
OpenStack deployment without volume service.

This change avoids the error notification as volume service is not required to 
boot an instance.

** Affects: horizon
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1427261

Title:
  Improve create instance without volume service

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  Currently an error notification is raised when creating an instance on an 
OpenStack deployment without volume service.
  
  This change avoids the error notification as volume service is not required 
to boot an instance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1427261/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1425890] [NEW] Neutron functional tests use an oslo.db private method removed in 1.5.0

[Cedric Brandily]

Public bug reported:

neutron/tests/functional/db/test_migrations.py uses _cleanup private
method defined in  oslo_db/sqlalchemy/test_migrations.py which has been
removed in oslo.db 1.5.0

https://jenkins02.openstack.org/job/check-neutron-dsvm-
functional/3593/console

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1425890

Title:
  Neutron functional tests use an oslo.db private method removed in
  1.5.0

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  neutron/tests/functional/db/test_migrations.py uses _cleanup private
  method defined in  oslo_db/sqlalchemy/test_migrations.py which has
  been removed in oslo.db 1.5.0

  https://jenkins02.openstack.org/job/check-neutron-dsvm-
  functional/3593/console

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1425890/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1413985] [NEW] BASEV2.__table_args__ is not properly overloaded

[Cedric Brandily]

Public bug reported:

neutron.db.model_base.BASEV2 defines __table_args__ attribute.
Most of its subclasses overloading __table_args__  does not properly inherit 
the __table args__ from parent class.

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1413985

Title:
  BASEV2.__table_args__ is not properly overloaded

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  neutron.db.model_base.BASEV2 defines __table_args__ attribute.
  Most of its subclasses overloading __table_args__  does not properly inherit 
the __table args__ from parent class.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1413985/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1404250] [NEW] get_binary_name should returns strings without spaces

[Cedric Brandily]

Public bug reported:

get_binary_name() generates a string from sys.argv[0] which could contains 
spaces: 
 * python -m unittest whatever implies sys.argv[0] = python -m unittest and 
get_binary_name == 'python -m unitte'

But  iptables does not support spaces in chain name ... and get_binary_name() 
is used as prefix in chain name by iptables_manager
 *  python -m unittest whatever implies incorrect iptables chain definition: 
iptables -N python -m unittest.


It typically brakes functional tests runned using python -m unittest $class.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: l3-ipam-dhcp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1404250

Title:
  get_binary_name should returns strings without spaces

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  get_binary_name() generates a string from sys.argv[0] which could contains 
spaces: 
   * python -m unittest whatever implies sys.argv[0] = python -m unittest and 
get_binary_name == 'python -m unitte'

  But  iptables does not support spaces in chain name ... and get_binary_name() 
is used as prefix in chain name by iptables_manager
   *  python -m unittest whatever implies incorrect iptables chain definition: 
iptables -N python -m unittest.

  
  It typically brakes functional tests runned using python -m unittest $class.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1404250/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1399462] [NEW] Incorrect iptables INPUT rules on l3-agent for metadata proxy

[Cedric Brandily]

Public bug reported:

On the l3-agent, 2 iptables rules are defined  to ensure the metadata proxy is 
reachable from vms on 169.254.169.254:80:
* REDIRECT 169.254.169.254:80 packets to the router on port 9697(metadata proxy 
port)
-A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 
80 -j REDIRECT --to-ports 9697
* ACCEPT traffic to 127.0.0.1 on port 9697
-A neutron-l3-agent-INPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 9697 -j 
ACCEPT

The 2nd rule is invalid as REDIRECT replaces destination ip by:
 * router ip (the one on the input interface)
 * 127.0.0.1 if the packet is a LOCAL packet (not metadata proxy case).


So ACCEPT rule filter is not matched ... the metadata proxy is only reachable 
because INPUT policy is ACCEPT.

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: l3-ipam-dhcp

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1399462

Title:
  Incorrect iptables INPUT rules on l3-agent for metadata proxy

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  On the l3-agent, 2 iptables rules are defined  to ensure the metadata proxy 
is reachable from vms on 169.254.169.254:80:
  * REDIRECT 169.254.169.254:80 packets to the router on port 9697(metadata 
proxy port)
  -A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp 
--dport 80 -j REDIRECT --to-ports 9697
  * ACCEPT traffic to 127.0.0.1 on port 9697
  -A neutron-l3-agent-INPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 9697 -j 
ACCEPT

  The 2nd rule is invalid as REDIRECT replaces destination ip by:
   * router ip (the one on the input interface)
   * 127.0.0.1 if the packet is a LOCAL packet (not metadata proxy case).

  
  So ACCEPT rule filter is not matched ... the metadata proxy is only reachable 
because INPUT policy is ACCEPT.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1399462/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1396489] [NEW] OVSInterfaceDriver should use ovs_lib not call ovs-vsctl directly

[Cedric Brandily]

Public bug reported:

ovs_lib module is responsible for the interaction with OVS but 
OVSInterfaceDriver._ovs_add_port() method calls directly
ovs-vsctl which implies inconsistencies: ovs_lib calls ovs-vsctl with a timeout 
but not OVSInterfaceDriver._ovs_add_port().

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: ovs

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1396489

Title:
  OVSInterfaceDriver should use ovs_lib not call ovs-vsctl directly

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  ovs_lib module is responsible for the interaction with OVS but 
OVSInterfaceDriver._ovs_add_port() method calls directly
  ovs-vsctl which implies inconsistencies: ovs_lib calls ovs-vsctl with a 
timeout but not OVSInterfaceDriver._ovs_add_port().

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1396489/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1346494] Re: l3 agent gw port missing vlan tag for vlan provider network

[Cedric Brandily]

Accordin to Chuck last comment #5, this bug is invalid

** Changed in: neutron
   Status: In Progress = Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1346494

Title:
  l3 agent gw port missing vlan tag for vlan provider network

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  Hi, I have a provider network with my floating NAT range on it and a vlan 
segmentation id:
  neutron net-show ext-net
  +---+--+
  | Field | Value|
  +---+--+
  | admin_state_up| True |
  | id| f8ea424f-fcbe-4d57-9f17-5c576bf56e60 |
  | name  | ext-net  |
  | provider:network_type | vlan |
  | provider:physical_network | datacentre   |
  | provider:segmentation_id  | 25   |
  | router:external   | True |
  | shared| False|
  | status| ACTIVE   |
  | subnets   | 391829e1-afc5-4280-9cd9-75f554315e82 |
  | tenant_id | e23f57e1d6c54398a68354adf522a36d |
  +---+--+

  My ovs agent config:

  cat /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini 
  [DATABASE]
  sql_connection = mysql://.@localhost/ovs_neutron?charset=utf8

  reconnect_interval = 2

  [OVS]
  bridge_mappings = datacentre:br-ex
  network_vlan_ranges = datacentre

  tenant_network_type = gre
  tunnel_id_ranges = 1:1000
  enable_tunneling = True
  integration_bridge = br-int
  tunnel_bridge = br-tun
  local_ip = 10.10.16.151

  
  [AGENT]
  polling_interval = 2

  [SECURITYGROUP]
  firewall_driver = 
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
  root@ci-overcloud-controller0-ydt5on7wojsb:~# 

  But, the thing is, the port created in ovs is missing the tag:
  Bridge br-ex
  Port qg-d8c27507-14
  Interface qg-d8c27507-14
  type: internal

  And we (As expected) are seeing tagged frames in tcpdump:
  19:37:16.107288 20:fd:f1:b6:f5:16  ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
(0x8100), length 68: vlan 25, p 0, ethertype ARP, Request who-has 138.35.77.67 
tell 138.35.77.1, length 50

  rather than untagged frames for the vlan 25.

  Running ovs-vsctl set port qg-d8c27507-14 tag=25 makes things work,
  but the agent should do this, no?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1346494/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1391326] [NEW] Remove openvswitch core plugin entry point

[Cedric Brandily]

Public bug reported:

The openvswitch core plugin has been removed[1] from neutron tree but
not its entry point.

setup.cfg:

neutron.core_plugins =
openvswitch = 
neutron.plugins.openvswitch.ovs_neutron_plugin:OVSNeutronPluginV2


[1] https://bugs.launchpad.net/neutron/+bug/1323729

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: juno-backport-potential

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1391326

Title:
  Remove openvswitch core plugin entry point

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  The openvswitch core plugin has been removed[1] from neutron tree but
  not its entry point.

  setup.cfg:

  neutron.core_plugins =
openvswitch = 
neutron.plugins.openvswitch.ovs_neutron_plugin:OVSNeutronPluginV2

  
  [1] https://bugs.launchpad.net/neutron/+bug/1323729

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1391326/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1384240] Re: It do not delete tap devices

[Cedric Brandily]

these interfaces qvoXXX/qvbXXX/qbrXXX/tapXXX are created by nova (when
ovs_hybrid_plug==True) not neutron.

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

** Project changed: neutron = nova

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1384240

Title:
  It do not delete tap devices

Status in OpenStack Compute (Nova):
  New

Bug description:
  After I added/removed routers, nets and subnets many times, for
  testing purpose, I found that I have 45 interfaces:

  b# ifconfig|grep encap:Ethernet
  br-eth0   Link encap:Ethernet  HWaddr d0:67:e5:03:18:0f
  br-eth0:1 Link encap:Ethernet  HWaddr d0:67:e5:03:18:0f
  eth0  Link encap:Ethernet  HWaddr d0:67:e5:03:18:0f
  int-br-eth0 Link encap:Ethernet  HWaddr 82:ad:59:16:ca:da
  phy-br-eth0 Link encap:Ethernet  HWaddr da:e4:8d:cd:38:43
  qbr056025bc-49 Link encap:Ethernet  HWaddr fa:c1:6d:fe:5e:b8
  qbr3dccedf9-e8 Link encap:Ethernet  HWaddr 02:42:c0:73:d2:0b
  qbr422898c8-df Link encap:Ethernet  HWaddr 76:b0:42:f5:ad:f9
  qbr69eb1f6a-71 Link encap:Ethernet  HWaddr d6:d2:7f:ee:1a:34
  qbr750aa557-b7 Link encap:Ethernet  HWaddr 5a:2e:b3:f3:30:b1
  qbr81eb2deb-b7 Link encap:Ethernet  HWaddr f2:d0:95:19:fb:c4
  qbr971c890b-8f Link encap:Ethernet  HWaddr ce:a1:c9:f0:b6:24
  qbr9ab03868-2f Link encap:Ethernet  HWaddr 2a:d5:8a:61:0a:a1
  qbrcfd38872-d1 Link encap:Ethernet  HWaddr 16:7d:ad:1b:4b:82
  qbrde55f70b-7d Link encap:Ethernet  HWaddr 2a:8c:f5:2b:49:99
  qbrdead1da5-98 Link encap:Ethernet  HWaddr d6:95:61:73:1d:c6
  qbrf0db8340-a6 Link encap:Ethernet  HWaddr 9e:9b:36:c3:cb:d3
  qbrf3f3c43f-ff Link encap:Ethernet  HWaddr 4a:c6:5c:70:e4:b4
  qvb056025bc-49 Link encap:Ethernet  HWaddr fa:c1:6d:fe:5e:b8
  qvb3dccedf9-e8 Link encap:Ethernet  HWaddr 02:42:c0:73:d2:0b
  qvb422898c8-df Link encap:Ethernet  HWaddr 76:b0:42:f5:ad:f9
  qvb69eb1f6a-71 Link encap:Ethernet  HWaddr d6:d2:7f:ee:1a:34
  qvb750aa557-b7 Link encap:Ethernet  HWaddr 5a:2e:b3:f3:30:b1
  qvb81eb2deb-b7 Link encap:Ethernet  HWaddr f2:d0:95:19:fb:c4
  qvb971c890b-8f Link encap:Ethernet  HWaddr ce:a1:c9:f0:b6:24
  qvb9ab03868-2f Link encap:Ethernet  HWaddr 2a:d5:8a:61:0a:a1
  qvbcfd38872-d1 Link encap:Ethernet  HWaddr 16:7d:ad:1b:4b:82
  qvbde55f70b-7d Link encap:Ethernet  HWaddr 2a:8c:f5:2b:49:99
  qvbdead1da5-98 Link encap:Ethernet  HWaddr d6:95:61:73:1d:c6
  qvbf0db8340-a6 Link encap:Ethernet  HWaddr 9e:9b:36:c3:cb:d3
  qvbf3f3c43f-ff Link encap:Ethernet  HWaddr 4a:c6:5c:70:e4:b4
  qvo056025bc-49 Link encap:Ethernet  HWaddr aa:82:8b:9f:d6:a0
  qvo3dccedf9-e8 Link encap:Ethernet  HWaddr ea:8c:1f:0e:ab:92
  qvo422898c8-df Link encap:Ethernet  HWaddr 7a:9f:47:3c:3b:57
  qvo69eb1f6a-71 Link encap:Ethernet  HWaddr a6:dd:41:ce:e6:39
  qvo750aa557-b7 Link encap:Ethernet  HWaddr 32:6c:f8:ca:af:e9
  qvo81eb2deb-b7 Link encap:Ethernet  HWaddr ea:22:94:19:ac:4c
  qvo971c890b-8f Link encap:Ethernet  HWaddr 2e:f8:a7:72:1c:85
  qvo9ab03868-2f Link encap:Ethernet  HWaddr aa:3e:bb:c6:6d:d3
  qvocfd38872-d1 Link encap:Ethernet  HWaddr 16:3a:12:30:f5:71
  qvode55f70b-7d Link encap:Ethernet  HWaddr fa:ee:28:ed:52:37
  qvodead1da5-98 Link encap:Ethernet  HWaddr 5a:66:51:d9:a5:60
  qvof0db8340-a6 Link encap:Ethernet  HWaddr 66:b6:23:c9:ca:73
  qvof3f3c43f-ff Link encap:Ethernet  HWaddr 5e:5b:53:e8:11:58
  tapdead1da5-98 Link encap:Ethernet  HWaddr fe:54:00:39:74:0a

  Also ther'a 265 namespaces.

  I use Icehouse.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1384240/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1388858] [NEW] Neutron disallows to change default enable_snat value

[Cedric Brandily]

Public bug reported:

Some deployments (private/enterprise clouds) would like to disable snat by 
default.
For example some enterprise policies disallow snat as it anonymizes/hides 
source ips and some private clouds don't use snat/nat features.

But it's currently not possible to change enable_snat default value.

A workaround is to allow and enforce neutron users to set enable_snat
attribute to False on external_gateway_info update through policy, but
it's not user friendly as neutron users must specify enable_snat=False
and if they do not neutron returns a 404 error.

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: l3-ipam-dhcp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1388858

Title:
  Neutron disallows to change default enable_snat value

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  Some deployments (private/enterprise clouds) would like to disable snat by 
default.
  For example some enterprise policies disallow snat as it anonymizes/hides 
source ips and some private clouds don't use snat/nat features.

  But it's currently not possible to change enable_snat default value.

  A workaround is to allow and enforce neutron users to set enable_snat
  attribute to False on external_gateway_info update through policy, but
  it's not user friendly as neutron users must specify enable_snat=False
  and if they do not neutron returns a 404 error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1388858/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1371701] Re: delete middleware module files

[Cedric Brandily]

** Also affects: neutron
   Importance: Undecided
   Status: New

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1371701

Title:
  delete middleware module files

Status in OpenStack Neutron (virtual network service):
  In Progress
Status in The Oslo library incubator:
  Fix Committed

Bug description:
  remove files part of oslo.middleware graduation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1371701/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1384146] [NEW] Inconsistent enable_snat management

[Cedric Brandily]

Public bug reported:

Neutron reset enable_snat on router-gateway-clear but not on router-
gateway-set which implies inconsistent behavior:


# pub1, pub2 are external networks and router1 is a router

(neutron) router-gateway-set router1 pub1 --disable-snat
Set gateway for router router
(neutron) router-show router1 -c external_gateway_info
+---+--+
| Field | Value 
   |
+---+--+
| external_gateway_info | {network_id: 
1682e4f4-7dc4-4ed0-bd10-e526ab2f6f81, enable_snat: false} |
+---+--+
(neutron) router-gateway-clear router
Removed gateway from router router
(neutron) router-gateway-set router pub2 
Set gateway for router router
(neutron) router-show router1 -c external_gateway_info
+---+--+
| Field | Value 
   |
+---+--+
| external_gateway_info | {network_id: 
a32bcb44-165a-4de8-a8db-35f6ff8f2712, enable_snat: true} |
+---+--+

== enable_snat == False lost during router-gateway-clear


(neutron) router-gateway-set router1 pub1 --disable-snat
Set gateway for router router
(neutron) router-show router1 -c external_gateway_info
+---+--+
| Field | Value 
   |
+---+--+
| external_gateway_info | {network_id: 
1682e4f4-7dc4-4ed0-bd10-e526ab2f6f81, enable_snat: false} |
+---+--+
(neutron) router-gateway-set router pub2 
Set gateway for router router
(neutron) router-show router1 -c external_gateway_info
+---+--+
| Field | Value 
   |
+---+--+
| external_gateway_info | {network_id: 
a32bcb44-165a-4de8-a8db-35f6ff8f2712, enable_snat: false} |
+---+--+

== enable_snat == False not lost during router-gateway-set

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: l3-ipam-dhcp

** Changed in: neutron
   Status: New = In Progress

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

** Tags added: l3-ipam-dhcp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1384146

Title:
  Inconsistent enable_snat management

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  Neutron reset enable_snat on router-gateway-clear but not on router-
  gateway-set which implies inconsistent behavior:

  
  # pub1, pub2 are external networks and router1 is a router

  (neutron) router-gateway-set router1 pub1 --disable-snat
  Set gateway for router router
  (neutron) router-show router1 -c external_gateway_info
  
+---+--+
  | Field | Value   
 |
  
+---+--+
  | external_gateway_info | {network_id: 
1682e4f4-7dc4-4ed0-bd10-e526ab2f6f81, enable_snat: false} |
  
+---+--+
  (neutron) router-gateway-clear router
  Removed gateway from router router
  (neutron) router-gateway-set router pub2 
  Set gateway for router router
  (neutron) router-show router1 -c external_gateway_info
  
+---+--+
  | Field | Value

[Yahoo-eng-team] [Bug 1370485] [NEW] Cannot update firewall rule protocol to ANY

[Cedric Brandily]

Public bug reported:

when updating a firewall rule, setting protocol to ANY is not possible
... only TCP, UDP and ICMP are available

** Affects: horizon
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: low-hanging-fruit

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1370485

Title:
  Cannot update firewall rule protocol to ANY

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  when updating a firewall rule, setting protocol to ANY is not possible
  ... only TCP, UDP and ICMP are available

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1370485/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1368752] [NEW] Regions are unordered in region list

[Cedric Brandily]

Public bug reported:

Regions are displayed unordered in region list

** Affects: horizon
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: low-hanging-fruit

** Changed in: horizon
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1368752

Title:
  Regions are unordered in region list

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  Regions are displayed unordered in region list

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1368752/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1368757] [NEW] Tenants are unordered in tenant switch list

[Cedric Brandily]

Public bug reported:

Tenants are displayed unordered in tenant switch list

** Affects: horizon
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: low-hanging-fruit

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1368757

Title:
  Tenants are unordered in tenant switch list

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  Tenants are displayed unordered in tenant switch list

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1368757/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1364358] [NEW] Remove SELECT FOR UPDATE usage

[Cedric Brandily]

Public bug reported:

MySQL Galera does not support SELECT ... FOR UPDATE[1], since it has no
concept of cross-node locking of records and results are non-
deterministic.

Moreover SELECT FOR  UPDATE could be deadlock and slowness sources.

Remove the use of SELECT FOR UPDATE in (neutron.db.firewall.)firewall_db
module

[1]http://lists.openstack.org/pipermail/openstack-
dev/2014-May/035264.html

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1364358

Title:
  Remove SELECT FOR UPDATE usage

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  MySQL Galera does not support SELECT ... FOR UPDATE[1], since it has
  no concept of cross-node locking of records and results are non-
  deterministic.

  Moreover SELECT FOR  UPDATE could be deadlock and slowness sources.

  Remove the use of SELECT FOR UPDATE in
  (neutron.db.firewall.)firewall_db module

  [1]http://lists.openstack.org/pipermail/openstack-
  dev/2014-May/035264.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1364358/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1056437] Re: L3 agent should support provider external networks

[Cedric Brandily]

This bug has been solved in trunk[1] (icehouse) and backported to
stable/havana[2]: When external_network_bridge and
gateway_external_network_id are empty, l3-agent uses provider attributes
to deploy the external network

[1] https://review.openstack.org/59359
[2] https://review.openstack.org/68601

** Changed in: neutron
   Status: Confirmed = Fix Released

** Tags removed: havana-backport-potential l3-ipam-dhcp
** Tags added: in-stable-havana

** Tags added: l3-ipam-dhcp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1056437

Title:
  L3 agent should support provider external networks

Status in OpenStack Neutron (virtual network service):
  Fix Released

Bug description:
  The l3-agent requires an external quantum network, and creates ports
  on that network, but does not actually use the external quantum
  network for network connectivity. Instead, it requires manual
  configuration of an external_network_bridge for connectivity.

  Now that the provider network extension allows creation of quantum
  networks that do provide external connectivity, the l3-agent should
  support external connectivity through such networks. This can be done
  in a backward-compatible way by interpreting an empty
  external_network_bridge configuration variable as indicating that the
  external network should actually be used for connectivity.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1056437/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1330562] [NEW] Remove SELECT ... FOR UPDATE usage from ML2 type drivers

[Cedric Brandily]

Public bug reported:

MySQL Galera does not support SELECT ... FOR UPDATE[1], since it has no
concept of cross-node locking of records and results are non-
deterministic.

We should prefer to avoid SELECT ... FOR UPDATE (sqlalchemy
with_lockmode method)


[1]http://lists.openstack.org/pipermail/openstack-dev/2014-May/035264.html

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: db ml2

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1330562

Title:
  Remove SELECT ... FOR UPDATE usage from ML2 type drivers

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  MySQL Galera does not support SELECT ... FOR UPDATE[1], since it has
  no concept of cross-node locking of records and results are non-
  deterministic.

  We should prefer to avoid SELECT ... FOR UPDATE (sqlalchemy
  with_lockmode method)

  
  [1]http://lists.openstack.org/pipermail/openstack-dev/2014-May/035264.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1330562/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1324428] Re: net_create fail without definite segmentation_id

[Cedric Brandily]

This is not a bug, but it is the expected behavior of the current
provider networks extension.

A blueprint [1] proposes to reduce constraints on inputs.


[1]https://blueprints.launchpad.net/neutron/+spec/provider-network-partial-specs
[1]https://review.openstack.org/#/q/topic:bp/provider-network-partial-specs,n,z

** Changed in: neutron
   Status: New = Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1324428

Title:
  net_create fail without definite segmentation_id

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  if i define provider, but no segmentation_id,  net-create fail. why not 
allocate segmentation_id automatically?
  ~$ neutron net-create test --provider:network_type=vlan 
--provider:physical_network=default
  Invalid input for operation: segmentation_id required for VLAN provider 
network.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1324428/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1297145] [NEW] L3 agent uses deprecated root_helper option

[Cedric Brandily]

Public bug reported:

L3 agent uses deprecated root_helper option through
self.conf.root_helper in
neutron.agent.l3_agent.L3NATAgent._update_routing_table instead of using
self.root_helper (result of neutron.agent.common.config.get_root_helper.

It implies if AGENT/root_helper option is configured and root_helper is
not configured, extra routes are not pushed in routers.

** Affects: neutron
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: In Progress

** Changed in: neutron
   Status: New = In Progress

** Changed in: neutron
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1297145

Title:
  L3 agent uses deprecated root_helper option

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  L3 agent uses deprecated root_helper option through
  self.conf.root_helper in
  neutron.agent.l3_agent.L3NATAgent._update_routing_table instead of
  using self.root_helper (result of
  neutron.agent.common.config.get_root_helper.

  It implies if AGENT/root_helper option is configured and root_helper
  is not configured, extra routes are not pushed in routers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1297145/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1268943] [NEW] Fake compute available resources are not configurable

[Cedric Brandily]

Public bug reported:

Available resources provided by fake computes to the scheduler are
hardcoded in FakeDriver.get_available_resource.

Currently, It implies to change scheduler cpu/ram/disk_allocation
because fake computes capacity is too low when using
Core/Ram/DiskFilter.


The correction would allow to change fake compute available resources through 
configuration.

** Affects: nova
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New

** Changed in: nova
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1268943

Title:
  Fake compute available resources are not configurable

Status in OpenStack Compute (Nova):
  New

Bug description:
  Available resources provided by fake computes to the scheduler are
  hardcoded in FakeDriver.get_available_resource.

  Currently, It implies to change scheduler cpu/ram/disk_allocation
  because fake computes capacity is too low when using
  Core/Ram/DiskFilter.

  
  The correction would allow to change fake compute available resources through 
configuration.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1268943/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1260771] [NEW] Fake compute driver cannot deploy image with hypervisor_type attribute

[Cedric Brandily]

Public bug reported:

The fake compute driver does not provide the attribute supported_instances to 
ImagePropertiesFilter scheduler filter.
So ImagePropertiesFilter refuses to deploy images with hypervisor_type=fake 
property on fake computes.


Consequently, fake computes can not be used in multi hypervisor_types 
deployments because in this case hypervisor_type property on image is mandatory 
to avoid mixing one hypervisor_type image with another hypervisor_type compute.

** Affects: nova
 Importance: Undecided
 Assignee: Cedric Brandily (cbrandily)
 Status: New


** Tags: grizzly-backport-potential havana-backport-potential

** Changed in: nova
 Assignee: (unassigned) = Cedric Brandily (cbrandily)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1260771

Title:
  Fake compute driver cannot deploy image with hypervisor_type attribute

Status in OpenStack Compute (Nova):
  New

Bug description:
  The fake compute driver does not provide the attribute supported_instances to 
ImagePropertiesFilter scheduler filter.
  So ImagePropertiesFilter refuses to deploy images with hypervisor_type=fake 
property on fake computes.

  
  Consequently, fake computes can not be used in multi hypervisor_types 
deployments because in this case hypervisor_type property on image is mandatory 
to avoid mixing one hypervisor_type image with another hypervisor_type compute.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1260771/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp