[Yahoo-eng-team] [Bug 1569404] Re: Remove threading before process forking
Reviewed: https://review.openstack.org/276842 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1cafff087194711399ad2a85a9f394f7204d7bdd Submitter: Jenkins Branch:master commit 1cafff087194711399ad2a85a9f394f7204d7bdd Author: dukhlov Date: Fri Feb 5 19:25:42 2016 +0200 Remove threading before process forking Forking a process when multiple threads are running is an unsafe operation and could cause a lot of problems because only current thread will continue working in child thread. Any locked by other thread resource will remain locked forever. We faced with this problem during oslo.messaging development and added workaround to hide this problem: https://review.openstack.org/#/c/274255/ I tried to fix this problem in oslo.service: https://review.openstack.org/#/c/270832/ but oslo folks said that this fix is ugly and it is wrong way to add workarounds to common libraries because projects use them incorrectly. I think that is fair. So this patch fixes incorrect usage of oslo libraries. In this patch I extended functionality of NeutronWorker and add there `worker_process_count` parameter which determines how many processes should be spawned for this worker. If `worker_process_count` = 0 - don't create process and spawn thread in scope of current process for worker Then I moved all background tasks to workers and return them by `get_workers` method. start_plugin_workers collects plugin's workers using `get_workers` method and starts in ProcessLauncher first workers with `worker_process_count` > 0 and only after this starts threaded workers by simple Launcher Closes-bug: #1569404 Change-Id: I0544f1d47ae53d572adda872847a56fa0b202d2e ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1569404 Title: Remove threading before process forking Status in neutron: Fix Released Bug description: Forking processes when a few threads are already running is potentially unsafe operation and could cause a lot of problems because only current thread will continue working in child thread. Any locked by other thread resource will remain locked forever. We faced with this problem during oslo.messaging development and added workaround to hide this problem: https://review.openstack.org/#/c/274255/ I tried to fix this problem in oslo.service: https://review.openstack.org/#/c/270832/ but oslo folks said that this fix is ugly and it is wrong way to add workarounds to common libraries because projects use them incorrectly. I think that is fare. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1569404/+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 1578047] [NEW] missing python library pycrypto in requireements.txt
Public bug reported: When I tried to install a nova-compute the way which is using python source, you would meet following log. It needs to be pycrypto in requirements.txt file. May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova sys.exit(main()) May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/opt/stack/nova/nova/cmd/compute.py", line 73, in main May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova db_allowed=CONF.conductor.use_local) May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/opt/stack/nova/nova/service.py", line 225, in create May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova db_allowed=db_allowed) May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/opt/stack/nova/nova/service.py", line 101, in __init__ May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova manager_class = importutils.import_class(self.manager_class_name) May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 30, in import_clas May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova __import__(mod_str) May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/opt/stack/nova/nova/compute/manager.py", line 56, in May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova from nova.cloudpipe import pipelib May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/opt/stack/nova/nova/cloudpipe/pipelib.py", line 33, in May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova from nova import crypto May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/opt/stack/nova/nova/crypto.py", line 29, in May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova from Crypto.PublicKey import RSA May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova ImportError: No module named Crypto.PublicKey May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova ** Affects: nova Importance: Undecided Assignee: Seungkyu Ahn (seungkyua) Status: New ** Changed in: nova Assignee: (unassigned) => Seungkyu Ahn (seungkyua) -- 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/1578047 Title: missing python library pycrypto in requireements.txt Status in OpenStack Compute (nova): New Bug description: When I tried to install a nova-compute the way which is using python source, you would meet following log. It needs to be pycrypto in requirements.txt file. May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova sys.exit(main()) May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/opt/stack/nova/nova/cmd/compute.py", line 73, in main May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova db_allowed=CONF.conductor.use_local) May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/opt/stack/nova/nova/service.py", line 225, in create May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova db_allowed=db_allowed) May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/opt/stack/nova/nova/service.py", line 101, in __init__ May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova manager_class = importutils.import_class(self.manager_class_name) May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 30, in import_clas May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova __import__(mod_str) May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/opt/stack/nova/nova/compute/manager.py", line 56, in May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova from nova.cloudpipe import pipelib May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova File "/opt/stack/nova/nova/cloudpipe/pipelib.py", line 33, in May 04 11:39:04 compute01 nova-compute[6270]: 2016-05-04 11:39:04.822 6270 ERROR nova from nova import crypto May 04 11:39:04 compute01 nova-compute[6270]: 201
[Yahoo-eng-team] [Bug 1578046] [NEW] Row actions (button group) shows text in white color, making them "invisible"
Public bug reported: Project -> Compute -> Instance How to reproduce: 1. Launch an Instance that will fail to boot, e.g. try to boot an instance demanding more resources than available. 2. See list of instances, search for the instance you just tried to boot and click on "Dropdown button" in "Actions" of its row. 3. Three options are listed: 1) Lock Instance (white colored) 2) Unlock Instance (white colored) 3) Delete Instance (red colored) The first two options (1 & 2) are impossible to read due to their color unless you "mouseover". These buttons have .btn-default with color: #FFF. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "bug instance error actions.png" https://bugs.launchpad.net/bugs/1578046/+attachment/4655018/+files/bug%20instance%20error%20actions.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/1578046 Title: Row actions (button group) shows text in white color, making them "invisible" Status in OpenStack Dashboard (Horizon): New Bug description: Project -> Compute -> Instance How to reproduce: 1. Launch an Instance that will fail to boot, e.g. try to boot an instance demanding more resources than available. 2. See list of instances, search for the instance you just tried to boot and click on "Dropdown button" in "Actions" of its row. 3. Three options are listed: 1) Lock Instance (white colored) 2) Unlock Instance (white colored) 3) Delete Instance (red colored) The first two options (1 & 2) are impossible to read due to their color unless you "mouseover". These buttons have .btn-default with color: #FFF. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1578046/+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 1477192] Re: test_dhcp6_stateless_from_os fails to ping intermittently
[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/1477192 Title: test_dhcp6_stateless_from_os fails to ping intermittently Status in neutron: Expired Bug description: This appears to be spiking since 7/22: http://logs.openstack.org/80/200380/3/gate/gate-tempest-dsvm-neutron- full/2b49b0d/console.html#_2015-07-22_09_57_50_146 2015-07-22 09:57:50.146 | tempest.scenario.test_network_v6.TestGettingAddress.test_multi_prefix_slaac[compute,id-dec222b1-180c-4098-b8c5-cc1b8342d611,network] 2015-07-22 09:57:50.146 | 2015-07-22 09:57:50.146 | 2015-07-22 09:57:50.146 | Captured traceback: 2015-07-22 09:57:50.146 | ~~~ 2015-07-22 09:57:50.147 | Traceback (most recent call last): 2015-07-22 09:57:50.147 | File "tempest/test.py", line 126, in wrapper 2015-07-22 09:57:50.147 | return f(self, *func_args, **func_kwargs) 2015-07-22 09:57:50.147 | File "tempest/scenario/test_network_v6.py", line 183, in test_multi_prefix_slaac 2015-07-22 09:57:50.147 | self._prepare_and_test(address6_mode='slaac', n_subnets6=2) 2015-07-22 09:57:50.147 | File "tempest/scenario/test_network_v6.py", line 150, in _prepare_and_test 2015-07-22 09:57:50.147 | result = sshv4_2.ping_host(ips_from_api_1['4']) 2015-07-22 09:57:50.147 | File "tempest/common/utils/linux/remote_client.py", line 101, in ping_host 2015-07-22 09:57:50.147 | return self.exec_command(cmd) 2015-07-22 09:57:50.147 | File "tempest/common/utils/linux/remote_client.py", line 56, in exec_command 2015-07-22 09:57:50.147 | return self.ssh_client.exec_command(cmd) 2015-07-22 09:57:50.147 | File "/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py", line 146, in exec_command 2015-07-22 09:57:50.148 | strerror=''.join(err_data)) 2015-07-22 09:57:50.148 | tempest_lib.exceptions.SSHExecCommandFailed: Command 'set -eu -o pipefail; PATH=$PATH:/sbin; ping -c1 -w1 -s56 10.100.0.3', exit status: 1, Error: There are so many errors in the neutron logs for false negatives that I can't really tell what could be causing the failures, see related bug 1455320 and related bug 1477190. http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiQ29tbWFuZCAnc2V0IC1ldSAtbyBwaXBlZmFpbDsgUEFUSD0kUEFUSDovc2JpbjsgcGluZyAtYzEgLXcxIC1zNTZcIiBBTkQgTk9UIGJ1aWxkX3F1ZXVlOlwiZXhwZXJpbWVudGFsXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0Mzc1NzU4NzgzNTYsIm1vZGUiOiIiLCJhbmFseXplX2ZpZWxkIjoiIn0= To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1477192/+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 1540983] Re: Gate failures for neutron in test_dualnet_multi_prefix_slaac
[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/1540983 Title: Gate failures for neutron in test_dualnet_multi_prefix_slaac Status in neutron: Expired Status in OpenStack-Gate: Expired Bug description: 24 hits in 7 days for logstash query : message:"in test_dualnet_multi_prefix_slaac" AND voting:1 2016-02-02 14:35:49.054 | Captured traceback: 2016-02-02 14:35:49.054 | ~~~ 2016-02-02 14:35:49.054 | Traceback (most recent call last): 2016-02-02 14:35:49.054 | File "tempest/test.py", line 113, in wrapper 2016-02-02 14:35:49.055 | return f(self, *func_args, **func_kwargs) 2016-02-02 14:35:49.055 | File "tempest/scenario/test_network_v6.py", line 246, in test_dualnet_multi_prefix_slaac 2016-02-02 14:35:49.055 | dualnet=True) 2016-02-02 14:35:49.055 | File "tempest/scenario/test_network_v6.py", line 155, in _prepare_and_test 2016-02-02 14:35:49.055 | sshv4_1, ips_from_api_1, sid1 = self.prepare_server(networks=net_list) 2016-02-02 14:35:49.055 | File "tempest/scenario/test_network_v6.py", line 128, in prepare_server 2016-02-02 14:35:49.055 | username=username) 2016-02-02 14:35:49.056 | File "tempest/scenario/manager.py", line 390, in get_remote_client 2016-02-02 14:35:49.056 | linux_client.validate_authentication() 2016-02-02 14:35:49.056 | File "tempest/common/utils/linux/remote_client.py", line 63, in validate_authentication 2016-02-02 14:35:49.056 | self.ssh_client.test_connection_auth() 2016-02-02 14:35:49.056 | File "/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py", line 172, in test_connection_auth 2016-02-02 14:35:49.056 | connection = self._get_ssh_connection() 2016-02-02 14:35:49.056 | File "/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py", line 87, in _get_ssh_connection 2016-02-02 14:35:49.057 | password=self.password) 2016-02-02 14:35:49.057 | tempest_lib.exceptions.SSHTimeout: Connection to the 172.24.5.141 via SSH timed out. 2016-02-02 14:35:49.057 | User: cirros, Password: None To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1540983/+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 1540983] Re: Gate failures for neutron in test_dualnet_multi_prefix_slaac
[Expired for OpenStack-Gate because there has been no activity for 60 days.] ** Changed in: openstack-gate 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/1540983 Title: Gate failures for neutron in test_dualnet_multi_prefix_slaac Status in neutron: Expired Status in OpenStack-Gate: Expired Bug description: 24 hits in 7 days for logstash query : message:"in test_dualnet_multi_prefix_slaac" AND voting:1 2016-02-02 14:35:49.054 | Captured traceback: 2016-02-02 14:35:49.054 | ~~~ 2016-02-02 14:35:49.054 | Traceback (most recent call last): 2016-02-02 14:35:49.054 | File "tempest/test.py", line 113, in wrapper 2016-02-02 14:35:49.055 | return f(self, *func_args, **func_kwargs) 2016-02-02 14:35:49.055 | File "tempest/scenario/test_network_v6.py", line 246, in test_dualnet_multi_prefix_slaac 2016-02-02 14:35:49.055 | dualnet=True) 2016-02-02 14:35:49.055 | File "tempest/scenario/test_network_v6.py", line 155, in _prepare_and_test 2016-02-02 14:35:49.055 | sshv4_1, ips_from_api_1, sid1 = self.prepare_server(networks=net_list) 2016-02-02 14:35:49.055 | File "tempest/scenario/test_network_v6.py", line 128, in prepare_server 2016-02-02 14:35:49.055 | username=username) 2016-02-02 14:35:49.056 | File "tempest/scenario/manager.py", line 390, in get_remote_client 2016-02-02 14:35:49.056 | linux_client.validate_authentication() 2016-02-02 14:35:49.056 | File "tempest/common/utils/linux/remote_client.py", line 63, in validate_authentication 2016-02-02 14:35:49.056 | self.ssh_client.test_connection_auth() 2016-02-02 14:35:49.056 | File "/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py", line 172, in test_connection_auth 2016-02-02 14:35:49.056 | connection = self._get_ssh_connection() 2016-02-02 14:35:49.056 | File "/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py", line 87, in _get_ssh_connection 2016-02-02 14:35:49.057 | password=self.password) 2016-02-02 14:35:49.057 | tempest_lib.exceptions.SSHTimeout: Connection to the 172.24.5.141 via SSH timed out. 2016-02-02 14:35:49.057 | User: cirros, Password: None To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1540983/+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 1578009] [NEW] Add 'help_url' example to local_settings.py
Public bug reported: Following instructions here: http://docs.openstack.org/admin- guide/common/dashboard_customizing.html, in section #Help URL, will break Horizon. Docs say to edit 'help_url' in local_settings.py, but the option isnt there. Please add a line: HORIZON_CONFIG["help_url"] = "http://openstack.mycompany.org"; I have also opened another bug in openstack-manuals to get docs updated: https://bugs.launchpad.net/openstack-manuals/+bug/1578008 ** 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/1578009 Title: Add 'help_url' example to local_settings.py Status in OpenStack Dashboard (Horizon): New Bug description: Following instructions here: http://docs.openstack.org/admin- guide/common/dashboard_customizing.html, in section #Help URL, will break Horizon. Docs say to edit 'help_url' in local_settings.py, but the option isnt there. Please add a line: HORIZON_CONFIG["help_url"] = "http://openstack.mycompany.org"; I have also opened another bug in openstack-manuals to get docs updated: https://bugs.launchpad.net/openstack-manuals/+bug/1578008 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1578009/+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 1577996] [NEW] Unable to distinguish between not is_admin_project and feature not enabled
Public bug reported: The is_admin_project flag is used in a token to indicate that the current token is scoped to a project that is indicated as the admin project. Currently this is only added to the token when the admin_project is True and nothing added when False. >From a policy perspective we need to write policy files that are backwards compatible, however we cannot determine the difference in policy between is_admin_project == False and the admin project not being set from config because both result in no flag being set in the token. If we were to enforce is_admin_project == True on a deployment that did not use it this would completely break backwards compatibility as the is_admin_project check would never pass. To fix this we need to make is_admin_project a required field of a token at least when the admin project is set. Because the current default is that every project can be the admin project, the default value of is_admin_project must be True. For deployments that do not configure an admin project we can either set is_admin_project=True for every project, or we can exclude the field from the token. I think exclude makes sense because the check from a policy perspective is going to have to default to True for backwards compatibility and you can then tell from a token whether the admin_project concept is in use (i'm not sure if this is an information leakage problem - please comment on preference). ** Affects: keystone Importance: Undecided Assignee: Adam Young (ayoung) Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1577996 Title: Unable to distinguish between not is_admin_project and feature not enabled Status in OpenStack Identity (keystone): New Bug description: The is_admin_project flag is used in a token to indicate that the current token is scoped to a project that is indicated as the admin project. Currently this is only added to the token when the admin_project is True and nothing added when False. From a policy perspective we need to write policy files that are backwards compatible, however we cannot determine the difference in policy between is_admin_project == False and the admin project not being set from config because both result in no flag being set in the token. If we were to enforce is_admin_project == True on a deployment that did not use it this would completely break backwards compatibility as the is_admin_project check would never pass. To fix this we need to make is_admin_project a required field of a token at least when the admin project is set. Because the current default is that every project can be the admin project, the default value of is_admin_project must be True. For deployments that do not configure an admin project we can either set is_admin_project=True for every project, or we can exclude the field from the token. I think exclude makes sense because the check from a policy perspective is going to have to default to True for backwards compatibility and you can then tell from a token whether the admin_project concept is in use (i'm not sure if this is an information leakage problem - please comment on preference). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1577996/+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 1490531] Re: api: deprecate the concept of extensions in v2.1
Reviewed: https://review.openstack.org/310399 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=75280e582e6d607b38bc2af9f51f80fd5135453c Submitter: Jenkins Branch:master commit 75280e582e6d607b38bc2af9f51f80fd5135453c Author: sharat.sharma Date: Wed Apr 27 15:26:03 2016 +0530 Deprecated the concept of extensions in v2.1. The extensions in api-ref-compute-v2.1 is deprecated. This patch depricates the extension infrastructure in v2.1. Change-Id: Ie7731c25ee7c5c662c22835add3314ffa51f37bc Closes-Bug: #1490531 ** Changed in: nova Status: In Progress => Fix Released -- 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/1490531 Title: api: deprecate the concept of extensions in v2.1 Status in OpenStack Compute (nova): Fix Released Bug description: https://review.openstack.org/214592 commit 11507eeceb2c56e50e9fe030a70470a02f577f2a Author: John Garbutt Date: Wed Aug 19 13:46:52 2015 +0100 api: deprecate the concept of extensions in v2.1 We want to remove the extension infrastructure in the v2.1 API during the next release. To make that possible, we must deprecate the configuration now. Also deprecating the osapi_v3 group, and moving to osapi_v21. UpgradeImpact DocImpact Part of blueprint nova-api-deprecate-extensions Change-Id: I08b11dceda7cf8f88c157aa67d36490fce49 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1490531/+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 1521791] Re: Nova client incorrectly lists block storage size units in GB
Reviewed: https://review.openstack.org/310414 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=4c5ba52b7421734e1910d2611cb72bbaa2536d69 Submitter: Jenkins Branch:master commit 4c5ba52b7421734e1910d2611cb72bbaa2536d69 Author: sharat.sharma Date: Wed Apr 27 16:40:01 2016 +0530 Changed the storage size from GB to GiB. Change-Id: Iede32b2764b9329bf9dc3d8aec02064db1f16d05 Closes-Bug: #1521791 ** Changed in: nova Status: In Progress => Fix Released -- 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/1521791 Title: Nova client incorrectly lists block storage size units in GB Status in OpenStack Compute (nova): Fix Released Status in openstack-api-site: Invalid Status in python-novaclient: In Progress Bug description: Both Horizon and the nova client documents the block storage size parameters in gigabytes(GB), when it should be in gibibytes (GiB). Both the cinder and manila clients and associated Horizon panels have been changed to address this issue. Nova should follow suit for consistency. Related bugs: https://bugs.launchpad.net/horizon/+bug/1511167 https://bugs.launchpad.net/python-manilaclient/+bug/1516841 https://bugs.launchpad.net/horizon/+bug/1516848 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1521791/+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 1577991] [NEW] No exception mapping between glance and glance_store
Public bug reported: 2016-05-04 11:06:59.717 2854 ERROR glance.common.wsgi [req-9f9d9912-e5ba-4ed1-89bd-e8e13b7a97fc 79f60e6ab1bf4b2fbe7987c6c2b57e63 94b566de52f9423fab80ceee8c0a4a23 - - -] Caught error: The image cannot be deleted because it is in use through the backend store outside of Glance. 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi Traceback (most recent call last): 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/common/wsgi.py", line 881, in __call__ 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi request, **action_args) 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/common/wsgi.py", line 909, in dispatch 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi return method(*args, **kwargs) 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/common/utils.py", line 508, in wrapped 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi return func(self, req, *args, **kwargs) 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/api/v1/images.py", line 1099, in delete 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi {'status': ori_status}) 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/oslo_utils/excutils.py", line 85, in __exit__ 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi six.reraise(self.type_, self.value, self.tb) 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/api/v1/images.py", line 1095, in delete 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi upload_utils.initiate_deletion(req, loc_data, id) 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/api/v1/upload_utils.py", line 46, in initiate_deletion 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi id, location_data) 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/common/store_utils.py", line 124, in delete_image_location_from_backend 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi safe_delete_from_backend(context, image_id, location) 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/common/store_utils.py", line 58, in safe_delete_from_backend 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi ret = store_api.delete_from_backend(location['url'], context=context) 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance_store/backend.py", line 290, in delete_from_backend 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi return store.delete(loc, context=context) 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance_store/capabilities.py", line 226, in op_checker 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi return store_op_fun(store, *args, **kwargs) 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance_store/_drivers/rbd.py", line 410, in delete 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi self._delete_image(target_pool, loc.image, loc.snapshot) 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi File "/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance_store/_drivers/rbd.py", line 304, in _delete_image 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi raise exceptions.InUseByStore() 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi InUseByStore: The image cannot be deleted because it is in use through the backend store outside of Glance. 2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi 2016-05-04 11:06:59.722 2854 INFO eventlet.wsgi.server [req-9f9d9912-e5ba-4ed1-89bd-e8e13b7a97fc 79f60e6ab1bf4b2fbe7987c6c2b57e63 94b566de52f9423fab80ceee8c0a4a23 - - -] 10.13.0.41 - - [04/May/2016 11:06:59] "DELETE /v1/images/a8876333-16c5-4a21-a3fb-7b24c29a7308 HTTP/1.1" 500 430 0.513240 ** Affects: glance Importance: Undecided Assignee: Fei Long Wang (flwang) Status: Invalid ** Changed in: glance Assignee: (unassigned) => Fei Long Wang (flwang) ** 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/1577991 Title: No exception mapping between glance and glance_store Statu
[Yahoo-eng-team] [Bug 1577987] [NEW] neutron-lbaas v2 - update pool's session_persistence to None fails
Public bug reported: When updating a pool's session_persistence to None, I get the following error: Invalid input for session_persistence 1. Create a loadbalancer, listener 2. Create a pool with default args: using postman: { "pool": { "name": "pool1", "description": "simple pool", "listener_id": "39de4d56-d663-46e5-85a1-5b9d5fa17829", "lb_algorithm": "ROUND_ROBIN", "protocol": "HTTP", "session_persistence": { "type": "APP_COOKIE", "cookie_name": "my_cookie" }, "admin_state_up": true } } Update pool with below data: { "pool": { "session_persistence": {"type": ""} } } neutron-server logs: 2016-05-03 16:39:54.698 DEBUG neutron.wsgi [-] (66382) accepted ('192.168.109.128', 58400) from (pid=66382) server /usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py:867 2016-05-03 16:39:55.025 DEBUG neutron.api.v2.base [req-78bc175f-374d-403c-b5a5-845d4bc79632 admin be81e9163d074036913aa52b1b9785a7] Request body: {u'pool': {u'session_persistence': {u'type': u''}}} from (pid=66382) prepare_request_body /opt/stack/neutron/neutron/api/v2/base.py:658 2016-05-03 16:39:55.025 DEBUG neutron_lib.api.validators [req-78bc175f-374d-403c-b5a5-845d4bc79632 admin be81e9163d074036913aa52b1b9785a7] ' ' is not in ('SOURCE_IP', 'HTTP_COOKIE', 'APP_COOKIE') from (pid=66382) validate_values /usr/local/lib/python2.7/dist-packages/neutron_lib/api/validators.py:91 2016-05-03 16:39:55.026 INFO neutron.api.v2.resource [req-78bc175f-374d-403c-b5a5-845d4bc79632 admin be81e9163d074036913aa52b1b9785a7] update failed (client error): Invalid input for session_persistence. Reason: '' is not in ('SOURCE_IP', 'HTTP_COOKIE', 'APP_COOKIE'). 2016-05-03 16:39:55.027 INFO neutron.wsgi [req-78bc175f-374d-403c-b5a5-845d4bc79632 admin be81e9163d074036913aa52b1b9785a7] 192.168.109.128 - - [03/May/2016 16:39:55] "PUT /v2.0/lbaas/pools/aa341feb-ff6f-4d87-a613-52812c665bc0 HTTP/1.1" 400 400 0.327893 using CLI: neutron lbaas-pool-update pool1 --session_persistence type=dict type=none Invalid input for session_persistence. Reason: 'none' is not in ('SOURCE_IP', 'HTTP_COOKIE', 'APP_COOKIE'). Neutron server returns request_ids: ['req-93cc8a21-4243-4498-899c-fc9646cddb71'] neutron-server logs: 2016-05-03 16:41:31.834 DEBUG neutron_lbaas.drivers.octavia.octavia_messaging_consumer [-] Received event from stream {u'info_type': u'listener_stats', u'info_id': u'04c16cac-b748-47a6-975f-b109bd80a419', u'info_payload': {u'bytes_in': 0, u'total_connections': 0, u'active_connections': 0, u'bytes_out': 0}} from (pid=66202) update_info /opt/stack/neutron-lbaas/neutron_lbaas/drivers/octavia/octavia_messaging_consumer.py:74 2016-05-03 16:41:34.571 DEBUG neutron.wsgi [-] (66383) accepted ('192.168.109.128', 59130) from (pid=66383) server /usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py:867 2016-05-03 16:41:35.079 INFO neutron.wsgi [req-695f0831-c84d-43b3-ae37-764cd4a4fd9c admin be81e9163d074036913aa52b1b9785a7] 192.168.109.128 - - [03/May/2016 16:41:35] "GET /v2.0/lbaas/pools.json?fields=id&name=pool1 HTTP/1.1" 200 607 0.506676 2016-05-03 16:41:35.333 DEBUG neutron.api.v2.base [req-93cc8a21-4243-4498-899c-fc9646cddb71 admin be81e9163d074036913aa52b1b9785a7] Request body: {u'pool': {u'session_persistence': {u'type': u'none'}}} from (pid=66383) prepare_request_body /opt/stack/neutron/neutron/api/v2/base.py:658 2016-05-03 16:41:35.335 DEBUG neutron_lib.api.validators [req-93cc8a21-4243-4498-899c-fc9646cddb71 admin be81e9163d074036913aa52b1b9785a7] 'none' is not in ('SOURCE_IP', 'HTTP_COOKIE', 'APP_COOKIE') from (pid=66383) validate_values /usr/local/lib/python2.7/dist-packages/neutron_lib/api/validators.py:91 2016-05-03 16:41:35.336 INFO neutron.api.v2.resource [req-93cc8a21-4243-4498-899c-fc9646cddb71 admin be81e9163d074036913aa52b1b9785a7] update failed (client error): Invalid input for session_persistence. Reason: 'none' is not in ('SOURCE_IP', 'HTTP_COOKIE', 'APP_COOKIE'). 2016-05-03 16:41:35.342 INFO neutron.wsgi [req-93cc8a21-4243-4498-899c-fc9646cddb71 admin be81e9163d074036913aa52b1b9785a7] 192.168.109.128 - - [03/May/2016 16:41:35] "PUT /v2.0/lbaas/pools/aa341feb-ff6f-4d87-a613-52812c665bc0.json HTTP/1.1" 400 403 0.258400 2016-05-03 16:41:36.258 DEBUG oslo_messaging._drivers.amqpdriver [-] received message msg_id: None reply to None from (pid=66384) __call__ /usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:201 ** Affects: neutron Importance: Undecided Status: New ** Tags: lbaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1577987 Title: neutron-lbaas v2 - update pool's session_persistence to None fails Status in neutron: New Bug description: When updating a pool's session_persistence to None, I get the following error: Invalid
[Yahoo-eng-team] [Bug 1577982] [NEW] ConfigDrive: cloud-init fails to configure network from network_data.json
Public bug reported: When running Ubuntu 16.04 on OpenStack, cloud-init fails to properly configure the network from network_data.json found in ConfigDrive. When instance boots, network is configured fine until next reboot where it falls back to dhcp. The /etc/network/interfaces.d/50-cloud-init.cfg file has the following content when instance is initially booted, this could explain why dhcp is used on second boot: auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp When debugging, if this line in stages.py [1] is commented, we can see that cloud-init initially copy the /etc/network/interfaces file found in the configdrive (the network template injected by Nova) and isn't using the network config found in network_data.json. But later it falls back to "dhcp" and rewrites yet again the network config. I also found that within self._find_networking_config(), it looks like no datasource is found at this point. This could be because cloud-init is still in "local" dsmode and then refuses to use the network config found in the ConfigDrive. (triggering the "dhcp" fallback logic) Manually forcing "net" dsmode makes cloud-init configure /etc/network/interfaces.d/50-cloud-init.cfg properly with network config found in the ConfigDrive. However no gateway is configured and so, instance doesn't respond to ping or SSH. At that point, I'm not sure what's going on and how I can debug further. Notes: * The image used for testing uses "net.ifnames=0". Removing this config makes things much worst. (no ping at all on first boot) * Logs, configs and configdrive can be found attached to this bug report. [1] http://bazaar.launchpad.net/~cloud-init-dev/cloud- init/trunk/view/head:/cloudinit/stages.py#L604 ** Affects: cloud-init Importance: Undecided Status: New ** Attachment added: "cloud-init configs, logs and configdrive" https://bugs.launchpad.net/bugs/1577982/+attachment/4654849/+files/debug.tar.gz -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1577982 Title: ConfigDrive: cloud-init fails to configure network from network_data.json Status in cloud-init: New Bug description: When running Ubuntu 16.04 on OpenStack, cloud-init fails to properly configure the network from network_data.json found in ConfigDrive. When instance boots, network is configured fine until next reboot where it falls back to dhcp. The /etc/network/interfaces.d/50-cloud-init.cfg file has the following content when instance is initially booted, this could explain why dhcp is used on second boot: auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp When debugging, if this line in stages.py [1] is commented, we can see that cloud-init initially copy the /etc/network/interfaces file found in the configdrive (the network template injected by Nova) and isn't using the network config found in network_data.json. But later it falls back to "dhcp" and rewrites yet again the network config. I also found that within self._find_networking_config(), it looks like no datasource is found at this point. This could be because cloud-init is still in "local" dsmode and then refuses to use the network config found in the ConfigDrive. (triggering the "dhcp" fallback logic) Manually forcing "net" dsmode makes cloud-init configure /etc/network/interfaces.d/50-cloud-init.cfg properly with network config found in the ConfigDrive. However no gateway is configured and so, instance doesn't respond to ping or SSH. At that point, I'm not sure what's going on and how I can debug further. Notes: * The image used for testing uses "net.ifnames=0". Removing this config makes things much worst. (no ping at all on first boot) * Logs, configs and configdrive can be found attached to this bug report. [1] http://bazaar.launchpad.net/~cloud-init-dev/cloud- init/trunk/view/head:/cloudinit/stages.py#L604 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1577982/+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 1544720] Re: In response template processing, some values are set to u'' instead of None
I couldn't reproduce the bug. I changed the value for OS-EXT-SRV-ATTR:kernel_id from null to "test_kernel" in both server-get-resp.json.tpl and server-get-resp.json. Test fails because value in template(test_kernel) and actual response('') is different. This is expected. Also value in Response is not u'' as mentioned in the description. I don't see any unexpected behavior. Moving the bug to invalid. ** Changed in: nova Status: Confirmed => 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/1544720 Title: In response template processing, some values are set to u'' instead of None Status in OpenStack Compute (nova): Invalid Bug description: I discovered this bug while refactoring functional tests. This happens in the current Nova master. Update the following files: - nova/tests/functional/api_sample_tests/api_samples/os-extended-server-attributes/v2.16/server-get-resp.json.tpl - nova/doc/api_samples/os-extended-server-attributes/v2.16/server-get-resp.json Set the field "OS-EXT-SRV-ATTR:kernel_id" from "null" to a value. Run functional tests (or just nova/tests/functional/api_sample_tests/test_extended_server_attributes.py) and you'll see that the value you for the response has been replaced with u''. Not sure if this is in nova itself or just the test framework, more research needed. I'm creating this bug to make sure I don't forget to come back and troubleshoot this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1544720/+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 1577913] [NEW] [RFE] On-demand segment and subnet allocation
Public bug reported: While routed networks [1] provides us the capability of managing L2 segments and related subnets with a view of L3 network, it assumes that the related infrastructure resources are always provisioned (vlans, host-segment bindings, subnets) beforehand and is not managed by neutron. However, in a large deployment cloud, there are use cases for on-demand resource provisioning. - On-demand segment provisioning: A host can be multi-tenancy, so when a host is provisioned, it may be unknown which tenant's VMs will be scheduled to the host. So some segments may not be needed for the host. It will be good if we can dynamically create the segment (i.e. create the vlan on the ToR) when the first VM of the tenant is scheduled under the ToR, then we don't need to pre-allocate all the possible vlans and create segments for all the ToRs. The information that is known duiring host onboarding is the ToR that the host is located. So we can model this as a BridgeGroup object (a group of vlans/l2 segments spanning across the same set of hosts, which are usually connected to a group of devices, and number of devices are usually 1, e.g. the ToR connecting the hosts under a rack), and BridgeGroup-Host mapping. And when the first neutron port is requested to be created on a routed network for a host under a BridgeGroup, a new segment is created and bound to the host. - On-demand subnet provisioning: In a shared infrastructure the workload location is flexible, so it is hard to predict the number of IPs required for a segment. To use IP resource (especially IPv4) efficiently, it will be good to be able to dynamically allocate subnets to a segment only when it is needed, i.e. when there are workloads scheduled to the segment. This feature request requires [1] but put additional requirements on top of it. [1] https://review.openstack.org/#/c/225384/ ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1577913 Title: [RFE] On-demand segment and subnet allocation Status in neutron: New Bug description: While routed networks [1] provides us the capability of managing L2 segments and related subnets with a view of L3 network, it assumes that the related infrastructure resources are always provisioned (vlans, host-segment bindings, subnets) beforehand and is not managed by neutron. However, in a large deployment cloud, there are use cases for on-demand resource provisioning. - On-demand segment provisioning: A host can be multi-tenancy, so when a host is provisioned, it may be unknown which tenant's VMs will be scheduled to the host. So some segments may not be needed for the host. It will be good if we can dynamically create the segment (i.e. create the vlan on the ToR) when the first VM of the tenant is scheduled under the ToR, then we don't need to pre-allocate all the possible vlans and create segments for all the ToRs. The information that is known duiring host onboarding is the ToR that the host is located. So we can model this as a BridgeGroup object (a group of vlans/l2 segments spanning across the same set of hosts, which are usually connected to a group of devices, and number of devices are usually 1, e.g. the ToR connecting the hosts under a rack), and BridgeGroup-Host mapping. And when the first neutron port is requested to be created on a routed network for a host under a BridgeGroup, a new segment is created and bound to the host. - On-demand subnet provisioning: In a shared infrastructure the workload location is flexible, so it is hard to predict the number of IPs required for a segment. To use IP resource (especially IPv4) efficiently, it will be good to be able to dynamically allocate subnets to a segment only when it is needed, i.e. when there are workloads scheduled to the segment. This feature request requires [1] but put additional requirements on top of it. [1] https://review.openstack.org/#/c/225384/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1577913/+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 1577909] [NEW] hz-dynamic-table has two magic-search bars
Public bug reported: The hz-dynamic-table directive's template has two magic-search bars, one correctly outside the table, the other incorrectly placed inside the table. The one inside the table should be removed. A proper implementation of the hz-dynamic-table directive using magic- search will illustrate the problem. ** Affects: horizon Importance: Undecided Assignee: Matt Borland (palecrow) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1577909 Title: hz-dynamic-table has two magic-search bars Status in OpenStack Dashboard (Horizon): In Progress Bug description: The hz-dynamic-table directive's template has two magic-search bars, one correctly outside the table, the other incorrectly placed inside the table. The one inside the table should be removed. A proper implementation of the hz-dynamic-table directive using magic- search will illustrate the problem. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1577909/+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 1361554] Re: Missing sort_key and sort_dir for server list api
Marking it as "invalid" due to existing similar patch https://review.openstack.org/#/c/96345/ ** Changed in: nova Status: Confirmed => 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/1361554 Title: Missing sort_key and sort_dir for server list api Status in OpenStack Compute (nova): Invalid Bug description: Since the compute api now supporting sort_dir and sort_key [1], we may need to add this to the REST api. [1]: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1790 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1361554/+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 1571628] Re: os-server-groups description is missing
I'm going to mark this as invalid to get it out of the bug queue. We'll fix this as part of the work in https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst . ** Changed in: nova 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/1571628 Title: os-server-groups description is missing Status in OpenStack Compute (nova): Invalid Bug description: Description of os-server-groups is missing from the Compute API reference [1]. [1]: http://developer.openstack.org/api-ref-compute-v2.1.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1571628/+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 1525806] Re: An incorrect value for block_device_mapping_v2 causes HTTP 500 response when creating a VM instance
Reviewed: https://review.openstack.org/258788 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=9ad3dad0c6ab868566e74f0c35a5375d4eaad560 Submitter: Jenkins Branch:master commit 9ad3dad0c6ab868566e74f0c35a5375d4eaad560 Author: Takashi NATSUME Date: Mon Mar 14 14:26:11 2016 +0900 Add validations for volume_size and destination_type Add validations for volume_size and destination_type of block device mapping when creating an instance in order to avoid HTTP 500 errors. Validations has been added in V2.1 API only. Validations that has been added are as follows: * volume_size: an empty string * volume_size: zero * volume_size: greater than DB column's limit * destination_type: an empty string * destination_type: invalid value Change-Id: I2d3084cccd15f409616031f106c611ff07ac4abf Closes-Bug: #1525806 ** Changed in: nova Status: In Progress => Fix Released -- 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/1525806 Title: An incorrect value for block_device_mapping_v2 causes HTTP 500 response when creating a VM instance Status in OpenStack Compute (nova): Fix Released Bug description: An incorrect value for block_device_mapping_v2 causes HTTP 500 response when creating a VM instance. It should be validated and not to return HTTP 500 response. [How to reproduce] a) destination_type is ""(an empty string) Execute the following command(REST API). curl -g -i --cacert "/opt/stack/data/CA/int-ca/ca-chain.pem" -X POST http://10.0.2.15:8774/v2.1/e7e043ffac8d4325b2872bd2b53cce2b/os-volumes_boot -H "User-Agent: python-novaclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}00abb28e025a6770fc13d70fc6a41e327bca90d6" -d '{"server": {"name": "server1", "imageRef": "", "block_device_mapping_v2": [{"boot_index": "0", "uuid": "4115a0d1-eee2-4c3e-847d-e50250a989a3", "volume_size": "1", "source_type": "image", "destination_type": "", "delete_on_termination": false}], "flavorRef": "1", "max_count": 1, "min_count": 1}}' The response is as follows: -- HTTP/1.1 500 Internal Server Error X-Openstack-Nova-Api-Version: 2.6 Vary: X-OpenStack-Nova-API-Version Content-Length: 194 Content-Type: application/json; charset=UTF-8 X-Compute-Request-Id: req-29fb2efe-eda8-43dd-8ea1-5f73b86f6171 Date: Mon, 14 Dec 2015 07:17:24 GMT {"computeFault": {"message": "Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n", "code": 500}} -- b) destination_type is neither 'volume' nor 'local' Execute the following command(REST API). curl -g -i --cacert "/opt/stack/data/CA/int-ca/ca-chain.pem" -X POST http://10.0.2.15:8774/v2.1/e7e043ffac8d4325b2872bd2b53cce2b/os-volumes_boot -H "User-Agent: python-novaclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}7add7a5e501cc287f6043d83144ea24a69134ae7" -d '{"server": {"name": "server1", "imageRef": "", "block_device_mapping_v2": [{"boot_index": "0", "uuid": "4115a0d1-eee2-4c3e-847d-e50250a989a3", "volume_size": "1", "source_type": "image", "destination_type": "X", "delete_on_termination": false}], "flavorRef": "1", "max_count": 1, "min_count": 1}}' The response is as follows: -- HTTP/1.1 500 Internal Server Error X-Openstack-Nova-Api-Version: 2.6 Vary: X-OpenStack-Nova-API-Version Content-Length: 194 Content-Type: application/json; charset=UTF-8 X-Compute-Request-Id: req-f3644722-ba2c-49bf-9db0-badfd7dffa30 Date: Mon, 14 Dec 2015 07:30:02 GMT {"computeFault": {"message": "Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n", "code": 500}} -- c) volume_size is ""(an empty string) Execute the following command(REST API). curl -g -i --cacert "/opt/stack/data/CA/int-ca/ca-chain.pem" -X POST http://10.0.2.15:8774/v2.1/e7e043ffac8d4325b2872bd2b53cce2b/os-volumes_boot -H "User-Agent: python-novaclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}85cc81c3f710561ddd640ce26c41990703d925ce" -d '{"server": {"name": "server1", "imageRef": "", "block_device_mapping_v2": [{"boot_index": "0", "uuid": "4115a0d1-eee2-4c3e-847d-e50250a989a3", "volume_size": "", "source_type": "image", "destination_type": "volume", "delete_on_termination": false}], "flavorRef": "1", "max_count": 1, "min_count": 1}}' The response is as follows: -- HTTP/1.1 500 Internal Server Error X-Openstack-Nova-Api-Version: 2.1 Vary: X-OpenStack-Nova-API-Version Content-Length: 194
[Yahoo-eng-team] [Bug 1554231] Re: Clean up warnings about keystoneclient.adapter.Adapter
These warnings get triggered by the python-cinderlient which uses deprecated keystoneclient code. Nova cannot prevent that. The Cinder folks should look into that. Captured traceback: ~~~ Traceback (most recent call last): File "nova/tests/unit/test_cinder.py", line 238, in test_volume_without_attachment volume = self.api.get(self.context, '5678') File "nova/volume/cinder.py", line 232, in wrapper res = method(self, ctx, *args, **kwargs) File "nova/volume/cinder.py", line 255, in wrapper res = method(self, ctx, volume_id, *args, **kwargs) File "nova/volume/cinder.py", line 301, in get item = cinderclient(context).volumes.get(volume_id) File "nova/volume/cinder.py", line 147, in cinderclient **service_parameters) File "/home/mzoeller/git/nova/.tox/py27/lib/python2.7/site-packages/cinderclient/client.py", line 634, in Client return client_class(*args, **kwargs) File "/home/mzoeller/git/nova/.tox/py27/lib/python2.7/site-packages/cinderclient/v2/client.py", line 117, in __init__ **kwargs) File "/home/mzoeller/git/nova/.tox/py27/lib/python2.7/site-packages/cinderclient/client.py", line 551, in _construct_http_client **kwargs) File "/home/mzoeller/git/nova/.tox/py27/lib/python2.7/site-packages/positional/__init__.py", line 101, in inner return wrapped(*args, **kwargs) File "/home/mzoeller/git/nova/.tox/py27/lib/python2.7/site-packages/keystoneclient/adapter.py", line 54, in __init__ raise Exception("mzoeller: baem!!") Exception: mzoeller: baem!! ** Project changed: nova => python-cinderclient -- 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/1554231 Title: Clean up warnings about keystoneclient.adapter.Adapter Status in python-cinderclient: Confirmed Bug description: Nova test runs output a bunch of warnings about keystoneclient.adapter.Adapter: Captured stderr: /home/jaypipes/repos/nova/.tox/py27/local/lib/python2.7/site-packages/keystoneclient/adapter.py:57: DeprecationWarning: keystoneclient.adapter.Adapter is deprecated as of the 2.1.0 release in favor of keystoneauth1.adapter.Adapter. It will be removed in future releases. 'removed in future releases.', DeprecationWarning) To manage notifications about this bug go to: https://bugs.launchpad.net/python-cinderclient/+bug/1554231/+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 1577861] [NEW] error when Populate the database Neutron on controller node
Public bug reported: I am following the Openstack documentation http://docs.openstack.org/mitaka/install-guide-ubuntu/neutron- controller-install.html for installing Openstack on Ubuntu server 14.04. there is an instruction to finalize the installation of Neutron on the controller node with the following command; # su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \ --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron However, I get the following error; root@controller:/home/controller # su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \ --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron No handlers could be found for logger "oslo_config.cfg" INFO [alembic.runtime.migration] Context impl SQLiteImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. Running upgrade for neutron ... INFO [alembic.runtime.migration] Context impl SQLiteImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. INFO [alembic.runtime.migration] Running upgrade dce3ec7a25c9 -> c3a73f615e4, Add ip_version to AddressScope Traceback (most recent call last): File "/usr/bin/neutron-db-manage", line 10, in sys.exit(main()) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 753, in main return_val |= bool(CONF.command.func(config, CONF.command.name)) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 226, in do_upgrade desc=branch, sql=CONF.command.sql) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 128, in do_alembic_command getattr(alembic_command, cmd)(config, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/alembic/command.py", line 174, in upgrade script.run_env() File "/usr/lib/python2.7/dist-packages/alembic/script/base.py", line 397, in run_env util.load_python_file(self.dir, 'env.py') File "/usr/lib/python2.7/dist-packages/alembic/util/pyfiles.py", line 81, in load_python_file module = load_module_py(module_id, path) File "/usr/lib/python2.7/dist-packages/alembic/util/compat.py", line 79, in load_module_py mod = imp.load_source(module_id, path, fp) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/env.py", line 126, in run_migrations_online() File "/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/env.py", line 120, in run_migrations_online context.run_migrations() File "", line 8, in run_migrations File "/usr/lib/python2.7/dist-packages/alembic/runtime/environment.py", line 797, in run_migrations self.get_context().run_migrations(**kw) File "/usr/lib/python2.7/dist-packages/alembic/runtime/migration.py", line 312, in run_migrations step.migration_fn(**kw) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/versions/mitaka/expand/c3a73f615e4_add_ip_version_to_address_scope.py", line 33, in upgrade sa.Column('ip_version', sa.Integer(), nullable=False)) File "", line 8, in add_column File "", line 3, in add_column File "/usr/lib/python2.7/dist-packages/alembic/operations/ops.py", line 1535, in add_column return operations.invoke(op) File "/usr/lib/python2.7/dist-packages/alembic/operations/base.py", line 318, in invoke return fn(self, operation) File "/usr/lib/python2.7/dist-packages/alembic/operations/toimpl.py", line 123, in add_column schema=schema File "/usr/lib/python2.7/dist-packages/alembic/ddl/impl.py", line 172, in add_column self._exec(base.AddColumn(table_name, column, schema=schema)) File "/usr/lib/python2.7/dist-packages/alembic/ddl/impl.py", line 118, in _exec return conn.execute(construct, *multiparams, **params) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 914, in execute return meth(self, multiparams, params) File "/usr/lib/python2.7/dist-packages/sqlalchemy/sql/ddl.py", line 68, in _execute_on_connection return connection._execute_ddl(self, multiparams, params) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 968, in _execute_ddl compiled File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1146, in _execute_context context) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1337, in _handle_dbapi_exception util.raise_from_cause(newraise, exc_info) File "/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 200, in raise_from_cause reraise(type(exception), exception, tb=exc_tb) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1139, in _execute_context context) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 450, in do_execute cursor.execute(statement, parameters) sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) Cannot add a NOT NULL column with default value NULL
[Yahoo-eng-team] [Bug 1577727] Re: nova flavor-create raises 500 error if long value passed to flavor properties
Can you please reply with why you are using long value? Attributes of nova flavor-create command including uuid, amount of ram, vcpus etc. should be positive integers. From the command in the bug description, it seems like you are passing long value for ram. It expects an integer value. Hence, above is an expected error. kindly refer, http://docs.openstack.org/admin-guide/cli_manage_flavors.html ** Changed in: nova Status: New => Invalid ** Tags added: api -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1577727 Title: nova flavor-create raises 500 error if long value passed to flavor properties Status in OpenStack Compute (nova): Invalid Bug description: If long value is provided for properties other than name and ID then 500 error is raised. Command: nova flavor-create new_flavor 35 234276234512334234 200 2 n-api LOG: 2016-05-03 10:44:46.744 ERROR nova.api.openstack.extensions [req-cadc48da-abb0-4dfb-abb8-c18855e45d30 admin admin] Unexpected exception in API method 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions Traceback (most recent call last): 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/openstack/extensions.py", line 478, in wrapped 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return f(*args, **kwargs) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return func(*args, **kwargs) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return func(*args, **kwargs) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/openstack/compute/flavor_manage.py", line 81, in _create 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions is_public=is_public) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/compute/flavors.py", line 152, in create 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions db.MAX_INT) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/utils.py", line 1030, in validate_integer 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions 'max_value': max_value}) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions InvalidInput: Invalid input received: ram must be <= 2147483647 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1577727/+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 1226342] Re: nova delete when a baremetal node is not responding to power management leaves the node orphaned
tripleo has move to ironic Closing this bug, please feel free to reopen it if you disagree. ** Changed in: tripleo Status: Triaged => Fix Released -- 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/1226342 Title: nova delete when a baremetal node is not responding to power management leaves the node orphaned Status in OpenStack Compute (nova): Won't Fix Status in tripleo: Fix Released Bug description: If you nova delete an instance on baremetal and the baremetal power manager fails for some reason, you end up with a stale instance_uuid in the bm_nodes table. This is unrecoverable via the API - db surgery is needed. To reproduce, configure a bad power manager, nova boot something on bm, then nova delete, and check the DB. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1226342/+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 1577820] [NEW] key import in "launch instance" dialog not useable
Public bug reported: If you import a key in the "launch instance" dialog it will be imported, but as long as the same dialog is open it will have a name and content. Starting a instance with it in this dialog will fail. Aborting the dialog and starting a new one will let you use it normally. Steps to reproduce: 1. Click on "launch instance" 2. Fill out every needed tab 3. Go to tab "key pair" and click on "import key pair" 4. Fill out name and paste a public key 5. Start instance Expected result: A new public key has been deposited and the new instance is started with it Observed result: "Error: Unable to create server" ** Affects: horizon Importance: Undecided Status: New ** Description changed: - If you import a key in the "launch instance" dialog it will be imported, but - as long as the same dialog is open it will have a name and content. + If you import a key in the "launch instance" dialog it will be imported, but as long as the same dialog is open it will have a name and content. Starting a instance with it in this dialog will fail. Aborting the dialog and starting a new one will let you use it normally. Steps to reproduce: 1. Click on "launch instance" 2. Fill out every needed tab 3. Go to tab "key pair" and click on "import key pair" 4. Fill out name and paste a public key 5. Start instance Expected result: A new public key has been deposited and the new instance is started with it Observed result: "Error: Unable to create server" -- 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/1577820 Title: key import in "launch instance" dialog not useable Status in OpenStack Dashboard (Horizon): New Bug description: If you import a key in the "launch instance" dialog it will be imported, but as long as the same dialog is open it will have a name and content. Starting a instance with it in this dialog will fail. Aborting the dialog and starting a new one will let you use it normally. Steps to reproduce: 1. Click on "launch instance" 2. Fill out every needed tab 3. Go to tab "key pair" and click on "import key pair" 4. Fill out name and paste a public key 5. Start instance Expected result: A new public key has been deposited and the new instance is started with it Observed result: "Error: Unable to create server" To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1577820/+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 1577821] [NEW] User cannot set arbitary IDs for images
Public bug reported: The glance command line enables user to supply ID for the image while creating it using the`glance image-create` command. However, the backend imposes that the ID of an image be a UUID. There is no meaning of letting user supply ID as parameter, if the ID needs to be a UUID. User should be able to set custom ID for images as per need. Also, the regular expression for the image ID is hard coded in the backend. It will be nice if it is configurable in `schema-image.json` ** Affects: glance Importance: Undecided Status: New ** Description changed: - The glance command line enables user to supply ID to the image - while creating the using the`glance image-create` command. + The glance command line enables user to supply ID for the image + while creating it using the`glance image-create` command. However, the backend imposes that the ID of an image be a UUID. - There no meaning of letting user supply ID as parameter, if the ID + There is no meaning of letting user supply ID as parameter, if the ID needs to be a UUID. User should be able to set custom ID for images as per need. Also, the regular expression for the image ID is hard coded in the backend. It will be nice if it is configurable in `schema-image.json` -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1577821 Title: User cannot set arbitary IDs for images Status in Glance: New Bug description: The glance command line enables user to supply ID for the image while creating it using the`glance image-create` command. However, the backend imposes that the ID of an image be a UUID. There is no meaning of letting user supply ID as parameter, if the ID needs to be a UUID. User should be able to set custom ID for images as per need. Also, the regular expression for the image ID is hard coded in the backend. It will be nice if it is configurable in `schema-image.json` To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1577821/+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 1577804] [NEW] /v3/users?name= bypasses user_filter for LDAP
Public bug reported: using the LDAP driver with user_filter, a GET /v3/users?name= returns users that do not match the filter. e.g.: user_filter = (|(uid=arc1_admin)(uid=arc1_stgmgr)) # openstack user list ++-+ | ID | Name| ++-+ | 91476076d6686143dff68d08e87358a29daf0725c549008f9c0852d2c7ab8e | arc1_admin | | 42 | | | 8c1beab95fc4c2b009383827f1ea1ec2880fa6eb5bbe42aebd43aab21ad685 | arc1_stgmgr | | b2 | | ++-+ # openstack user show arc1_dep +---+--+ | Field | Value| +---+--+ | domain_id | default | | id| 631bbab78e33e554bc6c7fd53071c6e046fd37680b1b154261bd6183b123e8b0 | | name | arc1_dep | +---+--+ ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1577804 Title: /v3/users?name= bypasses user_filter for LDAP Status in OpenStack Identity (keystone): New Bug description: using the LDAP driver with user_filter, a GET /v3/users?name= returns users that do not match the filter. e.g.: user_filter = (|(uid=arc1_admin)(uid=arc1_stgmgr)) # openstack user list ++-+ | ID | Name | ++-+ | 91476076d6686143dff68d08e87358a29daf0725c549008f9c0852d2c7ab8e | arc1_admin | | 42 | | | 8c1beab95fc4c2b009383827f1ea1ec2880fa6eb5bbe42aebd43aab21ad685 | arc1_stgmgr | | b2 | | ++-+ # openstack user show arc1_dep +---+--+ | Field | Value | +---+--+ | domain_id | default | | id| 631bbab78e33e554bc6c7fd53071c6e046fd37680b1b154261bd6183b123e8b0 | | name | arc1_dep | +---+--+ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1577804/+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 1553815] Re: host keys never restored following metadata api outage
** Also affects: cloud-init (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Wily) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1553815 Title: host keys never restored following metadata api outage Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: New Status in cloud-init source package in Trusty: New Status in cloud-init source package in Wily: New Status in cloud-init source package in Xenial: Fix Released Bug description: We are running an Openstack cloud and have noticed some unexpected behaviour in our Ubuntu Trusty cloud instances created by Nova. We have observed that if a previously initialised instance (e.g. DataSourceOpenstack has already been run) is rebooted while the metadata api is not available (i.e. 169.254.169.264 is unreachable), cloud-init will retry a few times then switch to DataSourceNone and regenerate host keys. # Boot instance under normal conditions ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance /var/lib/cloud/instances/cd535bc4-9c2f-4d31-8903-0ede59c7ef95 ubuntu@vm1:~$ grep "Generating public/private rsa key pair." /var/log/cloud-init-output.log Generating public/private rsa key pair. # Stop neutron metadata api service and reboot instance (observing that host keys were regenerated) ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance /var/lib/cloud/instances/iid-datasource-none ubuntu@vm1:~$ grep "Generating public/private rsa key pair." /var/log/cloud-init-output.log Generating public/private rsa key pair. Generating public/private rsa key pair. So far so good since we expect this behaviour, but now we reboot this instance with the metadata api is once again reachable. Cloud-init rightly selects the original DataSourceOpenstack instance but it does nothing since it already ran once (and it is set to only run once). The problem here is that the original host keys are never restored so any client connecting to that instance will have no option to accept the new host keys along with MITM attack warning. ubuntu@vm1:~$ sudo reboot ... ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance /var/lib/cloud/instances/cd535bc4-9c2f-4d31-8903-0ede59c7ef95 Surely we could find a way for cloud-init to know that if if the current DataSourceOpenstack uuid matches its previously run uuid, then it can check that the host keys are consistent with the original run. @smoser suggested in a side discussion that dmidecode info could perhaps be used since the Openstack instance uuid can be found there: ubuntu@vm1:~$ sudo dmidecode -t system # dmidecode 2.12 SMBIOS 2.8 present. Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: OpenStack Foundation Product Name: OpenStack Nova Version: 13.0.0 Serial Number: ba5f7371-fd4c-a25e-132f-3dd1e5b92e93 UUID: CD535BC4-9C2F-4D31-8903-0EDE59C7EF95 Wake-up Type: Power Switch SKU Number: Not Specified Family: Virtual Machine Handle 0x2000, DMI type 32, 11 bytes System Boot Information Status: No errors detected If cloud-init kept a copy of previous host keys prior to regenerating them, it could presumably use this info to know when to safely restore the original host keys. Since it is not inconceivable for the metadata api to become unreachable for a brief period (perhpas during an upgrade), i think we really need to make cloud-init more tolerant of this circumstance. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1553815/+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 1553815] Re: host keys never restored following metadata api outage
** Changed in: cloud-init (Ubuntu Xenial) Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1553815 Title: host keys never restored following metadata api outage Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: New Status in cloud-init source package in Trusty: New Status in cloud-init source package in Wily: New Status in cloud-init source package in Xenial: Fix Released Bug description: We are running an Openstack cloud and have noticed some unexpected behaviour in our Ubuntu Trusty cloud instances created by Nova. We have observed that if a previously initialised instance (e.g. DataSourceOpenstack has already been run) is rebooted while the metadata api is not available (i.e. 169.254.169.264 is unreachable), cloud-init will retry a few times then switch to DataSourceNone and regenerate host keys. # Boot instance under normal conditions ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance /var/lib/cloud/instances/cd535bc4-9c2f-4d31-8903-0ede59c7ef95 ubuntu@vm1:~$ grep "Generating public/private rsa key pair." /var/log/cloud-init-output.log Generating public/private rsa key pair. # Stop neutron metadata api service and reboot instance (observing that host keys were regenerated) ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance /var/lib/cloud/instances/iid-datasource-none ubuntu@vm1:~$ grep "Generating public/private rsa key pair." /var/log/cloud-init-output.log Generating public/private rsa key pair. Generating public/private rsa key pair. So far so good since we expect this behaviour, but now we reboot this instance with the metadata api is once again reachable. Cloud-init rightly selects the original DataSourceOpenstack instance but it does nothing since it already ran once (and it is set to only run once). The problem here is that the original host keys are never restored so any client connecting to that instance will have no option to accept the new host keys along with MITM attack warning. ubuntu@vm1:~$ sudo reboot ... ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance /var/lib/cloud/instances/cd535bc4-9c2f-4d31-8903-0ede59c7ef95 Surely we could find a way for cloud-init to know that if if the current DataSourceOpenstack uuid matches its previously run uuid, then it can check that the host keys are consistent with the original run. @smoser suggested in a side discussion that dmidecode info could perhaps be used since the Openstack instance uuid can be found there: ubuntu@vm1:~$ sudo dmidecode -t system # dmidecode 2.12 SMBIOS 2.8 present. Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: OpenStack Foundation Product Name: OpenStack Nova Version: 13.0.0 Serial Number: ba5f7371-fd4c-a25e-132f-3dd1e5b92e93 UUID: CD535BC4-9C2F-4D31-8903-0EDE59C7EF95 Wake-up Type: Power Switch SKU Number: Not Specified Family: Virtual Machine Handle 0x2000, DMI type 32, 11 bytes System Boot Information Status: No errors detected If cloud-init kept a copy of previous host keys prior to regenerating them, it could presumably use this info to know when to safely restore the original host keys. Since it is not inconceivable for the metadata api to become unreachable for a brief period (perhpas during an upgrade), i think we really need to make cloud-init more tolerant of this circumstance. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1553815/+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 1553815] Re: host keys never restored following metadata api outage
For the record, this was fixed in revno 1188 (upstream)[0], available since cloud-init version 0.7.7~bzr1192-0ubuntu1[1] [0] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/1188 [1] http://bazaar.launchpad.net/~smoser/ubuntu/xenial/cloud-init/pkg/revision/452 ** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1553815 Title: host keys never restored following metadata api outage Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: New Status in cloud-init source package in Trusty: New Status in cloud-init source package in Wily: New Status in cloud-init source package in Xenial: Fix Released Bug description: We are running an Openstack cloud and have noticed some unexpected behaviour in our Ubuntu Trusty cloud instances created by Nova. We have observed that if a previously initialised instance (e.g. DataSourceOpenstack has already been run) is rebooted while the metadata api is not available (i.e. 169.254.169.264 is unreachable), cloud-init will retry a few times then switch to DataSourceNone and regenerate host keys. # Boot instance under normal conditions ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance /var/lib/cloud/instances/cd535bc4-9c2f-4d31-8903-0ede59c7ef95 ubuntu@vm1:~$ grep "Generating public/private rsa key pair." /var/log/cloud-init-output.log Generating public/private rsa key pair. # Stop neutron metadata api service and reboot instance (observing that host keys were regenerated) ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance /var/lib/cloud/instances/iid-datasource-none ubuntu@vm1:~$ grep "Generating public/private rsa key pair." /var/log/cloud-init-output.log Generating public/private rsa key pair. Generating public/private rsa key pair. So far so good since we expect this behaviour, but now we reboot this instance with the metadata api is once again reachable. Cloud-init rightly selects the original DataSourceOpenstack instance but it does nothing since it already ran once (and it is set to only run once). The problem here is that the original host keys are never restored so any client connecting to that instance will have no option to accept the new host keys along with MITM attack warning. ubuntu@vm1:~$ sudo reboot ... ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance /var/lib/cloud/instances/cd535bc4-9c2f-4d31-8903-0ede59c7ef95 Surely we could find a way for cloud-init to know that if if the current DataSourceOpenstack uuid matches its previously run uuid, then it can check that the host keys are consistent with the original run. @smoser suggested in a side discussion that dmidecode info could perhaps be used since the Openstack instance uuid can be found there: ubuntu@vm1:~$ sudo dmidecode -t system # dmidecode 2.12 SMBIOS 2.8 present. Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: OpenStack Foundation Product Name: OpenStack Nova Version: 13.0.0 Serial Number: ba5f7371-fd4c-a25e-132f-3dd1e5b92e93 UUID: CD535BC4-9C2F-4D31-8903-0EDE59C7EF95 Wake-up Type: Power Switch SKU Number: Not Specified Family: Virtual Machine Handle 0x2000, DMI type 32, 11 bytes System Boot Information Status: No errors detected If cloud-init kept a copy of previous host keys prior to regenerating them, it could presumably use this info to know when to safely restore the original host keys. Since it is not inconceivable for the metadata api to become unreachable for a brief period (perhpas during an upgrade), i think we really need to make cloud-init more tolerant of this circumstance. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1553815/+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 1577630] Re: ERROR neutron_lbaas.agent.agent_manager - HaproxyNSDriver
Hi Brandon Logan, I use Openstack with two nodes (controller and compute1). http://docs.openstack.org/liberty/install-guide-ubuntu/overview.html I executed the follows commands: http://docs.openstack.org/liberty/networking-guide/adv-config-lbaas.html $ neutron lbaas-loadbalancer-create --name test-lb public $ neutron lbaas-loadbalancer-list +--+-+-+-+--+ | id | name| vip_address | provisioning_status | provider | +--+-+-+-+--+ | 24f50e79-53b6-4ee6-8da1-2a8f1233a857 | test-lb | 20.0.0.118 | ACTIVE | haproxy | +--+-+-+-+--+ $ neutron lbaas-loadbalancer-show test-lb +-+--+ | Field | Value| +-+--+ | admin_state_up | True | | description | | | id | 24f50e79-53b6-4ee6-8da1-2a8f1233a857 | | listeners | | | name| test-lb | | operating_status| ONLINE | | provider| haproxy | | provisioning_status | ACTIVE | | tenant_id | 60d7922e29e44dc1ac62df3fe7ba3841 | | vip_address | 20.0.0.118 | | vip_port_id | 2ef09104-397b-4f84-8977-3c3318e4d393 | | vip_subnet_id | ee4a850d-57f7-4389-936e-ea7cd2fc4cfb | +-+--+ $ neutron port-update \ > --security-group lbaas 2ef09104-397b-4f84-8977-3c3318e4d393 Updated port: 2ef09104-397b-4f84-8977-3c3318e4d393 ping -c 4 20.0.0.118 PING 20.0.0.118 (20.0.0.118) 56(84) bytes of data. >From 10.0.0.1 icmp_seq=1 Destination Host Unreachable >From 10.0.0.1 icmp_seq=2 Destination Host Unreachable >From 10.0.0.1 icmp_seq=3 Destination Host Unreachable >From 10.0.0.1 icmp_seq=4 Destination Host Unreachable neutron lbaas-listener-create --name test-lb-http --loadbalancer test-lb --protocol HTTP --protocol-port 80 Created a new listener: +---++ | Field | Value | +---++ | admin_state_up| True | | connection_limit | -1 | | default_pool_id || | default_tls_container_ref || | description || | id| e4d4730a-cd97-4d42-9d0a-a3fc55bbf710 | | loadbalancers | {"id": "24f50e79-53b6-4ee6-8da1-2a8f1233a857"} | | name | test-lb-http | | protocol | HTTP | | protocol_port | 80 | | sni_container_refs|| | tenant_id | 60d7922e29e44dc1ac62df3fe7ba3841 | +---++ # tail -f /var/log/neutron/neutron-lbaasv2-agent.log 2016-05-02 09:25:47.745 18394 INFO neutron.common.config [-] Logging enabled! 2016-05-02 09:25:47.745 18394 INFO neutron.common.config [-] /usr/bin/neutron-lbaasv2-agent version 7.0.3 2016-05-02 09:25:47.812 18394 INFO oslo.messaging._drivers.impl_rabbit [-] Connecting to AMQP server on controller:5672 2016-05-02 09:25:47.827 18394 INFO oslo.messaging._drivers.impl_rabbit [-] Connecting to AMQP server on controller:5672 2016-05-02 09:25:47.843 18394 INFO oslo.messaging._drivers.impl_rabbit [-] Connected to AMQP server on controller:5672 2016-05-02 09:25:47.845 18394 INFO oslo.messaging._drivers.impl_rabbit [-] Connected to AMQP server on controller:5672 2016-05-02 09:25:47.900 18394 INFO oslo.messaging._drivers.impl_rabbit [-] Connecting to AMQP server on controller:5672 2016-05-02 09:25:47.920 18394 INFO oslo.messaging._drivers.impl_rabbit [-] Connected to AMQP server on controller:5672 2016-05-02 09:31:37.951 18394 WARNING neutron_lbaas.drivers.haproxy.namespace_driver [-] Stats socket not found for loadbalancer 24f50e79-53b6-4ee6-8da1-2a8f1233a857 2016-05-02 09:31:47.951 18394 WARNING neutron_lbaas.drivers.haproxy.namespace_driver [-] Stats socket not found for loadbalancer 24f50e79-53b6-4ee6
[Yahoo-eng-team] [Bug 1572495] Re: Nova API fails to start if "ec2" is specified in enabled_apis
Reviewed: https://review.openstack.org/308264 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=533bd8175968a1bc9ac068ae2b23a62d0e07ea99 Submitter: Jenkins Branch:master commit 533bd8175968a1bc9ac068ae2b23a62d0e07ea99 Author: Sean Dague Date: Wed Apr 20 06:53:18 2016 -0400 Prevent nova-api from dying if enabled_apis is wrong This prevents nova-api from dying if there are values in ``enabled_apis`` which don't actually exist. Closes-Bug: #1572495 Change-Id: Id9a6f5e38b017f4687eb245fd238104379d437d6 ** Changed in: nova Status: In Progress => Fix Released -- 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/1572495 Title: Nova API fails to start if "ec2" is specified in enabled_apis Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) mitaka series: Confirmed Bug description: As reported by Kevin Foxx yesterday, if "ec2" is listed in enabled_apis in Mitaka and beyond Nova will refuse to start because we removed it. We assumed the change in defaults was good enough for people to move forward, but didn't realize that many of the install tools (packstack for sure) hardcoded this value into the config instead of sticking with the defaults. While we've added a new upgrade note on this, we could also actually catch the error and not crash people. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1572495/+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 1577791] [NEW] [RFE] Openflow pipeline modeling and API for OVS extensions
Public bug reported: Problem statement OpenFlow can be really powerful for programming the dataplane, but when several features are hooked up into the same virtual switch they need knowledge of each other implementation (entry table, next table, used registers, conventions, etc). Solution ~~~ Defining a model & extension api for features to describe their "OpenFlow functions", and their entry point in the processing pipeline (ingress prefiltering, ingress postfiltering, egress prefiltering, egress postfiltering), as well as the ability to allocate registers. On a high level, each extension (and the Openvwitch firewall implementation) would expose a model of it's low level functions. openvswitch_firewall would expose: ingress_filter & egress_filter. tapas-a-service (as an example) could expose: taas_{ingress, egress}_{prefilter, postfilter} Every extension would declare a set of "OFFunctions" which would be built of a number of "OFTables". Once all extensions are loaded, and order resolved, every function would get it's "next hop", and it's table numbers, dynamically. We could have a predefine OFFunction priority table somewhere in neutron_lib, with spaces in between priorities for experimentation, with the idea that extensions may request hook points into the pipeline, and those hook points may be discussed upstream to allow interoperability. If necessary, a configuration for admin defined ordering of OFFunctions could be provided in a second step. Diagram: http://paste.openstack.org/show/495967/ input tagging / output_stage / and ingress deflector would be shared common logic. ** Affects: neutron Importance: Undecided Status: New ** Description changed: Problem statement OpenFlow can be really powerful for programming the dataplane, but when several features are hooked up into the same virtual switch they need knowledge of each other implementation (entry table, next table, used registers, conventions, etc). Solution ~~~ Defining a model & extension api for features to describe their "OpenFlow functions", and their entry point in the processing pipeline (ingress prefiltering, ingress postfiltering, egress prefiltering, egress postfiltering), as well as the ability to allocate registers. - - On a high level, each extension (and the Openvwitch firewall implementation) would expose a model of it's low level functions. + On a high level, each extension (and the Openvwitch firewall + implementation) would expose a model of it's low level functions. openvswitch_firewall would expose: ingress_filter & egress_filter. tapas-a-service (as an example) could expose: taas_{ingress, egress}_{prefilter, postfilter} Every extension would declare a set of "OFFunctions" which would be - buillt of a number of "OFTables". Once all extensions are loaded, and + built of a number of "OFTables". Once all extensions are loaded, and order resolved, every function would get it's "next hop", and it's table numbers, dynamically. + Diagram: http://paste.openstack.org/show/495967/ + input tagging / output_stage / and ingress deflector would be shared common logic. - - - +--+ +-+ - |br int| | br xxx| - +-^+ +^+ -+---+ || +---+ -| TAP a <+ || +>TAP b | -+--++| || |+---+ - | | || | - 0+---v-+ 255+--+-++--+--+ - | input tagging | + output_stage | - +---+-+ +^+ - | | - +---v-+ +++ - | | | | - +---+-+ +^+ - | | - +---v-+ +++ - | egress filter | | ingress filter | - +---+-+ +^+ - | | - +---v-+ +++ - | | ^ | - +---+-+ /+^+ - | / | - 127---v-+ 0+++ - |ingress deflector| | input tagging | - +--+--+ +^^---+ - | || - 255+v--+ || - + output_stage +--+ | - +---+-+ | | | - | | | | - +v++ +v-+-+ - | br int | |br xxx | - +-+ ++ -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1577791 Title: [RFE] Openflow pipeline modeling and API for OVS extensions Status in neutron: New Bug description:
[Yahoo-eng-team] [Bug 1352193] Re: The nova API service can't hand image metadata properly when metadata key contains uppercase letter
The glance v1 API which the Nova images proxy is based on put metadata via headers. That means they are case insensitive. Nova will continue to do this regardless of backend, which means when talking to a v2 server, your metadata might be wrong. The Nova image proxy should not be used, and Glance should be interacted with directly. ** Changed in: nova Status: Confirmed => Won't Fix -- 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/1352193 Title: The nova API service can't hand image metadata properly when metadata key contains uppercase letter Status in Glance: In Progress Status in OpenStack Compute (nova): Won't Fix Bug description: OS: centos 6.5 64bit openstack release: icehouse Steps to reproduce: 1. Call the image metadata API of nova using the following command: curl -X 'POST' -v http://IP:PORT/v2/${tenant_id}/images/${image_id}/metadata -H "X-Auth-Token: $token" -H 'Content-type: application/json' -d '{"metadata":{"Key1":"Value1"}}' | python -mjson.tool 2. Execute the above command again: curl -X 'POST' -v http://IP:PORT/v2/${tenant_id}/images/${image_id}/metadata -H "X-Auth-Token: $token" -H 'Content-type: application/json' -d '{"metadata":{"Key1":"Value1"}}' | python -mjson.tool Expected result: In step1, the json response should be: {"metadata":{"Key1":"Value1"}} In setp2, the json response should be: {"metadata":{"Key1":"Value1"}} Observed result: In step1, the json response is: {"metadata":{"key1":"Value1"}} In setp2, the json response is: {"metadata":{"key1":"Value1,Value1"}} Besides, we can observer that each image metadata key in table image_properties of glance DB is converted to lowercase even if the key user inputted contains uppercase letter. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1352193/+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 1577311] Re: OperationalError: (pymysql.err.OperationalError)
You have only specified the api_database, not the main database. Both are needed. ** Changed in: nova Status: New => Invalid ** Tags added: cells -- 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/1577311 Title: OperationalError: (pymysql.err.OperationalError) Status in OpenStack Compute (nova): Invalid Bug description: This error happens in Mitaka on ubuntu 14.04 I have configured nova on separate nodes 1) 192.168.1.177 (Glance) 2)192.168.1.176(Keystone, and mysql for both glance, keystone, nova). 3)192.168.1.181(nova controller and nova compute). Am using a python script nova to connect and everything works fine, I can list flavors, i can list images, but when i try to create a server with nova.servers.create(name="TestServer", image=images_returned[0], flavors=flavors_avail[0]) It looks like the api does not connect to the database server, rather than connect to the database server "192.168.1.176" it connects to itself that is 192.168.1.181, I have not configured the mysql to run on the nova controler rather the mysql database server is running on a different node as described on the onset. Worse yet it that it connects to the real database when I list images and other flavors, but when i try to create the server it brings these areas ERROR nova.api.openstack.extensions OperationalError: (pymysql.err.OperationalError) (1045, u"Access denied for user 'nova'@'192.168.1.181' (using password: YES)") And that is not the database i configured it to use i configured it to use a different database 192.168.1.176 Here are my configs. [DEFAULT] dhcpbridge_flagfile=/etc/nova/nova.conf dhcpbridge=/usr/bin/nova-dhcpbridge log-dir=/var/log/nova state_path=/var/lib/nova lock_path=/var/lock/nova force_dhcp_release=True libvirt_use_virtio_for_bridges=True verbose=True ec2_private_dns_show_ip=True api_paste_config=/etc/nova/api-paste.ini enabled_apis=ec2,osapi_compute,metadata # Libvirt and Virtualization connection_type=libvirt libvirt_type=qemu # Database #connection = mysql://nova:nova/@192.168.1.176/nova # Messaging rabbit_host=192.168.1.181 # EC2 API Flags ec2_host=192.168.1.181 ec2_dmz_host=192.168.1.181 ec2_private_dns_show_ip=True # Networking public_interface=eth0 auto_assign_floating_ip=True # Image image_service=nova.image.Glance.GlanceIageService glance_api_servers=192.168.1.177:9292 # Scheduler scheduler_default_filters=AllHostsFilter # Object storage iscsi_helper=tgtadm # Auth keystone_ec2_url=http://192.168.1.176:6000/v3/ec2tokens auth_stragety=keystone [glance] api_servers=192.168.1.177:9292 host=192.168.1.177 port=9292 protocol=http [libvirt] virt_type=qemu [api_database] # # From nova # # The SQLAlchemy connection string to use to connect to the Nova API database. # (string value) connection = mysql://nova:nova/@192.168.1.176/nova # If True, SQLite uses synchronous mode. (boolean value) #sqlite_synchronous = true # The SQLAlchemy connection string to use to connect to the slave database. # (string value) #slave_connection = # The SQL mode to be used for MySQL sessions. This option, including the # default, overrides any server-set SQL mode. To use whatever SQL mode is set # by the server configuration, set this to no value. Example: mysql_sql_mode= # (string value) mysql_sql_mode = TRADITIONAL # Timeout before idle SQL connections are reaped. (integer value) #idle_timeout = 3600 # Maximum number of SQL connections to keep open in a pool. (integer value) #max_pool_size = # Maximum number of database connection retries during startup. Set to -1 to # specify an infinite retry count. (integer value) #max_retries = 10 # Interval between retries of opening a SQL connection. (integer value) #retry_interval = 10 # If set, use this value for max_overflow with SQLAlchemy. (integer value) # Verbosity of SQL debugging information: 0=None, 100=Everything. (integer # value) connection_debug = 100 # Add Python stack traces to SQL as comment strings. (boolean value) connection_trace = true # If set, use this value for pool_timeout with SQLAlchemy. (integer value) #pool_timeout = To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1577311/+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 1288230] Re: A project shouldn't be deleted when there are instances running
Removing Nova from this bug. As has been expressed this is true of anything in OpenStack. It's fine for Horizon to warn/block project deletion on these cases. At some level keystone is going to let you do the delete. The theory from Tokyo was that OSC should have a cleanup project plugin ** Changed in: nova Status: Confirmed => Won't Fix -- 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/1288230 Title: A project shouldn't be deleted when there are instances running Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Compute (nova): Won't Fix Bug description: Description of problem: currently, a project that has an instance (or instances) can be deleted without even a warning message in the Horizon by a user with an administrative permissions. An active project (meaning a project that has instances running) should have the protection from deletion. If the administrator would like to delete it he should delete the instances first. Version-Release number of selected component (if applicable): openstack-nova-cert-2013.2.2-2.el6ost.noarch python-novaclient-2.15.0-2.el6ost.noarch openstack-nova-common-2013.2.2-2.el6ost.noarch openstack-nova-api-2013.2.2-2.el6ost.noarch openstack-nova-compute-2013.2.2-2.el6ost.noarch openstack-nova-conductor-2013.2.2-2.el6ost.noarch openstack-nova-novncproxy-2013.2.2-2.el6ost.noarch openstack-nova-scheduler-2013.2.2-2.el6ost.noarch python-nova-2013.2.2-2.el6ost.noarch openstack-nova-console-2013.2.2-2.el6ost.noarch openstack-nova-network-2013.2.2-2.el6ost.noarch How reproducible: 100% Steps to Reproduce: 1. Create an new project. 2. Launch one (or more) instances. 3. Try to delete the project with the admin. Actual results: The instances are still running, but they are accessible only through the admin -> intances tab. Expected results: The administrator shouldn't be able to delete the project as long as there are instances running. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1288230/+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 1491949] Re: gate-tempest-dsvm-large-ops fails to deallocate instance network due to rpc timeout
This job has been deleted ** Changed in: nova Status: Confirmed => Won't Fix -- 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/1491949 Title: gate-tempest-dsvm-large-ops fails to deallocate instance network due to rpc timeout Status in devstack: Fix Released Status in OpenStack Compute (nova): Won't Fix Bug description: http://logs.openstack.org/96/219696/4/check/gate-tempest-dsvm-large- ops/158f061/logs/screen-n-cpu-1.txt.gz?level=TRACE 2015-09-03 15:11:10.090 ERROR nova.compute.manager [req-ae96c425-a199-472f-a0db-e1b48147bb4c tempest-TestLargeOpsScenario-1690771764 tempest-TestLargeOpsScenario-1474206998] [instance: 195361d7-95c3-4740-825b-1acab707969e] Failed to deallocate network for instance. 2015-09-03 15:11:11.051 ERROR nova.compute.manager [req-ae96c425-a199-472f-a0db-e1b48147bb4c tempest-TestLargeOpsScenario-1690771764 tempest-TestLargeOpsScenario-1474206998] [instance: 195361d7-95c3-4740-825b-1acab707969e] Setting instance vm_state to ERROR 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] Traceback (most recent call last): 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] File "/opt/stack/new/nova/nova/compute/manager.py", line 2396, in do_terminate_instance 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] self._delete_instance(context, instance, bdms, quotas) 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] File "/opt/stack/new/nova/nova/hooks.py", line 149, in inner 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] rv = f(*args, **kwargs) 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] File "/opt/stack/new/nova/nova/compute/manager.py", line 2375, in _delete_instance 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] quotas.rollback() 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 195, in __exit__ 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] six.reraise(self.type_, self.value, self.tb) 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] File "/opt/stack/new/nova/nova/compute/manager.py", line 2338, in _delete_instance 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] self._shutdown_instance(context, instance, bdms) 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] File "/opt/stack/new/nova/nova/compute/manager.py", line 2265, in _shutdown_instance 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] self._try_deallocate_network(context, instance, requested_networks) 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] File "/opt/stack/new/nova/nova/compute/manager.py", line 2194, in _try_deallocate_network 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] self._set_instance_obj_error_state(context, instance) 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 195, in __exit__ 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] six.reraise(self.type_, self.value, self.tb) 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] File "/opt/stack/new/nova/nova/compute/manager.py", line 2189, in _try_deallocate_network 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] self._deallocate_network(context, instance, requested_networks) 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] File "/opt/stack/new/nova/nova/compute/manager.py", line 1812, in _deallocate_network 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] context, instance, requested_networks=requested_networks) 2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 195361d7-95c3-4740-825b-1acab707969e] File "/opt/stack/new/nov
[Yahoo-eng-team] [Bug 1577758] [NEW] fix wrong key name in test code
Public bug reported: nova/tests/unit/virt/libvirt/test_driver.py, Line 12611 root_bdm = {'source_type': 'image', 'detination_type': 'volume', 'image_id': 'fake_id'} 'detination_type' should be 'destination_type', it will run fail when testing. ** Affects: nova Importance: Undecided Assignee: Peng Li (flyd1005) Status: New ** Tags: compute low-hanging-fruit ** Changed in: nova Assignee: (unassigned) => Peng Li (flyd1005) ** Tags added: compute low-hanging-fruit -- 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/1577758 Title: fix wrong key name in test code Status in OpenStack Compute (nova): New Bug description: nova/tests/unit/virt/libvirt/test_driver.py, Line 12611 root_bdm = {'source_type': 'image', 'detination_type': 'volume', 'image_id': 'fake_id'} 'detination_type' should be 'destination_type', it will run fail when testing. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1577758/+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 1577753] [NEW] Cloud-init fails of stage init
Public bug reported: Cloud-init 0.77 on Ubuntu 16.04 seems not to be able to connect to the OpenStack Metadata service and fails, although the Metadata service is available itself, see log here: root@ubuntu:/etc/network# cloud-init --debug init 2016-05-03 12:25:04,855 - handlers.py[DEBUG]: start: init-network: searching for network datasources 2016-05-03 12:25:04,855 - util.py[DEBUG]: Reading from /proc/uptime (quiet=False) 2016-05-03 12:25:04,855 - util.py[DEBUG]: Read 16 bytes from /proc/uptime 2016-05-03 12:25:04,856 - util.py[DEBUG]: Reading from /var/lib/cloud/data/status.json (quiet=False) 2016-05-03 12:25:04,856 - util.py[DEBUG]: Read 548 bytes from /var/lib/cloud/data/status.json 2016-05-03 12:25:04,857 - util.py[DEBUG]: Creating symbolic link from '/run/cloud-init/status.json' => '../../var/lib/cloud/data/status.json' 2016-05-03 12:25:04,858 - util.py[DEBUG]: Attempting to remove /run/cloud-init/status.json 2016-05-03 12:25:04,858 - util.py[DEBUG]: Running command ['systemd-detect-virt', '--quiet', '--container'] with allowed return codes [0] (shell=False, capture=True) 2016-05-03 12:25:04,861 - util.py[DEBUG]: Running command ['running-in-container'] with allowed return codes [0] (shell=False, capture=True) 2016-05-03 12:25:04,862 - util.py[DEBUG]: Running command ['lxc-is-container'] with allowed return codes [0] (shell=False, capture=True) 2016-05-03 12:25:04,864 - util.py[DEBUG]: Reading from /proc/1/environ (quiet=False) 2016-05-03 12:25:04,864 - util.py[DEBUG]: Read 110 bytes from /proc/1/environ 2016-05-03 12:25:04,864 - util.py[DEBUG]: Reading from /proc/self/status (quiet=False) 2016-05-03 12:25:04,865 - util.py[DEBUG]: Read 896 bytes from /proc/self/status 2016-05-03 12:25:04,865 - util.py[DEBUG]: Reading from /proc/cmdline (quiet=False) 2016-05-03 12:25:04,865 - util.py[DEBUG]: Read 64 bytes from /proc/cmdline 2016-05-03 12:25:04,866 - util.py[DEBUG]: Reading from /proc/uptime (quiet=False) 2016-05-03 12:25:04,866 - util.py[DEBUG]: Read 16 bytes from /proc/uptime 2016-05-03 12:25:04,866 - templater.py[WARNING]: Cheetah not available as the default renderer for unknown template, reverting to the basic renderer. 2016-05-03 12:25:04,867 - util.py[DEBUG]: Reading from /etc/cloud/cloud.cfg (quiet=False) 2016-05-03 12:25:04,867 - util.py[DEBUG]: Read 3011 bytes from /etc/cloud/cloud.cfg 2016-05-03 12:25:04,867 - util.py[DEBUG]: Attempting to load yaml from string of length 3011 with allowed root types (,) 2016-05-03 12:25:04,887 - util.py[DEBUG]: Reading from /etc/cloud/cloud.cfg.d/90_dpkg.cfg (quiet=False) 2016-05-03 12:25:04,887 - util.py[DEBUG]: Read 197 bytes from /etc/cloud/cloud.cfg.d/90_dpkg.cfg 2016-05-03 12:25:04,887 - util.py[DEBUG]: Attempting to load yaml from string of length 197 with allowed root types (,) 2016-05-03 12:25:04,889 - util.py[DEBUG]: Reading from /etc/cloud/cloud.cfg.d/05_logging.cfg (quiet=False) 2016-05-03 12:25:04,890 - util.py[DEBUG]: Read 1910 bytes from /etc/cloud/cloud.cfg.d/05_logging.cfg 2016-05-03 12:25:04,890 - util.py[DEBUG]: Attempting to load yaml from string of length 1910 with allowed root types (,) 2016-05-03 12:25:04,897 - cloud-init[DEBUG]: Closing stdin 2016-05-03 12:25:04,898 - util.py[DEBUG]: Redirecting <_io.TextIOWrapper name='' mode='w' encoding='UTF-8'> to | tee -a /var/log/cloud-init-output.log 2016-05-03 12:25:04,899 - util.py[DEBUG]: Redirecting <_io.TextIOWrapper name='' mode='w' encoding='UTF-8'> to | tee -a /var/log/cloud-init-output.log 2016-05-03 12:25:04,900 - cloud-init[DEBUG]: Logging being reset, this logger may no longer be active shortly Cloud-init v. 0.7.7 running 'init' at Tue, 03 May 2016 12:25:04 +. Up 4339.24 seconds. ci-info: ++Net device info+++ ci-info: ++--+--+---+---+---+ ci-info: | Device | Up | Address| Mask | Scope | Hw-Address| ci-info: ++--+--+---+---+---+ ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | . | . | ci-info: | lo | True | ::1/128| . | host | . | ci-info: | ens32 | True | 192.168.0.15 | 255.255.255.0 | . | fa:16:3e:40:92:3f | ci-info: | ens32 | True | fe80::f816:3eff:fe40:923f/64 | . | link | fa:16:3e:40:92:3f | ci-info: ++--+--+---+---+---+ ci-info: +Route IPv4 info+ ci-info: +---+-+-+---+---+---+ ci-info: | Route | Destination | Gateway |Genmask| Interface | Flags | ci-info: +---+-+-+---+---+---+ ci-info: | 0 | 0.0.
[Yahoo-eng-team] [Bug 1577370] Re: Duplicate lines in /etc/nova/policy.json
Bug belongs to the nova project. ** Project changed: openstack-manuals => nova ** Changed in: nova Assignee: monika (monikaparkar25) => (unassigned) -- 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/1577370 Title: Duplicate lines in /etc/nova/policy.json Status in OpenStack Compute (nova): Incomplete Bug description: The default /etc/nova/policy.json released with Liberty contains two times the declaration for: "compute:delete": "", "compute:soft_delete": "", "compute:force_delete": "", I don't known it can impact the policy, but it may be better to raise an error when a rule is declared more than one time. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1577370/+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 1569081] Re: Truncated or oversized response headers received from daemon process 'horizon': /usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi
** Project changed: openstack-community => horizon ** Changed in: horizon Status: Invalid => 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/1569081 Title: Truncated or oversized response headers received from daemon process 'horizon': /usr/share/openstack- dashboard/openstack_dashboard/wsgi/django.wsgi Status in OpenStack Dashboard (Horizon): New Bug description: trying to install openstack mikata openstack-dashboard newly installed ubuntu 16.04 kernel 4.4.0-18 keep getiing this error apache log Truncated or oversized response headers received from daemon process 'horizon': /usr/share/openstack- dashboard/openstack_dashboard/wsgi/django.wsgi To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1569081/+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 1577747] [NEW] Cloud- init doesn't configure network interfaces in Ubuntu 16.04
Public bug reported: I'm running vmbuilder 0.12.4 on an Ubuntu 16.04 server to create an Ubuntu 16.04 cloud image. cloud-init 0.77 is being added to run the cloud image in OpenStack. Upon starting the VM in OpenStack, cloud-init fails because the network interface can't be established. That seems to be related to discrepancy between /etc/network/interfaces and /etc/network/interfaces.d/50-cloud-init.cfg --> in /etc/network/interfaces, the primary network interface is eth0, whereby in cloud-init it is ens32 auto eth0 iface eth0 inet dhcp --> changing eth0 to ens32 correctly establishes the network interface ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1577747 Title: Cloud- init doesn't configure network interfaces in Ubuntu 16.04 Status in cloud-init: New Bug description: I'm running vmbuilder 0.12.4 on an Ubuntu 16.04 server to create an Ubuntu 16.04 cloud image. cloud-init 0.77 is being added to run the cloud image in OpenStack. Upon starting the VM in OpenStack, cloud-init fails because the network interface can't be established. That seems to be related to discrepancy between /etc/network/interfaces and /etc/network/interfaces.d/50-cloud-init.cfg --> in /etc/network/interfaces, the primary network interface is eth0, whereby in cloud-init it is ens32 auto eth0 iface eth0 inet dhcp --> changing eth0 to ens32 correctly establishes the network interface To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1577747/+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 1517704] Re: Test still passes even with tests failure
Reviewed: https://review.openstack.org/301862 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=037d1c0927b64848ea0934990ba6538d9d7a8133 Submitter: Jenkins Branch:master commit 037d1c0927b64848ea0934990ba6538d9d7a8133 Author: David Lyle Date: Wed Mar 16 10:25:26 2016 -0600 removing httplib2 test dependency Once upon a time, the python-*client libraries were primarily built to use httplib2. They have subsequently shift to using requests and thus urllib3. The horizon test helpers code was maintaining a reference to httplib2 as it intercepted errant library calls that were not mocked. httplib2 is not actively maintained and OpenStack is moving to remove it as a dependency. See http://lists.openstack.org/pipermail/openstack-dev/2016-March/089225.html for more details. This patch removed the httplib2 dependency. Upon removing the dependency it exposed a missed update from httplib2 to urllib3. A function that was intended to catch unmocked calls was only listening for httplib2 connections. This patch updates that failsafe to work with urllib3. Upon doing so, it pointed out many, many missing mocks and in turn, many broken tests that appeared to work because of API call failures. This patch adds the missing mocks and fixes the broken tests. The new failsafe prints the stack trace when an outside connection is attempted. Additionally, to fix the fact that a missed mock used to allow tests to potentially pass, as documented by bug 1517704, a test failure is now forced on tests where a missing mock is detected. Closes-Bug: #1517704 Implements blueprint: remove-httplib2-dep Change-Id: Iaabdf03966c14c82e0c58a3b1ab1a6755c05adcb ** Changed in: horizon Status: In Progress => Fix Released -- 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/1517704 Title: Test still passes even with tests failure Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Tests seems still to pass even with test failures. There are two tests failure on the code, and test run still report it passes: https://bugs.launchpad.net/horizon/+bug/1517670 https://bugs.launchpad.net/horizon/+bug/1517653 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1517704/+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 1569081] [NEW] Truncated or oversized response headers received from daemon process 'horizon': /usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi
You have been subscribed to a public bug: trying to install openstack mikata openstack-dashboard newly installed ubuntu 16.04 kernel 4.4.0-18 keep getiing this error apache log Truncated or oversized response headers received from daemon process 'horizon': /usr/share/openstack- dashboard/openstack_dashboard/wsgi/django.wsgi ** Affects: horizon Importance: Undecided Status: Invalid ** Tags: horizon mikata -- Truncated or oversized response headers received from daemon process 'horizon': /usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi https://bugs.launchpad.net/bugs/1569081 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). -- 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 1577370] [NEW] Duplicate lines in /etc/nova/policy.json
You have been subscribed to a public bug: The default /etc/nova/policy.json released with Liberty contains two times the declaration for: "compute:delete": "", "compute:soft_delete": "", "compute:force_delete": "", I don't known it can impact the policy, but it may be better to raise an error when a rule is declared more than one time. ** Affects: nova Importance: Undecided Assignee: monika (monikaparkar25) Status: Incomplete -- Duplicate lines in /etc/nova/policy.json https://bugs.launchpad.net/bugs/1577370 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). -- 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 1511982] Re: Unable to upgrade the DB from kilo to liberty with VPNaaS
*** This bug is a duplicate of bug 1550434 *** https://bugs.launchpad.net/bugs/1550434 ** This bug has been marked a duplicate of bug 1550434 vpnaas alembic migration fails for upgrade liberty -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1511982 Title: Unable to upgrade the DB from kilo to liberty with VPNaaS Status in neutron: Expired Bug description: i'm trying to upgrade neutron from Kilo to Liberty with VPNaaS enabled. While neutron-db-manage --config-file /etc/neutron/neutron.conf --config- file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade liberty I get this error. Traceback (most recent call last): File "/usr/bin/neutron-db-manage", line 10, in sys.exit(main()) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 554, in main CONF.command.func(config, CONF.command.name) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 188, in do_upgrade run_sanity_checks(config, revision) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 541, in run_sanity_checks script_dir.run_env() File "/usr/lib/python2.7/dist-packages/alembic/script/base.py", line 397, in run_env util.load_python_file(self.dir, 'env.py') File "/usr/lib/python2.7/dist-packages/alembic/util/pyfiles.py", line 81, in load_python_file module = load_module_py(module_id, path) File "/usr/lib/python2.7/dist-packages/alembic/util/compat.py", line 79, in load_module_py mod = imp.load_source(module_id, path, fp) File "/usr/lib/python2.7/dist-packages/neutron_vpnaas/db/migration/alembic_migrations/env.py", line 87, in run_migrations_online() File "/usr/lib/python2.7/dist-packages/neutron_vpnaas/db/migration/alembic_migrations/env.py", line 78, in run_migrations_online context.run_migrations() File "", line 8, in run_migrations File "/usr/lib/python2.7/dist-packages/alembic/runtime/environment.py", line 797, in run_migrations self.get_context().run_migrations(**kw) File "/usr/lib/python2.7/dist-packages/alembic/runtime/migration.py", line 303, in run_migrations for step in self._migrations_fn(heads, self): File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 532, in check_sanity revision, rev, implicit_base=True): File "/usr/lib/python2.7/dist-packages/alembic/script/revision.py", line 664, in _iterate_revisions raise RangeNotAncestorError(lower, upper) alembic.script.revision.RangeNotAncestorError: Revision (u'2c82e782d734',) is not an ancestor of revision 24f28869838b To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1511982/+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 1577727] [NEW] nova flavor-create raises 500 error if long value passed to flavor properties
Public bug reported: If long value is provided for properties other than name and ID then 500 error is raised. Command: nova flavor-create new_flavor 35 234276234512334234 200 2 n-api LOG: 2016-05-03 10:44:46.744 ERROR nova.api.openstack.extensions [req-cadc48da-abb0-4dfb-abb8-c18855e45d30 admin admin] Unexpected exception in API method 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions Traceback (most recent call last): 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/openstack/extensions.py", line 478, in wrapped 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return f(*args, **kwargs) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return func(*args, **kwargs) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return func(*args, **kwargs) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/openstack/compute/flavor_manage.py", line 81, in _create 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions is_public=is_public) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/compute/flavors.py", line 152, in create 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions db.MAX_INT) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/utils.py", line 1030, in validate_integer 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions 'max_value': max_value}) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions InvalidInput: Invalid input received: ram must be <= 2147483647 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions ** Affects: nova Importance: Undecided Assignee: Dinesh Bhor (dinesh-bhor) Status: New ** Changed in: nova Assignee: (unassigned) => Dinesh Bhor (dinesh-bhor) -- 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/1577727 Title: nova flavor-create raises 500 error if long value passed to flavor properties Status in OpenStack Compute (nova): New Bug description: If long value is provided for properties other than name and ID then 500 error is raised. Command: nova flavor-create new_flavor 35 234276234512334234 200 2 n-api LOG: 2016-05-03 10:44:46.744 ERROR nova.api.openstack.extensions [req-cadc48da-abb0-4dfb-abb8-c18855e45d30 admin admin] Unexpected exception in API method 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions Traceback (most recent call last): 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/openstack/extensions.py", line 478, in wrapped 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return f(*args, **kwargs) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return func(*args, **kwargs) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return func(*args, **kwargs) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/api/openstack/compute/flavor_manage.py", line 81, in _create 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions is_public=is_public) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/compute/flavors.py", line 152, in create 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions db.MAX_INT) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions File "/opt/stack/nova/nova/utils.py", line 1030, in validate_integer 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions 'max_value': max_value}) 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions InvalidInput: Invalid input received: ram must be <= 2147483647 2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1577727/+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 1577725] [NEW] Expired token passed to neutron return 500 instead of 401
Public bug reported: If we pass to Nova an about-to-expire token, then Nova pass this token to neutronclient to manipulate networks. neutronclient can raise an unauthorized exception. This exception is not understand by Nova and so converted to a 500 which does not let any chance for novaclient to try a new attempt of this request with a re-generated token. We should to convert the unauthorized exception from Neutron to a 401 returned to nova clients. https://github.com/openstack/python- novaclient/blob/master/novaclient/client.py#L438 ** Affects: nova Importance: Undecided Assignee: sahid (sahid-ferdjaoui) Status: New ** Changed in: nova Assignee: (unassigned) => sahid (sahid-ferdjaoui) -- 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/1577725 Title: Expired token passed to neutron return 500 instead of 401 Status in OpenStack Compute (nova): New Bug description: If we pass to Nova an about-to-expire token, then Nova pass this token to neutronclient to manipulate networks. neutronclient can raise an unauthorized exception. This exception is not understand by Nova and so converted to a 500 which does not let any chance for novaclient to try a new attempt of this request with a re-generated token. We should to convert the unauthorized exception from Neutron to a 401 returned to nova clients. https://github.com/openstack/python- novaclient/blob/master/novaclient/client.py#L438 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1577725/+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 1576245] Re: block live-migration fails if source/dest have different instance dir
According to ML post [1] this bug report is invalid. [1] http://lists.openstack.org/pipermail/openstack- dev/2016-May/093744.html ** Changed in: nova Status: New => Invalid ** Changed in: nova Assignee: Eli Qiao (taget-9) => (unassigned) -- 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/1576245 Title: block live-migration fails if source/dest have different instance dir Status in OpenStack Compute (nova): Invalid Bug description: block live migration fails if using libvirt python inter face migrationTOURI3 if source/dest have different instance dir. migrationTOURI3 requires a xml on the dest host, but we don't update instance dir. error logs: File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 1833, in migrateToURI3 if ret == -1: raise libvirtError ('virDomainMigrateToURI3() failed', dom=self) libvirtError: Unable to pre-create chardev file '/opt/stack/data/nova/instances/e73cc732-8b75-4743-8583-64da9bd7fee0/console.log': No such file or directory To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1576245/+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