[Yahoo-eng-team] [Bug 1491317] [NEW] Add port fowrading extension to L3
Public bug reported: I have searched and found many past efforts to implement port forwarding in Neutron. I have found two incomplete blueprints [1], [2] and an abandoned patch [3]. There is even a project in Stackforge [4], [5] that claims to implement this, but the L3 parts in it seems older then current master. I have recently came across this requirement for various use cases, one of them is providing feature compliance with Docker port-mapping feature (for Kuryr), and saving floating IP's space. There has been many discussions in the past that require this feature, so i assume there is a demand to make this formal, just a small examples [6], [7], [8], [9] The idea in a nutshell is to support port forwarding (TCP/UDP ports) on the external router leg from the public network to internal ports, so user can use one Floating IP (the external gateway router interface IP) and reach different internal ports depending on the port numbers. This should happen on the network node (and can also be leveraged for security reasons). I think that the POC implementation in the Stackforge project shows that this needs to be implemented inside the L3 parts of the current reference implementation, it will be hard to maintain something like that in an external repository. (I also think that the API/DB extensions should be close to the current L3 reference implementation) I would like to renew the efforts on this feature and propose a spec for this to the next release. And of course if any of the people interested or any of the people that worked on this before want to join the effort, you are more then welcome to join and comment. [1] https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding [2] https://blueprints.launchpad.net/neutron/+spec/fip-portforwarding [3] https://review.openstack.org/#/c/60512/ [4] https://github.com/stackforge/networking-portforwarding [5] https://review.openstack.org/#/q/port+forwarding,n,z [6] https://ask.openstack.org/en/question/75190/neutron-port-forwarding-qrouter-vms/ [7] http://www.gossamer-threads.com/lists/openstack/dev/34307 [8] http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-for-router-td46639.html [9] http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-from-gateway-to-internal-hosts-td32410.html ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Tags: rfe ** Changed in: neutron Assignee: (unassigned) => Gal Sagie (gal-sagie) ** Tags added: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1491317 Title: Add port fowrading extension to L3 Status in neutron: New Bug description: I have searched and found many past efforts to implement port forwarding in Neutron. I have found two incomplete blueprints [1], [2] and an abandoned patch [3]. There is even a project in Stackforge [4], [5] that claims to implement this, but the L3 parts in it seems older then current master. I have recently came across this requirement for various use cases, one of them is providing feature compliance with Docker port-mapping feature (for Kuryr), and saving floating IP's space. There has been many discussions in the past that require this feature, so i assume there is a demand to make this formal, just a small examples [6], [7], [8], [9] The idea in a nutshell is to support port forwarding (TCP/UDP ports) on the external router leg from the public network to internal ports, so user can use one Floating IP (the external gateway router interface IP) and reach different internal ports depending on the port numbers. This should happen on the network node (and can also be leveraged for security reasons). I think that the POC implementation in the Stackforge project shows that this needs to be implemented inside the L3 parts of the current reference implementation, it will be hard to maintain something like that in an external repository. (I also think that the API/DB extensions should be close to the current L3 reference implementation) I would like to renew the efforts on this feature and propose a spec for this to the next release. And of course if any of the people interested or any of the people that worked on this before want to join the effort, you are more then welcome to join and comment. [1] https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding [2] https://blueprints.launchpad.net/neutron/+spec/fip-portforwarding [3] https://review.openstack.org/#/c/60512/ [4] https://github.com/stackforge/networking-portforwarding [5] https://review.openstack.org/#/q/port+forwarding,n,z [6] https://ask.openstack.org/en/question/75190/neutron-port-forwarding-qrouter-vms/ [7] http://www.gossamer-threads.com/lists/openstack/dev/34307 [8] http://openstack.10931.n7.nabble.com/Neutron-p
[Yahoo-eng-team] [Bug 1489291] [NEW] Add tags to neutron resources
Public bug reported: In most popular REST API interfaces, objects in the domain model can be tagged with zero or more simple strings. These strings may then be used to group and categorize objects in the domain model. Neutron resources in current DB model do not contain any tags, and dont have a generic consistent way to add tags or/and any other data by the user. Adding tags to resources can be useful for management and orchestration in OpenStack, if its done in the API level and IS NOT backend specific data. The following use cases refer to adding tags to networks, but the same can be applicable to any other Neutron resource (core resource and router): 1) Ability to map different networks in different OpenStack locations to one logically same network (for Multi site OpenStack) 2) Ability to map Id's from different management/orchestration systems to OpenStack networks in mixed environments, for example for project Kuryr, map docker network id to neutron network id 3) Leverage tags by deployment tools spec : https://review.openstack.org/#/c/216021/ ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Tags: rfe ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1489291 Title: Add tags to neutron resources Status in neutron: New Bug description: In most popular REST API interfaces, objects in the domain model can be tagged with zero or more simple strings. These strings may then be used to group and categorize objects in the domain model. Neutron resources in current DB model do not contain any tags, and dont have a generic consistent way to add tags or/and any other data by the user. Adding tags to resources can be useful for management and orchestration in OpenStack, if its done in the API level and IS NOT backend specific data. The following use cases refer to adding tags to networks, but the same can be applicable to any other Neutron resource (core resource and router): 1) Ability to map different networks in different OpenStack locations to one logically same network (for Multi site OpenStack) 2) Ability to map Id's from different management/orchestration systems to OpenStack networks in mixed environments, for example for project Kuryr, map docker network id to neutron network id 3) Leverage tags by deployment tools spec : https://review.openstack.org/#/c/216021/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1489291/+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 1489138] [NEW] Add devref documentation to distributed DHCP feature
Public bug reported: Distributed DHCP implementation in the reference implementation is based on an abandoned spec and approved bug, the description of the feature and its limitations needs to be organised and well documented implementation: https://review.openstack.org/#/c/184423/ ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) ** Description changed: Distributed DHCP implementation in the reference implementation is based on an abandoned spec and approved bug, the description of the feature and its limitations needs to be organised and well documented + + implementation: https://review.openstack.org/#/c/184423/ -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1489138 Title: Add devref documentation to distributed DHCP feature Status in neutron: New Bug description: Distributed DHCP implementation in the reference implementation is based on an abandoned spec and approved bug, the description of the feature and its limitations needs to be organised and well documented implementation: https://review.openstack.org/#/c/184423/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1489138/+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 1464394] [NEW] Improve OVS agent init method
Public bug reported: Currently the agent init method takes the configuration object cfg.CONF but also there is a method which creates specific configurations dictionary according to it and call the agent with that structure. One method should be picked and code needs to be aligned as this is causing confusion and makes it hard to track ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1464394 Title: Improve OVS agent init method Status in OpenStack Neutron (virtual network service): New Bug description: Currently the agent init method takes the configuration object cfg.CONF but also there is a method which creates specific configurations dictionary according to it and call the agent with that structure. One method should be picked and code needs to be aligned as this is causing confusion and makes it hard to track To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1464394/+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 1461069] [NEW] Add Geneve type driver for ML2
Public bug reported: Add Geneve type driver for ML2 ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1461069 Title: Add Geneve type driver for ML2 Status in OpenStack Neutron (virtual network service): New Bug description: Add Geneve type driver for ML2 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1461069/+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 1461068] [NEW] Add STT Type Driver to ML2
Public bug reported: Add STT type driver for ML2 ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) ** Summary changed: - Add STT Type Driver + Add STT Type Driver to ML2 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1461068 Title: Add STT Type Driver to ML2 Status in OpenStack Neutron (virtual network service): New Bug description: Add STT type driver for ML2 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1461068/+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 1458541] [NEW] Decomposite DVR router compute node and network node functionallity to two classes
Public bug reported: Currently the same dvr router class is used both by the L3 Agent in the compute nodes that is responsible for the virtual routers namespace and the fip namespace and also used by the centralized SNAT L3 Agent in the network node. This bug address splitting the above functionality into two different classes ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1458541 Title: Decomposite DVR router compute node and network node functionallity to two classes Status in OpenStack Neutron (virtual network service): New Bug description: Currently the same dvr router class is used both by the L3 Agent in the compute nodes that is responsible for the virtual routers namespace and the fip namespace and also used by the centralized SNAT L3 Agent in the network node. This bug address splitting the above functionality into two different classes To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1458541/+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 1443259] Re: OVS IDL utils - need search by external id's method
This will be implemented inside OVN project, setting to invalid for now ** 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/1443259 Title: OVS IDL utils - need search by external id's method Status in OpenStack Neutron (virtual network service): Invalid Bug description: Add a method to search a table row by external id's dictionary the search dictionary can be partial and should return the first match To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1443259/+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 1444277] [NEW] OVSDB transaction timeout parameter needs to be configurable
Public bug reported: Currently the transaction timeout is taken from a context object that has a vsctl_timeout attribute this method is confusing for other users of this class (like OVN) and should be configurable in a different way ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1444277 Title: OVSDB transaction timeout parameter needs to be configurable Status in OpenStack Neutron (virtual network service): New Bug description: Currently the transaction timeout is taken from a context object that has a vsctl_timeout attribute this method is confusing for other users of this class (like OVN) and should be configurable in a different way To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1444277/+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 1443259] [NEW] OVS IDL utils - need search by external id's method
Public bug reported: Add a method to search a table row by external id's dictionary the search dictionary can be partial and should return the first match ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1443259 Title: OVS IDL utils - need search by external id's method Status in OpenStack Neutron (virtual network service): New Bug description: Add a method to search a table row by external id's dictionary the search dictionary can be partial and should return the first match To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1443259/+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 1442217] [NEW] native OVSDB needs to use Row.delete() for rows deletions
Public bug reported: The current OVSDB deletion mechanism needs to use the Row.delete() in order to properly delete the rows ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1442217 Title: native OVSDB needs to use Row.delete() for rows deletions Status in OpenStack Neutron (virtual network service): New Bug description: The current OVSDB deletion mechanism needs to use the Row.delete() in order to properly delete the rows To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1442217/+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 1441180] [NEW] OVSDB connection should get schema name as a parameter
Public bug reported: The schema name should be configurable for the OVSDB connection That way it can be used by external users (like OVN), currently the Open_Vswitch schema name is hard coded ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: In Progress ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1441180 Title: OVSDB connection should get schema name as a parameter Status in OpenStack Neutron (virtual network service): In Progress Bug description: The schema name should be configurable for the OVSDB connection That way it can be used by external users (like OVN), currently the Open_Vswitch schema name is hard coded To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1441180/+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 1440638] [NEW] OVSDB Transaction should get the connection as a parameter
Public bug reported: in the OVSDB native implementation using IDL, the transaction is taking the ovsdb connection from a global constant. should be getting it as a parameter to the construction This way other users can use the same implementation without the same connection (for example OVN) ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) ** Description changed: - in the OVSDB native implementation using IDL the transaction is taking the ovsdb connection from a global - constant. + in the OVSDB native implementation using IDL, the transaction is taking the ovsdb connection from a global constant. should be getting it as a parameter to the construction + + This way other users can use the same implementation without the same + connection (for example OVN) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1440638 Title: OVSDB Transaction should get the connection as a parameter Status in OpenStack Neutron (virtual network service): New Bug description: in the OVSDB native implementation using IDL, the transaction is taking the ovsdb connection from a global constant. should be getting it as a parameter to the construction This way other users can use the same implementation without the same connection (for example OVN) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1440638/+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 1438583] [NEW] DVR snat manipulations are not covered enough in tests
Public bug reported: The entire centralized SNAT namespace manipulations in DVR are not covered enough in unit tests/functional tests especially the method : _snat_redirect_modify ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1438583 Title: DVR snat manipulations are not covered enough in tests Status in OpenStack Neutron (virtual network service): New Bug description: The entire centralized SNAT namespace manipulations in DVR are not covered enough in unit tests/functional tests especially the method : _snat_redirect_modify To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1438583/+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 1435012] [NEW] Exception when removing last network port from external router
Public bug reported: Steps to reproduce: Single node devstack setup. Start devstack with ML2 and ovs,l2 population drivers. Enable DVR in L3/L2 and Service plugin (with DVR_SNAT) 1. Create Network with an instance on it 2. Create Router attached to external network 3. Add the network to the router (Two new interfaces should be added to the router, the network and an SNAT interface 4. Delete the two added interfaces from the router (or just the network one) The following exception is shown in the L3 Agent: 2015-03-22 16:07:54.613 ERROR neutron.agent.linux.utils [-] Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-81176deb-cc2b-4d29-903e-0a1a2fe207d6', 'ip', '-4', 'route', 'del', 'default', 'via', '10.1.0.8', 'dev', 'qr-a3c4575d-5f', 'table', '167837697'] Exit code: 1 Stdin: Stdout: Stderr: Cannot find device qr-a3c4575d-5f 2015-03-22 16:07:54.614 ERROR neutron.agent.l3.dvr_router [-] DVR: removed snat failed 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router Traceback (most recent call last): 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router File /opt/stack/neutron/neutron/agent/l3/dvr_router.py, line 282, in _snat_redirect_remove 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router ns_ipd.route.delete_gateway(gateway, table=snat_idx) 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router File /opt/stack/neutron/neutron/agent/linux/ip_lib.py, line 409, in delete_gateway 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router self._as_root([ip_version], tuple(args)) 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router File /opt/stack/neutron/neutron/agent/linux/ip_lib.py, line 222, in _as_root 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router use_root_namespace=use_root_namespace) 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router File /opt/stack/neutron/neutron/agent/linux/ip_lib.py, line 69, in _as_root 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router log_fail_as_error=self.log_fail_as_error) 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router File /opt/stack/neutron/neutron/agent/linux/ip_lib.py, line 78, in _execute 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router log_fail_as_error=log_fail_as_error) 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router File /opt/stack/neutron/neutron/agent/linux/utils.py, line 135, in execute 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router raise RuntimeError(m) 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router RuntimeError: 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-81176deb-cc2b-4d29-903e-0a1a2fe207d6', 'ip', '-4', 'route', 'del', 'default', 'via', '10.1.0.8', 'dev', 'qr-a3c4575d-5f', 'table', '167837697'] 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router Exit code: 1 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router Stdin: 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router Stdout: 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router Stderr: Cannot find device qr-a3c4575d-5f 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router Assumption: The code tries to delete the default route (for the SNAT) inside the router namespace, how ever the namespace is already deleted (since this is only connected network) ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) ** Description changed: Steps to reproduce: Single node devstack setup. Start devstack with ML2 and ovs,l2 population drivers. Enable DVR in L3/L2 and Service plugin (with DVR_SNAT) - 1. Create Network with an instance on it - 2. Create Router attached to external router + 2. Create Router attached to external network 3. Add the network to the router (Two new interfaces should be added to the router, the network and an SNAT interface 4. Delete the two added interfaces from the router (or just the network one) The following exception is shown in the L3 Agent: - 2015-03-22 16:07:54.613 ERROR neutron.agent.linux.utils [-] + 2015-03-22 16:07:54.613 ERROR neutron.agent.linux.utils [-] Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-81176deb-cc2b-4d29-903e-0a1a2fe207d6', 'ip', '-4', 'route', 'del', 'default', 'via', '10.1.0.8', 'dev', 'qr-a3c4575d-5f', 'table', '167837697'] Exit code: 1 - Stdin: - Stdout: + Stdin: + Stdout: Stderr: Cannot find device qr-a3c4575d-5f 2015-03-22 16:07:54.614 ERROR neutron.agent.l3.dvr_router [-] DVR: removed snat failed 2015-03-22 16:07:54.614 TRACE neutron.agent.l3.dvr_router Traceback (most recent call last
[Yahoo-eng-team] [Bug 1433208] [NEW] OVS_LIB should support setting controller connection-mode
Public bug reported: OVS_LIB doesn't have an API to change the connection-mode of a controller (change it from the default in-band to out-of-band for example) ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1433208 Title: OVS_LIB should support setting controller connection-mode Status in OpenStack Neutron (virtual network service): New Bug description: OVS_LIB doesn't have an API to change the connection-mode of a controller (change it from the default in-band to out-of-band for example) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1433208/+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
