[Yahoo-eng-team] [Bug 1412617] [NEW] Fix grammatical error in horizon 'contributing' docs
Public bug reported: While reading 'contributing.rst' in docs folder , i saw a sentence on line 38 that says: 'Got that all that? ' which doesnt make any sense grammatically, it should be preferably 'Got that all?' or 'Got all of that? '. here is source : https://git.openstack.org/cgit/openstack/horizon/tree/doc/source/contributing.rst#n38 ** Affects: horizon Importance: Undecided Status: New ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1412617 Title: Fix grammatical error in horizon 'contributing' docs Status in OpenStack Dashboard (Horizon): New Bug description: While reading 'contributing.rst' in docs folder , i saw a sentence on line 38 that says: 'Got that all that? ' which doesnt make any sense grammatically, it should be preferably 'Got that all?' or 'Got all of that? '. here is source : https://git.openstack.org/cgit/openstack/horizon/tree/doc/source/contributing.rst#n38 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1412617/+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 1394148] Re: subnet-create should not force me to supply cidr
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete = Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1394148 Title: subnet-create should not force me to supply cidr Status in OpenStack Neutron (virtual network service): Expired Bug description: When I create a subnet with dhcp disabled, it should not force me to supply mandatory cidr. Currently it is: neutron subnet-create dhcp-net -- --enable_dhcp=False cidr Expected should be: neutron subnet-create dhcp-net -- --enable_dhcp=False or neutron subnet-create dhcp-net -- --enable_dhcp=False --extra-dhcp- opts So, that I can use this subnet flexibly with extra_dhcp_opts. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1394148/+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 1412325] Re: test_subnet_details failed due to MismatchError
IMO this is actually a Neutron bug and Tempest reveals a race. We should add a waiter for the update to verify it's really a race. ** Also 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/1412325 Title: test_subnet_details failed due to MismatchError Status in OpenStack Neutron (virtual network service): New Status in Tempest: In Progress Bug description: A new test test_subnet_details failed on the gate for Nova like the following: http://logs.openstack.org/92/144092/3/check/check-tempest-dsvm- neutron-full/6bcefe8/logs/testr_results.html.gz Traceback (most recent call last): File tempest/test.py, line 112, in wrapper return f(self, *func_args, **func_kwargs) File tempest/scenario/test_network_basic_ops.py, line 486, in test_subnet_details self._check_dns_server(ssh_client, [alt_dns_server]) File tempest/scenario/test_network_basic_ops.py, line 437, in _check_dns_server trgt_serv=dns_servers)) File /usr/local/lib/python2.7/dist-packages/testtools/testcase.py, line 348, in assertEqual self.assertThat(observed, matcher, message) File /usr/local/lib/python2.7/dist-packages/testtools/testcase.py, line 433, in assertThat raise mismatch_error MismatchError: set(['9.8.7.6']) != set(['1.2.3.4']): Looking for servers: ['9.8.7.6']. Retrieved DNS nameservers: ['1.2.3.4'] From host: 172.24.4.98. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1412325/+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 1412348] [NEW] Missing index on allocated
Public bug reported: ml2_vxlan_allocations, ml2_gre_allocations, ml2_vlan_allocations tables has field named 'allocated'. These tables frequently used by similar queries: SELECT ml2_vxlan_allocations.vxlan_vni AS ml2_vxlan_allocations_vxlan_vni, ml2_vxlan_allocations.allocated AS ml2_vxlan_allocations_allocated FROM ml2_vxlan_allocations WHERE ml2_vxlan_allocations.allocated = 0 LIMIT 1; This does select without an index, which causes very poor performance. If Transaction which involved in allocation took long time, in parallel can lead to an allocation failure and retry. These tables needs to have index on the 'allocated' field. In the ml2_vlan_allocations table case consider creating an index on (physical_network, allocation) together. ** Affects: neutron Importance: Undecided Status: New ** Description changed: ml2_vxlan_allocations, ml2_gre_allocations, ml2_vlan_allocations tables - has field named 'allocation'. + has field named 'allocated'. - These tables frequently used by similar queries: + These tables frequently used by similar queries: SELECT ml2_vxlan_allocations.vxlan_vni AS ml2_vxlan_allocations_vxlan_vni, ml2_vxlan_allocations.allocated AS ml2_vxlan_allocations_allocated FROM ml2_vxlan_allocations WHERE ml2_vxlan_allocations.allocated = 0 LIMIT 1; This does select without an index, which causes very poor performance. If Transaction which involved in allocation took long time, in parallel can lead to an allocation failure and retry. These tables needs to have index on the 'allocated' field. In the ml2_vlan_allocations table case consider creating an index on (physical_network, allocation) together. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1412348 Title: Missing index on allocated Status in OpenStack Neutron (virtual network service): New Bug description: ml2_vxlan_allocations, ml2_gre_allocations, ml2_vlan_allocations tables has field named 'allocated'. These tables frequently used by similar queries: SELECT ml2_vxlan_allocations.vxlan_vni AS ml2_vxlan_allocations_vxlan_vni, ml2_vxlan_allocations.allocated AS ml2_vxlan_allocations_allocated FROM ml2_vxlan_allocations WHERE ml2_vxlan_allocations.allocated = 0 LIMIT 1; This does select without an index, which causes very poor performance. If Transaction which involved in allocation took long time, in parallel can lead to an allocation failure and retry. These tables needs to have index on the 'allocated' field. In the ml2_vlan_allocations table case consider creating an index on (physical_network, allocation) together. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1412348/+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 1380806] Re: Shouldn't use unicode() when exception used in msgs
** Also affects: cinder 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/1380806 Title: Shouldn't use unicode() when exception used in msgs Status in Cinder: New Status in OpenStack Compute (Nova): Fix Released Bug description: There are cases (identified by mriedem) where an exception is used as replacement text and is coerced using unicode(): http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py?id=2014.2.rc2#n3264 reason=_(Driver Error: %s) % unicode(e)) http://git.openstack.org/cgit/openstack/nova/tree/nova/api/ec2/__init__.py?id=2014.2.rc2#n89 LOG.exception(_(FaultWrapper: %s), unicode(ex)) doing this can interfere with translation by causing things to be prematurely translated. Need to scan for and correct any occurrences. Also need to look at adding/updating a hacking check. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1380806/+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 1412653] [NEW] ofagent decomposition
Public bug reported: this bug is to track the status of neutron core-vendor-decomposition for ofagent. ** 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/1412653 Title: ofagent decomposition Status in OpenStack Neutron (virtual network service): New Bug description: this bug is to track the status of neutron core-vendor-decomposition for ofagent. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1412653/+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 1412577] [NEW] Thin Arista ML2 driver in tree
Public bug reported: This bug is to track the decomposition of Arista ML2 driver from neutron tree to stackforge repository. The Config and DB related stuff remains in the tree and rest will be moved to a separate repository. ** Affects: neutron Importance: Undecided Status: New ** Tags: arista ml2 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1412577 Title: Thin Arista ML2 driver in tree Status in OpenStack Neutron (virtual network service): New Bug description: This bug is to track the decomposition of Arista ML2 driver from neutron tree to stackforge repository. The Config and DB related stuff remains in the tree and rest will be moved to a separate repository. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1412577/+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 1412581] [NEW] Integration test failing in horizon
Public bug reported: Steps to reproduce this error: 1. Check out the latest master branch (currently on f64664ddc54f24477c59404e84d7ec5d9bb1d88e). 2. Then run the integration tests: ./run_tests.sh --integration 3. See error I have also tried going back a few patches, but it seems like we have had this error for quite sometime. Here is the complete trace: http://paste.openstack.org/show/158986/ $ ./run_tests.sh --integration Checking environment. Environment is up to date. Running Horizon integration tests... openstack_dashboard.test.integration_tests.tests.test_dashboard_help_redirection.TestDashboardHelp.test_dashboard_help_redirection ... ERROR openstack_dashboard.test.integration_tests.tests.test_flavors.TestFlavors.test_flavor_create ... ERROR openstack_dashboard.test.integration_tests.tests.test_image_create_delete.TestImage.test_image_create_delete ... ERROR openstack_dashboard.test.integration_tests.tests.test_keypair.TestKeypair.test_keypair ... ERROR openstack_dashboard.test.integration_tests.tests.test_login.TestLogin.test_login ... FAIL openstack_dashboard.test.integration_tests.tests.test_password_change.TestPasswordChange.test_password_change ... ERROR openstack_dashboard.test.integration_tests.tests.test_user_settings.TestUserSettings.test_user_settings_change ... ERROR ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1412581 Title: Integration test failing in horizon Status in OpenStack Dashboard (Horizon): New Bug description: Steps to reproduce this error: 1. Check out the latest master branch (currently on f64664ddc54f24477c59404e84d7ec5d9bb1d88e). 2. Then run the integration tests: ./run_tests.sh --integration 3. See error I have also tried going back a few patches, but it seems like we have had this error for quite sometime. Here is the complete trace: http://paste.openstack.org/show/158986/ $ ./run_tests.sh --integration Checking environment. Environment is up to date. Running Horizon integration tests... openstack_dashboard.test.integration_tests.tests.test_dashboard_help_redirection.TestDashboardHelp.test_dashboard_help_redirection ... ERROR openstack_dashboard.test.integration_tests.tests.test_flavors.TestFlavors.test_flavor_create ... ERROR openstack_dashboard.test.integration_tests.tests.test_image_create_delete.TestImage.test_image_create_delete ... ERROR openstack_dashboard.test.integration_tests.tests.test_keypair.TestKeypair.test_keypair ... ERROR openstack_dashboard.test.integration_tests.tests.test_login.TestLogin.test_login ... FAIL openstack_dashboard.test.integration_tests.tests.test_password_change.TestPasswordChange.test_password_change ... ERROR openstack_dashboard.test.integration_tests.tests.test_user_settings.TestUserSettings.test_user_settings_change ... ERROR To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1412581/+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 1253467] Re: Add .idea to .gitignore
Marking as invalid as ignoring specific IDEs indeed shouldn't be in horizon repo. ** Changed in: horizon Status: In Progress = Invalid ** Changed in: horizon Assignee: Maxime Vidori (maxime-vidori) = (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1253467 Title: Add .idea to .gitignore Status in OpenStack Dashboard (Horizon): Invalid Bug description: Openstack grants developers a free PyCharm licence, this IDE use a folder .idea to track project folder. Adding .idea to .gitignore will avoid mistakes and to take care of this. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1253467/+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 1412447] [NEW] SQL identity driver does't support backend filtering on membership queries
Public bug reported: The SQL identity driver leaves filtering on list_users_in_group and list_groups_for_user to the controller. This is probably a reasonable assumption - although the LDAP driver now does support at least filtering on list_groups_for_user (this is included in https://review.openstack.org/#/c/147612/). It would be sensible for SQL to at least match what LDAP can do (and avoid having to skip the test related to this in test_backend_sql). ** Affects: keystone Importance: Low Status: New ** Description changed: - The SQL identity driver leaves filter on list_users_in_group and + The SQL identity driver leaves filtering on list_users_in_group and list_groups_for_user to the controller. This is probably a reasonable assumption - although the LDAP driver now does support at least filtering on list_groups_for_user (this is included in https://review.openstack.org/#/c/147612/). It would be sensible for SQL to at least match what LDAP can do (and avoid having to skip the test related to this in test_backend_sql). ** Changed in: keystone Importance: Undecided = Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1412447 Title: SQL identity driver does't support backend filtering on membership queries Status in OpenStack Identity (Keystone): New Bug description: The SQL identity driver leaves filtering on list_users_in_group and list_groups_for_user to the controller. This is probably a reasonable assumption - although the LDAP driver now does support at least filtering on list_groups_for_user (this is included in https://review.openstack.org/#/c/147612/). It would be sensible for SQL to at least match what LDAP can do (and avoid having to skip the test related to this in test_backend_sql). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1412447/+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 1412436] [NEW] Race in instance_create with security_group_destroy
Public bug reported: There is a race in instance_create between fetching security groups (returned by _security_group_get_by_names) and adding them to the instance. We have no guarantee that they have not been deleted in the meantime. The result is currently that the SecurityGroupInstanceAssociation is created, pointing to the deleted SecurityGroup. This is different to the result of deleting the SecurityGroup afterwards, when both SecurityGroupInstanceAssociation and SecurityGroup are marked deleted. It is also different to the result of deleting the SecurityGroup before, which is to raise an error. While this intermediate state doesn't appear to cause an immediate problem, I feel it would be likely to result in unexpected behaviour at some point in the future, probably during a datamodel upgrade. My preference would be to cause it to fail, as that feels intuitively to me to be the most useful response to the end user (they have just requested an instance with a security group, but the returned instance already does not have that security group). However, either behaviour would be correct IMO. I suspect the failure behaviour would be harder to achieve in practice. ** 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/1412436 Title: Race in instance_create with security_group_destroy Status in OpenStack Compute (Nova): New Bug description: There is a race in instance_create between fetching security groups (returned by _security_group_get_by_names) and adding them to the instance. We have no guarantee that they have not been deleted in the meantime. The result is currently that the SecurityGroupInstanceAssociation is created, pointing to the deleted SecurityGroup. This is different to the result of deleting the SecurityGroup afterwards, when both SecurityGroupInstanceAssociation and SecurityGroup are marked deleted. It is also different to the result of deleting the SecurityGroup before, which is to raise an error. While this intermediate state doesn't appear to cause an immediate problem, I feel it would be likely to result in unexpected behaviour at some point in the future, probably during a datamodel upgrade. My preference would be to cause it to fail, as that feels intuitively to me to be the most useful response to the end user (they have just requested an instance with a security group, but the returned instance already does not have that security group). However, either behaviour would be correct IMO. I suspect the failure behaviour would be harder to achieve in practice. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1412436/+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 1412469] [NEW] Integration tests sometime fail with WebDriverException: Message: The browser appears to have exited before we could connect.
Public bug reported: For example on test here ( http://logs.openstack.org/04/148204/4/check /gate-horizon-dsvm-integration/5b55890/console.html ) 2015-01-19 10:04:02.134 | 2015-01-19 10:04:02.118 | ERROR: openstack_dashboard.test.integration_tests.tests.test_flavors.TestFlavors.test_flavor_create 2015-01-19 10:04:02.136 | 2015-01-19 10:04:02.119 | -- 2015-01-19 10:04:02.168 | 2015-01-19 10:04:02.121 | _StringException: Traceback (most recent call last): 2015-01-19 10:04:02.168 | 2015-01-19 10:04:02.122 | File /opt/stack/new/horizon/openstack_dashboard/test/integration_tests/helpers.py, line 72, in setUp 2015-01-19 10:04:02.169 | 2015-01-19 10:04:02.124 | super(AdminTestCase, self).setUp() 2015-01-19 10:04:02.169 | 2015-01-19 10:04:02.125 | File /opt/stack/new/horizon/openstack_dashboard/test/integration_tests/helpers.py, line 33, in setUp 2015-01-19 10:04:02.169 | 2015-01-19 10:04:02.127 | self.driver = webdriver.WebDriverWrapper() 2015-01-19 10:04:02.169 | 2015-01-19 10:04:02.128 | File /opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/firefox/webdriver.py, line 59, in __init__ 2015-01-19 10:04:02.170 | 2015-01-19 10:04:02.130 | self.binary, timeout), 2015-01-19 10:04:02.170 | 2015-01-19 10:04:02.131 | File /opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/firefox/extension_connection.py, line 47, in __init__ 2015-01-19 10:04:02.170 | 2015-01-19 10:04:02.132 | self.binary.launch_browser(self.profile) 2015-01-19 10:04:02.171 | 2015-01-19 10:04:02.134 | File /opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/firefox/firefox_binary.py, line 66, in launch_browser 2015-01-19 10:04:02.171 | 2015-01-19 10:04:02.135 | self._wait_until_connectable() 2015-01-19 10:04:02.171 | 2015-01-19 10:04:02.137 | File /opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/firefox/firefox_binary.py, line 100, in _wait_until_connectable 2015-01-19 10:04:02.171 | 2015-01-19 10:04:02.138 | raise WebDriverException(The browser appears to have exited 2015-01-19 10:04:02.172 | 2015-01-19 10:04:02.140 | WebDriverException: Message: The browser appears to have exited before we could connect. If you specified a log_file in the FirefoxBinary constructor, check it for details. 3 tests with that error in http://logs.openstack.org/47/147047/5/gate /gate-horizon-dsvm-integration/2e044be/console.html : 2015-01-19 14:09:49.343 | 2015-01-19 14:09:49.309 | == 2015-01-19 14:09:49.343 | 2015-01-19 14:09:49.310 | ERROR: openstack_dashboard.test.integration_tests.tests.test_keypair.TestKeypair.test_keypair 2015-01-19 14:09:49.343 | 2015-01-19 14:09:49.311 | -- 2015-01-19 14:09:49.343 | 2015-01-19 14:09:49.313 | _StringException: Traceback (most recent call last): 2015-01-19 14:09:49.343 | 2015-01-19 14:09:49.314 | File /opt/stack/new/horizon/openstack_dashboard/test/integration_tests/helpers.py, line 59, in setUp 2015-01-19 14:09:49.344 | 2015-01-19 14:09:49.315 | super(TestCase, self).setUp() 2015-01-19 14:09:49.344 | 2015-01-19 14:09:49.316 | File /opt/stack/new/horizon/openstack_dashboard/test/integration_tests/helpers.py, line 33, in setUp 2015-01-19 14:09:49.344 | 2015-01-19 14:09:49.318 | self.driver = webdriver.WebDriverWrapper() 2015-01-19 14:09:49.344 | 2015-01-19 14:09:49.319 | File /opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/firefox/webdriver.py, line 59, in __init__ 2015-01-19 14:09:49.344 | 2015-01-19 14:09:49.320 | self.binary, timeout), 2015-01-19 14:09:49.345 | 2015-01-19 14:09:49.321 | File /opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/firefox/extension_connection.py, line 47, in __init__ 2015-01-19 14:09:49.345 | 2015-01-19 14:09:49.323 | self.binary.launch_browser(self.profile) 2015-01-19 14:09:49.345 | 2015-01-19 14:09:49.324 | File /opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/firefox/firefox_binary.py, line 66, in launch_browser 2015-01-19 14:09:49.345 | 2015-01-19 14:09:49.325 | self._wait_until_connectable() 2015-01-19 14:09:49.345 | 2015-01-19 14:09:49.327 | File /opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/firefox/firefox_binary.py, line 100, in _wait_until_connectable 2015-01-19 14:09:49.345 | 2015-01-19 14:09:49.329 | raise WebDriverException(The browser appears to have exited 2015-01-19 14:09:49.346 | 2015-01-19 14:09:49.330 | WebDriverException: Message: The browser appears to have exited before we could connect. If
[Yahoo-eng-team] [Bug 1412480] [NEW] Hyper-V: Instance booted from volume fails to resize
Public bug reported: Hyper-V instances which are booted from volume fail during nova resize with the message: HyperVException: Cannot find boot VHD file for instance: instance-000d Since the instance boots from an ISCSI volume, there is no VHD file for it, so this error is wrong. This causes the instance to be put in ERROR state and be destroyed. Log: http://paste.openstack.org/show/158889/ ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v ** Tags added: hyper-v ** Changed in: nova Assignee: (unassigned) = Claudiu Belu (cbelu) -- 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/1412480 Title: Hyper-V: Instance booted from volume fails to resize Status in OpenStack Compute (Nova): New Bug description: Hyper-V instances which are booted from volume fail during nova resize with the message: HyperVException: Cannot find boot VHD file for instance: instance-000d Since the instance boots from an ISCSI volume, there is no VHD file for it, so this error is wrong. This causes the instance to be put in ERROR state and be destroyed. Log: http://paste.openstack.org/show/158889/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1412480/+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 1412483] [NEW] Horizon UI behavior when browser cookies disabled
Public bug reported:
Steps to reproduce:
1) Disable cookies in browser settings.
2) Navigate to Horizon.
3) See login page.
4) Fill username and password fields, then click Sign In button
5)
Actual: Forbidden (403) CSRF verification failed. Request aborted. (see
screenshot)
Expected: to see some neat message that cookies must be enabled for
logging-in.
Usually good services provide human-friendly warning for user. Examples:
Google: Oops! Your browser seems to have cookies disabled. Make sure cookies
are enabled or try opening a new browser window.
Microsoft: Cookies must be allowed. Your browser is currently set to block
cookies. Your browser must allow cookies before you can use a Microsoft
account.
Environment:
{build_id: 2014-12-26_14-25-46, ostf_sha:
a9afb68710d809570460c29d6c3293219d3624d4, build_number: 58,
auth_required: true, api: 1.0, nailgun_sha:
5f91157daa6798ff522ca9f6d34e7e135f150a90, production: docker,
fuelmain_sha: 81d38d6f2903b5a8b4bee79ca45a54b76c1361b8, astute_sha:
16b252d93be6aaa73030b8100cf8c5ca6a970a91, feature_groups: [mirantis],
release: 6.0, release_versions: {2014.2-6.0: {VERSION: {build_id:
2014-12-26_14-25-46, ostf_sha: a9afb68710d809570460c29d6c3293219d3624d4,
build_number: 58, api: 1.0, nailgun_sha:
5f91157daa6798ff522ca9f6d34e7e135f150a90, production: docker,
fuelmain_sha: 81d38d6f2903b5a8b4bee79ca45a54b76c1361b8, astute_sha:
16b252d93be6aaa73030b8100cf8c5ca6a970a91, feature_groups: [mirantis],
release: 6.0, fuellib_sha: fde8ba5e11a1acaf819d402c645c731af450aff0}}},
fuellib_sha: fde8ba5e11a1acaf819d402c645c731af450aff0}
Browsers:
Chrome: Version 39.0.2171.99 (64-bit) on Ubuntu 14.04
Firefox: 35.0 on Ubuntu 14.04
** Affects: horizon
Importance: Undecided
Status: New
** Tags: ux
** Attachment added: Horizon_no_cookies.png
https://bugs.launchpad.net/bugs/1412483/+attachment/4301848/+files/Horizon_no_cookies.png
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1412483
Title:
Horizon UI behavior when browser cookies disabled
Status in OpenStack Dashboard (Horizon):
New
Bug description:
Steps to reproduce:
1) Disable cookies in browser settings.
2) Navigate to Horizon.
3) See login page.
4) Fill username and password fields, then click Sign In button
5)
Actual: Forbidden (403) CSRF verification failed. Request aborted. (see
screenshot)
Expected: to see some neat message that cookies must be enabled for
logging-in.
Usually good services provide human-friendly warning for user. Examples:
Google: Oops! Your browser seems to have cookies disabled. Make sure cookies
are enabled or try opening a new browser window.
Microsoft: Cookies must be allowed. Your browser is currently set to block
cookies. Your browser must allow cookies before you can use a Microsoft
account.
Environment:
{build_id: 2014-12-26_14-25-46, ostf_sha:
a9afb68710d809570460c29d6c3293219d3624d4, build_number: 58,
auth_required: true, api: 1.0, nailgun_sha:
5f91157daa6798ff522ca9f6d34e7e135f150a90, production: docker,
fuelmain_sha: 81d38d6f2903b5a8b4bee79ca45a54b76c1361b8, astute_sha:
16b252d93be6aaa73030b8100cf8c5ca6a970a91, feature_groups: [mirantis],
release: 6.0, release_versions: {2014.2-6.0: {VERSION: {build_id:
2014-12-26_14-25-46, ostf_sha: a9afb68710d809570460c29d6c3293219d3624d4,
build_number: 58, api: 1.0, nailgun_sha:
5f91157daa6798ff522ca9f6d34e7e135f150a90, production: docker,
fuelmain_sha: 81d38d6f2903b5a8b4bee79ca45a54b76c1361b8, astute_sha:
16b252d93be6aaa73030b8100cf8c5ca6a970a91, feature_groups: [mirantis],
release: 6.0, fuellib_sha: fde8ba5e11a1acaf819d402c645c731af450aff0}}},
fuellib_sha: fde8ba5e11a1acaf819d402c645c731af450aff0}
Browsers:
Chrome: Version 39.0.2171.99 (64-bit) on Ubuntu 14.04
Firefox: 35.0 on Ubuntu 14.04
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1412483/+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 1411807] Re: linuxbridge using mulicast vxlan w/o l2pop fails
Thanks Darragh, that is the problem. I am closing the bug. If anyone see this check out the bug that Darragh referenced above. The packets coming from the DHCP server donot have a correct shecksum and are being droped as they cross the bridge. Adding a magle rule to add the checksum or ignore it fixes everything. ** 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/1411807 Title: linuxbridge using mulicast vxlan w/o l2pop fails Status in OpenStack Neutron (virtual network service): Invalid Bug description: I am running Ubuntu 14.04 with a source Juno install updated as of yesterday. I have two network nodes and two compute nodes. When a VM is booted the broadcast DHCP request goes out and is received by the network node dnsmasq process. The unicast DHCP response is sent and is received by the compute node. It can be captured on the vxlan and Linux bridge interfaces but is never forwarded to the VM's tap interface which is on the bridge.. tcpdump on VM's tap interface. DHCP requests go out but the reply is never forwarded to the VM: root@compute:~# tcpdump -e -n -vv -i tapde7ffb39-b7 tcpdump: WARNING: tapde7ffb39-b7: no IPv4 address assigned tcpdump: listening on tapde7ffb39-b7, link-type EN10MB (Ethernet), capture size 65535 bytes 16:18:54.614728 fa:16:3e:32:93:95 ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 315) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x) Client-Ethernet-Address fa:16:3e:32:93:95 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether fa:16:3e:32:93:95 MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 9: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, MTU, BR, NTP Classless-Static-Route Vendor-Class Option 60, length 12: udhcp 1.20.1 Hostname Option 12, length 3: one 16:18:54.615002 fa:16:3e:32:93:95 ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 315) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x) Client-Ethernet-Address fa:16:3e:32:93:95 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether fa:16:3e:32:93:95 MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 9: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, MTU, BR, NTP Classless-Static-Route Vendor-Class Option 60, length 12: udhcp 1.20.1 Hostname Option 12, length 3: one 16:18:55.066473 fa:16:3e:32:93:95 33:33:ff:32:93:95, ethertype IPv6 (0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length: 24) :: ff02::1:ff32:9395: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has fe80::f816:3eff:fe32:9395 tcpdump on the that has both the VM's tap interface and the ethernet vxlan sub-interface. DHCP request goes out and the DHCP reply comes back but is not forwarded to the tap interface: root@compute:~# tcpdump -e -n -vv -i brq475b2aeb-b5 tcpdump: WARNING: brq475b2aeb-b5: no IPv4 address assigned 16:18:54.614728 fa:16:3e:32:93:95 ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 315) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x) Client-Ethernet-Address fa:16:3e:32:93:95 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether fa:16:3e:32:93:95 MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 9: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, MTU, BR, NTP Classless-Static-Route Vendor-Class Option 60, length 12: udhcp 1.20.1 Hostname Option 12, length 3: one 16:18:54.614983 fa:16:3e:32:93:95 ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 315)
[Yahoo-eng-team] [Bug 1186907] Re: If ebtables is not present nova-network fails with misleading error
** Changed in: ubuntu Status: New = Invalid -- 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/1186907 Title: If ebtables is not present nova-network fails with misleading error Status in OpenStack Compute (Nova): Invalid Status in Ubuntu: Invalid Bug description: In an upgrade from Folsom to Grizzly, nova-network fails as follows: 2013-06-03 10:08:01.430 6947 CRITICAL nova [-] Interface eth1 not found. 2013-06-03 10:08:01.430 6947 TRACE nova Traceback (most recent call last): 2013-06-03 10:08:01.430 6947 TRACE nova File /usr/bin/nova-network, line 54, in module 2013-06-03 10:08:01.430 6947 TRACE nova service.wait() 2013-06-03 10:08:01.430 6947 TRACE nova File /usr/lib/python2.7/dist-packages/nova/service.py, line 689, in wait 2013-06-03 10:08:01.430 6947 TRACE nova _launcher.wait() 2013-06-03 10:08:01.430 6947 TRACE nova File /usr/lib/python2.7/dist-packages/nova/service.py, line 209, in wait 2013-06-03 10:08:01.430 6947 TRACE nova super(ServiceLauncher, self).wait() 2013-06-03 10:08:01.430 6947 TRACE nova File /usr/lib/python2.7/dist-packages/nova/service.py, line 179, in wait 2013-06-03 10:08:01.430 6947 TRACE nova service.wait() 2013-06-03 10:08:01.430 6947 TRACE nova File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 166, in wait 2013-06-03 10:08:01.430 6947 TRACE nova return self._exit_event.wait() 2013-06-03 10:08:01.430 6947 TRACE nova File /usr/lib/python2.7/dist-packages/eventlet/event.py, line 116, in wait 2013-06-03 10:08:01.430 6947 TRACE nova return hubs.get_hub().switch() 2013-06-03 10:08:01.430 6947 TRACE nova File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 177, in switch 2013-06-03 10:08:01.430 6947 TRACE nova return self.greenlet.switch() 2013-06-03 10:08:01.430 6947 TRACE nova File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 192, in main 2013-06-03 10:08:01.430 6947 TRACE nova result = function(*args, **kwargs) 2013-06-03 10:08:01.430 6947 TRACE nova File /usr/lib/python2.7/dist-packages/nova/service.py, line 147, in run_server 2013-06-03 10:08:01.430 6947 TRACE nova server.start() 2013-06-03 10:08:01.430 6947 TRACE nova File /usr/lib/python2.7/dist-packages/nova/service.py, line 429, in start 2013-06-03 10:08:01.430 6947 TRACE nova self.manager.init_host() 2013-06-03 10:08:01.430 6947 TRACE nova File /usr/lib/python2.7/dist-packages/nova/network/manager.py, line 1681, in init_host 2013-06-03 10:08:01.430 6947 TRACE nova self.init_host_floating_ips() 2013-06-03 10:08:01.430 6947 TRACE nova File /usr/lib/python2.7/dist-packages/nova/network/floating_ips.py, line 98, in init_host_floating_ips 2013-06-03 10:08:01.430 6947 TRACE nova raise exception.NoFloatingIpInterface(interface=interface) 2013-06-03 10:08:01.430 6947 TRACE nova NoFloatingIpInterface: Interface eth1 not found. 2013-06-03 10:08:01.430 6947 TRACE nova This is caused because ebtables is not present in the system, therefore the process that adds the floating ip fails, and the wrong error is shown. ebtables should be a dependency of nova-network and it is not: Package: nova-network State: installed Automatically installed: no Version: 1:2013.1-0ubuntu2.1~cloud0 Priority: extra Section: net Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com Architecture: all Uncompressed Size: 1934 k Depends: bridge-utils, dnsmasq-base, dnsmasq-utils, iptables, iputils-arping, netcat, nova-common (= 1:2013.1-0ubuntu2.1~cloud0), vlan, upstart-job, python To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1186907/+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 1412394] [NEW] schema-image.json should contain the hypervisor specific parameters
Public bug reported: xen driver uses the os_type property which is not in https://github.com/openstack/glance/blob/master/etc/schema-image.json. libvirt has several additional properties https://wiki.openstack.org/wiki/LibvirtCustomHardware . The default schema specification should not restrict these frequently used parameters, or any parameter which nova can understand. ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1412394 Title: schema-image.json should contain the hypervisor specific parameters Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: xen driver uses the os_type property which is not in https://github.com/openstack/glance/blob/master/etc/schema-image.json. libvirt has several additional properties https://wiki.openstack.org/wiki/LibvirtCustomHardware . The default schema specification should not restrict these frequently used parameters, or any parameter which nova can understand. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1412394/+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 1412512] [NEW] policy.json location shouldn't be discovered by unittests at test-time
Public bug reported: During test-time, a call is made by neutron/policy.py to locate the path to the policy file, this is not the like-able behavior, Instead, the path to the policy file should be explicitly defined and given to the running test. ** Affects: neutron Importance: Undecided Assignee: Roey Chen (roeyc) Status: New ** Changed in: neutron Assignee: (unassigned) = Roey Chen (roeyc) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1412512 Title: policy.json location shouldn't be discovered by unittests at test-time Status in OpenStack Neutron (virtual network service): New Bug description: During test-time, a call is made by neutron/policy.py to locate the path to the policy file, this is not the like-able behavior, Instead, the path to the policy file should be explicitly defined and given to the running test. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1412512/+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 1409455] Re: Look for config files also in neutron root directory
** Changed in: neutron Status: Opinion = 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/1409455 Title: Look for config files also in neutron root directory Status in OpenStack Neutron (virtual network service): In Progress Bug description: the function neutron.common.utils.find_config_file should also search for config files in neutron root directory, which is assumed to be the cwd, this is not true where user runs tests which requires neutron library. for example, for Kilo, vendor specific code exists on a different project, but requires neutron to run unittests. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1409455/+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 1412547] [NEW] Additional properties are not allowed ('block_device_mapping_v2' was unexpected)
Public bug reported:
Logstash query:
message:'block_device_mapping_v2' was unexpected
Logstash URL:
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiJ2Jsb2NrX2RldmljZV9tYXBwaW5nX3YyJyB3YXMgdW5leHBlY3RlZFwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiIxNzI4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDIxNjk0Nzk2MDE3fQ==
Example traceback
2015-01-19 18:58:52.035 |
nova.tests.unit.api.openstack.compute.contrib.test_block_device_mapping_v1.BlockDeviceMappingTestV21.test_create_instance_both_bdm_formats
2015-01-19 18:58:52.035 |
--
2015-01-19 18:58:52.035 |
2015-01-19 18:58:52.035 | Captured traceback:
2015-01-19 18:58:52.035 | ~~~
2015-01-19 18:58:52.035 | Traceback (most recent call last):
2015-01-19 18:58:52.036 | File
nova/tests/unit/api/openstack/compute/contrib/test_block_device_mapping_v1.py,
line 337, in test_create_instance_both_bdm_formats
2015-01-19 18:58:52.036 | self.assertRaises(exc.HTTPBadRequest,
self._test_create, params)
2015-01-19 18:58:52.036 | File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
line 420, in assertRaises
2015-01-19 18:58:52.036 | self.assertThat(our_callable, matcher)
2015-01-19 18:58:52.036 | File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
line 431, in assertThat
2015-01-19 18:58:52.036 | mismatch_error = self._matchHelper(matchee,
matcher, message, verbose)
2015-01-19 18:58:52.036 | File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
line 481, in _matchHelper
2015-01-19 18:58:52.036 | mismatch = matcher.match(matchee)
2015-01-19 18:58:52.036 | File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/matchers/_exception.py,
line 108, in match
2015-01-19 18:58:52.036 | mismatch =
self.exception_matcher.match(exc_info)
2015-01-19 18:58:52.036 | File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/matchers/_higherorder.py,
line 62, in match
2015-01-19 18:58:52.036 | mismatch = matcher.match(matchee)
2015-01-19 18:58:52.037 | File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
line 412, in match
2015-01-19 18:58:52.037 | reraise(*matchee)
2015-01-19 18:58:52.037 | File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/matchers/_exception.py,
line 101, in match
2015-01-19 18:58:52.037 | result = matchee()
2015-01-19 18:58:52.037 | File
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
line 965, in __call__
2015-01-19 18:58:52.037 | return self._callable_object(*self._args,
**self._kwargs)
2015-01-19 18:58:52.037 | File
nova/tests/unit/api/openstack/compute/contrib/test_block_device_mapping_v1.py,
line 95, in _test_create
2015-01-19 18:58:52.037 | self.controller.create(req,
body=body).obj['server']
2015-01-19 18:58:52.037 | File nova/api/openstack/extensions.py, line
428, in wrapped
2015-01-19 18:58:52.037 | return f(*args, **kwargs)
2015-01-19 18:58:52.037 | File nova/api/validation/__init__.py, line
56, in wrapper
2015-01-19 18:58:52.038 | schema_validator.validate(kwargs['body'])
2015-01-19 18:58:52.038 | File nova/api/validation/validators.py, line
114, in validate
2015-01-19 18:58:52.038 | raise exception.ValidationError(detail=detail)
2015-01-19 18:58:52.038 | ValidationError: Invalid input for
field/attribute server. Value: {'name': 'server_test', 'imageRef':
'76fa36fc-c930-4bf3-8c8a-ea2a2420deb6', 'block_device_mapping':
[{'device_name': 'foo'}], 'block_device_mapping_v2': [{'source_type': 'volume',
'uuid': 'fake_vol'}], 'flavorRef': 'http://localhost/123/flavors/3',
'metadata': {'open': 'stack', 'hello': 'world'}}. Additional properties are not
allowed ('block_device_mapping_v2' was unexpected)
** 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/1412547
Title:
Additional properties are not allowed ('block_device_mapping_v2' was
unexpected)
Status in OpenStack Compute (Nova):
New
Bug description:
Logstash query:
message:'block_device_mapping_v2' was unexpected
Logstash URL:
[Yahoo-eng-team] [Bug 1247655] Re: Simple db incorrectly treats image tags as part of the core image entity
** Changed in: glance Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1247655 Title: Simple db incorrectly treats image tags as part of the core image entity Status in OpenStack Image Registry and Delivery Service (Glance): Invalid Bug description: Simple db treats image tags as a core attribute of images. image tags should not be returned as part of an image nor set when calling db_api.image_create. Since simple db has allowed this, many tests have incorrectly been treating tags as a core attribute. Fixing this and the tests is a prerequisite for finishing blueprint remove-simple-driver since the sqlalchemy driver does not allow setting tags this way and the tests currently depend on it. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1247655/+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 1412542] [NEW] L3 agent restart does not SIGHUP running keepalived processes
Public bug reported: Per https://github.com/openstack/neutron/blob/master/neutron/agent/linux/keepalived.py#L405: When the L3 agent starts, it invokes keepalived_manager spawn method, which spawns the the underlying keepalived process, unless it's already running. This issue only manifests for L3 agent restarts, because for an already-running agent, when it reconfigures keepalived due to an RPC update call, it does successfully sends a SIGHUP signal to the process. The effect is that restarting a L3 agent does not SIGHUP any running keepalived processes. So, for example, if the L3 agent crashes and is started again a minute or two later (This is dependent on timers configured for external tools such as Pacemaker), the L3 agent resyncs with the controller but doesn't SIGHUP any existing keepalived processes. This means that any updates that happened during the L3 agent downtime will be picked up during that initial resync, but the agent won't actually reconfigure keepalived. It is also an issue during upgrades for reasons similar to what's explained above, as it's actually an identical flow. Fixing this bug is a precondition to a couple of other fixes if we want backports to actually fix their respective issues on Juno. ** Affects: neutron Importance: Undecided Assignee: Assaf Muller (amuller) Status: In Progress ** Tags: juno-backport-potential l3-ha -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1412542 Title: L3 agent restart does not SIGHUP running keepalived processes Status in OpenStack Neutron (virtual network service): In Progress Bug description: Per https://github.com/openstack/neutron/blob/master/neutron/agent/linux/keepalived.py#L405: When the L3 agent starts, it invokes keepalived_manager spawn method, which spawns the the underlying keepalived process, unless it's already running. This issue only manifests for L3 agent restarts, because for an already-running agent, when it reconfigures keepalived due to an RPC update call, it does successfully sends a SIGHUP signal to the process. The effect is that restarting a L3 agent does not SIGHUP any running keepalived processes. So, for example, if the L3 agent crashes and is started again a minute or two later (This is dependent on timers configured for external tools such as Pacemaker), the L3 agent resyncs with the controller but doesn't SIGHUP any existing keepalived processes. This means that any updates that happened during the L3 agent downtime will be picked up during that initial resync, but the agent won't actually reconfigure keepalived. It is also an issue during upgrades for reasons similar to what's explained above, as it's actually an identical flow. Fixing this bug is a precondition to a couple of other fixes if we want backports to actually fix their respective issues on Juno. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1412542/+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 1404073] Re: type should be required for v2.0 service create
** Changed in: python-openstackclient
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1404073
Title:
type should be required for v2.0 service create
Status in OpenStack Identity (Keystone):
New
Status in Python client library for Keystone:
In Progress
Status in OpenStack Command Line Client:
Fix Released
Bug description:
For v2.0, the API says the following, but is unclear about what is
required vs. optional
http://developer.openstack.org/api-ref-identity-v2.html
{
OS-KSADM:service: {
id: 123,
name: nova,
type: compute,
description: OpenStack Compute Service
}
}
Based on the v3 API, type should be the only argument that is
required.
However, looking at what is implemented, there is very little validation
going on. 'id' is assigned set at the controller level:
https://github.com/openstack/keystone/blob/master/keystone/catalog/controllers.py#L53-L60
And 'enabled' which is missing from the API is set at the manager level:
https://github.com/openstack/keystone/blob/master/keystone/catalog/core.py#L145-L147
There is no validation performed at any level, leaving it up to the backends,
for the SQL backend for instance, only 'enabled' is required:
https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/sql.py#L57-L65
class Service(sql.ModelBase, sql.DictBase):
__tablename__ = 'service'
attributes = ['id', 'type', 'enabled']
id = sql.Column(sql.String(64), primary_key=True)
type = sql.Column(sql.String(255))
enabled = sql.Column(sql.Boolean, nullable=False, default=True,
server_default=sqlalchemy.sql.expression.true())
extra = sql.Column(sql.JsonBlob())
endpoints = sqlalchemy.orm.relationship(Endpoint, backref=service)
Which means the following call works, and is very useless:
$ http post http://localhost:35357/v2.0/OS-KSADM/services
'{OS-KSADM:service: {}}' --x-auth-token=ADMIN
{
OS-KSADM:service: {
type: null,
enabled: true,
id: fe937fd1152f494d88edd89e3adbfe1f
}
}
Keystoneclient requires name, type and description.
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v2_0/services.py#L38-L43
It should probably at least default some of those to None.
Lastly OpenstackClient has only 'name' as a required argument.
$ openstack service create --type service_type_1
usage: openstack service create [-h] [-f {html,json,shell,table,value,yaml}]
[-c COLUMN] [--max-width integer]
[--prefix PREFIX] --type service-type
[--description service-description]
service-name
openstack service create: error: too few arguments
We should probably make this similar to v3, where the only required argument
is 'type', and name/description are optional.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1404073/+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
