[Yahoo-eng-team] [Bug 1446326] Re: 403 response from Nova when making a DELETE call for an image in pending_delete
** Changed in: glance Assignee: Sudipta Biswas (sbiswas7) => (unassigned) ** Changed in: glance Status: In Progress => Incomplete ** Changed in: glance Status: Incomplete => Opinion -- 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/1446326 Title: 403 response from Nova when making a DELETE call for an image in pending_delete Status in OpenStack Image Registry and Delivery Service (Glance): Opinion Status in OpenStack Compute (Nova): Invalid Bug description: Context and information: -- Currently, 404 is seen by the user when "image-delete" call is made via the Glance API or through the Images API of Nova for an Image in "deleted" status. However, if an Image is in "pending_delete" and a user with the UUID of that Image tries "image-delete" call from the Nova API, she gets a back a 403 which is not consistent. The user should get a 404 back. Notes: -- * The user needs to specify the UUID, name is not sufficient. * For "image-show" call the user is able to see the Image in DELETED status with the appropriate metadata for Image in "deleted" or "pending_delete" status in Glance as nova passes-in the force_show_deleted=True flag by default. Feedback needed and action to be taken: --- Nova should be able to return a 404 back to the user while issuing a "image-delete" call if the Image is flagged deleted in the Glance DB (deleted=True), irrespective of the Image status in "deleted" or "pending_delete". To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1446326/+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 1458809] Re: Unable to delete instances created using stale networks
** Changed in: nova Status: In Progress => Invalid ** Changed in: nova Assignee: Sudipta Biswas (sbiswas7) => (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/1458809 Title: Unable to delete instances created using stale networks Status in OpenStack Compute (Nova): Invalid Bug description: I am on Kilo. I was using VxLAN based networks. As the lab requirement changed, I had to move over to "FLAT" networking. This involved editing the ml2_conf.ini file and the necessary changes for 'flat' networking to work. However, I didn't enable VxLAN networking any longer - even though the networks pre-created (using VxLAN) were still lying there. (This wasn't intentional). Again without actual intentions, I ended up deploying an instance with the VxLAN based networks. This results into a build failure on the compute node with the following exception: Unable to clear device ID for port 'None' TRACE nova.network.neutronv2.api Traceback (most recent call last): TRACE nova.network.neutronv2.api File "/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 366, in _unbind_ports TRACE nova.network.neutronv2.api port_client.update_port(port_id, port_req_body) TRACE nova.network.neutronv2.api File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 102, in with_params TRACE nova.network.neutronv2.api ret = self.function(instance, *args, **kwargs) TRACE nova.network.neutronv2.api File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 549, in update_port TRACE nova.network.neutronv2.api return self.put(self.port_path % (port), body=body) TRACE nova.network.neutronv2.api File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 302, in put TRACE nova.network.neutronv2.api headers=headers, params=params) TRACE nova.network.neutronv2.api File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 270, in retry_request TRACE nova.network.neutronv2.api headers=headers, params=params) TRACE nova.network.neutronv2.api File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 211, in do_request TRACE nova.network.neutronv2.api self._handle_fault_response(status_code, replybody) TRACE nova.network.neutronv2.api File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 185, in _handle_fault_response TRACE nova.network.neutronv2.api exception_handler_v20(status_code, des_error_body) TRACE nova.network.neutronv2.api File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 83, in exception_handler_v20 TRACE nova.network.neutronv2.api message=message) nova.network.neutronv2.api NeutronClientException: 404 Not Found The bind failed because of the following error: Network a813e9e3-4e87-4de6-8f48-84e4a4cb774a is of type vxlan but agent or mechanism driver only support ['local', 'flat', 'vlan']. check_segment_for_agent /usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/mech_agent.py:193 which is clear and expected. Post this, I wanted to clean up the instances and it just won't get deleted. Even though the delete request comes back with "Request to delete server has been accepted" Upon pdbing, I could see that there's an error being thrown at the nova/api/openstack/wsgi.py around line 1061 - "'Controller' object has no attribute 'versioned_methods'" I think this is a different bug than the ones which have been earlier reported. Bug 1329559 being one for reference. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1458809/+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 1472503] [NEW] install error because of tests_require string
Public bug reported: I use the lastest devstack and lastest keystone, and the install error from devstack is like this: 2015-07-08 07:15:36.238 | + local name=keystone 2015-07-08 07:15:36.238 | + /opt/stack/requirements/.venv/bin/edit-constraints /opt/stack/requirements/upper-constraints.txt -- keystone '-e file:///opt/stack/keystone#egg=keystone' 2015-07-08 07:15:36.315 | + setup_package /opt/stack/keystone -e 2015-07-08 07:15:36.315 | + local project_dir=/opt/stack/keystone 2015-07-08 07:15:36.315 | + local flags=-e 2015-07-08 07:15:36.315 | + pip_install -e /opt/stack/keystone 2015-07-08 07:15:36.592 | + sudo -H http_proxy=http://proxy01.cd.intel.com:911 https_proxy=http://proxy01.cd.intel.com:911 'no_proxy=intel.com,*.intel.com,10.0.0.0/8,192.168.0.0/16,127.0.0.0/8,localhost,127.0.0.1,192.168.140.145' PIP_FIND_LINKS=file:///opt/stack/.wheelhouse /usr/local/bin/pip install -e /opt/stack/keystone 2015-07-08 07:15:37.358 | Obtaining file:///opt/stack/keystone 2015-07-08 07:15:38.004 | Complete output from command python setup.py egg_info: 2015-07-08 07:15:38.004 | error in setup command: 'tests_require' must be a string or list of strings containing valid project/version requirement specifiers; Expected ',' or end-of-list in python-ldap>=2.4;python_version=='2.7' at ;python_version=='2.7' 2015-07-08 07:15:38.004 | 2015-07-08 07:15:38.004 | 2015-07-08 07:15:38.004 | Command "python setup.py egg_info" failed with error code 1 in /opt/stack/keystone 2015-07-08 07:15:38.015 | + exit_trap 2015-07-08 07:15:38.015 | + local r=1 2015-07-08 07:15:38.016 | ++ jobs -p 2015-07-08 07:15:38.016 | + jobs= 2015-07-08 07:15:38.016 | + [[ -n '' ]] 2015-07-08 07:15:38.016 | + kill_spinner 2015-07-08 07:15:38.016 | + '[' '!' -z '' ']' 2015-07-08 07:15:38.016 | + [[ 1 -ne 0 ]] 2015-07-08 07:15:38.016 | + echo 'Error on exit' 2015-07-08 07:15:38.017 | Error on exit 2015-07-08 07:15:38.017 | + [[ -z /opt/stack/logs ]] 2015-07-08 07:15:38.017 | + /home/stack/devstack/devstack/tools/worlddump.py -d /opt/stack/logs 2015-07-08 07:15:38.051 | df: '/run/user/112/gvfs': Permission denied 2015-07-08 07:15:38.484 | + exit 1 stack@stack-PC44-8000:~/devstack/devstack$ 2015-07-08 07:15:38.490 | /bin/sh: 1: kill: Usage: kill [-s sigspec | -signum | -sigspec] [pid | job]... or 2015-07-08 07:15:38.490 | kill -l [exitstatus] seems this line in https://review.openstack.org/#/c/197773/2/test-requirements.txt python-ldap>=2.4;python_version=='2.7' ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1472503 Title: install error because of tests_require string Status in OpenStack Identity (Keystone): New Bug description: I use the lastest devstack and lastest keystone, and the install error from devstack is like this: 2015-07-08 07:15:36.238 | + local name=keystone 2015-07-08 07:15:36.238 | + /opt/stack/requirements/.venv/bin/edit-constraints /opt/stack/requirements/upper-constraints.txt -- keystone '-e file:///opt/stack/keystone#egg=keystone' 2015-07-08 07:15:36.315 | + setup_package /opt/stack/keystone -e 2015-07-08 07:15:36.315 | + local project_dir=/opt/stack/keystone 2015-07-08 07:15:36.315 | + local flags=-e 2015-07-08 07:15:36.315 | + pip_install -e /opt/stack/keystone 2015-07-08 07:15:36.592 | + sudo -H http_proxy=http://proxy01.cd.intel.com:911 https_proxy=http://proxy01.cd.intel.com:911 'no_proxy=intel.com,*.intel.com,10.0.0.0/8,192.168.0.0/16,127.0.0.0/8,localhost,127.0.0.1,192.168.140.145' PIP_FIND_LINKS=file:///opt/stack/.wheelhouse /usr/local/bin/pip install -e /opt/stack/keystone 2015-07-08 07:15:37.358 | Obtaining file:///opt/stack/keystone 2015-07-08 07:15:38.004 | Complete output from command python setup.py egg_info: 2015-07-08 07:15:38.004 | error in setup command: 'tests_require' must be a string or list of strings containing valid project/version requirement specifiers; Expected ',' or end-of-list in python-ldap>=2.4;python_version=='2.7' at ;python_version=='2.7' 2015-07-08 07:15:38.004 | 2015-07-08 07:15:38.004 | 2015-07-08 07:15:38.004 | Command "python setup.py egg_info" failed with error code 1 in /opt/stack/keystone 2015-07-08 07:15:38.015 | + exit_trap 2015-07-08 07:15:38.015 | + local r=1 2015-07-08 07:15:38.016 | ++ jobs -p 2015-07-08 07:15:38.016 | + jobs= 2015-07-08 07:15:38.016 | + [[ -n '' ]] 2015-07-08 07:15:38.016 | + kill_spinner 2015-07-08 07:15:38.016 | + '[' '!' -z '' ']' 2015-07-08 07:15:38.016 | + [[ 1 -ne 0 ]] 2015-07-08 07:15:38.016 | + echo 'Error on exit' 2015-07-08 07:15:38.017 | Error on exit 2015-07-08 07:15:38.017 | + [[ -z /opt/stack/logs ]] 2015-07-08 07:15:38.017 | + /home/stack/devstack/devstack/tools/worlddump.py -d
[Yahoo-eng-team] [Bug 1471098] Re: Cinder volume stuck in swap_volume
IMO, the 'migrate_volume_completion' process in cinder should be fixed.
** Also affects: cinder
Importance: Undecided
Status: New
** Changed in: cinder
Assignee: (unassigned) => Takashi NATSUME (natsume-takashi)
** Changed in: cinder
Status: New => In Progress
--
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/1471098
Title:
Cinder volume stuck in swap_volume
Status in Cinder:
In Progress
Status in OpenStack Compute (Nova):
In Progress
Bug description:
Cinder volumes are stuck in 'attaching'/'detaching' state when 'swap
volume' is executed.
A cinder volume is attached to a VM instance.
Then the cinder volume is swapped for a new volume by 'swap volume'.
Concretely the following API is called.
PUT /v2/{tenant_id}/servers/{server_id}/os-
volume_attachments/{attachment_id}
After the API is called, the attached volume(old volume) becomes stuck in
'detaching' state
and the new volume becomes stuck in 'attaching' state.
[How to reproduce]
stack@devstack-kilo:/opt/devstack$ cinder list
+--+---+---+--+-+--+--+
| ID | Status | Name | Size | Volume
Type | Bootable | Attached to |
+--+---+---+--+-+--+--+
| c3aff356-7545-444c-8b4f-33670b3e483c | in-use | TEST2 | 1 |
lvmdriver-1 | false | adc00700-c7c8-4fe9-b3b4-df9beed40405 |
| da251e5b-a783-4f96-8b9f-a8db5dc070c1 | available | TEST1 | 1 |
lvmdriver-1 | false | |
+--+---+---+--+-+--+--+
stack@devstack-kilo:/opt/devstack$ nova show server1
+--++
| Property | Value
|
+--++
| OS-DCF:diskConfig| MANUAL
|
| OS-EXT-AZ:availability_zone | nova
|
| OS-EXT-SRV-ATTR:host | devstack-kilo
|
| OS-EXT-SRV-ATTR:hypervisor_hostname | devstack-kilo
|
| OS-EXT-SRV-ATTR:instance_name| instance-0001
|
| OS-EXT-STS:power_state | 1
|
| OS-EXT-STS:task_state| -
|
| OS-EXT-STS:vm_state | active
|
| OS-SRV-USG:launched_at | 2015-07-02T00:53:25.00
|
| OS-SRV-USG:terminated_at | -
|
| accessIPv4 |
|
| accessIPv6 |
|
| config_drive | True
|
| created | 2015-07-02T00:53:19Z
|
| flavor | m1.tiny (1)
|
| hostId |
ea09a5e13b086e757a5c21f093c46d0aa6ae373d82a34ef7ac798816 |
| id | adc00700-c7c8-4fe9-b3b4-df9beed40405
|
| image| cirros-0.3.2-x86_64-uec
(abe0afbf-7f82-4361-a308-a69d7206989f) |
| key_name | -
|
| metadata | {}
|
| name | server1
|
| os-extended-volumes:volumes_attached | [{"id":
"c3aff356-7545-444c-8b4f-33670b3e483c"}] |
| progress | 0
|
| public network | 10.0.2.195
|
| security
[Yahoo-eng-team] [Bug 1472589] [NEW] nova quota-class-update returns wrong HTTP error code if name length exceeds 255 characters
You have been subscribed to a public bug: The quota-class-update API in Nova returns wrong HTTP error code if the name passed to it has length more than 255 characters. If you pass (name of the class) parameter with more than 255 characters to this API, it returns HTTP 500 error code whereas HTTP 400 (HttpBadRequest) should be returned to the user. Run below command to reproduce this issue. $ nova quota-class-update abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuv --instances 2 Expected output should have contained (HTTP 400) but actual output is: ERROR (ClientException): The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-55f9faea-f971-46f2-bf5c-0d854404f11e) ** Affects: nova Importance: Undecided Assignee: Aniket Anikhindi (aniketanikhindi) Status: New ** Tags: nova -- nova quota-class-update returns wrong HTTP error code if name length exceeds 255 characters https://bugs.launchpad.net/bugs/1472589 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 1472589] Re: nova quota-class-update returns wrong HTTP error code if name length exceeds 255 characters
Updating project to 'nova' Assigning to myself for resolution.. ** Project changed: fuel => nova ** Changed in: nova Assignee: (unassigned) => Aniket Anikhindi (aniketanikhindi) ** Changed in: nova Status: New => Confirmed -- 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/1472589 Title: nova quota-class-update returns wrong HTTP error code if name length exceeds 255 characters Status in OpenStack Compute (Nova): Confirmed Bug description: The quota-class-update API in Nova returns wrong HTTP error code if the name passed to it has length more than 255 characters. If you pass (name of the class) parameter with more than 255 characters to this API, it returns HTTP 500 error code whereas HTTP 400 (HttpBadRequest) should be returned to the user. Run below command to reproduce this issue. $ nova quota-class-update abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuv --instances 2 Expected output should have contained (HTTP 400) but actual output is: ERROR (ClientException): The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-55f9faea-f971-46f2-bf5c-0d854404f11e) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1472589/+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 1472612] [NEW] multi domain support false issue
Public bug reported: When using the new domains support code, and you wish to disable this feature (to not use domains in horizon), this creates a number is issues for project admin users. They suddenly lose the ability to manage members, create projects, update_projects, modify quotas, delete projects(s) domain support patches need to have backwards compatibility with project admin behavior in a non domain world. ** Affects: horizon Importance: Undecided Assignee: Michael Hagedorn (mike-hagedorn) Status: In Progress ** Tags: domains ** Tags added: domains ** Changed in: horizon Assignee: (unassigned) => Michael Hagedorn (mike-hagedorn) -- 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/1472612 Title: multi domain support false issue Status in OpenStack Dashboard (Horizon): In Progress Bug description: When using the new domains support code, and you wish to disable this feature (to not use domains in horizon), this creates a number is issues for project admin users. They suddenly lose the ability to manage members, create projects, update_projects, modify quotas, delete projects(s) domain support patches need to have backwards compatibility with project admin behavior in a non domain world. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1472612/+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 1450594] Re: Instance deletion fails sometimes when serial_console is enabled
** Tags added: kilo-backport-potential ** Tags added: juno-backport-potential ** Also affects: nova/juno Importance: Undecided Status: New ** Also affects: nova/kilo Importance: Undecided Status: New ** Changed in: nova Importance: Low => Medium -- 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/1450594 Title: Instance deletion fails sometimes when serial_console is enabled Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) juno series: New Status in OpenStack Compute (nova) kilo series: New Bug description: Nova Version: 2014.2.1 For situations where nova-compute is re-trying an instance delete after the original delete failed, and the serial console feature is enabled, the instance delete fails with: 2015-04-27 16:54:49.900 114127 TRACE nova.compute.manager [instance: 6d117169-4057-4a4a-a0b7-0b12e996caa0] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1179, in cleanup 2015-04-27 16:54:49.900 114127 TRACE nova.compute.manager [instance: 6d117169-4057-4a4a-a0b7-0b12e996caa0] for host, port in self._get_serial_ports_from_instance(instance): 2015-04-27 16:54:49.900 114127 TRACE nova.compute.manager [instance: 6d117169-4057-4a4a-a0b7-0b12e996caa0] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1197, in _get_serial_ports_from_instance 2015-04-27 16:54:49.900 114127 TRACE nova.compute.manager [instance: 6d117169-4057-4a4a-a0b7-0b12e996caa0] virt_dom = self._lookup_by_name(instance['name']) 2015-04-27 16:54:49.900 114127 TRACE nova.compute.manager [instance: 6d117169-4057-4a4a-a0b7-0b12e996caa0] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4195, in _lookup_by_name 2015-04-27 16:54:49.900 114127 TRACE nova.compute.manager [instance: 6d117169-4057-4a4a-a0b7-0b12e996caa0] raise exception.InstanceNotFound(instance_id=instance_name) 2015-04-27 16:54:49.900 114127 TRACE nova.compute.manager [instance: 6d117169-4057-4a4a-a0b7-0b12e996caa0] InstanceNotFound: Instance instance-0444 could not be found. Or, said another way, the _get_serial_ports_from_instance call should maybe not cause an exception if the instance cannot be found. More details/context: In our particular situation, some instance deletes are initially failing because the neutron port delete operation was failing or timing out. So the VM goes to 'error' and remains in the deleting task_state. However, since the failure is on the port delete, the domain has already been undefined in libvirt. The first invocation of _delete_instance calls shutdown_instance before an attempt is made to delete the network. Shutdown_instance is able to successfully call driver.destroy which will shutdown the instance and then runs the cleanup action, ignoring any errors around vif removal. This will undefine the domain as long as it was successfully shutdown. The next time nova-compute is started, it finds the instance still in the deleting task state, so it re-tries the delete. Part of the cleanup call ran by driver.destroy is to remove the serial console. Note: this was already ran and successfully deleted on the first delete when the domain was successfully undefined. But since the domain is no longer defined in libvirt, the _get_serial_ports_from_instance call fails, and again the entire delete operation fails and stops. This makes it impossible to fully delete the instance. When the serial console feature is disabled, this delete re-try operation functions correctly and properly cleans up the rest of the instance, and it transitions to deleted. FWIW, we are also running nova-cells, so the neutron --> nova port notifications do not work/are disabled. Don't know if that's relevant or not. Steps to reproduce: - nova-compute configured with serial console feature enabled - Create an instance which has a serial console configured - Delete that instance, but cause the neutron port delete to fail or timeout (via iptables or just shutting off neutron temporarily) - The instance should now be stuck in the deleting task state - Restart nova-compute - During the re-try of the delete operation, the above stack trace results. Expected result: Retries of instance deletions in this scenario should succeed with the same behavior that happens when the serial console feature is disabled. Proposed Fix: Under: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L761-L765 shorty above this create a variable called isdefined and set it to true when we are checking to see if the domain is defined set the variable isdefined to false Under: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L848-L851 a
[Yahoo-eng-team] [Bug 1472634] [NEW] Improve netns_cleanup functional test
Public bug reported: Currently functional test for netns_cleanup utility does not verify that processes spawned by DHCP agent are get killed. ** Affects: neutron Importance: Undecided Assignee: Ilya Shakhat (shakhat) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Ilya Shakhat (shakhat) ** Changed in: neutron Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1472634 Title: Improve netns_cleanup functional test Status in OpenStack Neutron (virtual network service): In Progress Bug description: Currently functional test for netns_cleanup utility does not verify that processes spawned by DHCP agent are get killed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1472634/+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 1472503] Re: python-ldap 2.4.20 causing install issues
Might want to double check that you're not using an old devstack or pbr. I'm not seeing any breaks in our CI ** Also affects: pbr (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1472503 Title: python-ldap 2.4.20 causing install issues Status in OpenStack Identity (Keystone): Incomplete Status in pbr package in Ubuntu: New Bug description: I use the lastest devstack and lastest keystone, and the install error from devstack is like this: 2015-07-08 07:15:36.238 | + local name=keystone 2015-07-08 07:15:36.238 | + /opt/stack/requirements/.venv/bin/edit-constraints /opt/stack/requirements/upper-constraints.txt -- keystone '-e file:///opt/stack/keystone#egg=keystone' 2015-07-08 07:15:36.315 | + setup_package /opt/stack/keystone -e 2015-07-08 07:15:36.315 | + local project_dir=/opt/stack/keystone 2015-07-08 07:15:36.315 | + local flags=-e 2015-07-08 07:15:36.315 | + pip_install -e /opt/stack/keystone 2015-07-08 07:15:36.592 | + sudo -H http_proxy=http://proxy01.cd.intel.com:911 https_proxy=http://proxy01.cd.intel.com:911 'no_proxy=intel.com,*.intel.com,10.0.0.0/8,192.168.0.0/16,127.0.0.0/8,localhost,127.0.0.1,192.168.140.145' PIP_FIND_LINKS=file:///opt/stack/.wheelhouse /usr/local/bin/pip install -e /opt/stack/keystone 2015-07-08 07:15:37.358 | Obtaining file:///opt/stack/keystone 2015-07-08 07:15:38.004 | Complete output from command python setup.py egg_info: 2015-07-08 07:15:38.004 | error in setup command: 'tests_require' must be a string or list of strings containing valid project/version requirement specifiers; Expected ',' or end-of-list in python-ldap>=2.4;python_version=='2.7' at ;python_version=='2.7' 2015-07-08 07:15:38.004 | 2015-07-08 07:15:38.004 | 2015-07-08 07:15:38.004 | Command "python setup.py egg_info" failed with error code 1 in /opt/stack/keystone 2015-07-08 07:15:38.015 | + exit_trap 2015-07-08 07:15:38.015 | + local r=1 2015-07-08 07:15:38.016 | ++ jobs -p 2015-07-08 07:15:38.016 | + jobs= 2015-07-08 07:15:38.016 | + [[ -n '' ]] 2015-07-08 07:15:38.016 | + kill_spinner 2015-07-08 07:15:38.016 | + '[' '!' -z '' ']' 2015-07-08 07:15:38.016 | + [[ 1 -ne 0 ]] 2015-07-08 07:15:38.016 | + echo 'Error on exit' 2015-07-08 07:15:38.017 | Error on exit 2015-07-08 07:15:38.017 | + [[ -z /opt/stack/logs ]] 2015-07-08 07:15:38.017 | + /home/stack/devstack/devstack/tools/worlddump.py -d /opt/stack/logs 2015-07-08 07:15:38.051 | df: '/run/user/112/gvfs': Permission denied 2015-07-08 07:15:38.484 | + exit 1 stack@stack-PC44-8000:~/devstack/devstack$ 2015-07-08 07:15:38.490 | /bin/sh: 1: kill: Usage: kill [-s sigspec | -signum | -sigspec] [pid | job]... or 2015-07-08 07:15:38.490 | kill -l [exitstatus] seems this line in https://review.openstack.org/#/c/197773/2/test-requirements.txt python-ldap>=2.4;python_version=='2.7' To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1472503/+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 1472687] [NEW] local_settings HORIZON_CONFIG is over writing previously defined config
Public bug reported: the local_settings.py example file redefines the HORIZON_CONFIG section of config info. This creates confusion as to what is used why and where to make changes. The correct way is to have the local_settings.py example do things like: HORIZON_CONFIG["password_validator"] or HORIZON_CONFIG["simple_ip_management"] redeclaring HORIZON_CONFIG creates a lot of issues for errors ** Affects: horizon Importance: Low Status: Confirmed ** Tags: low-hanging-fruit ** Tags added: low-hanging-fruit -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1472687 Title: local_settings HORIZON_CONFIG is over writing previously defined config Status in OpenStack Dashboard (Horizon): Confirmed Bug description: the local_settings.py example file redefines the HORIZON_CONFIG section of config info. This creates confusion as to what is used why and where to make changes. The correct way is to have the local_settings.py example do things like: HORIZON_CONFIG["password_validator"] or HORIZON_CONFIG["simple_ip_management"] redeclaring HORIZON_CONFIG creates a lot of issues for errors To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1472687/+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 1472692] [NEW] test_port_creation_and_deletion randomly fails with: eventlet.timeout.Timeout: 60 seconds
Public bug reported: http://logs.openstack.org/28/199128/1/gate/gate-neutron-dsvm- functional/2d48aff/console.html#_2015-07-08_08_06_35_766 2015-07-08 08:06:35.768 | 2015-07-08 08:06:35.728 | Captured traceback: 2015-07-08 08:06:35.769 | 2015-07-08 08:06:35.730 | ~~~ 2015-07-08 08:06:35.770 | 2015-07-08 08:06:35.731 | Traceback (most recent call last): 2015-07-08 08:06:35.770 | 2015-07-08 08:06:35.733 | File "neutron/tests/functional/agent/test_l2_ovs_agent.py", line 258, in test_port_creation_and_deletion 2015-07-08 08:06:35.771 | 2015-07-08 08:06:35.734 | lambda: self._expected_plugin_rpc_call( 2015-07-08 08:06:35.771 | 2015-07-08 08:06:35.736 | File "neutron/agent/linux/utils.py", line 328, in wait_until_true 2015-07-08 08:06:35.772 | 2015-07-08 08:06:35.737 | eventlet.sleep(sleep) 2015-07-08 08:06:35.772 | 2015-07-08 08:06:35.739 | File "/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/greenthread.py", line 34, in sleep 2015-07-08 08:06:35.773 | 2015-07-08 08:06:35.740 | hub.switch() 2015-07-08 08:06:35.774 | 2015-07-08 08:06:35.742 | File "/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 294, in switch 2015-07-08 08:06:35.774 | 2015-07-08 08:06:35.743 | return self.greenlet.switch() 2015-07-08 08:06:35.775 | 2015-07-08 08:06:35.745 | eventlet.timeout.Timeout: 60 seconds http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwibGFtYmRhOiBzZWxmLl9leHBlY3RlZF9wbHVnaW5fcnBjX2NhbGwoXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIgQU5EIGJ1aWxkX25hbWU6XCJnYXRlLW5ldXRyb24tZHN2bS1mdW5jdGlvbmFsXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MzYzNzI1MzAyOTl9 ** Affects: neutron Importance: Medium Status: Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1472692 Title: test_port_creation_and_deletion randomly fails with: eventlet.timeout.Timeout: 60 seconds Status in OpenStack Neutron (virtual network service): Confirmed Bug description: http://logs.openstack.org/28/199128/1/gate/gate-neutron-dsvm- functional/2d48aff/console.html#_2015-07-08_08_06_35_766 2015-07-08 08:06:35.768 | 2015-07-08 08:06:35.728 | Captured traceback: 2015-07-08 08:06:35.769 | 2015-07-08 08:06:35.730 | ~~~ 2015-07-08 08:06:35.770 | 2015-07-08 08:06:35.731 | Traceback (most recent call last): 2015-07-08 08:06:35.770 | 2015-07-08 08:06:35.733 | File "neutron/tests/functional/agent/test_l2_ovs_agent.py", line 258, in test_port_creation_and_deletion 2015-07-08 08:06:35.771 | 2015-07-08 08:06:35.734 | lambda: self._expected_plugin_rpc_call( 2015-07-08 08:06:35.771 | 2015-07-08 08:06:35.736 | File "neutron/agent/linux/utils.py", line 328, in wait_until_true 2015-07-08 08:06:35.772 | 2015-07-08 08:06:35.737 | eventlet.sleep(sleep) 2015-07-08 08:06:35.772 | 2015-07-08 08:06:35.739 | File "/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/greenthread.py", line 34, in sleep 2015-07-08 08:06:35.773 | 2015-07-08 08:06:35.740 | hub.switch() 2015-07-08 08:06:35.774 | 2015-07-08 08:06:35.742 | File "/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 294, in switch 2015-07-08 08:06:35.774 | 2015-07-08 08:06:35.743 | return self.greenlet.switch() 2015-07-08 08:06:35.775 | 2015-07-08 08:06:35.745 | eventlet.timeout.Timeout: 60 seconds http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwibGFtYmRhOiBzZWxmLl9leHBlY3RlZF9wbHVnaW5fcnBjX2NhbGwoXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIgQU5EIGJ1aWxkX25hbWU6XCJnYXRlLW5ldXRyb24tZHN2bS1mdW5jdGlvbmFsXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MzYzNzI1MzAyOTl9 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1472692/+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 1472704] [NEW] Support networks that work through routing instead of bridging
Public bug reported: This RFE bug describes and proposes a type of Neutron network in which connectivity between the VMs attached to that network is provided by L3 routing. This type of network provides full (subject to security policy) IP connectivity between VMs in that and other routed networks: v4 and v6, unicast and multicast; but it provides no L2 capability, except as required for this IP connectivity, plus correct operation of the ICMP, ARP and NDP protocols that exist to support IP. Therefore, this kind of network is suitable for VMs that only communicate over IP. Why would anyone want that? Compared to the other kinds of networks that provide connectivity at L2, its arguable benefits are that: - it is conceptually simpler, in that VM data is transported in a uniform way between a VM and its compute host, between compute hosts, and between the data center network and the outside world, without any encapsulation changes anywhere - as a practical consequence, it is easier to debug, using standard tools such as ping, traceroute, wireshark and tcpdump - its scale is not limited in the way that VLAN-based and VXLAN-based networks are, by the practical diameter of the physical underlying L2 network. FYI I started proposing/discussing this as a devref at https://review.openstack.org/#/c/198439/, and lots more detail can be found there about how I think this could work. However, I understand that that is not the correct process, hence in principle starting again here as an RFE bug. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe ** Tags added: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1472704 Title: Support networks that work through routing instead of bridging Status in OpenStack Neutron (virtual network service): New Bug description: This RFE bug describes and proposes a type of Neutron network in which connectivity between the VMs attached to that network is provided by L3 routing. This type of network provides full (subject to security policy) IP connectivity between VMs in that and other routed networks: v4 and v6, unicast and multicast; but it provides no L2 capability, except as required for this IP connectivity, plus correct operation of the ICMP, ARP and NDP protocols that exist to support IP. Therefore, this kind of network is suitable for VMs that only communicate over IP. Why would anyone want that? Compared to the other kinds of networks that provide connectivity at L2, its arguable benefits are that: - it is conceptually simpler, in that VM data is transported in a uniform way between a VM and its compute host, between compute hosts, and between the data center network and the outside world, without any encapsulation changes anywhere - as a practical consequence, it is easier to debug, using standard tools such as ping, traceroute, wireshark and tcpdump - its scale is not limited in the way that VLAN-based and VXLAN-based networks are, by the practical diameter of the physical underlying L2 network. FYI I started proposing/discussing this as a devref at https://review.openstack.org/#/c/198439/, and lots more detail can be found there about how I think this could work. However, I understand that that is not the correct process, hence in principle starting again here as an RFE bug. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1472704/+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 1472712] [NEW] Using SSL with rabbitmq prevents communication between nova-compute and conductor after latest nova updates
Public bug reported: On the latest update of the Ubuntu OpenStack packages, it was discovered that the nova-compute/nova-conductor (1:2014.1.4-0ubuntu2.1) packages encountered a bug with using SSL to connect to rabbitmq. When this problem occurs, the compute node cannot connect to the controller, and this message is constantly displayed: WARNING nova.conductor.api [req-4022395c-9501-47cf-bf8e-476e1cc58772 None None] Timed out waiting for nova-conductor. Is it running? Or did this service start before nova-conductor? Investigation revealed that having rabbitmq configured with SSL was the root cause of this problem. This seems to have been introduced with the current version of the nova packages. Rabbitmq was not updated as part of this distribution update, but the messaging library (python- oslo.messaging 1.3.0-0ubuntu1.1) was updated. So the problem could exist in any of these components. Versions installed: Openstack version: Icehouse Ubuntu 14.04.2 LTS nova-conductor1:2014.1.4-0ubuntu2.1 nova-compute1:2014.1.4-0ubuntu2.1 rabbitmq-server 3.2.4-1 openssl:amd64/trusty-security 1.0.1f-1ubuntu2.15 ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1472712 Title: Using SSL with rabbitmq prevents communication between nova-compute and conductor after latest nova updates Status in OpenStack Compute (Nova): New Bug description: On the latest update of the Ubuntu OpenStack packages, it was discovered that the nova-compute/nova-conductor (1:2014.1.4-0ubuntu2.1) packages encountered a bug with using SSL to connect to rabbitmq. When this problem occurs, the compute node cannot connect to the controller, and this message is constantly displayed: WARNING nova.conductor.api [req-4022395c-9501-47cf-bf8e-476e1cc58772 None None] Timed out waiting for nova-conductor. Is it running? Or did this service start before nova-conductor? Investigation revealed that having rabbitmq configured with SSL was the root cause of this problem. This seems to have been introduced with the current version of the nova packages. Rabbitmq was not updated as part of this distribution update, but the messaging library (python-oslo.messaging 1.3.0-0ubuntu1.1) was updated. So the problem could exist in any of these components. Versions installed: Openstack version: Icehouse Ubuntu 14.04.2 LTS nova-conductor1:2014.1.4-0ubuntu2.1 nova-compute1:2014.1.4-0ubuntu2.1 rabbitmq-server 3.2.4-1 openssl:amd64/trusty-security 1.0.1f-1ubuntu2.15 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1472712/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1472725] [NEW] Pidfile.unlock checks responses of a"void" function
Public bug reported: Pidfile.unlock[1] implementation uses fcntl.flock response as a condition but fcntl.flock is a "void" function. [1] neutron.agent.linux.daemon ** Affects: neutron Importance: Undecided Assignee: Cedric Brandily (cbrandily) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Cedric Brandily (cbrandily) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1472725 Title: Pidfile.unlock checks responses of a"void" function Status in OpenStack Neutron (virtual network service): In Progress Bug description: Pidfile.unlock[1] implementation uses fcntl.flock response as a condition but fcntl.flock is a "void" function. [1] neutron.agent.linux.daemon To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1472725/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1472727] [NEW] Subnet pools and the quota on subnets
Public bug reported: Here is the use case I have in mind: Want to have a quota on subnets but all subnets being created from a single subnet pool be counted as 1 against the quota. (The newly added quota mechanism for subnet pools (or something similar to it) can coexist and be enforced along side the quota on subnets). For example, if the Neutron quota on subnets is 1 and subnets are being created from a single subnet pool, even if there are several subnets being created, I want to allow that. Currently the Neutron quota limit will prevent creation of subnets beyond the quota even though they are from say a single subnet pool (or a number of pools that is smaller than the quota). ** 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/1472727 Title: Subnet pools and the quota on subnets Status in OpenStack Neutron (virtual network service): New Bug description: Here is the use case I have in mind: Want to have a quota on subnets but all subnets being created from a single subnet pool be counted as 1 against the quota. (The newly added quota mechanism for subnet pools (or something similar to it) can coexist and be enforced along side the quota on subnets). For example, if the Neutron quota on subnets is 1 and subnets are being created from a single subnet pool, even if there are several subnets being created, I want to allow that. Currently the Neutron quota limit will prevent creation of subnets beyond the quota even though they are from say a single subnet pool (or a number of pools that is smaller than the quota). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1472727/+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 1467780] Re: Unused config_files parameter of service entry
** Changed in: keystone Importance: Undecided => Wishlist ** Changed in: keystone Status: In Progress => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1467780 Title: Unused config_files parameter of service entry Status in OpenStack Identity (Keystone): Opinion Bug description: The entry of keystone service tried to provide a default config file path to load config options, but the path is unused. Actually, the oslo_config lib can automatically find default config file or automatically load the config file specified by --config-file option. So the useless code should be removed. The following is debug trace when using'keystone-manage' command with breakpoint, the other keystone service scripts is similar. it obvious that the 'config_file' parameter inputted to cli.main is None. The path of config file is impossible be "/usr/etc/keystone.conf". > /opt/stack/keystone/keystone/cmd/manage.py(44)main() -> config_files = None (Pdb) l 39 environment.use_stdlib() 40 41 dev_conf = os.path.join(possible_topdir, 42 'etc', 43 'keystone.conf') 44 -> config_files = None 45 if os.path.exists(dev_conf): 46 config_files = [dev_conf] 47 48 cli.main(argv=sys.argv, config_files=config_files) [EOF] (Pdb) p sys.argv[0] '/usr/local/bin/keystone-manage' (Pdb) p possible_topdir '/usr' (Pdb) p dev_conf '/usr/etc/keystone.conf' To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1467780/+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 1212196] Re: legacy "tenant" terminology still used interchangeably with "project"
*** This bug is a duplicate of bug 1017606 *** https://bugs.launchpad.net/bugs/1017606 ** This bug has been marked a duplicate of bug 1017606 Mixing references to 'Tenants' and 'Projects' is confusing -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1212196 Title: legacy "tenant" terminology still used interchangeably with "project" Status in OpenStack Identity (Keystone): Triaged Bug description: When moving to the new version of keystone, table 'tenant' is renamed to 'project', but the information in 'extra' field of table 'user' is still using the old name 'tenantId', which confused me when I moved to the new version first time. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1212196/+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 1472747] [NEW] keystone projects rest api does not handle get requests boolean parameters correctly
Public bug reported: When passing a boolean parameter in a get request to the projects api, the parameter value should be appropriately converted to a python boolean value. Listing of a non-admin user projects via rest api, for example, is broken because the boolean 'admin' parameter is not handled correctly. To reproduce this bug: 1) Pull this patch from gerrit: https://review.openstack.org/#/c/199567/ and enable the panel; 2) Use manage.py utility and restart apache, if needed; 3) Login with a non-admin user (should have privilege to list their own projects, i.e., identity:list_user_projects in policy); 4) Go to url /identity/ngprojects. ** Affects: horizon Importance: Undecided Assignee: Paulo Ewerton (pauloewerton) Status: New ** Changed in: horizon Assignee: (unassigned) => Paulo Ewerton (pauloewerton) -- 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/1472747 Title: keystone projects rest api does not handle get requests boolean parameters correctly Status in OpenStack Dashboard (Horizon): New Bug description: When passing a boolean parameter in a get request to the projects api, the parameter value should be appropriately converted to a python boolean value. Listing of a non-admin user projects via rest api, for example, is broken because the boolean 'admin' parameter is not handled correctly. To reproduce this bug: 1) Pull this patch from gerrit: https://review.openstack.org/#/c/199567/ and enable the panel; 2) Use manage.py utility and restart apache, if needed; 3) Login with a non-admin user (should have privilege to list their own projects, i.e., identity:list_user_projects in policy); 4) Go to url /identity/ngprojects. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1472747/+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 1468248] Re: weird URLs in 'keystone-all' console log
*** This bug is a duplicate of bug 1454968 *** https://bugs.launchpad.net/bugs/1454968 ** This bug has been marked a duplicate of bug 1454968 hard to understand the uri printed in the log -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1468248 Title: weird URLs in 'keystone-all' console log Status in OpenStack Identity (Keystone): Incomplete Bug description: When 'keystone-all' is executed, weird URLs are printed in the console log. ... 3595 INFO keystone.common.wsgi [-] GET http://10.0.2.15:5000/v3/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy ... The corresponding API call that was executed is as below: curl -v -H "X-Auth-Token: xxx" http://10.0.2.15:5000/v3/endpoints/01092d12a8064c7caccba2b5b9e5f24f/OS-ENDPOINT-POLICY/policy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1468248/+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 1470164] Re: Unexpected error in glance registry when param 'allow_anonymous_access' is True
I approved these Erno. Thanks for nominating them. ** Also affects: glance/juno Importance: Undecided Status: New ** Also affects: glance/liberty Importance: Undecided Assignee: jelly (coding1314) Status: In Progress ** Also affects: glance/kilo Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1470164 Title: Unexpected error in glance registry when param 'allow_anonymous_access' is True Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Glance juno series: New Status in Glance kilo series: New Status in Glance liberty series: In Progress Bug description: Steps to reproduce: 1. Stop "glance-api" service. 2. In "glance-api.conf" set "allow_anonymous_access = True" 3. Start "glance-api" service. 4. Trying to get image-list with use v1 and without keystone "x-auth-token" GET /v1/images HTTP/1.1 Host: 172.18.85.25:2081 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive Actual result: HTTP/1.1 500 Internal Server Error Content-Type: text/plain Content-Length: 0 Date: Tue, 30 Jun 2015 14:54:42 GMT Connection: close P.S: Affected all versions of glance (v1,v2,v3) if you use 'registry' backend and "use_user_token = true" in glance-api.conf (default value). To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1470164/+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 1462266] Re: spelling mistake in the comment of class Service in nova/service.py
Related change https://review.openstack.org/#/c/189560/ ** Changed in: nova Importance: Undecided => Wishlist ** Changed in: nova Status: Fix Released => In Progress ** Changed in: nova Milestone: liberty-1 => None -- 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/1462266 Title: spelling mistake in the comment of class Service in nova/service.py Status in OpenStack Compute (Nova): In Progress Bug description: The spell mistake is in the comment of class Service in nova/service.py. """Service object for binaries running on hosts. A service takes a manager and enables rpc by listening to queues based on topic. It also periodically runs tasks on the manager and reports it state to the database services table. """ In the comment,the last "it" should be "its".It's a very little spell mistake. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1462266/+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 1095271] Re: Cannot get/update/delete individual meta-data key for volume
** Changed in: python-cinderclient Status: Fix Committed => Fix Released ** Changed in: python-cinderclient Milestone: None => 1.3.1 -- 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/1095271 Title: Cannot get/update/delete individual meta-data key for volume Status in Cinder: Invalid Status in OpenStack Compute (Nova): Invalid Status in Python client library for Cinder: Fix Released Bug description: This bug report is in reference to this comment https://bugs.launchpad.net/cinder/+bug/1046382/comments/2 Volumes can support arbitrary meta-data which can be set on create, but the current api, cinderclient does not expose any means to get/update/delete any individual metadata key. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1095271/+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 1280033] Re: Remove dependent module py3kcompat
** Changed in: python-cinderclient Status: Fix Committed => Fix Released ** Changed in: python-cinderclient Milestone: None => 1.3.1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1280033 Title: Remove dependent module py3kcompat Status in Orchestration API (Heat): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): Fix Released Status in OpenStack Compute (Nova): Fix Released Status in Messaging API for OpenStack: Fix Released Status in Python client library for Ceilometer: Fix Released Status in Python client library for Cinder: Fix Released Status in Python client library for Glance: Fix Released Status in Python client library for Ironic: Fix Released Status in Python client library for Keystone: Fix Released Status in Python client library for Nova: Fix Released Status in Python client library for Sahara (ex. Savanna): Fix Released Status in Trove client binding: Fix Released Status in OpenStack Data Processing (Sahara): Invalid Status in OpenStack contribution dashboard: Fix Released Bug description: Everything in module py3kcompat is ready in six > 1.4.0, we don't need this module now . It was removed from oslo-incubator recently, see https://review.openstack.org/#/c/71591/. This make us don't need maintain this module any more, use six directly. To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1280033/+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 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()
** Changed in: python-cinderclient Status: Fix Committed => Fix Released ** Changed in: python-cinderclient Milestone: None => 1.3.1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1268480 Title: assertTrue(isinstance()) in tests should be replace with assertIsInstance() Status in OpenStack Telemetry (Ceilometer): Fix Released Status in Cinder: Opinion Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Bare Metal Provisioning Service (Ironic): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): Invalid Status in OpenStack Compute (Nova): Fix Released Status in Python client library for Ceilometer: Fix Released Status in Python client library for Cinder: Fix Released Status in Python client library for Glance: Fix Released Status in Python client library for Keystone: Fix Released Status in Python client library for Nova: Fix Released Bug description: some of tests use different method of assertTrue(isinstance(A, B)) or assertEqual(type(A), B). The correct way is to use assertIsInstance(A, B) provided by testtools To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1268480/+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 1262424] Re: Files without code should not contain copyright notices
** Changed in: python-cinderclient Status: Fix Committed => Fix Released ** Changed in: python-cinderclient Milestone: None => 1.3.1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1262424 Title: Files without code should not contain copyright notices Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Fix Released Status in Python client library for Cinder: Fix Released Status in Taskflow for task-oriented systems.: Fix Released Bug description: Due to a recent policy change in HACKING (http://docs.openstack.org/developer/hacking/#openstack-licensing), empty files should no longer contain copyright notices. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1262424/+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 1259292] Re: Some tests use assertEqual(observed, expected) , the argument order is wrong
** Changed in: python-cinderclient Status: Fix Committed => Fix Released ** Changed in: python-cinderclient Milestone: None => 1.3.1 -- 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/1259292 Title: Some tests use assertEqual(observed, expected) , the argument order is wrong Status in OpenStack Telemetry (Ceilometer): Invalid Status in Cinder: In Progress Status in Orchestration API (Heat): Fix Released Status in OpenStack Dashboard (Horizon): In Progress Status in Python client library for Ceilometer: In Progress Status in Python client library for Cinder: Fix Released Status in OpenStack Data Processing (Sahara): Fix Released Bug description: The test cases will produce a confusing error message if the tests ever fail, so this is worth fixing. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1259292/+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 1255876] Re: need to ignore swap files from getting into repository
** Changed in: python-cinderclient Status: Fix Committed => Fix Released ** Changed in: python-cinderclient Milestone: None => 1.3.1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1255876 Title: need to ignore swap files from getting into repository Status in OpenStack Telemetry (Ceilometer): Invalid Status in Heat Orchestration Templates and tools: Invalid Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Neutron (virtual network service): Fix Released Status in The Oslo library incubator: Won't Fix Status in Python client library for Ceilometer: Fix Released Status in Python client library for Cinder: Fix Released Status in Python client library for Glance: Fix Released Status in Python client library for Keystone: Fix Released Status in Python client library for Neutron: Fix Released Status in Python client library for Nova: Fix Released Status in Python client library for Swift: Fix Committed Status in OpenStack Data Processing (Sahara): Invalid Bug description: need to ignore swap files from getting into repository currently the implemented ignore in .gitignore is *.swp however vim goes beyond to generate these so to improve it could be done *.sw? To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1255876/+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 1207635] Re: Cinderclient not converting third-party exceptions
** Changed in: python-cinderclient Status: Fix Committed => Fix Released ** Changed in: python-cinderclient Milestone: None => 1.3.1 -- 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/1207635 Title: Cinderclient not converting third-party exceptions Status in OpenStack Dashboard (Horizon): Fix Released Status in Python client library for Cinder: Fix Released Bug description: When Cinder is available in the service catalog but it's not usable the /admin/info panel only shows a ConnectionError. There is no exception handling in openstack_dashboard/usage/quotas.py in the method _get_quota_data. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1207635/+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 1200214] Re: Relax OpenStack upper capping of client versions
** Changed in: python-cinderclient Status: Fix Committed => Fix Released ** Changed in: python-cinderclient Milestone: None => 1.3.1 -- 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/1200214 Title: Relax OpenStack upper capping of client versions Status in OpenStack Telemetry (Ceilometer): Fix Released Status in Cinder: Fix Released Status in Orchestration API (Heat): Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Bare Metal Provisioning Service (Ironic): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Compute (Nova): Fix Released Status in Python client library for Ceilometer: Fix Released Status in Python client library for Cinder: Fix Released Status in Python client library for Glance: Fix Released Status in Python client library for heat: Fix Released Status in Tempest: Fix Released Bug description: Because of the way the gate process pip requirements (one project at a time), on a current gate run we actually install and uninstall python-keystoneclient 4 times in a normal run, flipping back and forth from HEAD to 0.2.5. http://paste.openstack.org/show/39880/ - shows what's going on The net of this means that if any of the projects specify a capped client, it has the potential for preventing that client from being tested in the gate. As part of the discussion here: http://lists.openstack.org/pipermail/openstack- dev/2013-July/011660.html it was suggested to only cap client versions at the major version, since all minor version bumps must be strictly backward compatible by policy. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1200214/+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 1182678] Re: Horizon repeating log messages when DEBUG=True
** Changed in: python-cinderclient Status: Fix Committed => Fix Released ** Changed in: python-cinderclient Milestone: None => 1.3.1 -- 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/1182678 Title: Horizon repeating log messages when DEBUG=True Status in OpenStack Dashboard (Horizon): Fix Released Status in Python client library for Cinder: Fix Released Status in Python client library for Keystone: Fix Released Status in Python client library for Nova: Fix Released Bug description: When setting DEBUG=True (i.e., in devstack and other development environments) we noticed that all the python-*client API calls would get logged multiple times. On high-traffic dev instances, it would be dozens of repeats for each log message. This made development work on these instances an experience somewhere on the scale between "hey, this is annoying" and "it's impossible to tell what's going on through all this noise" Testing revealed that the problem seems to stem from different mod_wsgi processes/threads vivifying their own API client objects. The clients seem to blindly shove logging handlers into the list without looking to see if it's necessary to do so first, and this causes Horizon to have dozens of identical handlers for each log message, and it then does what you'd expect. This isn't a problem with Horizon per se, but Horizon is affected by it. So far, we've observed the problem with novaclient, cinderclient and keystoneclient, but all the client libraries likely behave in the same fashion. We also discovered in testing that there is no logging handler defined for cinderclient in the local_settings.py, so it uses the default hander. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1182678/+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 1172444] Re: migrate all projects to flake8
** Changed in: python-cinderclient Status: Fix Committed => Fix Released ** Changed in: python-cinderclient Milestone: None => 1.3.1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1172444 Title: migrate all projects to flake8 Status in OpenStack Telemetry (Ceilometer): Fix Released Status in Cinder: Fix Released Status in Python Gearman Interface: Fix Released Status in Git Review: Fix Released Status in Orchestration API (Heat): Fix Released Status in Heat API Instance Tools: Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Core Infrastructure: Fix Released Status in The Oslo library incubator: Fix Released Status in Python client library for Ceilometer: Fix Released Status in Python client library for Cinder: Fix Released Status in Python client library for Glance: Fix Released Status in Python client library for heat: Fix Released Status in Python client library for Keystone: Fix Released Status in Python client library for Neutron: Fix Released Status in Python client library for Nova: Fix Released Status in OpenStack Command Line Client: Fix Released Status in Python client library for Swift: Fix Released Status in Openstack Database (Trove): Fix Released Status in Zuul: A project gating system: Fix Released Bug description: affects openstack-ci milestone havana status triaged importance medium To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1172444/+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 1052161] Re: setup.py build fails on Windows due to hardcoded paths
** Changed in: python-cinderclient Status: Fix Committed => Fix Released ** Changed in: python-cinderclient Milestone: None => 1.3.1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1052161 Title: setup.py build fails on Windows due to hardcoded paths Status in OpenStack Neutron (virtual network service): Fix Released Status in The Oslo library incubator: Fix Released Status in oslo-incubator grizzly series: Fix Released Status in Python client library for Cinder: Fix Released Status in Python client library for Glance: Fix Released Status in Python client library for Keystone: Fix Released Status in Python client library for Neutron: Fix Released Status in Python client library for Nova: Fix Released Status in OpenStack Command Line Client: Fix Released Status in Python client library for Swift: Fix Committed Bug description: python setup.py build fails on Windows due to the following hardcoded /bib/sh path in setup.py, line 120: def _run_shell_command(cmd): output = subprocess.Popen(["/bin/sh", "-c", cmd], stdout=subprocess.PIPE) A possible solution consists in replacing "/bin/sh -c" with "cmd /C" when os.name == 'nt' To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1052161/+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 1013417] Re: Cinderclient Doesn't Return A Useful Error When Trying To Create A Volume Larger Than The Quota Allocation
** Changed in: python-cinderclient
Status: Fix Committed => Fix Released
** Changed in: python-cinderclient
Milestone: None => 1.3.1
--
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/1013417
Title:
Cinderclient Doesn't Return A Useful Error When Trying To Create A
Volume Larger Than The Quota Allocation
Status in OpenStack Compute (Nova):
Fix Released
Status in OpenStack Compute (nova) icehouse series:
Fix Released
Status in Python client library for Cinder:
Fix Released
Bug description:
Actually, it is nearly useless. It just returns an exception that it
casts from a HTTP 500.
My quota limit is 1000GB, here I try to make a volume that is 2000GB
g = cinderclient(request).volumes.create(size, display_name=name,
display_description=description)
cinderclient connection created using token
"e3fbb3c2d94949b0975db11de85bebc5" and url
"http://10.145.1.51:8776/v1/9da18fcaedf74eb7b1cf73b67b5b870c";
REQ: curl -i
http://10.145.1.51:8776/v1/9da18fcaedf74eb7b1cf73b67b5b870c/volumes -X
POST -H "X-Auth-Project-Id: 9da18fcaedf74eb7b1cf73b67b5b870c" -H
"User-Agent: python-novaclient" -H "Content-Type: application/json" -H
"Accept: application/json" -H "X-Auth-Token:
e3fbb3c2d94949b0975db11de85bebc5"
REQ BODY: {"volume": {"snapshot_id": null, "display_name": "My Vol",
"volume_type": null, "display_description": "", "size": 2000}}
RESP:{'date': 'Thu, 14 Jun 2012 22:14:02 GMT', 'status': '500',
'content-length': '128', 'content-type': 'application/json;
charset=UTF-8', 'x-compute-request-id': 'req-316c81e2-3407-4df0-8b0e-
190bf63f549b'} {"computeFault": {"message": "The server has either
erred or is incapable of performing the requested operation.", "code":
500}}
*** ClientException: The server has either erred or is incapable of
performing the requested operation. (HTTP 500) (Request-ID: req-
316c81e2-3407-4df0-8b0e-190bf63f549b)
This is basically useless from an end-user perspective and doesn't
allow us to tell users of Horizon anything useful about why this
error'd. :( It should probably be a 406, not a 500, and the error
message should be "Cannot create a volume of 2000GB because your quota
is currently 1000GB." Or something along those lines...
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1013417/+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 1004382] Re: Stuck to attached when a volume is detached from an instance
** Changed in: python-cinderclient Status: Fix Committed => Fix Released ** Changed in: python-cinderclient Milestone: None => 1.3.1 -- 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/1004382 Title: Stuck to attached when a volume is detached from an instance Status in Cinder: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Compute (Nova): Fix Released Status in Python client library for Cinder: Fix Released Bug description: When I try detach a volume from a running instance from the horizon interface, the status of the volume is still attached, even though the volume is successfully detached. When I refresh the page, the status of the volume become available. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1004382/+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 1449492] Re: Cinder not working with IPv6 ISCSI
** Also affects: cinder
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1449492
Title:
Cinder not working with IPv6 ISCSI
Status in Cinder:
New
Status in OpenStack Compute (Nova):
New
Bug description:
Testing configuring Openstack completely with IPv6
Found that IP address parsing was thrown in a lot of cases because of
need to have '[]' encasing the address, or not for use with URLs and
the parsing of some user space 3rd party C binaries - iscsiadm for
example. All the others are best left by using a name set to the IPv6
address in the /etc/hosts file, iSCSI though its not possible.
Got Cinder working by setting iscsi_ip_address
(/etc/cinder/cinder.conf) to '[$my_ip]' where my ip is an IPv6 address
like 2001:db08::1 (not RFC documentation address ?) and changing one
line of python iin the nova virt/libvirt/volume.py code:
--- nova/virt/libvirt/volume.py.orig2015-04-27 23:00:00.208075644 +1200
+++ nova/virt/libvirt/volume.py 2015-04-27 22:38:08.938643636 +1200
@@ -833,7 +833,7 @@
def _get_host_device(self, transport_properties):
"""Find device path in devtemfs."""
device = ("ip-%s-iscsi-%s-lun-%s" %
- (transport_properties['target_portal'],
+
(transport_properties['target_portal'].replace('[','').replace(']',''),
transport_properties['target_iqn'],
transport_properties.get('target_lun', 0)))
if self._get_transport() == "default":
Nova-compute was looking for '/dev/disk/by-path/ip-[2001:db08::1]:3260
-iscsi-iqn.2010-10.org.openstack:*' when there were no '[]' in the
udev generated path
This one can't be worked around by using the /etc/hosts file. iscsiadm
and tgt ned the IPv6 address wrapped in '[]', and iscsadm uses it in
output. The above patch could be matched with a bi ihte cinder code
that puts '[]' around iscsi_ip_address if if it is not supplied.
More work is obvioulsy need on a convention for writing IPv6 addresses
in the Openstack configuration files, and there will be a lot of
places where code will need to be tweaked.
Lets start by fixing this blooper/lo hanging one first though as it
makes it possible to get Cinder working in a pure IPv6 environment.
Above may be a bit of a hack, but only one one code path needs
adjustment...
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1449492/+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 1472828] [NEW] Remove hz.dashboard module from enabled
Public bug reported: Since hz.dashboard is now included at the app level, we no longer need to include them at the dashboard level. https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/app.module.js#L34 ** Affects: horizon Importance: Medium Assignee: Thai Tran (tqtran) Status: In Progress ** Tags: low-hanging-fruit -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1472828 Title: Remove hz.dashboard module from enabled Status in OpenStack Dashboard (Horizon): In Progress Bug description: Since hz.dashboard is now included at the app level, we no longer need to include them at the dashboard level. https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/app.module.js#L34 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1472828/+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 1472860] [NEW] install latest devstack error
Public bug reported: removing old stack folder and use latest devstack to install, we get the error: 015-07-09 03:10:00.733 | + git_clone git://git.openstack.org/openstack/keystone.git /opt/stack/keystone master 2015-07-09 03:10:00.733 | + local git_remote=git://git.openstack.org/openstack/keystone.git 2015-07-09 03:10:00.733 | + local git_dest=/opt/stack/keystone 2015-07-09 03:10:00.733 | + local git_ref=master 2015-07-09 03:10:00.734 | ++ pwd 2015-07-09 03:10:00.735 | + local orig_dir=/home/canh/devstack 2015-07-09 03:10:00.735 | + local git_clone_flags= 2015-07-09 03:10:00.736 | ++ trueorfalse False RECLONE 2015-07-09 03:10:00.741 | + RECLONE=False 2015-07-09 03:10:00.741 | + [[ 0 -gt 0 ]] 2015-07-09 03:10:00.741 | + [[ False = \T\r\u\e ]] 2015-07-09 03:10:00.742 | + echo master 2015-07-09 03:10:00.742 | + egrep -q '^refs' 2015-07-09 03:10:00.744 | + [[ ! -d /opt/stack/keystone ]] 2015-07-09 03:10:00.745 | + [[ False = \T\r\u\e ]] 2015-07-09 03:10:00.745 | + git_timed clone git://git.openstack.org/openstack/keystone.git /opt/stack/keystone 2015-07-09 03:10:00.745 | + local count=0 2015-07-09 03:10:00.745 | + local timeout=0 2015-07-09 03:10:00.745 | + [[ -n 0 ]] 2015-07-09 03:10:00.745 | + timeout=0 2015-07-09 03:10:00.745 | + timeout -s SIGINT 0 git clone git://git.openstack.org/openstack/keystone.git /opt/stack/keystone 2015-07-09 03:10:00.748 | Cloning into '/opt/stack/keystone'... 2015-07-09 03:10:13.001 | + cd /opt/stack/keystone 2015-07-09 03:10:13.001 | + git checkout master 2015-07-09 03:10:13.053 | Already on 'master' 2015-07-09 03:10:13.053 | Your branch is up-to-date with 'origin/master'. 2015-07-09 03:10:13.054 | + cd /opt/stack/keystone 2015-07-09 03:10:13.055 | + git show --oneline 2015-07-09 03:10:13.055 | + head -1 2015-07-09 03:10:13.060 | 2bf413e Merge "Remove convert_to_sqlite.sh" 2015-07-09 03:10:13.060 | + cd /home/canh/devstack 2015-07-09 03:10:13.061 | + setup_develop /opt/stack/keystone 2015-07-09 03:10:13.061 | + local project_dir=/opt/stack/keystone 2015-07-09 03:10:13.061 | + setup_package_with_req_sync /opt/stack/keystone -e 2015-07-09 03:10:13.061 | + local project_dir=/opt/stack/keystone 2015-07-09 03:10:13.061 | + local flags=-e 2015-07-09 03:10:13.061 | ++ cd /opt/stack/keystone 2015-07-09 03:10:13.062 | ++ git diff --exit-code 2015-07-09 03:10:13.067 | + local update_requirements= 2015-07-09 03:10:13.067 | + [[ '' != \c\h\a\n\g\e\d ]] 2015-07-09 03:10:13.067 | + [[ strict == \s\o\f\t ]] 2015-07-09 03:10:13.068 | + cd /opt/stack/requirements 2015-07-09 03:10:13.068 | + python update.py /opt/stack/keystone 2015-07-09 03:10:13.107 | Traceback (most recent call last): 2015-07-09 03:10:13.108 | File "update.py", line 35, in 2015-07-09 03:10:13.108 | from openstack_requirements import project 2015-07-09 03:10:13.108 | ImportError: No module named openstack_requirements 2015-07-09 03:10:13.111 | + exit_trap 2015-07-09 03:10:13.112 | + local r=1 2015-07-09 03:10:13.112 | ++ jobs -p 2015-07-09 03:10:13.113 | + jobs= 2015-07-09 03:10:13.113 | + [[ -n '' ]] 2015-07-09 03:10:13.113 | + kill_spinner 2015-07-09 03:10:13.113 | + '[' '!' -z '' ']' 2015-07-09 03:10:13.113 | + [[ 1 -ne 0 ]] 2015-07-09 03:10:13.113 | + echo 'Error on exit' 2015-07-09 03:10:13.113 | Error on exit 2015-07-09 03:10:13.113 | + [[ -z /opt/stack/logs ]] 2015-07-09 03:10:13.113 | + /home/canh/devstack/tools/worlddump.py -d /opt/stack/logs 2015-07-09 03:10:16.852 | + exit 1 ** 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/1472860 Title: install latest devstack error Status in OpenStack Dashboard (Horizon): New Bug description: removing old stack folder and use latest devstack to install, we get the error: 015-07-09 03:10:00.733 | + git_clone git://git.openstack.org/openstack/keystone.git /opt/stack/keystone master 2015-07-09 03:10:00.733 | + local git_remote=git://git.openstack.org/openstack/keystone.git 2015-07-09 03:10:00.733 | + local git_dest=/opt/stack/keystone 2015-07-09 03:10:00.733 | + local git_ref=master 2015-07-09 03:10:00.734 | ++ pwd 2015-07-09 03:10:00.735 | + local orig_dir=/home/canh/devstack 2015-07-09 03:10:00.735 | + local git_clone_flags= 2015-07-09 03:10:00.736 | ++ trueorfalse False RECLONE 2015-07-09 03:10:00.741 | + RECLONE=False 2015-07-09 03:10:00.741 | + [[ 0 -gt 0 ]] 2015-07-09 03:10:00.741 | + [[ False = \T\r\u\e ]] 2015-07-09 03:10:00.742 | + echo master 2015-07-09 03:10:00.742 | + egrep -q '^refs' 2015-07-09 03:10:00.744 | + [[ ! -d /opt/stack/keystone ]] 2015-07-09 03:10:00.745 | + [[ False = \T\r\u\e ]] 2015-07-09 03:10:00.745 | + git_timed clone git://git.openstack.org/openstack/keystone.git /opt/stack/keystone 2015-07-09 03:10:00.745 | + local count=0 2015-07-09 03:10:00.745 | + local timeout=0 2015-07-09 03:10:00
[Yahoo-eng-team] [Bug 1472900] [NEW] instance boot from image(creates a new volume) deploy failed when volume rescheduling to other backends
Public bug reported: This bug happens in Icehouse and Kilo version of openstack. I launched instance on web by " boot from image(creates a new volume)", it failed and raise "Invalid volume", and I check cinder list, found the volume is rescheduled and created success. I reviewed the code of cinder volume, found that when volume create failed on one backends, the volume create workflow will revert, which will set the volume status "creating" and reschedule, and then set the volume status "error", volume rescheduled to other backends and then set status "downloading", "available". In the process of launching instances, nova wait the volume status in function "_await_block_device_map_created", it returned when volume status in "available" and "error", when volume rescheduling happend, it will return with volume in "error" state, and then raise "Invalid volume" in function check_attach when volume attach. it suggests that when volume is rescheduling, volume status will be set to "rescheduling", without setting to "error" state in wokrflow revert, which make the volume status precise to other components. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1472900 Title: instance boot from image(creates a new volume) deploy failed when volume rescheduling to other backends Status in OpenStack Compute (Nova): New Bug description: This bug happens in Icehouse and Kilo version of openstack. I launched instance on web by " boot from image(creates a new volume)", it failed and raise "Invalid volume", and I check cinder list, found the volume is rescheduled and created success. I reviewed the code of cinder volume, found that when volume create failed on one backends, the volume create workflow will revert, which will set the volume status "creating" and reschedule, and then set the volume status "error", volume rescheduled to other backends and then set status "downloading", "available". In the process of launching instances, nova wait the volume status in function "_await_block_device_map_created", it returned when volume status in "available" and "error", when volume rescheduling happend, it will return with volume in "error" state, and then raise "Invalid volume" in function check_attach when volume attach. it suggests that when volume is rescheduling, volume status will be set to "rescheduling", without setting to "error" state in wokrflow revert, which make the volume status precise to other components. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1472900/+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 1472899] [NEW] bug in ipam driver code
Public bug reported: http://logs.openstack.org/26/195326/21/check/check-tempest-dsvm- networking- ovn/c071fed/logs/screen-q-svc.txt.gz?level=TRACE#_2015-07-09_04_45_12_248 Fails on existing tempest test. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1472899 Title: bug in ipam driver code Status in OpenStack Neutron (virtual network service): New Bug description: http://logs.openstack.org/26/195326/21/check/check-tempest-dsvm- networking- ovn/c071fed/logs/screen-q-svc.txt.gz?level=TRACE#_2015-07-09_04_45_12_248 Fails on existing tempest test. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1472899/+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
