[Yahoo-eng-team] [Bug 1503862] [NEW] VPNaaS: Enhance error checking on subnet changes
Public bug reported: Currently, if the CIDR of a subnet changes, and that subnet is used by VPN, there is no checking performed. Should add a notification for subnet CIDR changes and either block the change, if in use by VPN service/endpoint group, or to cause a sync operation in VPN so that existing connections are updated (if possible). I'm not sure which would be better. Need to ensure that we don't disrupt any existing IPSec connections that have not changed. Need to ensure this supports the new endpoint group capability for VPNaaS, where local subnets are specified in endpoint groups (versus the older method of a sole subnet being associated with a VPN service). ** Affects: neutron Importance: Undecided Status: New ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1503862 Title: VPNaaS: Enhance error checking on subnet changes Status in neutron: New Bug description: Currently, if the CIDR of a subnet changes, and that subnet is used by VPN, there is no checking performed. Should add a notification for subnet CIDR changes and either block the change, if in use by VPN service/endpoint group, or to cause a sync operation in VPN so that existing connections are updated (if possible). I'm not sure which would be better. Need to ensure that we don't disrupt any existing IPSec connections that have not changed. Need to ensure this supports the new endpoint group capability for VPNaaS, where local subnets are specified in endpoint groups (versus the older method of a sole subnet being associated with a VPN service). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1503862/+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 1504880] [NEW] VPNaaS: Update API documentation for endpoint groups
Public bug reported: As part of the upstreamed implementation for endpoint groups, the API documentation should be updated. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: doc vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1504880 Title: VPNaaS: Update API documentation for endpoint groups Status in neutron: In Progress Bug description: As part of the upstreamed implementation for endpoint groups, the API documentation should be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1504880/+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 1504881] [NEW] VPNaaS: Update API documentation for multiple local subnets
Public bug reported: As part of the multiple local subnets feature, update the API documentation. Note: also update the external_v4_ip and external_v6_ip fields that were added by a bug fix (missing DocImpact). ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: doc vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1504881 Title: VPNaaS: Update API documentation for multiple local subnets Status in neutron: In Progress Bug description: As part of the multiple local subnets feature, update the API documentation. Note: also update the external_v4_ip and external_v6_ip fields that were added by a bug fix (missing DocImpact). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1504881/+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 1505799] [NEW] VPNaaS: Provide functional test support for multiple local subnets
Public bug reported: Need to enhance the functional tests for VPNaaS so that they verify IPSec site-to-site connections with multiple local subnets in support of RFE 1459423. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1505799 Title: VPNaaS: Provide functional test support for multiple local subnets Status in neutron: In Progress Bug description: Need to enhance the functional tests for VPNaaS so that they verify IPSec site-to-site connections with multiple local subnets in support of RFE 1459423. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1505799/+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 1503862] Re: VPNaaS: Enhance error checking on subnet changes
Found out that the CIDR for a subnet is read-only, so we don't have to block changes, when the subnet is used by VPNaaS. ** 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/1503862 Title: VPNaaS: Enhance error checking on subnet changes Status in neutron: Invalid Bug description: Currently, if the CIDR of a subnet changes, and that subnet is used by VPN, there is no checking performed. Should add a notification for subnet CIDR changes and either block the change, if in use by VPN service/endpoint group, or to cause a sync operation in VPN so that existing connections are updated (if possible). I'm not sure which would be better. Need to ensure that we don't disrupt any existing IPSec connections that have not changed. Need to ensure this supports the new endpoint group capability for VPNaaS, where local subnets are specified in endpoint groups (versus the older method of a sole subnet being associated with a VPN service). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1503862/+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 1515670] [NEW] VPNaaS: Modify neutron-client to allow Horizon to detect multiple local subnet feature
Public bug reported: In review of 231133, Akihiro mentioned follow up work for the neutron client, so that Horizon can detect whether or not the new multiple local subnet feature, with endpoint groups, is available. Placeholder for that work. ** Affects: neutron Importance: Undecided Status: New ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1515670 Title: VPNaaS: Modify neutron-client to allow Horizon to detect multiple local subnet feature Status in neutron: New Bug description: In review of 231133, Akihiro mentioned follow up work for the neutron client, so that Horizon can detect whether or not the new multiple local subnet feature, with endpoint groups, is available. Placeholder for that work. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1515670/+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 1441783] Re: VPNaaS: Non-stacking functional jobs
Marked as invalid, as is a duplicate. ** 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/1441783 Title: VPNaaS: Non-stacking functional jobs Status in neutron: Invalid Bug description: In a fashion similar to Neutron, the functional tests jobs (dsvm- functional, dsvm-functional-sswan) should be converted to only prepare the environment, using DevStack, and not to actually stack (starting up all the processes). This will permit better performance for the functional tests and make the jobs more consistent to what is done in the Neutron repo. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1441783/+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 1521766] [NEW] pylint breakage in neutron and neutron-vpnaas
Public bug reported: The astroid package, used by pylint, was recently updated to version 1.4.1. Both 1.4.0 and 1.4.1 do not work with pylint 1.4.4, which is being used by LB, VPN, and neutron. astroid 1.3.8 works with pylint 1.4.4. For neutron: master and liberty gate uses pep8-constraints, which has a pin for astroid kilo needs pinning (proposal is to add to requriements) juno doesn't use pylint, so works Note: Can modify pep8 target to do same as pep8-constraints, so that developers can use same command they are used to. To add users For LB: master - Temp workaround was to remove pylint, can pin, if desired. liberty, kilo? - will need to pin juno? For VPN: master, liberty, and kilo need to pin pylint and astroid juno does not use pylint NOTE: Can migrate to using pep8-constraints job and target. For FW: does not do pylint for pep8, so no problem seen (but no coverage). Because this broke gate, there are several patches already in play for this. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: neutron neutron-lbaas neutron-vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1521766 Title: pylint breakage in neutron and neutron-vpnaas Status in neutron: In Progress Bug description: The astroid package, used by pylint, was recently updated to version 1.4.1. Both 1.4.0 and 1.4.1 do not work with pylint 1.4.4, which is being used by LB, VPN, and neutron. astroid 1.3.8 works with pylint 1.4.4. For neutron: master and liberty gate uses pep8-constraints, which has a pin for astroid kilo needs pinning (proposal is to add to requriements) juno doesn't use pylint, so works Note: Can modify pep8 target to do same as pep8-constraints, so that developers can use same command they are used to. To add users For LB: master - Temp workaround was to remove pylint, can pin, if desired. liberty, kilo? - will need to pin juno? For VPN: master, liberty, and kilo need to pin pylint and astroid juno does not use pylint NOTE: Can migrate to using pep8-constraints job and target. For FW: does not do pylint for pep8, so no problem seen (but no coverage). Because this broke gate, there are several patches already in play for this. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1521766/+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 1522503] [NEW] Add support for constraints based jobs for neutron-*aas
Public bug reported: Need to modify neutron-fwaas, neutron-lbaas, and neutron-vpnaas projects to support constraints based targets for pep8, cover, and docs. Create jobs (initially experimental) for pep8 and docs constraints. This will bring the advanced services projects in line with what is done in neutron. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: fwaas lbaas vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1522503 Title: Add support for constraints based jobs for neutron-*aas Status in neutron: In Progress Bug description: Need to modify neutron-fwaas, neutron-lbaas, and neutron-vpnaas projects to support constraints based targets for pep8, cover, and docs. Create jobs (initially experimental) for pep8 and docs constraints. This will bring the advanced services projects in line with what is done in neutron. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1522503/+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 1349829] [NEW] VPNaaS: Enable UT now that oslo.messaging udpated
Public bug reported: Now that 1.4.0.0a3 oslo.messaging is available in Neutron, enable commented out unit test cases that were failing due to garbage chars in imported oslo.messaging module. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1349829 Title: VPNaaS: Enable UT now that oslo.messaging udpated Status in OpenStack Neutron (virtual network service): In Progress Bug description: Now that 1.4.0.0a3 oslo.messaging is available in Neutron, enable commented out unit test cases that were failing due to garbage chars in imported oslo.messaging module. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1349829/+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 1356127] [NEW] VPNaaS: Cisco validator incorrectly checking public IP of router
Public bug reported: The IPSec site connection validation checks that the router has a GW specified. It incorrectly accesses this information via the VPN service table. As a result, all validations fail. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: cisco vnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => In Progress ** Description changed: The IPSec site connection validation checks that the router has a GW specified. It incorrectly accesses this information via the VPN service table. + + As a result, all validations fail. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1356127 Title: VPNaaS: Cisco validator incorrectly checking public IP of router Status in OpenStack Neutron (virtual network service): In Progress Bug description: The IPSec site connection validation checks that the router has a GW specified. It incorrectly accesses this information via the VPN service table. As a result, all validations fail. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1356127/+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 1358470] [NEW] VPNaaS modify Cisco REST client UTs to use requests-mock library
Public bug reported: The unit test module for the Cisco CSR REST client was written to use the httmock package for Icehouse. However, this was disabled (named notest_cisco_csr_rest.py), as the community decision was to not add the httmock package. There also was discussion about replacing the other (approved) package, httpretty. Because of that, no activity was performed on this unit test module. Since, Icehouse, a new package requests_mock was added to global requirements, and work is on-going to migrate httpretty use to this new package. This bug is to update the notest_cisco_csr_rest.py module to work with the requests_mock package. A companion bug will be created to add requests_mock to the Neutron test-requirements.txt (not sure why it wasn't automatically added). This will allow coverage of the REST client code for VPNaaS. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1358470 Title: VPNaaS modify Cisco REST client UTs to use requests-mock library Status in OpenStack Neutron (virtual network service): In Progress Bug description: The unit test module for the Cisco CSR REST client was written to use the httmock package for Icehouse. However, this was disabled (named notest_cisco_csr_rest.py), as the community decision was to not add the httmock package. There also was discussion about replacing the other (approved) package, httpretty. Because of that, no activity was performed on this unit test module. Since, Icehouse, a new package requests_mock was added to global requirements, and work is on-going to migrate httpretty use to this new package. This bug is to update the notest_cisco_csr_rest.py module to work with the requests_mock package. A companion bug will be created to add requests_mock to the Neutron test-requirements.txt (not sure why it wasn't automatically added). This will allow coverage of the REST client code for VPNaaS. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1358470/+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 1358472] [NEW] Add requests-mock to Neutron test-requirements.txt
Public bug reported: The requests-mock package has been added to test requirements in global requirements, but is not in Neutron test-requirements. This bug is simply a request to add this package to test-requirements.txt for Neutron. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1358472 Title: Add requests-mock to Neutron test-requirements.txt Status in OpenStack Neutron (virtual network service): In Progress Bug description: The requests-mock package has been added to test requirements in global requirements, but is not in Neutron test-requirements. This bug is simply a request to add this package to test-requirements.txt for Neutron. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1358472/+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 1360435] [NEW] Service Type Manager singleton needs protection
Public bug reported: During review of some UT code for VPNaaS (https://review.openstack.org/110432) it was found that the tests were failing in Jenkins, with a cryptic StringException and no traceback. The root cause of that was found to be that two test classes were instantiating a VPN plugin, which in turn calls the Service Type Manager's load_driver() standalone method. This method will create/get an instance of the service type manager. As part of that, it will call load_conf, which creates a ProviderConfiguration object and reads in a configuration multistring into a dictionary. When multiple tests run in parallel, it appears that the dictionary can be munged by concurrent access during construction. For 110432, the workaround was to create a unique (non-singleton) instance of the service type manager. However, we shuld probably lock the access to this load_conf() method (change the singleton design, or don't use a class). ** Affects: neutron 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/1360435 Title: Service Type Manager singleton needs protection Status in OpenStack Neutron (virtual network service): New Bug description: During review of some UT code for VPNaaS (https://review.openstack.org/110432) it was found that the tests were failing in Jenkins, with a cryptic StringException and no traceback. The root cause of that was found to be that two test classes were instantiating a VPN plugin, which in turn calls the Service Type Manager's load_driver() standalone method. This method will create/get an instance of the service type manager. As part of that, it will call load_conf, which creates a ProviderConfiguration object and reads in a configuration multistring into a dictionary. When multiple tests run in parallel, it appears that the dictionary can be munged by concurrent access during construction. For 110432, the workaround was to create a unique (non-singleton) instance of the service type manager. However, we shuld probably lock the access to this load_conf() method (change the singleton design, or don't use a class). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1360435/+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 1361605] [NEW] Use lazy init for L3 plugin reference
Public bug reported: In many L3 plugins, there is a reference needed to the L3 core plugin. This is typically done as: plugin = manager.NeutronManager.get_service_plugins().get(constants.L3_ROUTER_NAT) Rather than looking up the plugin, each time it is needed (e.g. processing each VPN API request), this bug proposes to do a lazy init of the plugin as in: @property def l3_plugin(self): try: return self._l3_plugin except AttributeError: self._l3_plugin = manager.NeutronManager.get_service_plugins().get( constants.L3_ROUTER_NAT) return self._l3_plugin In addition, we can look at placing this in a common area (mixin?) or as a decorator, so that each class that needs it could use the mixin, rather than repeat this property. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: New ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1361605 Title: Use lazy init for L3 plugin reference Status in OpenStack Neutron (virtual network service): New Bug description: In many L3 plugins, there is a reference needed to the L3 core plugin. This is typically done as: plugin = manager.NeutronManager.get_service_plugins().get(constants.L3_ROUTER_NAT) Rather than looking up the plugin, each time it is needed (e.g. processing each VPN API request), this bug proposes to do a lazy init of the plugin as in: @property def l3_plugin(self): try: return self._l3_plugin except AttributeError: self._l3_plugin = manager.NeutronManager.get_service_plugins().get( constants.L3_ROUTER_NAT) return self._l3_plugin In addition, we can look at placing this in a common area (mixin?) or as a decorator, so that each class that needs it could use the mixin, rather than repeat this property. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1361605/+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 1366797] [NEW] Add UT assert to check subset of dict
Public bug reported: With the VPN unit tests, there are many occasions where there is a desire to test if an actual dict contains keys and values specified in some expected dict. The actual dict would be a superset, as there may be keys (e.g. auth) that can be ignored. Rather than make the change local to VPN code, this bug is suggesting to add this as an assert into the base test class, so that everyone can use it. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1366797 Title: Add UT assert to check subset of dict Status in OpenStack Neutron (virtual network service): In Progress Bug description: With the VPN unit tests, there are many occasions where there is a desire to test if an actual dict contains keys and values specified in some expected dict. The actual dict would be a superset, as there may be keys (e.g. auth) that can be ignored. Rather than make the change local to VPN code, this bug is suggesting to add this as an assert into the base test class, so that everyone can use it. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1366797/+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 1368900] [NEW] Exception masked due to log exception
Public bug reported: In neutron/plugins/cisco/cfg_agent/device_drivers/driver_mgr.py, if an exception occurs loading the Cfg Agent, a log message is created and it causes a second exception due to incorrect key used to access template name. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1368900 Title: Exception masked due to log exception Status in OpenStack Neutron (virtual network service): In Progress Bug description: In neutron/plugins/cisco/cfg_agent/device_drivers/driver_mgr.py, if an exception occurs loading the Cfg Agent, a log message is created and it causes a second exception due to incorrect key used to access template name. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1368900/+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 1368899] [NEW] Exception masked due to log exception
Public bug reported: In neutron/plugins/cisco/cfg_agent/device_drivers/driver_mgr.py, if an exception occurs loading the Cfg Agent, a log message is created and it causes a second exception due to incorrect key used to access template name. ** Affects: neutron Importance: Undecided Assignee: Numan Siddique (numansiddique) 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/1368899 Title: Exception masked due to log exception Status in OpenStack Neutron (virtual network service): New Bug description: In neutron/plugins/cisco/cfg_agent/device_drivers/driver_mgr.py, if an exception occurs loading the Cfg Agent, a log message is created and it causes a second exception due to incorrect key used to access template name. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1368899/+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 1368899] Re: Exception masked due to log exception
For some reason a duplicate was created for this bug (1368899 and 1368900). Will close this one. ** Changed in: neutron Assignee: Numan Siddique (numansiddique) => (unassigned) ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** 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/1368899 Title: Exception masked due to log exception Status in OpenStack Neutron (virtual network service): Invalid Bug description: In neutron/plugins/cisco/cfg_agent/device_drivers/driver_mgr.py, if an exception occurs loading the Cfg Agent, a log message is created and it causes a second exception due to incorrect key used to access template name. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1368899/+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 1258656] [NEW] Remove duplication in get_resource for services
Public bug reported:
In VPNaaS extension there is a code block in get_resources() that is
very similar to other services (and with the additions being proposed
for SSL VPN - two more cases).
Should consider moving this up into a common module (base.py?) to remove
duplication (assuming the variations don't make that feasible).
The block is:
for collection_name in RESOURCE_ATTRIBUTE_MAP:
resource_name = plural_mapping.get(
collection_name, collection_name[:-1])
params = RESOURCE_ATTRIBUTE_MAP[collection_name]
collection_name = collection_name.replace('_', '-')
quota.QUOTAS.register_resource_by_name(resource_name)
controller = base.create_resource(
collection_name, resource_name, plugin, params,
allow_pagination=cfg.CONF.allow_pagination,
allow_sorting=cfg.CONF.allow_sorting)
resource = extensions.ResourceExtension(
collection_name,
controller,
path_prefix=constants.COMMON_PREFIXES[constants.VPN],
attr_map=params)
resources.append(resource)
** Affects: neutron
Importance: Undecided
Status: New
** Tags: fwaas lbaas vpnaas
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1258656
Title:
Remove duplication in get_resource for services
Status in OpenStack Neutron (virtual network service):
New
Bug description:
In VPNaaS extension there is a code block in get_resources() that is
very similar to other services (and with the additions being proposed
for SSL VPN - two more cases).
Should consider moving this up into a common module (base.py?) to
remove duplication (assuming the variations don't make that feasible).
The block is:
for collection_name in RESOURCE_ATTRIBUTE_MAP:
resource_name = plural_mapping.get(
collection_name, collection_name[:-1])
params = RESOURCE_ATTRIBUTE_MAP[collection_name]
collection_name = collection_name.replace('_', '-')
quota.QUOTAS.register_resource_by_name(resource_name)
controller = base.create_resource(
collection_name, resource_name, plugin, params,
allow_pagination=cfg.CONF.allow_pagination,
allow_sorting=cfg.CONF.allow_sorting)
resource = extensions.ResourceExtension(
collection_name,
controller,
path_prefix=constants.COMMON_PREFIXES[constants.VPN],
attr_map=params)
resources.append(resource)
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1258656/+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 1258952] [NEW] tox failues due to out of memory
Public bug reported: I'm running tox -e py27 under Ubuntu 12.04 desktop 64 bit in a VM on my laptop with 4 GB or RAM allocated. The memory in the run creeps up to 4GB and then near the end, it drops back down to about 2GB and in the end, I get numerous tox failures, many indicating out of memory and too many open files: ... == FAIL: neutron.tests.unit.test_agent_linux_utils.AgentUtilsExecuteTest.test_without_helper tags: worker-0 -- Empty attachments: pythonlogging:'' stderr stdout Traceback (most recent call last): File "/opt/stack/neutron/neutron/tests/unit/test_agent_linux_utils.py", line 39, in test_without_helper result = utils.execute(["ls", self.test_file]) File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 65, in execute addl_env=addl_env) File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 56, in create_process env=env) File "/opt/stack/neutron/neutron/common/utils.py", line 125, in subprocess_popen close_fds=True, env=env) File "/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/eventlet/green/subprocess.py", line 44, in __init__ subprocess_orig.Popen.__init__(self, args, 0, *argss, **kwds) File "/usr/lib/python2.7/subprocess.py", line 679, in __init__ errread, errwrite) File "/usr/lib/python2.7/subprocess.py", line 1143, in _execute_child self.pid = os.fork() OSError: [Errno 12] Cannot allocate memory == FAIL: process-returncode tags: worker-0 -- Binary content: traceback (test/plain; charset="utf8") == FAIL: neutron.tests.unit.test_agent_linux_utils.AgentUtilsExecuteTest.test_check_exit_code tags: worker-1 -- Empty attachments: pythonlogging:'' stderr stdout Traceback (most recent call last): File "/opt/stack/neutron/neutron/tests/unit/test_agent_linux_utils.py", line 59, in test_check_exit_code check_exit_code=False) File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 65, in execute addl_env=addl_env) File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 56, in create_process env=env) File "/opt/stack/neutron/neutron/common/utils.py", line 125, in subprocess_popen close_fds=True, env=env) File "/opt/stack/neutron/.tox/py27/local/lib/python2.7/site-packages/eventlet/green/subprocess.py", line 44, in __init__ subprocess_orig.Popen.__init__(self, args, 0, *argss, **kwds) File "/usr/lib/python2.7/subprocess.py", line 672, in __init__ errread, errwrite) = self._get_handles(stdin, stdout, stderr) File "/usr/lib/python2.7/subprocess.py", line 1038, in _get_handles p2cread, p2cwrite = self.pipe_cloexec() File "/usr/lib/python2.7/subprocess.py", line 1091, in pipe_cloexec r, w = os.pipe() OSError: [Errno 24] Too many open files == ... Ran 9290 (+1703) tests in 2704.305s (+299.051s) FAILED (id=1, failures=194 (+185), skips=324) Here is the version info: cm@vpn-a[2853] $ git log -n 1 commit 3014e1e021b3fe59c75daae1734472c3a11582ee Merge: e22626e 5652e20 Author: Jenkins Date: Sat Dec 7 23:05:30 2013 + Merge "Preserve floating ips when initializing l3 gateway interface" ** Affects: neutron 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/1258952 Title: tox failues due to out of memory Status in OpenStack Neutron (virtual network service): New Bug description: I'm running tox -e py27 under Ubuntu 12.04 desktop 64 bit in a VM on my laptop with 4 GB or RAM allocated. The memory in the run creeps up to 4GB and then near the end, it drops back down to about 2GB and in the end, I get numerous tox failures, many indicating out of memory and too many open files: ... == FAIL: neutron.tests.unit.test_agent_linux_utils.AgentUtilsExecuteTest.test_without_helper tags: worker-0 -- Empty attachments: pythonlogging:'' stderr stdout Traceback (most recent call last): File "/opt/stack/neutron/neutron/tests/unit/test_agent_linux_utils.py", line 39, in test_without_helper result = utils.execute(["ls", self.test_file]) File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 65, in execute addl_env=addl_env) File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 56, in create_process env=env) File "/opt/
[Yahoo-eng-team] [Bug 1078490] Re: l3-agent failed to set default route when gateway_ip of subnet is outside cidr
Wil mark invalid and have opened bug 1178675 for UT coverage enhancement. ** Changed in: quantum Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to quantum. https://bugs.launchpad.net/bugs/1078490 Title: l3-agent failed to set default route when gateway_ip of subnet is outside cidr Status in OpenStack Quantum (virtual network service): Invalid Bug description: quantum net-create net-ext --router:external quantum subnet-create --gateway 10.3.3.1 net-ext 10.2.2.0/24 quantum router-create r1 quantum router-gateway-set r1 ext-net 2012-11-13 14:22:12DEBUG [quantum.agent.linux.utils] Running command: sudo /opt/stack/quantum/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ip netns exec qrouter-ab903988-25ce-41a2-848b-6544f6e7d1e0 ip -4 addr add 10.2.2.2/24 brd 10.2.2.255 scope global dev qg-f71a48e9-0b 2012-11-13 14:22:12DEBUG [quantum.agent.linux.utils] Command: ['sudo', '/opt/stack/quantum/bin/quantum-rootwrap', '/etc/quantum/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-ab903988-25ce-41a2-848b-6544f6e7d1e0', 'ip', '-4', 'addr', 'add', '10.2.2.2/24', 'brd', '10.2.2.255', 'scope', 'global', 'dev', 'qg-f71a48e9-0b'] Exit code: 0 Stdout: '' Stderr: '' 2012-11-13 14:22:12DEBUG [quantum.agent.linux.utils] Running command: sudo /opt/stack/quantum/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ip netns exec qrouter-ab903988-25ce-41a2-848b-6544f6e7d1e0 route add default gw 10.3.3.1 2012-11-13 14:22:12DEBUG [quantum.agent.linux.utils] Command: ['sudo', '/opt/stack/quantum/bin/quantum-rootwrap', '/etc/quantum/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-ab903988-25ce-41a2-848b-6544f6e7d1e0', 'route', 'add', 'default', 'gw', '10.3.3.1'] Exit code: 7 Stdout: '' Stderr: 'SIOCADDRT: No such process\n' To manage notifications about this bug go to: https://bugs.launchpad.net/quantum/+bug/1078490/+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 1547032] [NEW] Enhance API tests for neutron-vpnaas
Public bug reported: Once VPN API tests are operational again (bug 1483417), they should be enhanced to exercise the new endpoint group APIs and the modifications to other APIs resulting from the new endpoint groups (e.g. no local subnet specified for vpnservice, and no peer subnets specified for ipsec site connection API - instead these are in endpoint groups). This will require mappings in the tempest, as is being restored by 1546786. This will improve the coverage of the API. ** Affects: neutron Importance: Undecided Status: New ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1547032 Title: Enhance API tests for neutron-vpnaas Status in neutron: New Bug description: Once VPN API tests are operational again (bug 1483417), they should be enhanced to exercise the new endpoint group APIs and the modifications to other APIs resulting from the new endpoint groups (e.g. no local subnet specified for vpnservice, and no peer subnets specified for ipsec site connection API - instead these are in endpoint groups). This will require mappings in the tempest, as is being restored by 1546786. This will improve the coverage of the API. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1547032/+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 1473194] [NEW] Grenade tests fail for *aaS migrations
Public bug reported: I found that when Grenade runs (check-grenade-dsvm-function), it runs the migration for *aaS repos BEFORE upgrade, but not part of upgrade. In my case, the migration modified a table and the migration never ran. This fails a bunch of tests as a result. http://logs.openstack.org/70/199670/2/check/check-grenade-dsvm- neutron/8000a62/ Applies to all the advanced services. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: New ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1473194 Title: Grenade tests fail for *aaS migrations Status in OpenStack Neutron (virtual network service): New Bug description: I found that when Grenade runs (check-grenade-dsvm-function), it runs the migration for *aaS repos BEFORE upgrade, but not part of upgrade. In my case, the migration modified a table and the migration never ran. This fails a bunch of tests as a result. http://logs.openstack.org/70/199670/2/check/check-grenade-dsvm- neutron/8000a62/ Applies to all the advanced services. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1473194/+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 1473475] [NEW] VPNaaS: Add DevStack plugin
Public bug reported: This is an enhancement to the neutron-vpnaas repo to add DevStack plugin support. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1473475 Title: VPNaaS: Add DevStack plugin Status in neutron: In Progress Bug description: This is an enhancement to the neutron-vpnaas repo to add DevStack plugin support. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1473475/+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 1475173] Re: IPsecSiteConnection status doesn't go to PENDING_UPDATE when being updated
The pending states are used for cases when an action takes a long time - namely, longer than the request response. For example, when creating an IPSec connection, there is a period of time where the tunnel must be set up and negotiated. As a result, the create request will return a response, but the operation is still in progress. The actual creation may take 30+ seconds to complete. All update requests, are performed immediately, and will have completed by the time the request returns a response. Hence, no intermediate PENDING state is needed. This operates as designed. ** 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/1475173 Title: IPsecSiteConnection status doesn't go to PENDING_UPDATE when being updated Status in neutron: Invalid Bug description: In the function update_ipsec_site_connection in module neutron- vpnaas.services.vpn.plugin, it should have existed a statement assigning PENDING_UPDATE to ipsec_site_connection['ipsec_site_connection']['status'] before invoke the corresponding db operation. Am I missing something? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1475173/+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 1475172] Re: VPNService status doesn't go to PENDING_UPDATE when being updated
The pending states are used for cases when an action takes a long time - namely, longer than the request response. For example, when creating an IPSec connection, there is a period of time where the tunnel must be set up and negotiated. As a result, the create request will return a response, but the operation is still in progress. The actual creation may take 30+ seconds to complete. All update requests, are performed immediately, and will have completed by the time the request returns a response. Hence, no intermediate PENDING state is needed. This operates as designed. ** 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/1475172 Title: VPNService status doesn't go to PENDING_UPDATE when being updated Status in neutron: Invalid Bug description: In the function update_vpnservice in module neutron- vpnaas.services.vpn.plugin, it should have existed a statement assigning PENDING_UPDATE to vpnservice['vpnservice']['status'] before invoke the corresponding db operation. Am I missing something? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1475172/+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 1484141] [NEW] VPNaaS: devstack plugin starts duplicate process
Public bug reported: The new plugin shares the same service name as the non-plugin implementation of VPN setup for DevStack. That combined with missing logic in the devstack scripts to make sure non-plugin and plugin VPN setup are mutually exclusive, causes two instances of the agent being spawned. Need to update the DevStack script to force mutual exclusion, and need to rename the service for the plugin to prevent the conflict. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1484141 Title: VPNaaS: devstack plugin starts duplicate process Status in neutron: In Progress Bug description: The new plugin shares the same service name as the non-plugin implementation of VPN setup for DevStack. That combined with missing logic in the devstack scripts to make sure non-plugin and plugin VPN setup are mutually exclusive, causes two instances of the agent being spawned. Need to update the DevStack script to force mutual exclusion, and need to rename the service for the plugin to prevent the conflict. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1484141/+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 1495505] [NEW] VPNaaS: Coverage tests broken
Public bug reported: Currently, 'testr' does not support the --coverage-package-name option, which is needed for coverage testing of VPN. Need to update tox.ini to use 'test'. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1495505 Title: VPNaaS: Coverage tests broken Status in neutron: In Progress Bug description: Currently, 'testr' does not support the --coverage-package-name option, which is needed for coverage testing of VPN. Need to update tox.ini to use 'test'. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495505/+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 1495503] [NEW] VPNaaS: Coverage tests broken
Public bug reported: Coverage tests for VPNaaS are no longer working, as testr does not support --coverage-package-name argument any more. Need to switch to using 'test' instead. ** Affects: neutron Importance: Undecided Status: Invalid ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1495503 Title: VPNaaS: Coverage tests broken Status in neutron: Invalid Bug description: Coverage tests for VPNaaS are no longer working, as testr does not support --coverage-package-name argument any more. Need to switch to using 'test' instead. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495503/+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 1495504] [NEW] VPNaaS: Coverage tests broken
Public bug reported: Coverage tests for VPNaaS are no longer working, as testr does not support --coverage-package-name argument any more. Need to switch to using 'test' instead. ** Affects: neutron Importance: Undecided Status: Invalid ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1495504 Title: VPNaaS: Coverage tests broken Status in neutron: Invalid Bug description: Coverage tests for VPNaaS are no longer working, as testr does not support --coverage-package-name argument any more. Need to switch to using 'test' instead. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495504/+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 1495497] [NEW] VPNaaS: Coverage tests broken
Public bug reported: Currently, 'testr' does not support the --coverage-package-name option, which is needed for coverage testing of VPN. Need to update tox.ini to use 'test'. ** Affects: neutron Importance: Undecided Status: Invalid ** Tags: vpnaas ** 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/1495497 Title: VPNaaS: Coverage tests broken Status in neutron: Invalid Bug description: Currently, 'testr' does not support the --coverage-package-name option, which is needed for coverage testing of VPN. Need to update tox.ini to use 'test'. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495497/+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 1495503] Re: VPNaaS: Coverage tests broken
Duplicate bug created due to launchpad issue. ** 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/1495503 Title: VPNaaS: Coverage tests broken Status in neutron: Invalid Bug description: Coverage tests for VPNaaS are no longer working, as testr does not support --coverage-package-name argument any more. Need to switch to using 'test' instead. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495503/+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 1495504] Re: VPNaaS: Coverage tests broken
Duplicate bug created due to launchpad issue. ** 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/1495504 Title: VPNaaS: Coverage tests broken Status in neutron: Invalid Bug description: Coverage tests for VPNaaS are no longer working, as testr does not support --coverage-package-name argument any more. Need to switch to using 'test' instead. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495504/+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 1495502] Re: VPNaaS: Coverage tests broken
Duplicate bug created due to launchpad issue. ** Changed in: neutron Status: New => Incomplete ** 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/1495502 Title: VPNaaS: Coverage tests broken Status in neutron: Invalid Bug description: Currently, 'testr' does not support the --coverage-package-name option, which is needed for coverage testing of VPN. Need to update tox.ini to use 'test'. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495502/+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 1495502] [NEW] VPNaaS: Coverage tests broken
Public bug reported: Currently, 'testr' does not support the --coverage-package-name option, which is needed for coverage testing of VPN. Need to update tox.ini to use 'test'. ** Affects: neutron Importance: Undecided Status: Invalid ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1495502 Title: VPNaaS: Coverage tests broken Status in neutron: Invalid Bug description: Currently, 'testr' does not support the --coverage-package-name option, which is needed for coverage testing of VPN. Need to update tox.ini to use 'test'. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495502/+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 1495499] [NEW] VPNaaS: Coverage tests broken
Public bug reported: Currently, 'testr' does not support the --coverage-package-name option, which is needed for coverage testing of VPN. Need to update tox.ini to use 'test'. ** Affects: neutron Importance: Undecided Status: Invalid ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1495499 Title: VPNaaS: Coverage tests broken Status in neutron: Invalid Bug description: Currently, 'testr' does not support the --coverage-package-name option, which is needed for coverage testing of VPN. Need to update tox.ini to use 'test'. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495499/+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 1495499] Re: VPNaaS: Coverage tests broken
Duplicate bug created due to launchpad issue. ** 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/1495499 Title: VPNaaS: Coverage tests broken Status in neutron: Invalid Bug description: Currently, 'testr' does not support the --coverage-package-name option, which is needed for coverage testing of VPN. Need to update tox.ini to use 'test'. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495499/+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 1495505] Re: VPNaaS: Coverage tests broken
Already have bug under 1454772. ** 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/1495505 Title: VPNaaS: Coverage tests broken Status in neutron: Invalid Bug description: Currently, 'testr' does not support the --coverage-package-name option, which is needed for coverage testing of VPN. Need to update tox.ini to use 'test'. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495505/+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 1495584] [NEW] VPNaaS: Help reduce cross project breakage
Public bug reported: One issue that has been occurring is that a neutron project commit may change a method/attribute that the neutron-vpnaas project uses, resulting in breakage in the neutron-vpnaas project (which may not be detected for days). To help reduce this probability, there is a desire to have neutron commits run VPN unit and functional tests. This bug is to document the need for running VPN functional tests on neutron commits. Code review 203201 upstreamed (before this bug was created) a pair of neutron jobs that will run VPN functional tests in the experimental queue. These jobs need to move to check, and eventually gate queues. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1495584 Title: VPNaaS: Help reduce cross project breakage Status in neutron: In Progress Bug description: One issue that has been occurring is that a neutron project commit may change a method/attribute that the neutron-vpnaas project uses, resulting in breakage in the neutron-vpnaas project (which may not be detected for days). To help reduce this probability, there is a desire to have neutron commits run VPN unit and functional tests. This bug is to document the need for running VPN functional tests on neutron commits. Code review 203201 upstreamed (before this bug was created) a pair of neutron jobs that will run VPN functional tests in the experimental queue. These jobs need to move to check, and eventually gate queues. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495584/+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 1408404] [NEW] VPNaaS: remove ABCMeta decorator from device drivers
Public bug reported: It looks like, from day one, the Cisco and reference VPN device driver classes have a decorator for ABC, but these classes are children of an ABC and a re concrete classes, AFAICT. This fix is to remove that decorator from the class definitions. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1408404 Title: VPNaaS: remove ABCMeta decorator from device drivers Status in OpenStack Neutron (virtual network service): In Progress Bug description: It looks like, from day one, the Cisco and reference VPN device driver classes have a decorator for ABC, but these classes are children of an ABC and a re concrete classes, AFAICT. This fix is to remove that decorator from the class definitions. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1408404/+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 1416427] [NEW] VPNaaS: Create functional tests for OpenSwan implementation
Public bug reported: Currently, there are no functional tests for OpenSwan reference implementation of VPNaaS. Should develop tests to exercise this implementation. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: New ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1416427 Title: VPNaaS: Create functional tests for OpenSwan implementation Status in OpenStack Neutron (virtual network service): New Bug description: Currently, there are no functional tests for OpenSwan reference implementation of VPNaaS. Should develop tests to exercise this implementation. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1416427/+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 1418190] [NEW] Remove duplication in functional gate hook
Public bug reported: The post_test_hook.sh script has generate_testr_results(), which is used in the neutron and neutron-vpnaas (and in the future other *aaS) repos. This bug is to move this up into the destack-gate repo and use it from each of the repos, thus removing the duplicate code. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1418190 Title: Remove duplication in functional gate hook Status in OpenStack Neutron (virtual network service): In Progress Bug description: The post_test_hook.sh script has generate_testr_results(), which is used in the neutron and neutron-vpnaas (and in the future other *aaS) repos. This bug is to move this up into the destack-gate repo and use it from each of the repos, thus removing the duplicate code. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1418190/+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 1418190] Re: Remove duplication in functional gate hook
After discussions with Maru, we've decided to abandon this change, as the effort to remove the duplication is not worth it. Requires modification to run-tox for sudo for dsvm-functional. ** 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/1418190 Title: Remove duplication in functional gate hook Status in OpenStack Neutron (virtual network service): Invalid Bug description: The post_test_hook.sh script has generate_testr_results(), which is used in the neutron and neutron-vpnaas (and in the future other *aaS) repos. This bug is to move this up into the destack-gate repo and use it from each of the repos, thus removing the duplicate code. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1418190/+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 1422895] [NEW] parse_service_provider_opt affecting VPN UTs
Public bug reported: For VPN functional tests or unit test that are run after stacking with DevStack, the tests are failing, indicating that the service driver is not unique. It appears that parse_service_provider_opt() is loading the service driver based on what is in neutron_vpnaas.conf. Then, the tests are also loading the service driver and neutrons add_provider() is throwing an exception indicating that there is not a unique driver (which there now is not). The work-around for unit tests, is to comment out the service_providers entry for VPN in neutron_vpnaas.conf, or remove the file. There is no work-around for the functional tests. ** Affects: neutron Importance: Undecided Status: New ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1422895 Title: parse_service_provider_opt affecting VPN UTs Status in OpenStack Neutron (virtual network service): New Bug description: For VPN functional tests or unit test that are run after stacking with DevStack, the tests are failing, indicating that the service driver is not unique. It appears that parse_service_provider_opt() is loading the service driver based on what is in neutron_vpnaas.conf. Then, the tests are also loading the service driver and neutrons add_provider() is throwing an exception indicating that there is not a unique driver (which there now is not). The work-around for unit tests, is to comment out the service_providers entry for VPN in neutron_vpnaas.conf, or remove the file. There is no work-around for the functional tests. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1422895/+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 1427858] [NEW] VPNaaS: Fix UT breakage in neutron-vpnaas
Public bug reported: The commit for namespaces in neutron (under review 147744, which is approved, but awaiting upstreaming), changes the router creation logic. This breaks the neutron-vpnaas unit tests. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1427858 Title: VPNaaS: Fix UT breakage in neutron-vpnaas Status in OpenStack Neutron (virtual network service): In Progress Bug description: The commit for namespaces in neutron (under review 147744, which is approved, but awaiting upstreaming), changes the router creation logic. This breaks the neutron-vpnaas unit tests. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1427858/+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 1430967] [NEW] Remove get_snat_ns_name from dvr.py
Public bug reported: This method was needed, until VPN has been updated to use the DVR router object snat_namespace.name attribute. Also fixing PEP8 error in event_observer.py. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1430967 Title: Remove get_snat_ns_name from dvr.py Status in OpenStack Neutron (virtual network service): In Progress Bug description: This method was needed, until VPN has been updated to use the DVR router object snat_namespace.name attribute. Also fixing PEP8 error in event_observer.py. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1430967/+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 1433552] [NEW] Refactor *aaS and L3 agent interaction
Public bug reported: This bug is to do some cleanup refactoring of the *aaS and L3 agent interactions. It has several goals: 1) Switch from the L3EventObservers to the CallbacksManager mechanism for all *aaS agents. 2) Remove/reduce the dependency of *aaS agents on the L3 agent 3) Eliminate the AdvancedService base class 4) Eliminate the *(now) unused advanced_service.py and event_observer.py modules. This will reduce from having two separate mechanisms to manage callbacks from the L3 agent to the *aaS agents and their device drivers. (#1, #4) It also simplifies the code. Instead of the classes, like VPNService, from handling callbacks, forwarding calls to L3 agent to get router info (removed in previous refactoring), maintaining another copy of L3 agent and config settings( #2), and loading device drivers, the classes can focus just on driver loading. Will no longer need a class hierarchy for this as well (#3) ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => In Progress ** Summary changed: - Refactor *aaS and L2 agent interaction + Refactor *aaS and L3 agent interaction -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1433552 Title: Refactor *aaS and L3 agent interaction Status in OpenStack Neutron (virtual network service): In Progress Bug description: This bug is to do some cleanup refactoring of the *aaS and L3 agent interactions. It has several goals: 1) Switch from the L3EventObservers to the CallbacksManager mechanism for all *aaS agents. 2) Remove/reduce the dependency of *aaS agents on the L3 agent 3) Eliminate the AdvancedService base class 4) Eliminate the *(now) unused advanced_service.py and event_observer.py modules. This will reduce from having two separate mechanisms to manage callbacks from the L3 agent to the *aaS agents and their device drivers. (#1, #4) It also simplifies the code. Instead of the classes, like VPNService, from handling callbacks, forwarding calls to L3 agent to get router info (removed in previous refactoring), maintaining another copy of L3 agent and config settings( #2), and loading device drivers, the classes can focus just on driver loading. Will no longer need a class hierarchy for this as well (#3) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1433552/+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 1438259] [NEW] VPNaaS: remove dependency on Neutron in UT
Public bug reported: Some of the driver unit tests mock execute() from Neutron, which creates a (brittle) dependency (as seen by a recent breakage). The dependency can be removed, but mocking higher up, from within the *Swan process _execute() method. In addition, there are some unit tests that are not active, due to missing test base class. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1438259 Title: VPNaaS: remove dependency on Neutron in UT Status in OpenStack Neutron (virtual network service): In Progress Bug description: Some of the driver unit tests mock execute() from Neutron, which creates a (brittle) dependency (as seen by a recent breakage). The dependency can be removed, but mocking higher up, from within the *Swan process _execute() method. In addition, there are some unit tests that are not active, due to missing test base class. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1438259/+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 1441244] [NEW] VPNaaS: Remove check for bash scripts
Public bug reported: Like the change in Neutron (1440824), remove the check for bash script usage. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1441244 Title: VPNaaS: Remove check for bash scripts Status in OpenStack Neutron (virtual network service): In Progress Bug description: Like the change in Neutron (1440824), remove the check for bash script usage. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1441244/+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 1441632] [NEW] FWaaS: Remove checks for bash scripts
Public bug reported: Like the change in Neutron (14408244), remove the check for bash script. ** Affects: neutron Importance: Low Assignee: Paul Michali (pcm) Status: In Progress ** Tags: fwaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1441632 Title: FWaaS: Remove checks for bash scripts Status in OpenStack Neutron (virtual network service): In Progress Bug description: Like the change in Neutron (14408244), remove the check for bash script. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1441632/+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 1441783] [NEW] VPNaaS: Non-stacking functional jobs
Public bug reported: In a fashion similar to Neutron, the functional tests jobs (dsvm- functional, dsvm-functional-sswan) should be converted to only prepare the environment, using DevStack, and not to actually stack (starting up all the processes). This will permit better performance for the functional tests and make the jobs more consistent to what is done in the Neutron repo. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1441783 Title: VPNaaS: Non-stacking functional jobs Status in OpenStack Neutron (virtual network service): In Progress Bug description: In a fashion similar to Neutron, the functional tests jobs (dsvm- functional, dsvm-functional-sswan) should be converted to only prepare the environment, using DevStack, and not to actually stack (starting up all the processes). This will permit better performance for the functional tests and make the jobs more consistent to what is done in the Neutron repo. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1441783/+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 1441788] [NEW] VPNaaS: Fedora support for StrongSwan
Public bug reported: In early testing, I was unable to create a VPN connection using Fedora Release 12 and StrongSwan driver. Found out from StrongSwan IRC folks these issues: A) Unlike Ubuntu, both Strongswan and LibreSwan can be installed at once B) Fedora uses the process name "strongswan", whereas Ubuntu uses "ipsec". The "ipsec" process is for LIbreSwan, under Fedora. C) The may be some sensitivity to tabs, in the config file, for Fedora (use only one?) The StrongSwan folks also mentioned about a issue, where one needs a kernel with support for XFRM and namespaces. They stated that there can be problems with passing traffic. They indicated it was a kernel issue and therefore applied to all Swan flavors. Research is needed to see if both Ubuntu and Fedora kernels have this support. Currently, we don't see an issue with Ubuntu, but should verify the kernel for all target operating systems. ** Affects: neutron Importance: Undecided Status: New ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1441788 Title: VPNaaS: Fedora support for StrongSwan Status in OpenStack Neutron (virtual network service): New Bug description: In early testing, I was unable to create a VPN connection using Fedora Release 12 and StrongSwan driver. Found out from StrongSwan IRC folks these issues: A) Unlike Ubuntu, both Strongswan and LibreSwan can be installed at once B) Fedora uses the process name "strongswan", whereas Ubuntu uses "ipsec". The "ipsec" process is for LIbreSwan, under Fedora. C) The may be some sensitivity to tabs, in the config file, for Fedora (use only one?) The StrongSwan folks also mentioned about a issue, where one needs a kernel with support for XFRM and namespaces. They stated that there can be problems with passing traffic. They indicated it was a kernel issue and therefore applied to all Swan flavors. Research is needed to see if both Ubuntu and Fedora kernels have this support. Currently, we don't see an issue with Ubuntu, but should verify the kernel for all target operating systems. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1441788/+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 1441789] [NEW] VPNaaS: Confirm OpenSwan <--> StrongSwan interop
Public bug reported: Some early testing was showing a problem getting VPN IPSec connection up and passing traffic, when using StrongSwan on one end and OpenSwan on the other end (using the same, default, configuration). Worked fine, when the same Swan flavor was used on each end. Need to investigate into whether or not this works, and if it does not work, research into the root cause. ** Affects: neutron Importance: Undecided Status: New ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1441789 Title: VPNaaS: Confirm OpenSwan <--> StrongSwan interop Status in OpenStack Neutron (virtual network service): New Bug description: Some early testing was showing a problem getting VPN IPSec connection up and passing traffic, when using StrongSwan on one end and OpenSwan on the other end (using the same, default, configuration). Worked fine, when the same Swan flavor was used on each end. Need to investigate into whether or not this works, and if it does not work, research into the root cause. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1441789/+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 1445052] [NEW] VPNaaS: Revise functional jobs to only setup DevStack
Public bug reported: In a manner similar to what is done for Neutron, the two functional jobs need to be modified to only set up DevStack, and not actually run DevStack. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1445052 Title: VPNaaS: Revise functional jobs to only setup DevStack Status in OpenStack Neutron (virtual network service): In Progress Bug description: In a manner similar to what is done for Neutron, the two functional jobs need to be modified to only set up DevStack, and not actually run DevStack. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1445052/+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 1445056] [NEW] VPNaaS Functional job test module discovery
Public bug reported: With the current functional job setups, if there are import errors in test modules, the errors will be silently ignored and tests not invoked. Apparently there is an issue with the unittest package and import errors. Because VPNaaS has two reference driver implementations currently, and they each require a different test setup and have test cases that differ, there are two functional jobs, of which each tests different modules. Need to switch to unittest2, or modify the method used to discovery modules to run in the functional jobs. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1445056 Title: VPNaaS Functional job test module discovery Status in OpenStack Neutron (virtual network service): In Progress Bug description: With the current functional job setups, if there are import errors in test modules, the errors will be silently ignored and tests not invoked. Apparently there is an issue with the unittest package and import errors. Because VPNaaS has two reference driver implementations currently, and they each require a different test setup and have test cases that differ, there are two functional jobs, of which each tests different modules. Need to switch to unittest2, or modify the method used to discovery modules to run in the functional jobs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1445056/+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 1316748] Re: VPNaaS : VPN service and VPN connection goes in pending_create state , when user tries to create second VPN service for router and second subnet of the router.
>From what I can tell, this is an invalid bug, as multiple services are not supported for a single router. It is 1:1. changing 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/1316748 Title: VPNaaS : VPN service and VPN connection goes in pending_create state , when user tries to create second VPN service for router and second subnet of the router. Status in OpenStack Neutron (virtual network service): Invalid Bug description: Please refer to the topology diagram attached Steps to Reproduce: 1. Create a site to site onto two separate openstack setup (site1 and site2) (refer attached scenario diagram with sub1 and sub3) 2. Create a subnet and associated to the site1 router and create a vpnservice with the new subnet (refer attached scenario diagram sub2 ) 3. Create a third site with the new vpnservice ,ike policy and ipsec policy. 4. Onto the site3 Create a ipsecsite connection with the peercidr as the newsubnet (sub2 )created in step 2. 5 Now a new tunnel is created between the site3(sub4) and site 1 (sub2). 6.Check the status if the vpn ipsec site connection list. is show pending creating after the site 3 creation, vpnl +--++---+++---++ | id | name | peer_address | peer_cidrs | route_mode | auth_mode | status | +--++---+++---++ | 9ee32e09-7ca3-4483-a874-90ac760a03c0 | vpnconnection4 | $peer_address2 | "10.10.4.0/24" | static | psk | PENDING_CREATE | | e2dd8cb7-31ef-4d73-ba03-58576ad07f52 | vpnconnection1 | $peer_address1 | "10.10.3.0/24" | static | psk | ACTIVE | +--++---+++---++ Actual Results: VPN service and VPN connection go in pending_create state , when user tries to create second VPN service for router and second subnet of the router. Expected Results: VPN service and VPN connection should be in active state when user tries to create second VPN service for router and second subnet of the router. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1316748/+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 1318550] Re: Vpnaas: Vpn_agent is not able to handle two vpn service object for the same router.
This is, by design, not supported. The service and router must be 1:1. A blueprint would need to be submitted to change the design, IMO. Changing to 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/1318550 Title: Vpnaas: Vpn_agent is not able to handle two vpn service object for the same router. Status in OpenStack Neutron (virtual network service): Invalid Bug description: neutron net-create ext-net1 --router:external=True neutron subnet-create --allocation-pool start=192.142.0.60,end=192.142.0.100 --gateway 192.142.0.1 ext-net1 192.142.0.0/16 --enable_dhcp=False step 1=> neutron net-create net1 neutron subnet-create net1 10.10.1.0/24 --name sub1 neutron router-create r1 neutron router-interface-add r1 sub1 neutron router-gateway-set r1 ext-net1 neutron net-create net2 neutron subnet-create net2 10.10.2.0/24 --name sub2 neutron router-create r2 neutron router-interface-add r2 sub2 neutron router-gateway-set r2 ext-net1 neutron vpn-ikepolicy-create ikepolicy1 neutron vpn-ipsecpolicy-create ipsecpolicy1 neutron vpn-service-create --name myvpn1 --description "My vpn service" r1 sub1 neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id myvpn1 --ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1 --peer-address 192.142.0.61 --peer-id 192.142.0.61 --peer-cidr 10.10.2.0/24 --psk secret neutron vpn-ikepolicy-create ikepolicy2 neutron vpn-ipsecpolicy-create ipsecpolicy2 neutron vpn-service-create --name myvpn2 --description "My vpn service" r2 sub2 neutron ipsec-site-connection-create --name vpnconnection2 --vpnservice-id myvpn2 --ikepolicy-id ikepolicy2 --ipsecpolicy-id ipsecpolicy2 --peer-address 192.142.0.60 --peer-id 192.142.0.60 --peer-cidr 10.10.1.0/24 --psk secret create one more network on site1 net3 with subnet 5.5.5.0/24 sub3 create a network on site2 net4 with subnet 8.8.8.0/24 sub4 create a service objects myvpn3 with r1 and sub3 create a service objects myvpn4 with r2 and sub4 create a ipsecsite connection neutron ipsec-site-connection-create --name vpnconnection3 --vpnservice-id myvpn3 --ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1 --peer-address 192.142.0.61 --peer-id 192.142.0.61 --peer-cidr 5.5.5.0/24 --psk secret neutron ipsec-site-connection-create --name vpnconnection4 --vpnservice-id myvpn2 --ikepolicy-id ikepolicy2 --ipsecpolicy-id ipsecpolicy2 --peer-address 192.142.0.60 --peer-id 192.142.0.60 --peer-cidr 8.8.8.0/24 --psk secret ipsecsite connection with vpnconnection3 and vpnconnection4 always goes into pending create state. basically i am trying to bind two vpn service objects with one routerid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1318550/+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 1316726] Re: VPNAAS :IPSEC Policy on peer site mismatched still the ipsec sitec connection shows active state
AFAIK, the IPSec connection is auto-negotiated and will use the IKE and IPSec policy that is compatible with each end (in this case negotiating down to aes-128. This is not a bug, as far as I know. Will mark as invalid. ** 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/1316726 Title: VPNAAS :IPSEC Policy on peer site mismatched still the ipsec sitec connection shows active state Status in OpenStack Neutron (virtual network service): Invalid Bug description: Steps to Reproduce: 1. Create vpn site with one ipsec policy with encryption_algorithm aes-256 and other site as aes-128. 2. Create the ipsec-siteconnection and other operation like vpn-services and ike policy onto both the sites. 3. Check the status of vpn service +--+--+--++ | id | name | router_id | status | +--+--+--++ | 530c3dfb-9224-403c-b285-a224c9a7036d | vpn1 | cd288ec1-cad5-48e4-a402-882103ac6ec5 | ACTIVE | | 77d0b36f-35e3-46d9-8d33-1b989092cecf | vpn2 | 224c35b8-01b3-4e9b-a148-2751840a1b18 | ACTIVE | +--+--+--++ 4. Check the status of ipsec site connection. +--+---+--+++---++ | id | name | peer_address | peer_cidrs | route_mode | auth_mode | status | +--+---+--+++---++ | a158f5d5-128e-47ba-9260-34dc9ff315b0 | site1 | $peer_address2 | "$peer_cidrs2" | static | psk | ACTIVE | | a9486296-bc36-439b-b0a8-4d4b0417486d | site2 | $peer_address1 | "$peer_cidrs1" | static | psk | ACTIVE | +--+---+--+++---++ 5. List the ike policy +--+--++--+-++ | id | name | auth_algorithm | encryption_algorithm | ike_version | pfs| +--+--++--+-++ | b04d74ad-ec1f-44b0-8ae6-802872bf4ca0 | IKE1 | sha1 | aes-256 | v1 | group5 | | e5be37ec-9888-46a7-b884-083b5b5336aa | IKE2 | sha1 | aes-256 | v1 | group5 | +--+--++--+-++ 6. List the ipsec-policy +--+++--++ | id | name | auth_algorithm | encryption_algorithm | pfs| +--+++--++ | 12c9db3b-8122-4e1e-9aad-8e6e87225a1f | IPSEC1 | sha1 | aes-128 | group5 | | d38bba51-ecdd-43ef-822c-4f1c86507c9a | IPSEC2 | sha1 | aes-256 | group5 | +--+++--++ Actual Results: Ipsec site connection show as active with mismatched version of encryption algorithm in the ipsecpolicy Ping across the sites also happening Expected Results: Ipsec site connection should show as down state since mismatched version of encryption algorithm in the ipsecpolicy is provide To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1316726/+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 1360435] Re: Service Type Manager singleton needs protection
The service type manager mechanism has been abandoned and will be replaced in the future by a "Flavor" mechanism, so no sense in providing additional improvements here. ** 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/1360435 Title: Service Type Manager singleton needs protection Status in OpenStack Neutron (virtual network service): Invalid Bug description: During review of some UT code for VPNaaS (https://review.openstack.org/110432) it was found that the tests were failing in Jenkins, with a cryptic StringException and no traceback. The root cause of that was found to be that two test classes were instantiating a VPN plugin, which in turn calls the Service Type Manager's load_driver() standalone method. This method will create/get an instance of the service type manager. As part of that, it will call load_conf, which creates a ProviderConfiguration object and reads in a configuration multistring into a dictionary. When multiple tests run in parallel, it appears that the dictionary can be munged by concurrent access during construction. For 110432, the workaround was to create a unique (non-singleton) instance of the service type manager. However, we shuld probably lock the access to this load_conf() method (change the singleton design, or don't use a class). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1360435/+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 1240537] Re: VPNaaS client support for service type framework
Service Type Framework effort was abandoned and will be replaced in the
future by the "flavor" framework. This will not be done.
** Changed in: neutron
Status: In Progress => Invalid
** Changed in: neutron
Assignee: Paul Michali (pcm) => (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/1240537
Title:
VPNaaS client support for service type framework
Status in OpenStack Neutron (virtual network service):
Invalid
Bug description:
There is a blueprint for adding service type framework support to
VPNaaS:
https://blueprints.launchpad.net/neutron/+spec/vpn-service-types-
integration
There is a (currently abandoned, but needs to be rebased for Icehouse)
review under:
https://review.openstack.org/#/c/41827/
To go along with the service changes, we need client side
modifications to allow specification of provider.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1240537/+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 1282855] Re: Add httmock to test-requirements.txt and update requests -> 2.1.0
** 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/1282855 Title: Add httmock to test-requirements.txt and update requests -> 2.1.0 Status in OpenStack Neutron (virtual network service): Invalid Bug description: To enhance unit testing of REST API code I'd like to add this PyPI package to test-requirements.txt. I had this as part of my Icehouse-3 review for VPNaaS device driver, in requirements.txt, but it was failing Jenkins as this is not on the master requirements. Since it is only used for unit testing, it was suggested to place this in test-requirements.txt. So, I'm going to push a separate review just for this file, so I can use it for other commits. Ref: https://pypi.python.org/pypi/httmock/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1282855/+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 1420139] Re: VPNPluginDbTestCase unit test failed with upstream submit I16b5e5b2
Problem with driver loading in new repo was resolved, so this is no
longer a failure. Marked as invalid.
** 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/1420139
Title:
VPNPluginDbTestCase unit test failed with upstream submit I16b5e5b2
Status in OpenStack Neutron (virtual network service):
Invalid
Bug description:
today I found the unit test case VPNPluginDbTestCase doesn't work as
below error log shows.
I debug the code and find the reason, that's because the upstream
submit I16b5e5b2 (
https://review.openstack.org/#/c/151375/7/neutron/services/provider_configuration.py
), it trys to read services_provider configrations items in
neutron-{service}.conf file.
on the other hand, VPNPluginDbTestCase still try to override
service_provider, so error 'Invalid: Driver
neutron_vpnaas.services.vpn.service_drivers.ipsec.IPsecVPNDriver is
not unique across providers' is throwed.
if not vpnaas_provider:
vpnaas_provider = (
constants.VPN +
':vpnaas:neutron_vpnaas.services.vpn.'
'service_drivers.ipsec.IPsecVPNDriver:default')
cfg.CONF.set_override('service_provider',
[vpnaas_provider],
'service_providers')
Traceback (most recent call last):
File
"/bak/openstack/neutron-vpnaas/neutron_vpnaas/tests/unit/services/vpn/test_vpnaas_driver_plugin.py",
line 47, in setUp
vpnaas_plugin=VPN_DRIVER_CLASS)
File
"/bak/openstack/neutron-vpnaas/neutron_vpnaas/tests/unit/db/vpn/test_db_vpnaas.py",
line 437, in setUp
service_plugins=service_plugins
File "/bak/openstack/neutron-vpnaas/neutron_vpnaas/tests/base.py", line 53,
in setUp
plugin, service_plugins, ext_mgr)
File "/bak/openstack/neutron/neutron/tests/unit/test_db_plugin.py", line
120, in setUp
self.api = router.APIRouter()
File "/bak/openstack/neutron/neutron/api/v2/router.py", line 74, in __init__
plugin = manager.NeutronManager.get_plugin()
File "/bak/openstack/neutron/neutron/manager.py", line 222, in get_plugin
return weakref.proxy(cls.get_instance().plugin)
File "/bak/openstack/neutron/neutron/manager.py", line 216, in get_instance
cls._create_instance()
File
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line
431, in inner
return f(*args, **kwargs)
File "/bak/openstack/neutron/neutron/manager.py", line 202, in
_create_instance
cls._instance = cls()
File "/bak/openstack/neutron/neutron/manager.py", line 128, in __init__
self._load_service_plugins()
File "/bak/openstack/neutron/neutron/manager.py", line 175, in
_load_service_plugins
provider)
File "/bak/openstack/neutron/neutron/manager.py", line 143, in
_get_plugin_instance
return plugin_class()
File "/bak/openstack/neutron-vpnaas/neutron_vpnaas/services/vpn/plugin.py",
line 44, in __init__
constants.VPN, self)
File "/bak/openstack/neutron/neutron/services/service_base.py", line 64, in
load_drivers
service_type_manager = sdb.ServiceTypeManager.get_instance()
File "/bak/openstack/neutron/neutron/db/servicetype_db.py", line 41, in
get_instance
cls._instance = cls()
File "/bak/openstack/neutron/neutron/db/servicetype_db.py", line 45, in
__init__
self._load_conf()
File "/bak/openstack/neutron/neutron/db/servicetype_db.py", line 49, in
_load_conf
pconf.parse_service_provider_opt())
File "/bak/openstack/neutron/neutron/services/provider_configuration.py",
line 139, in __init__
self.add_provider(prov)
File "/bak/openstack/neutron/neutron/services/provider_configuration.py",
line 160, in add_provider
self._ensure_driver_unique(provider['driver'])
File "/bak/openstack/neutron/neutron/services/provider_configuration.py",
line 147, in _ensure_driver_unique
raise n_exc.Invalid(msg)
Invalid: Driver
neutron_vpnaas.services.vpn.service_drivers.ipsec.IPsecVPNDriver is not unique
across providers
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1420139/+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 1446807] [NEW] Enhance configure_for_func_testing.sh for other repo use
Public bug reported: For the *aaS repos to run functional tests, the same setup is needed as is provided by configure_for_func_testing.sh in Neutron, with these differences: - The rootwrap sudoers need to point to the *aaS repo functional job's .tox area. - Some repos (e.g. VPN) have more than one functional test job, so this needs to be provided. Everything else is the same. The purpose of this bug, is to modify the script, so that it can be called from other repos. The proposal is to add another argument, when using the script locally, so that the functional job can be specified. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1446807 Title: Enhance configure_for_func_testing.sh for other repo use Status in OpenStack Neutron (virtual network service): In Progress Bug description: For the *aaS repos to run functional tests, the same setup is needed as is provided by configure_for_func_testing.sh in Neutron, with these differences: - The rootwrap sudoers need to point to the *aaS repo functional job's .tox area. - Some repos (e.g. VPN) have more than one functional test job, so this needs to be provided. Everything else is the same. The purpose of this bug, is to modify the script, so that it can be called from other repos. The proposal is to add another argument, when using the script locally, so that the functional job can be specified. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1446807/+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 1448245] [NEW] VPNaaS UTs broken in neutron/tests/unit/extensions/test_l3.py
Public bug reported: Recently, VPNaaS repo UTs are failing in tests that inherit from Neutron tests. The tests worked 4/22/2015 and are broken on 4/24/2015. Will try to bisect to find change in Neutron that affects tests. Example failure: 2015-04-24 06:40:39.838 | Captured pythonlogging: 2015-04-24 06:40:39.838 | ~~~ 2015-04-24 06:40:39.838 | 2015-04-24 06:40:38,704ERROR [neutron.api.extensions] Extension path 'neutron/tests/unit/extensions' doesn't exist! 2015-04-24 06:40:39.838 | 2015-04-24 06:40:39.838 | 2015-04-24 06:40:39.838 | Captured traceback: 2015-04-24 06:40:39.838 | ~~~ 2015-04-24 06:40:39.838 | Traceback (most recent call last): 2015-04-24 06:40:39.838 | File "neutron_vpnaas/tests/unit/db/vpn/test_vpn_db.py", line 886, in test_delete_router_interface_in_use_by_vpnservice 2015-04-24 06:40:39.839 | expected_code=webob.exc. 2015-04-24 06:40:39.839 | File "/home/jenkins/workspace/gate-neutron-vpnaas-python27/.tox/py27/src/neutron/neutron/tests/unit/extensions/test_l3.py", line 401, in _router_interface_action 2015-04-24 06:40:39.839 | self.assertEqual(res.status_int, expected_code, msg) 2015-04-24 06:40:39.839 | File "/home/jenkins/workspace/gate-neutron-vpnaas-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 350, in assertEqual 2015-04-24 06:40:39.839 | self.assertThat(observed, matcher, message) 2015-04-24 06:40:39.839 | File "/home/jenkins/workspace/gate-neutron-vpnaas-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 435, in assertThat 2015-04-24 06:40:39.839 | raise mismatch_error 2015-04-24 06:40:39.839 | testtools.matchers._impl.MismatchError: 200 != 409 2015-04-24 06:40:39.839 | 2015-04-24 06:40:39.839 | 2015-04-24 06:40:39.839 | Captured pythonlogging: 2015-04-24 06:40:39.839 | ~~~ 2015-04-24 06:40:39.840 | 2015-04-24 06:40:38,694 INFO [neutron.manager] Loading core plugin: neutron_vpnaas.tests.unit.db.vpn.test_vpn_db.TestVpnCorePlugin 2015-04-24 06:40:39.840 | 2015-04-24 06:40:38,694 INFO [neutron.manager] Service L3_ROUTER_NAT is supported by the core plugin 2015-04-24 06:40:39.840 | 2015-04-24 06:40:38,694 INFO [neutron.manager] Loading Plugin: neutron_vpnaas.services.vpn.plugin.VPNPlugin 2015-04-24 06:40:39.840 | 2015-04-24 06:40:38,704ERROR [neutron.api.extensions] Extension path 'neutron/tests/unit/extensions' doesn't exist! ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1448245 Title: VPNaaS UTs broken in neutron/tests/unit/extensions/test_l3.py Status in OpenStack Neutron (virtual network service): In Progress Bug description: Recently, VPNaaS repo UTs are failing in tests that inherit from Neutron tests. The tests worked 4/22/2015 and are broken on 4/24/2015. Will try to bisect to find change in Neutron that affects tests. Example failure: 2015-04-24 06:40:39.838 | Captured pythonlogging: 2015-04-24 06:40:39.838 | ~~~ 2015-04-24 06:40:39.838 | 2015-04-24 06:40:38,704ERROR [neutron.api.extensions] Extension path 'neutron/tests/unit/extensions' doesn't exist! 2015-04-24 06:40:39.838 | 2015-04-24 06:40:39.838 | 2015-04-24 06:40:39.838 | Captured traceback: 2015-04-24 06:40:39.838 | ~~~ 2015-04-24 06:40:39.838 | Traceback (most recent call last): 2015-04-24 06:40:39.838 | File "neutron_vpnaas/tests/unit/db/vpn/test_vpn_db.py", line 886, in test_delete_router_interface_in_use_by_vpnservice 2015-04-24 06:40:39.839 | expected_code=webob.exc. 2015-04-24 06:40:39.839 | File "/home/jenkins/workspace/gate-neutron-vpnaas-python27/.tox/py27/src/neutron/neutron/tests/unit/extensions/test_l3.py", line 401, in _router_interface_action 2015-04-24 06:40:39.839 | self.assertEqual(res.status_int, expected_code, msg) 2015-04-24 06:40:39.839 | File "/home/jenkins/workspace/gate-neutron-vpnaas-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 350, in assertEqual 2015-04-24 06:40:39.839 | self.assertThat(observed, matcher, message) 2015-04-24 06:40:39.839 | File "/home/jenkins/workspace/gate-neutron-vpnaas-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 435, in assertThat 2015-04-24 06:40:39.839 | raise mismatch_error 20
[Yahoo-eng-team] [Bug 1459423] [NEW] VPNaaS: Allow multiple local subnets for IPSec
Public bug reported: Currently, VPNaaS IPsec site to site connections may be created with one or more peer (right side) subnets specified (as CIDRs). However, for the local (left) side, only a single subnet can be specified. The reference OpenSwan/StrongSwan implementations will support multiple subnets on the local side, and this RFE is proposing to provide that support. This requires the following changes: REST API === Modify the API to not specify the local subnet on the VPN service create API, and instead, require the local subnet(s) to be specified on the IPSec connection API, in a similar fashion to what is done for remote CIDRs. Validation can make sure that there is at least one local CIDR, and all subnets in the connection are using the same IP version. This involves a backward incompatible API change, so will go to v2.0, and provide support for 1.0 in the code base. NEUTRON CLIENT == The CLI client could change from: neutron vpn-service-create ROUTER SUBNET neutron ipsec-site-connection-create ... --vpnservice-id VPNSERVICE --ikepolicy-id IKEPOLICY --ipsecpolicy-id IPSECPOLICY --peer-address PEER_ADDRESS --peer-id PEER_ID --peer-cidr PEER_CIDRS --psk PSK to: neutron vpn-service-create ROUTER neutron ipsec-site-connection-create ... --vpnservice-id VPNSERVICE --ikepolicy-id IKEPOLICY --ipsecpolicy-id IPSECPOLICY --peer-address PEER_ADDRESS --peer-id PEER_ID --peer-cidr PEER_CIDRS --local-cidr LOCAL_CIDRS --psk PSK DATABASE = The local CIDRs could be added to the IPSec connection table. Migration needed for this change. DRIVER == Besides passing the local CIDR information from service to device driver (along with existing info), the device driver needs to apply this information to the *Swan template in the same manner as is done for peer CIDR information. DOCS Update the API reference pages for VPN service create and IPSec connection create. Update existing Wiki how-to pages. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1459423 Title: VPNaaS: Allow multiple local subnets for IPSec Status in OpenStack Neutron (virtual network service): New Bug description: Currently, VPNaaS IPsec site to site connections may be created with one or more peer (right side) subnets specified (as CIDRs). However, for the local (left) side, only a single subnet can be specified. The reference OpenSwan/StrongSwan implementations will support multiple subnets on the local side, and this RFE is proposing to provide that support. This requires the following changes: REST API === Modify the API to not specify the local subnet on the VPN service create API, and instead, require the local subnet(s) to be specified on the IPSec connection API, in a similar fashion to what is done for remote CIDRs. Validation can make sure that there is at least one local CIDR, and all subnets in the connection are using the same IP version. This involves a backward incompatible API change, so will go to v2.0, and provide support for 1.0 in the code base. NEUTRON CLIENT == The CLI client could change from: neutron vpn-service-create ROUTER SUBNET neutron ipsec-site-connection-create ... --vpnservice-id VPNSERVICE --ikepolicy-id IKEPOLICY --ipsecpolicy-id IPSECPOLICY --peer-address PEER_ADDRESS --peer-id PEER_ID --peer-cidr PEER_CIDRS --psk PSK to: neutron vpn-service-create ROUTER neutron ipsec-site-connection-create ... --vpnservice-id VPNSERVICE --ikepolicy-id IKEPOLICY --ipsecpolicy-id IPSECPOLICY --peer-address PEER_ADDRESS
[Yahoo-eng-team] [Bug 1459427] [NEW] VPNaaS: Certificate support for IPSec
Public bug reported: Since Barbican provides certificate management/storage, and LBaaS has successfully used the certificates, this RFE proposes to provide certificate support for VPN IPSec site-to-site connections. The expectation is that the user would use Barbican to create the certificate, and then reference the certificate when creating an IPSec connection. This would require an REST/CLI API change to accept certificate ID vs PSK, minor database change to store the certificate ID, *Swan driver modifications to apply the certificate to the template, and unit/functional test updates for these changes. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1459427 Title: VPNaaS: Certificate support for IPSec Status in OpenStack Neutron (virtual network service): New Bug description: Since Barbican provides certificate management/storage, and LBaaS has successfully used the certificates, this RFE proposes to provide certificate support for VPN IPSec site-to-site connections. The expectation is that the user would use Barbican to create the certificate, and then reference the certificate when creating an IPSec connection. This would require an REST/CLI API change to accept certificate ID vs PSK, minor database change to store the certificate ID, *Swan driver modifications to apply the certificate to the template, and unit/functional test updates for these changes. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1459427/+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 1464387] [NEW] VPNaaS: Provide local tunnel IP for service
Public bug reported: To support the case where the VPN service is provided outside of the Neutron router (appliance, VM, separate S/W, H/W, etc), the following changes should be made: - Add a field to VPN service table for the local tunnel IP - When the VPN service GET REST API is called, return the IP address - When creating a VPN service, populate the database field with the GW IP of the Neutron router (for current implementations). - Update UTs for this functionality. This IP information could be used by orchestration tools when setting up two ends of a VPN IPSec connection. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: New ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1464387 Title: VPNaaS: Provide local tunnel IP for service Status in OpenStack Neutron (virtual network service): New Bug description: To support the case where the VPN service is provided outside of the Neutron router (appliance, VM, separate S/W, H/W, etc), the following changes should be made: - Add a field to VPN service table for the local tunnel IP - When the VPN service GET REST API is called, return the IP address - When creating a VPN service, populate the database field with the GW IP of the Neutron router (for current implementations). - Update UTs for this functionality. This IP information could be used by orchestration tools when setting up two ends of a VPN IPSec connection. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1464387/+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 1381221] [NEW] VPNaaS Cisco cleanup test code
Public bug reported: There is unused arguments in a mock method, and duplication of constants, in the Cisco VPNaaS unit test files. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1381221 Title: VPNaaS Cisco cleanup test code Status in OpenStack Neutron (virtual network service): In Progress Bug description: There is unused arguments in a mock method, and duplication of constants, in the Cisco VPNaaS unit test files. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1381221/+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 1281357] [NEW] IntegrityError on Nicira get_vcns_router_binding
Public bug reported:
Neutron gate for py27 is failing with this error...
2014-02-17 17:22:49.452 | 2014-02-17 17:22:49,107ERROR
[neutron.api.rpc.agentnotifiers.dhcp_rpc_agent_api] No DHCP agents are
associated with network '35b65fc4-9904-4bcc-9d94-2a5af567e910'. Unable to send
notification for 'network_create_end' with payload: {'network': {'status':
'ACTIVE', 'subnets': [], 'name': u'net1', 'admin_state_up': True, 'tenant_id':
u'92dae896-947e-4dd8-b7bc-8b7652eeea3f', 'shared': False,
'port_security_enabled': True, 'id': '35b65fc4-9904-4bcc-9d94-2a5af567e910'}}
2014-02-17 17:22:49.452 | 2014-02-17 17:22:49,113ERROR
[neutron.plugins.nicira.vshield.tasks.tasks] Task
Task-deploying-router1-c71b0936-b0db-441f-81eb-871722e43310-1fb1cf62-97f8-11e3-9688-bc764e050f7e
encountered exception in > at state 3
2014-02-17 17:22:49.452 | Traceback (most recent call last):
2014-02-17 17:22:49.452 | File
"neutron/plugins/nicira/vshield/tasks/tasks.py", line 98, in _invoke_monitor
2014-02-17 17:22:49.452 | func(self)
2014-02-17 17:22:49.453 | File
"neutron/plugins/nicira/NeutronServicePlugin.py", line 1566, in
edge_deploy_result
2014-02-17 17:22:49.453 | context.session, neutron_router_id)
2014-02-17 17:22:49.454 | File "neutron/plugins/nicira/dbexts/vcns_db.py",
line 43, in get_vcns_router_binding
2014-02-17 17:22:49.454 | filter_by(router_id=router_id).first())
2014-02-17 17:22:49.454 | File
"/home/jenkins/workspace/gate-neutron-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py",
line 2156, in first
2014-02-17 17:22:49.454 | ret = list(self[0:1])
2014-02-17 17:22:49.455 | File
"/home/jenkins/workspace/gate-neutron-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py",
line 2023, in __getitem__
2014-02-17 17:22:49.455 | return list(res)
2014-02-17 17:22:49.455 | File
"/home/jenkins/workspace/gate-neutron-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py",
line 2226, in __iter__
2014-02-17 17:22:49.456 | self.session._autoflush()
2014-02-17 17:22:49.456 | File
"/home/jenkins/workspace/gate-neutron-python27/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py",
line 1127, in _autoflush
2014-02-17 17:22:49.456 | self.flush()
2014-02-17 17:22:49.457 | File
"neutron/openstack/common/db/sqlalchemy/session.py", line 542, in _wrap
2014-02-17 17:22:49.457 | raise exception.DBError(e)
2014-02-17 17:22:49.457 | DBError: (IntegrityError) foreign key constraint
failed u'INSERT INTO neutron_nsx_network_mappings (neutron_id, nsx_id) VALUES
(?, ?)' ('35b65fc4-9904-4bcc-9d94-2a5af567e910',
u'a035e43d-91b3-479e-a0d0-b98b7c4b29ab')
2014-02-17 17:22:49.458 | 2014-02-17 17:22:49,135ERROR
[neutron.api.rpc.agentnotifiers.dhcp_rpc_agent_api] No DHCP agents are
associated with network 'e970f0a0-d222-4a37-91c8-00eaefaee61b'. Unable to send
notification for 'network_create_end' with payload: {'network': {'status':
'ACTIVE', 'subnets': [], 'name': u'net1', 'admin_state_up': True, 'tenant_id':
u'8e6ecbc9-1902-46ea-9757-a8b2c9e969a5', 'shared': False,
'port_security_enabled': True, 'id': 'e970f0a0-d222-4a37-91c8-00eaefaee61b'}}
2014-02-17 17:22:49.458 | 2014-02-17 17:22:49,153ERROR
[neutron.api.v2.resource] create failed
Ref: http://logs.openstack.org/27/41827/21/check/gate-neutron-
python27/fdcefc5/console.html
** Affects: neutron
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/1281357
Title:
IntegrityError on Nicira get_vcns_router_binding
Status in OpenStack Neutron (virtual network service):
New
Bug description:
Neutron gate for py27 is failing with this error...
2014-02-17 17:22:49.452 | 2014-02-17 17:22:49,107ERROR
[neutron.api.rpc.agentnotifiers.dhcp_rpc_agent_api] No DHCP agents are
associated with network '35b65fc4-9904-4bcc-9d94-2a5af567e910'. Unable to send
notification for 'network_create_end' with payload: {'network': {'status':
'ACTIVE', 'subnets': [], 'name': u'net1', 'admin_state_up': True, 'tenant_id':
u'92dae896-947e-4dd8-b7bc-8b7652eeea3f', 'shared': False,
'port_security_enabled': True, 'id': '35b65fc4-9904-4bcc-9d94-2a5af567e910'}}
2014-02-17 17:22:49.452 | 2014-02-17 17:22:49,113ERROR
[neutron.plugins.nicira.vshield.tasks.tasks] Task
Task-deploying-router1-c71b0936-b0db-441f-81eb-871722e43310-1fb1cf62-97f8-11e3-9688-bc764e050f7e
encountered exception in > at state 3
2014-02-17 17:22:49.452 | Traceback (most recent call last):
2014-02-17 17:22:49.452 | File
"neutron/plugins/nicira/vshield/tasks/tasks.py", line 98, in _invoke_monitor
2014-02-17 17:22:49.452 | func(self)
2014-02-17 17:22:49.453 | File
"neutron/plugins/nicira/NeutronServicePlugin.py", line 1566, in
edge_deploy_result
2014-02-17 17:22:49.453 | context.session, neutron_r
[Yahoo-eng-team] [Bug 1282855] [NEW] Add httmock to test-requirements.txt
Public bug reported: To enhance unit testing of REST API code I'd like to add this PyPI package to test-requirements.txt. I had this as part of my Icehouse-3 review for VPNaaS device driver, in requirements.txt, but it was failing Jenkins as this is not on the master requirements. Since it is only used for unit testing, it was suggested to place this in test-requirements.txt. So, I'm going to push a separate review just for this file, so I can use it for other commits. Ref: https://pypi.python.org/pypi/httmock/ ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1282855 Title: Add httmock to test-requirements.txt Status in OpenStack Neutron (virtual network service): In Progress Bug description: To enhance unit testing of REST API code I'd like to add this PyPI package to test-requirements.txt. I had this as part of my Icehouse-3 review for VPNaaS device driver, in requirements.txt, but it was failing Jenkins as this is not on the master requirements. Since it is only used for unit testing, it was suggested to place this in test-requirements.txt. So, I'm going to push a separate review just for this file, so I can use it for other commits. Ref: https://pypi.python.org/pypi/httmock/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1282855/+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 1288387] [NEW] CIsco CSR VPNaaS service & device driver cleanup
Public bug reported: Post blueprint vpnaas-cisco, there were minor review comments that this bug will address. - LOG.error -> LOG.exception in _request() of device driver - assertEqual(0, ...call_count) -> AssertFalse(...called) for two UTs in device driver ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1288387 Title: CIsco CSR VPNaaS service & device driver cleanup Status in OpenStack Neutron (virtual network service): In Progress Bug description: Post blueprint vpnaas-cisco, there were minor review comments that this bug will address. - LOG.error -> LOG.exception in _request() of device driver - assertEqual(0, ...call_count) -> AssertFalse(...called) for two UTs in device driver To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1288387/+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 1291609] [NEW] VPNaaS admin up/down on service/connection broken
Public bug reported: With an active IPSec site-to-site connection, if the VPN service state is changed to admin down, the connection and service states still show as ACTIVE and traffic still flows over the connection. If the IPsec site-to-site connection state is changed to admin down, the connection still shows as ACTIVE and traffic passes as well. Does not look like the update_vpnservice API forwards to the device driver. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1291609 Title: VPNaaS admin up/down on service/connection broken Status in OpenStack Neutron (virtual network service): In Progress Bug description: With an active IPSec site-to-site connection, if the VPN service state is changed to admin down, the connection and service states still show as ACTIVE and traffic still flows over the connection. If the IPsec site-to-site connection state is changed to admin down, the connection still shows as ACTIVE and traffic passes as well. Does not look like the update_vpnservice API forwards to the device driver. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1291609/+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 1291619] [NEW] Cisco VPN device drivers admin state not reported correctly
Public bug reported: Currently, this driver supports update of the VPN service, which one can change the admin state to up or down. In addition, even though IPSec site-to-site connection update is not currently supported (one can do a delete/create), the user could create the connection with admin state down. When the service admin state is changed to down, the change does not happen in the device driver, and the status is not reported correctly. This is due to an issue with the plugin (bug 1291609 created). If later, another change occurs that causes a sync of the config, the connections on the VPN service will be deleted (the CSR REST API doesn't yet have support for admin down), but the status still will not be updated correctly. The configuration in OpenStack can get out of sync with the configuration on the CSR. If the IPSec site-to-site connection is created in admin down state, the underlying tunnel is not created (correct), but the status still shows PENDING_CREATE. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1291619 Title: Cisco VPN device drivers admin state not reported correctly Status in OpenStack Neutron (virtual network service): In Progress Bug description: Currently, this driver supports update of the VPN service, which one can change the admin state to up or down. In addition, even though IPSec site-to-site connection update is not currently supported (one can do a delete/create), the user could create the connection with admin state down. When the service admin state is changed to down, the change does not happen in the device driver, and the status is not reported correctly. This is due to an issue with the plugin (bug 1291609 created). If later, another change occurs that causes a sync of the config, the connections on the VPN service will be deleted (the CSR REST API doesn't yet have support for admin down), but the status still will not be updated correctly. The configuration in OpenStack can get out of sync with the configuration on the CSR. If the IPSec site-to-site connection is created in admin down state, the underlying tunnel is not created (correct), but the status still shows PENDING_CREATE. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1291619/+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 1303820] [NEW] Update Cisco VPN device driver
Public bug reported: Based on recent updates to the Cisco CSR REST APIs, update the Cisco device driver for VPN to sync up with those changes. This includes - Support for various IKE and IPSec encryption modes. - Support for disable of anti-replay-window-size - Cleanup UTs based on verified changes - Enhance UT coverage for new REST API capabilities ** Affects: neutron 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/1303820 Title: Update Cisco VPN device driver Status in OpenStack Neutron (virtual network service): New Bug description: Based on recent updates to the Cisco CSR REST APIs, update the Cisco device driver for VPN to sync up with those changes. This includes - Support for various IKE and IPSec encryption modes. - Support for disable of anti-replay-window-size - Cleanup UTs based on verified changes - Enhance UT coverage for new REST API capabilities To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1303820/+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 1303830] [NEW] Cisco VPN device driver support ipsec site conn udpates
Public bug reported: Provide support in the Cisco VPN device driver for updates to the IPSec site to site connection configuration. Currently, one must manually delete and then recreate the connection to change the configuration. Changeable items include MTU, admin state, PSK, peer address/id, and peer CIDRs. Once the Cisco CSR REST API supports admin state change for IPSec site- to-site connections (tunnel admin up/down), enhance the device driver to change the admin state of the tunnel, rather than deleting the tunnel and maintaining state. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: Confirmed ** Changed in: neutron Status: New => Confirmed ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1303830 Title: Cisco VPN device driver support ipsec site conn udpates Status in OpenStack Neutron (virtual network service): Confirmed Bug description: Provide support in the Cisco VPN device driver for updates to the IPSec site to site connection configuration. Currently, one must manually delete and then recreate the connection to change the configuration. Changeable items include MTU, admin state, PSK, peer address/id, and peer CIDRs. Once the Cisco CSR REST API supports admin state change for IPSec site-to-site connections (tunnel admin up/down), enhance the device driver to change the admin state of the tunnel, rather than deleting the tunnel and maintaining state. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1303830/+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 1594529] [NEW] VM creation failure due to Nova hugepage assumptions
Public bug reported: Description: In Liberty and Mitaka, Nova assumes that it has exclusive access to the huge pages on the compute node. It maintains track of the total pages per NUMA node on the compute node, and then number of used (by Nova VMs) pages on each NUMA node. This is done for the three huge page sizes supported. However, if other third party processes consume huge pages, there will be a discrepancy between the actual pages available and what Nova thinks is available. As a result, it is possible (based on the number of pages and the VM size) for Nova to think it has enough pages, when there are not enough pages. The create will fail with QEMU reporting insufficient memory available, for example. Steps to reproduce: 1. Compute with 32768 2MB pages available, giving 16384 per NUMA node with two nodes. 2. Third party process that consumes 256 pages per NUMA node. 3. Create 15 small flavor (2GB = 1024 pages) VMs. 4. Create another small flavor VM. Expected Result: That the 16th VM would be created, without an error, and using huge pages on the second NUMA node (and allow more VMs as well). Actual Result: After step 3, Nova thinks there are 1024 pages available, but the compute host shows only 768 pages available. The scheduler thinks there is space for one more VM, it will pass the filter. The creation will commence, as Nova thinks there is enough space on NUMA node 0. QEMU will fail, indicating that there is not enough memory. In addition, there are 16128 pages available on NUMA node 1, but Nova will not attempt using them, as it thinks there is still memory available on NUMA node 0. In my case, I had multiple compute hosts and ended up with a "No hosts available" error, as it fails on each host when trying NUMA node 0. If, at step 4, one creates a medium flavor VM, it will succeed, as Nova will not see enough pages on NUMA node 0, and will try NUMA node 1, which has ample space. Commentary: Nova checks total huge pages, but not available huge pages. Note: A feature was added to master (for Newton) that has a config based mechanism to reserve huge pages for third party applications under bug 1543149. However, the Nova team indicated that this change cannot be back ported to Liberty. Environment: Liberty release (12.0.3), with LB, neutron networking, libvirt 1.2.17, API QEMU 1.2.17, QEMU 2.3.0. Config: nova flavor-key m1.small set hw:numa_nodes=1 nova flavor-key m1.small set hw:mem_page_size=2048 network, subnet, and standard VM create commands. ** 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/1594529 Title: VM creation failure due to Nova hugepage assumptions Status in OpenStack Compute (nova): New Bug description: Description: In Liberty and Mitaka, Nova assumes that it has exclusive access to the huge pages on the compute node. It maintains track of the total pages per NUMA node on the compute node, and then number of used (by Nova VMs) pages on each NUMA node. This is done for the three huge page sizes supported. However, if other third party processes consume huge pages, there will be a discrepancy between the actual pages available and what Nova thinks is available. As a result, it is possible (based on the number of pages and the VM size) for Nova to think it has enough pages, when there are not enough pages. The create will fail with QEMU reporting insufficient memory available, for example. Steps to reproduce: 1. Compute with 32768 2MB pages available, giving 16384 per NUMA node with two nodes. 2. Third party process that consumes 256 pages per NUMA node. 3. Create 15 small flavor (2GB = 1024 pages) VMs. 4. Create another small flavor VM. Expected Result: That the 16th VM would be created, without an error, and using huge pages on the second NUMA node (and allow more VMs as well). Actual Result: After step 3, Nova thinks there are 1024 pages available, but the compute host shows only 768 pages available. The scheduler thinks there is space for one more VM, it will pass the filter. The creation will commence, as Nova thinks there is enough space on NUMA node 0. QEMU will fail, indicating that there is not enough memory. In addition, there are 16128 pages available on NUMA node 1, but Nova will not attempt using them, as it thinks there is still memory available on NUMA node 0. In my case, I had multiple compute hosts and ended up with a "No hosts available" error, as it fails on each host when trying NUMA node 0. If, at step 4, one creates a medium flavor VM, it will succeed, as Nova will not see enough pages on NUMA node 0, and will try NUMA node 1, which has ample space. Commentary: Nova checks total huge pages, but not available huge pages. Note: A feature was added to master (for New
[Yahoo-eng-team] [Bug 1313801] [NEW] Cisco VPN move URI strings to constants
Public bug reported: Colocate strings used in REST client methods as URIs for APIs to Cisco CSR device, to make it easier to find and maintain them. File is: neutron/services/vpn/device_drivers/cisco_csr_rest_client.py ** Affects: neutron 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/1313801 Title: Cisco VPN move URI strings to constants Status in OpenStack Neutron (virtual network service): New Bug description: Colocate strings used in REST client methods as URIs for APIs to Cisco CSR device, to make it easier to find and maintain them. File is: neutron/services/vpn/device_drivers/cisco_csr_rest_client.py To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1313801/+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 1326785] [NEW] Inactive UT broken on Cisco VPNaaS
Public bug reported: As part of bug 1291032 to fix PEP8 H302 violations, some changes made to UT files in Cisco VPNaaS were not correctly modified (imports that were for modules already, were changed to import the directory above, instead of being left alone). The mistake wasn't detected, because the UT is currently deactivated. To verify the fix these things are needed: 1) Symlink tests/unit/services/vpn/device_drivers/notest_cisco_csr_rest.py to a name w/o no prefix. 2) manually include httmock library or the source file. 3) Run tox to verify the fix. Problem affects notest_cisco_csr_rest.py and cisco_csr_mock.py in that area. Long term the goal is to resolve the issue with this UTs library usage, but in the interim, we'd like to keep the file operational until that time (even if tested manually). ** Affects: neutron Importance: Undecided Status: New ** Tags: cisco vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1326785 Title: Inactive UT broken on Cisco VPNaaS Status in OpenStack Neutron (virtual network service): New Bug description: As part of bug 1291032 to fix PEP8 H302 violations, some changes made to UT files in Cisco VPNaaS were not correctly modified (imports that were for modules already, were changed to import the directory above, instead of being left alone). The mistake wasn't detected, because the UT is currently deactivated. To verify the fix these things are needed: 1) Symlink tests/unit/services/vpn/device_drivers/notest_cisco_csr_rest.py to a name w/o no prefix. 2) manually include httmock library or the source file. 3) Run tox to verify the fix. Problem affects notest_cisco_csr_rest.py and cisco_csr_mock.py in that area. Long term the goal is to resolve the issue with this UTs library usage, but in the interim, we'd like to keep the file operational until that time (even if tested manually). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1326785/+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 1326793] [NEW] VPNaaS enhance abstract methods for service driver APIs
Public bug reported: Currently an ABC is defined (VPNPlugin) for the service driver APIs. For some of the methods that must be implemented by the vendor and reference service drivers, there is an abstract method defined in this class to ensure that the child classes implement the method: @abc.abstractmethod def create_vpnservice(self, context, vpnservice): pass @abc.abstractmethod def update_vpnservice( self, context, old_vpnservice, vpnservice): pass @abc.abstractmethod def delete_vpnservice(self, context, vpnservice): pass However, for other methods, there are no abstract methods defined in VPNPlugin. Fortunately, the reference implmentation and every provider currently implement these methods in their child classes, but it would be good to enforce this in the ABC, so that any new service drivers will be sure to implement. This is a low-hanging fruit enhancement, ideal for new contributors. ** Affects: neutron Importance: Undecided Status: New ** Tags: vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1326793 Title: VPNaaS enhance abstract methods for service driver APIs Status in OpenStack Neutron (virtual network service): New Bug description: Currently an ABC is defined (VPNPlugin) for the service driver APIs. For some of the methods that must be implemented by the vendor and reference service drivers, there is an abstract method defined in this class to ensure that the child classes implement the method: @abc.abstractmethod def create_vpnservice(self, context, vpnservice): pass @abc.abstractmethod def update_vpnservice( self, context, old_vpnservice, vpnservice): pass @abc.abstractmethod def delete_vpnservice(self, context, vpnservice): pass However, for other methods, there are no abstract methods defined in VPNPlugin. Fortunately, the reference implmentation and every provider currently implement these methods in their child classes, but it would be good to enforce this in the ABC, so that any new service drivers will be sure to implement. This is a low-hanging fruit enhancement, ideal for new contributors. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1326793/+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 1334798] [NEW] Gate test is masking failure details
Public bug reported:
Both the 2.6 and 2.7 gate tests are failing, console log indicating two
failures, but only showing one failure 'process-retcode'. When looking
at testr_results it shows a fail and only mentions:
ft1.12873:
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used_StringException
Here is 2.7 logs: http://logs.openstack.org/51/102351/4/check/gate-
neutron-python27/a757b36/
Upon future investigation, it was found that there was non-printable
characters in an oslo file. With manual testing, it shows the error:
$ python -m neutron.openstack.common.lockutils python -m unittest
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used
F
==
FAIL: test_reference_driver_used
(neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection)
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used
--
_StringException: Empty attachments:
pythonlogging:''
pythonlogging:'neutron.api.extensions'
traceback-1: {{{
Traceback (most recent call last):
File "neutron/common/rpc.py", line 63, in cleanup
assert TRANSPORT is not None
AssertionError
}}}
Traceback (most recent call last):
File "neutron/tests/unit/services/vpn/service_drivers/test_ipsec.py", line
52, in setUp
super(TestValidatorSelection, self).setUp()
File "neutron/tests/base.py", line 188, in setUp
n_rpc.init(CONF)
File "neutron/common/rpc.py", line 56, in init
aliases=TRANSPORT_ALIASES)
File "/opt/stack/oslo.messaging/oslo/messaging/transport.py", line 185, in
get_transport
invoke_kwds=kwargs)
File "/opt/stack/stevedore/stevedore/driver.py", line 45, in __init__
verify_requirements=verify_requirements,
File "/opt/stack/stevedore/stevedore/named.py", line 55, in __init__
verify_requirements)
File "/opt/stack/stevedore/stevedore/extension.py", line 170, in _load_plugins
self._on_load_failure_callback(self, ep, err)
File "/opt/stack/stevedore/stevedore/driver.py", line 50, in
_default_on_load_failure
raise err
File "/opt/stack/oslo.messaging/oslo/messaging/_drivers/impl_fake.py", line 48
SyntaxError: Non-ASCII character '\xc2' in file
/opt/stack/oslo.messaging/oslo/messaging/_drivers/impl_fake.py on line 48, but
no encoding declared; see http://www.python.org/peps/pep-0263.html for details
A fix will be done for the oslo error, but we need to investigate why
the gate test does not show any information on the error.
** Affects: neutron
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/1334798
Title:
Gate test is masking failure details
Status in OpenStack Neutron (virtual network service):
New
Bug description:
Both the 2.6 and 2.7 gate tests are failing, console log indicating
two failures, but only showing one failure 'process-retcode'. When
looking at testr_results it shows a fail and only mentions:
ft1.12873:
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used_StringException
Here is 2.7 logs: http://logs.openstack.org/51/102351/4/check/gate-
neutron-python27/a757b36/
Upon future investigation, it was found that there was non-printable
characters in an oslo file. With manual testing, it shows the error:
$ python -m neutron.openstack.common.lockutils python -m unittest
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used
F
==
FAIL: test_reference_driver_used
(neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection)
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used
--
_StringException: Empty attachments:
pythonlogging:''
pythonlogging:'neutron.api.extensions'
traceback-1: {{{
Traceback (most recent call last):
File "neutron/common/rpc.py", line 63, in cleanup
assert TRANSPORT is not None
AssertionError
}}}
Traceback (most recent call last):
File "neutron/tests/unit/services/vpn/service_drivers/test_ipsec.py", line
52, in setUp
super(TestValidatorSelection, self).setUp()
File "neutron/tests/base.py", line 188, in setUp
n_rpc.init(CONF)
File "neutron/common/rpc.py", line 56, in init
aliases=TRANSPORT_ALIASES)
File "/opt/stack/oslo.messaging/oslo/messaging/transport.py", line 185, in
get_transport
invoke_kwds=kwargs)
File "/opt/stack/stevedore/stevedore/driver.py", line 45,
[Yahoo-eng-team] [Bug 1335973] [NEW] VPNaaS Cisco table not created
Public bug reported: When specifying the Cisco CSR VPNaaS driver, a cisco_csr_identifier_map table is used for mapping OpenStack VPN resource IDs to Cisco CSR IDs. This table is used by the service driver, but the table is not registered during init (the service driver is loaded after the plugin has already done configure_db). Need to register during __init__. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1335973 Title: VPNaaS Cisco table not created Status in OpenStack Neutron (virtual network service): In Progress Bug description: When specifying the Cisco CSR VPNaaS driver, a cisco_csr_identifier_map table is used for mapping OpenStack VPN resource IDs to Cisco CSR IDs. This table is used by the service driver, but the table is not registered during init (the service driver is loaded after the plugin has already done configure_db). Need to register during __init__. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1335973/+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 1335977] [NEW] VPNaaS Cisco REST client UT broken
Public bug reported: The currently inactive UT for the Cisco CSR REST client, is broken due to incorrect H302 changes. Want to temporarily fix the UT so that they can be run locally (by renaming the file to remove the "no" prefix and by including the httmock package or source file). In the future, this UT will need to be reworked to use the httpretty library. The httpretty package uses a register based mechanism, whereas httmock uses a context manager mechanism, so there are significant changes needed. The goal here is to have a way to (manually) continue to check operation of the Cisco REST client code. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => 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/1335977 Title: VPNaaS Cisco REST client UT broken Status in OpenStack Neutron (virtual network service): In Progress Bug description: The currently inactive UT for the Cisco CSR REST client, is broken due to incorrect H302 changes. Want to temporarily fix the UT so that they can be run locally (by renaming the file to remove the "no" prefix and by including the httmock package or source file). In the future, this UT will need to be reworked to use the httpretty library. The httpretty package uses a register based mechanism, whereas httmock uses a context manager mechanism, so there are significant changes needed. The goal here is to have a way to (manually) continue to check operation of the Cisco REST client code. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1335977/+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 1335973] Re: VPNaaS Cisco table not created
** 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/1335973 Title: VPNaaS Cisco table not created Status in OpenStack Neutron (virtual network service): Invalid Bug description: When specifying the Cisco CSR VPNaaS driver, a cisco_csr_identifier_map table is used for mapping OpenStack VPN resource IDs to Cisco CSR IDs. This table is used by the service driver, but the table is not registered during init (the service driver is loaded after the plugin has already done configure_db). Need to register during __init__. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1335973/+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 1336478] [NEW] VPNaaS Cisco REST client enhance CSR create
Public bug reported: Currently, int he Cisco CSR REST client, the CSR instances are created using numerous parameters. This enhancement is to take a dict with the configuration information, so that additional settings can be provided in the future. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: cisco vpnaas ** Changed in: neutron Assignee: (unassigned) => Paul Michali (pcm) ** Changed in: neutron Status: New => In Progress ** Description changed: Currently, int he Cisco CSR REST client, the CSR instances are created using numerous parameters. This enhancement is to take a dict with the - configuration information, so that future settings can be added w/o - changing the construction of the objects. + configuration information, so that additional settings can be provided + in the future. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1336478 Title: VPNaaS Cisco REST client enhance CSR create Status in OpenStack Neutron (virtual network service): In Progress Bug description: Currently, int he Cisco CSR REST client, the CSR instances are created using numerous parameters. This enhancement is to take a dict with the configuration information, so that additional settings can be provided in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1336478/+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 1336556] [NEW] migration default value not being applied to dbase
Public bug reported:
I have a private repo that is a few weeks behind the upstream, and was
having problems stacking. Initially it was failing in one of the
migrations, so I changed the SQLAlchemy version to 0.8.4 and alembic to
0.6.5 and retried (clean database).
What I saw was that the migration worked, but later a router create
failed. It was complaining that the enable_snat field was not specified
and did not have a default value. Checking in the migrations, I saw that
128e042a2b68_ext_gw_mode.py adds this field and sets the default value
to True. However, it was not doing that.
I changed the migration file to use server_default=sa.text("true") and
now the migration works. BTW, it was the only migration file using
'default=True'.
Not sure if we should just apply this change to the existing migration
file or if some other action is needed.
** Affects: neutron
Importance: Undecided
Status: New
** Tags: migration
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1336556
Title:
migration default value not being applied to dbase
Status in OpenStack Neutron (virtual network service):
New
Bug description:
I have a private repo that is a few weeks behind the upstream, and was
having problems stacking. Initially it was failing in one of the
migrations, so I changed the SQLAlchemy version to 0.8.4 and alembic
to 0.6.5 and retried (clean database).
What I saw was that the migration worked, but later a router create
failed. It was complaining that the enable_snat field was not
specified and did not have a default value. Checking in the
migrations, I saw that 128e042a2b68_ext_gw_mode.py adds this field and
sets the default value to True. However, it was not doing that.
I changed the migration file to use server_default=sa.text("true") and
now the migration works. BTW, it was the only migration file using
'default=True'.
Not sure if we should just apply this change to the existing migration
file or if some other action is needed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1336556/+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
