[Yahoo-eng-team] [Bug 1479644] [NEW] nova periodic_task.periodic_task can be moved to oslo_service
Public bug reported: periodic_task.periodic_task is already put in oslo_service\periodic_task so the class in "openstack.commonperiodic_task.periodic_task " can be deleted and use "oslo_service.periodic_task.periodicTasks" ** 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/1479644 Title: nova periodic_task.periodic_task can be moved to oslo_service Status in OpenStack Compute (nova): New Bug description: periodic_task.periodic_task is already put in oslo_service\periodic_task so the class in "openstack.commonperiodic_task.periodic_task " can be deleted and use "oslo_service.periodic_task.periodicTasks" To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1479644/+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 1376316] Re: nova absolute-limits floating ip count is incorrect
Re-verified this on Kilo: (tempest)ubuntu@james-page-bastion:~/tools/openstack-charm-testing⟫ nova floating-ip-create +--++---+--+-+ | Id | IP | Server Id | Fixed IP | Pool| +--++---+--+-+ | b4c00015-d1e7-49cd-9b34-1dc20a955df5 | 10.5.150.1 | - | -| ext_net | +--++---+--+-+ (tempest)ubuntu@james-page-bastion:~/tools/openstack-charm-testing⟫ nova absolute-limits ++--+---+ | Name | Used | Max | ++--+---+ | Cores | 0| 20| | FloatingIps| 0| 10| | ImageMeta | -| 128 | | Instances | 0| 10| | Keypairs | -| 100 | | Personality| -| 5 | | Personality Size | -| 10240 | | RAM| 0| 51200 | | SecurityGroupRules | -| 20| | SecurityGroups | 0| 10| | Server Meta| -| 128 | | ServerGroupMembers | -| 10| | ServerGroups | 0| 10| ++--+---+ ** Package changed: python-novaclient (Ubuntu) => nova (Ubuntu) ** Also affects: nova Importance: Undecided Status: New ** Summary changed: - nova absolute-limits floating ip count is incorrect + nova absolute-limits floating ip count is incorrect in a neutron based deployment ** Changed in: nova (Ubuntu) Status: Confirmed => Triaged ** Changed in: nova (Ubuntu) Importance: Medium => Low -- 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/1376316 Title: nova absolute-limits floating ip count is incorrect in a neutron based deployment Status in OpenStack Compute (nova): New Status in nova package in Ubuntu: Triaged Bug description: 1. $ lsb_release -rd Description: Ubuntu 14.04 LTS Release: 14.04 2. $ apt-cache policy python-novaclient python-novaclient: Installed: 1:2.17.0-0ubuntu1 Candidate: 1:2.17.0-0ubuntu1 Version table: *** 1:2.17.0-0ubuntu1 0 500 http://nova.clouds.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages 100 /var/lib/dpkg/status 3. nova absolute-limits should report the correct value of allocated floating ips 4. nova absolute-limits shows 0 floating ips when I have 5 allocated $ nova absolute-limits | grep Floating | totalFloatingIpsUsed| 0 | | maxTotalFloatingIps | 10 | $ nova floating-ip-list +---+---++-+ | Ip| Server Id | Fixed Ip | Pool| +---+---++-+ | 10.98.191.146 | | - | ext_net | | 10.98.191.100 | | 10.5.0.242 | ext_net | | 10.98.191.138 | | 10.5.0.2 | ext_net | | 10.98.191.147 | | - | ext_net | | 10.98.191.102 | | - | ext_net | +---+---++-+ ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: python-novaclient 1:2.17.0-0ubuntu1 ProcVersionSignature: User Name 3.13.0-24.47-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 Date: Wed Oct 1 15:19:08 2014 Ec2AMI: ami-0001 Ec2AMIManifest: FIXME Ec2AvailabilityZone: nova Ec2InstanceType: m1.small Ec2Kernel: aki-0002 Ec2Ramdisk: ari-0002 PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: python-novaclient UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1376316/+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 1479637] [NEW] CSS get None when error in inline_editing
Public bug reported: Like bugs #1470594 But this time it show up when the inline editor error occur. GET http://172.22.2.24/static/dashboard/scss/None 404 (NOT FOUND) jQuery.extend.style @ 6b862e7eeeb9.js:449 (anonymous function) @ 6b862e7eeeb9.js:627 jQuery.extend.access @ 6b862e7eeeb9.js:47 jQuery.each.jQuery.each.jQuery.fn.(anonymous function) @ 6b862e7eeeb9.js:625 self.update.horizon.ajax.queue.error @ c5b1a3ff77e6.js:3180 jQuery.Callbacks.fire @ 6b862e7eeeb9.js:187 jQuery.Callbacks.self.fireWith @ 6b862e7eeeb9.js:192 done @ 6b862e7eeeb9.js:524 jQuery.ajaxTransport.s.send.callback @ 6b862e7eeeb9.js:560 ** Affects: horizon Importance: Undecided Assignee: eric (eric-y-i) 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/1479637 Title: CSS get None when error in inline_editing Status in OpenStack Dashboard (Horizon): New Bug description: Like bugs #1470594 But this time it show up when the inline editor error occur. GET http://172.22.2.24/static/dashboard/scss/None 404 (NOT FOUND) jQuery.extend.style @ 6b862e7eeeb9.js:449 (anonymous function) @ 6b862e7eeeb9.js:627 jQuery.extend.access @ 6b862e7eeeb9.js:47 jQuery.each.jQuery.each.jQuery.fn.(anonymous function) @ 6b862e7eeeb9.js:625 self.update.horizon.ajax.queue.error @ c5b1a3ff77e6.js:3180 jQuery.Callbacks.fire @ 6b862e7eeeb9.js:187 jQuery.Callbacks.self.fireWith @ 6b862e7eeeb9.js:192 done @ 6b862e7eeeb9.js:524 jQuery.ajaxTransport.s.send.callback @ 6b862e7eeeb9.js:560 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1479637/+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 1317515] Re: flavor-access-add doesn't validate the tenant id
** Also affects: cinder Importance: Undecided Status: New ** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1317515 Title: flavor-access-add doesn't validate the tenant id Status in Cinder: New Status in neutron: New Status in OpenStack Compute (nova): Confirmed Bug description: I can use a random string to represent the tenant when calling flavor- access-add, and it will be shown in the flavor-access-list output even though it has no meaning and won't work. This causes confusion for users, who use the command to add tenants by name and then wonder why they can't access the new flavour (e.g. bug 1083602, bug 1315479). Steps to reproduce: 1. Create a private flavour $ nova flavor-create --is-public false abcdef auto 1 1 1 +--++---+--+---+--+---+-+---+ | ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | +--++---+--+---+--+---+-+---+ | f349c9a1-ce16-4511-9da0-eeced2f1baa4 | abcdef | 1 | 1| 0 | | 1 | 1.0 | False | +--++---+--+---+--+---+-+---+ 2. Give access to a tenant by name $ nova flavor-access-add f349c9a1-ce16-4511-9da0-eeced2f1baa4 demo 3. It looks like it was added correctly, but if I do 'nova flavor- list' with a user from the demo tenant it will not show the flavour. $ nova flavor-access-list --flavor f349c9a1-ce16-4511-9da0-eeced2f1baa4 +--+---+ | Flavor_ID| Tenant_ID | +--+---+ | f349c9a1-ce16-4511-9da0-eeced2f1baa4 | demo | +--+---+ The name doesn't need to exist at all, I can successfully add random strings: $ nova flavor-access-add f349c9a1-ce16-4511-9da0-eeced2f1baa4 this-tenant-does-not-exist +--++ | Flavor_ID| Tenant_ID | +--++ | f349c9a1-ce16-4511-9da0-eeced2f1baa4 | demo | | f349c9a1-ce16-4511-9da0-eeced2f1baa4 | this-tenant-does-not-exist | +--++ I think we shouldn't allow invalid IDs when running "nova flavor- access-add". To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1317515/+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 1399065] Re: Quota updated through nova api not refelected in Horizon
*** This bug is a duplicate of bug 1317515 *** https://bugs.launchpad.net/bugs/1317515 Running OpenStack IceHouse. I can confirm that if I do: nova quota-update --instances 0 [...--all other things 0...] my-tenant- name nova quota-show my-tenant-name +-+---+ | Quota | Limit | +-+---+ | instances | 0 | | cores | 0 | | ram | 0 | | floating_ips| 0 | | fixed_ips | 0 | | metadata_items | 0 | | injected_files | 0 | | injected_file_content_bytes | 0 | | injected_file_path_bytes| 0 | | key_pairs | 0 | | security_groups | 0 | | security_group_rules| 0 | +-+---+ You can see that the quota update apparently works and I can even query the quota for my-tenant-name and get back the right results. However, when I query the TENANT_ID that matches my tenant name, I see: nova quota-show --tenant $TENANT_ID +-+---+ | Quota | Limit | +-+---+ | instances | 10| | cores | 20| | ram | 65536 | | floating_ips| 5 | | fixed_ips | -1| | metadata_items | 128 | | injected_files | 5 | | injected_file_content_bytes | 10240 | | injected_file_path_bytes| 255 | | key_pairs | 100 | | security_groups | 10| | security_group_rules| 20| +-+---+ The same is shown on the dashboard, and as expected, I can launch instances. Looking at the quotas table in the database, in particular the tenant- id, we can see that OpenStack inserted the tenant name (my-tenant-name), instead the tenant-id in the tenant-id column. mysql> select * from quotas; | 3015 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | metadata_items | 1 | 0 | | 3018 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | injected_file_content_bytes | 1 | 0 | | 3021 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | ram | 1 | 0 | | 3024 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | floating_ips| 1 | 0 | | 3027 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | key_pairs | 1 | 0 | | 3030 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | instances | 1 | 0 | | 3033 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | injected_files | 1 | 0 | | 3036 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | cores | 1 | 0 | | 3039 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | fixed_ips | 1 | 0 | | 3042 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | injected_file_path_bytes| 1 | 0 | | 3093 | 2015-07-30 03:43:28 | 2015-07-30 04:26:04 | NULL | my-tenant-name | security_group_rules| 1 | 0 | | 3108 | 2015-07-30 03:43:28 | 2015-07-30 04:26:04 | NULL | my-tenant-name | security_groups | 1 | 0 | The same applies to cinder and neutron. In essence, the APIs and the command line tools should refuse to update quota for a tenant-id that does not exist, but are not doing so. As a result, you end up with some dodgy entries in the database and an apparently successful quota update that does not work. ** Also affects: cinder Importance: Undecided Status: New ** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1399065 Title: Quota updated through nova api not refelected in Horizon Status in Cinder: New Status in OpenStack Dashboard (Horizon): Invalid Status in neutron: New Status in OpenStack Compute (nova): Invalid Bug description: I am trying to update the quota of the user using the nova.quota.update( ... ), when i do this the quota is reflected in the commmond line but the same updated values are not reflected in the horizon dashboard. To manage notifications about this bug go to: https://bugs.launchpad.ne
[Yahoo-eng-team] [Bug 1479604] [NEW] load instance failed from other compute node(Nova-networking)
Public bug reported: pre-condition: OS: ubuntu14.04; nova-networking mode, one controller node, three compute nodes(compute1, compute2, compute3), one block node; only one NIC in every node; Error description: I load some instances, at first, some instances are load correctly in compute1 node, when I load the fourth instance, it's create failed(HOST is compute2 and status is ERROR) ; the error logs(more information pls refer nova-compute.log as attachment): ERROR nova.compute.manager [-] Instance failed network setup after 1 attempt(s) TRACE nova.compute.manager Traceback (most recent call last): TRACE nova.compute.manager RemoteError: Remote error: ProcessExecutionError Unexpected error while running command. TRACE nova.compute.manager Exit code: 2 TRACE nova.compute.manager Stdout: u'' Loading network driver \'nova.netwok.linux_net\'\\n\\ndnsmasq: failed to create listening socket for 192.168.122.1: Address already in use\\n"\n']. TRACE nova.compute.manager ERROR nova.compute.manager Instance failed to spawn TRACE nova.compute.manager RemoteError: Remote error: ProcessExecutionError Unexpected error while running command. TRACE nova.compute.manager Exit code: 2 compute node nova.conf configuration(all compute node's configuration are same except IP address) , [DEFAULT] dhcpbridge_flagfile=/etc/nova/nova.conf dhcpbridge=/usr/bin/nova-dhcpbridge logdir=/var/log/nova state_path=/var/lib/nova lock_path=/var/lock/nova force_dhcp_release=True iscsi_helper=tgtadm libvirt_use_virtio_for_bridges=True connection_type=libvirt root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf verbose=True ec2_private_dns_show_ip=True api_paste_config=/etc/nova/api-paste.ini volumes_path=/var/lib/nova/volumes enabled_apis=ec2,osapi_compute,metadata rpc_backend = rabbit rabbit_host = controller rabbit_password = RABBIT_PASS auth_strategy = keystone my_ip = 10.71.255.206 vnc_enabled = True vncserver_listen = 0.0.0.0 vncserver_proxyclient_address = 10.71.255.206 novncproxy_base_url = http://controller:6080/vnc_auto.html network_api_class = nova.network.api.API security_group_api = nova firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver network_manager = nova.network.manager.FlatDHCPManager network_size = 254 allow_same_net_traffic = False multi_host = True send_arp_for_ha = True share_dhcp_address = True force_dhcp_release = True flat_network_bridge = br100 flat_interface = eth0 public_interface = eth0 [keystone_authtoken] auth_uri = http://controller:5000/v2.0 identity_uri = http://controller:35357 admin_tenant_name = service admin_user = nova admin_password = NOVA_PASS [glance] host = controller Thanks. Jazry ** Affects: nova Importance: Undecided Status: New ** Attachment added: "nova-compute.log" https://bugs.launchpad.net/bugs/1479604/+attachment/4436022/+files/nova-compute.log -- 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/1479604 Title: load instance failed from other compute node(Nova-networking) Status in OpenStack Compute (nova): New Bug description: pre-condition: OS: ubuntu14.04; nova-networking mode, one controller node, three compute nodes(compute1, compute2, compute3), one block node; only one NIC in every node; Error description: I load some instances, at first, some instances are load correctly in compute1 node, when I load the fourth instance, it's create failed(HOST is compute2 and status is ERROR) ; the error logs(more information pls refer nova-compute.log as attachment): ERROR nova.compute.manager [-] Instance failed network setup after 1 attempt(s) TRACE nova.compute.manager Traceback (most recent call last): TRACE nova.compute.manager RemoteError: Remote error: ProcessExecutionError Unexpected error while running command. TRACE nova.compute.manager Exit code: 2 TRACE nova.compute.manager Stdout: u'' Loading network driver \'nova.netwok.linux_net\'\\n\\ndnsmasq: failed to create listening socket for 192.168.122.1: Address already in use\\n"\n']. TRACE nova.compute.manager ERROR nova.compute.manager Instance failed to spawn TRACE nova.compute.manager RemoteError: Remote error: ProcessExecutionError Unexpected error while running command. TRACE nova.compute.manager Exit code: 2 compute node nova.conf configuration(all compute node's configuration are same except IP address) , [DEFAULT] dhcpbridge_flagfile=/etc/nova/nova.conf dhcpbridge=/usr/bin/nova-dhcpbridge logdir=/var/log/nova state_path=/var/lib/nova lock_path=/var/lock/nova force_dhcp_release=True iscsi_helper=tgtadm libvirt_use_virtio_for_bridges=True connection_type=libvirt root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf verbose=True ec2_private_dns_show_ip=True api_paste_config=/etc/nova/api-paste.ini volumes_path=/var/lib/nova/volumes enabled_apis=ec2
[Yahoo-eng-team] [Bug 1479578] [NEW] Domain-specific config breaks some ops
Public bug reported: I set up a multi-domain config on my devstack and tried to do a simple: $ openstack user list with project-scoped environment variables (in fact I downloaded the admin-openrc.sh from Horizon). This results in: ERROR: openstack The request you have made requires authentication. (Disable debug mode to suppress these details.) (HTTP 401) (Request-ID: req-b687e823-9896-4905-83d3-b1e45fa966ed) If I disable domain-specific configs in the keystone.conf, it works again. If it *is* enabled, I can force a domain-specific request using something like: $ OS_TENANT_ID= OS_TENANT_NAME= OS_PROJECT_NAME= openstack --os-domain- name user list However if I specify the default domain then I get this: ERROR: openstack User 0fa9633d884a42448bbd386778ca6b87 has no access to domain default (Disable debug mode to suppress these details.) (HTTP 401) (Request-ID: req-65e053e4-33c2-4b7b-aedf-30d3ef88735c) ** 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/1479578 Title: Domain-specific config breaks some ops Status in Keystone: New Bug description: I set up a multi-domain config on my devstack and tried to do a simple: $ openstack user list with project-scoped environment variables (in fact I downloaded the admin-openrc.sh from Horizon). This results in: ERROR: openstack The request you have made requires authentication. (Disable debug mode to suppress these details.) (HTTP 401) (Request- ID: req-b687e823-9896-4905-83d3-b1e45fa966ed) If I disable domain-specific configs in the keystone.conf, it works again. If it *is* enabled, I can force a domain-specific request using something like: $ OS_TENANT_ID= OS_TENANT_NAME= OS_PROJECT_NAME= openstack --os- domain-name user list However if I specify the default domain then I get this: ERROR: openstack User 0fa9633d884a42448bbd386778ca6b87 has no access to domain default (Disable debug mode to suppress these details.) (HTTP 401) (Request-ID: req-65e053e4-33c2-4b7b-aedf-30d3ef88735c) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1479578/+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 1479123] Re: N1Kv ML2 mech driver and DB models decomposition
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Assignee: (unassigned) => Saksham Varma (sakvarma) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1479123 Title: N1Kv ML2 mech driver and DB models decomposition Status in networking-cisco: In Progress Status in neutron: In Progress Bug description: As part of the second phase of core-vendor decomposition, N1Kv mech driver and DB models need to be moved from neutron's shim layer to the networking-cisco repo. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-cisco/+bug/1479123/+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 1479558] [NEW] _ensure_default_security_group calls create_security_group within at db transaction
Public bug reported: _ensure_default_security_group calls create_security_group within at db transaction [1], Neutron plugin may choose to override create_security_group so it can invoke backend operations, handling it under an open transaction might lead to a db lock timeout. [1]: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/securitygroups_db.py#n666 ** Affects: neutron Importance: Undecided Assignee: Roey Chen (roeyc) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Roey Chen (roeyc) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1479558 Title: _ensure_default_security_group calls create_security_group within at db transaction Status in neutron: In Progress Bug description: _ensure_default_security_group calls create_security_group within at db transaction [1], Neutron plugin may choose to override create_security_group so it can invoke backend operations, handling it under an open transaction might lead to a db lock timeout. [1]: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/securitygroups_db.py#n666 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1479558/+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 1479551] [NEW] Keystone project role REST is broken
Public bug reported: There is an extra white space in the REST url making it impossible to reach the endpoint. Removing the white space will fix this issue. ** Affects: horizon Importance: High 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/1479551 Title: Keystone project role REST is broken Status in OpenStack Dashboard (Horizon): In Progress Bug description: There is an extra white space in the REST url making it impossible to reach the endpoint. Removing the white space will fix this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1479551/+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 1398754] Re: LBaas v1 Associate Monitor to Pool Fails
** Changed in: horizon/kilo Status: Fix Committed => 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/1398754 Title: LBaas v1 Associate Monitor to Pool Fails Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: Try to associate health monitor to pool in horizon, there's no monitor listed on page "Associate Monitor". Reproduce Procedure: 1. Create Pool 2. Add two members 3. Create Health Monitor 4. Click "Associate Monitor" button of pool resource 5. There's no monitor listed. *** At this point, use CLI to: 1. show pool, there's no monitor associated yet. ++--+ | Field | Value | ++--+ | health_monitors| | | health_monitors_status | | ++--+ 2. list monitor, there's available monitor. $ neutron lb-healthmonitor-list +--+--++ | id | type | admin_state_up | +--+--++ | f5e764f0-eceb-4516-9919-7806f409c1ae | HTTP | True | +--+--++ 3. Assocaite monitor to pool. Succeeded. $ neutron lb-healthmonitor-associate f5e764f0-eceb-4516-9919-7806f409c1ae mypool Associated health monitor f5e764f0-eceb-4516-9919-7806f409c1ae * Base on above info, it should be a horizon bug. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1398754/+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 1416496] Re: nova.conf - configuration options icehouse compat flag is not right
** Changed in: nova/kilo Status: Fix Committed => 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/1416496 Title: nova.conf - configuration options icehouse compat flag is not right Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Status in openstack-manuals: Fix Released Bug description: Table 2.57. Description of upgrade levels configuration options has the wrong information for setting icehouse/juno compat flags during upgrades. Specifically this section: compute = None (StrOpt) Set a version cap for messages sent to compute services. If you plan to do a live upgrade from havana to icehouse, you should set this option to "icehouse-compat" before beginning the live upgrade procedure This should be compute = , for example compute = icehouse when doing an upgrade from I to J. --- Built: 2015-01-29T19:27:05 00:00 git SHA: 3e80c2419cfe03f86057f3229044cd0d495e0295 URL: http://docs.openstack.org/juno/config-reference/content/list-of-compute-config-options.html source File: file:/home/jenkins/workspace/openstack-manuals-tox-doc-publishdocs/doc/config-reference/compute/section_compute-options-reference.xml xml:id: list-of-compute-config-options To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1416496/+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 1447249] Re: Ironic: injected files not passed through to configdrive
** Changed in: nova/kilo Status: Fix Committed => 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/1447249 Title: Ironic: injected files not passed through to configdrive Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: The ironic driver's code to generate a configdrive does not pass injected_files through to the configdrive builder, resulting in injected files not being in the resulting configdrive. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1447249/+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 1249065] Re: Nova throws 400 when attempting to add floating ip (instance.info_cache.network_info is empty)
** Changed in: nova/kilo Status: Fix Committed => 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/1249065 Title: Nova throws 400 when attempting to add floating ip (instance.info_cache.network_info is empty) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: Ran into this problem in check-tempest-devstack-vm-neutron Traceback (most recent call last): File "tempest/scenario/test_snapshot_pattern.py", line 74, in test_snapshot_pattern self._set_floating_ip_to_server(server, fip_for_server) File "tempest/scenario/test_snapshot_pattern.py", line 62, in _set_floating_ip_to_server server.add_floating_ip(floating_ip) File "/opt/stack/new/python-novaclient/novaclient/v1_1/servers.py", line 108, in add_floating_ip self.manager.add_floating_ip(self, address, fixed_address) File "/opt/stack/new/python-novaclient/novaclient/v1_1/servers.py", line 465, in add_floating_ip self._action('addFloatingIp', server, {'address': address}) File "/opt/stack/new/python-novaclient/novaclient/v1_1/servers.py", line 993, in _action return self.api.client.post(url, body=body) File "/opt/stack/new/python-novaclient/novaclient/client.py", line 234, in post return self._cs_request(url, 'POST', **kwargs) File "/opt/stack/new/python-novaclient/novaclient/client.py", line 213, in _cs_request **kwargs) File "/opt/stack/new/python-novaclient/novaclient/client.py", line 195, in _time_request resp, body = self.request(url, method, **kwargs) File "/opt/stack/new/python-novaclient/novaclient/client.py", line 189, in request raise exceptions.from_response(resp, body, url, method) BadRequest: No nw_info cache associated with instance (HTTP 400) (Request-ID: req-9fea0363-4532-4ad1-af89-114cff68bd89) Full console logs here: http://logs.openstack.org/27/55327/3/check /check-tempest-devstack-vm-neutron/8d26d3c/console.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1249065/+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 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests
** Changed in: keystone/kilo Status: Fix Committed => 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/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in Keystone: Fix Released Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Released Status in Manila: Fix Released Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Status in Sahara: Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+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 1296414] Re: quotas not updated when periodic tasks or startup finish deletes
** Changed in: nova/kilo Status: Fix Committed => 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/1296414 Title: quotas not updated when periodic tasks or startup finish deletes Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: There are a couple of cases in the compute manager where we don't pass reservations to _delete_instance(). For example, one of them is cleaning up when we see a delete that is stuck in DELETING. The only place we ever update quotas as part of delete should be when the instance DB record is removed. If something is stuck in DELETING, it means that the quota was not updated. We should make sure we're always updating the quota when the instance DB record is removed. Soft delete kinda throws a wrench in this, though, because I think you want soft deleted instances to not count against quotas -- yet their DB records will still exist. In this case, it seems we may have a race condition in _delete_instance() -> _complete_deletion() where if the instance somehow was SOFT_DELETED, quotas would have updated twice (once in soft_delete and once in _complete_deletion). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1296414/+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 1407664] Re: Race: instance nw_info cache is updated to empty list because of nova/neutron event mechanism
** Changed in: nova/kilo Status: Fix Committed => 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/1407664 Title: Race: instance nw_info cache is updated to empty list because of nova/neutron event mechanism Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: This applies only when the nova/neutron event reporting mechanism is enabled. Boot instance, like this: nova boot --image xxx --flavor xxx --nic port-id=xxx test_vm The booting instance is successful, but instance nw_info cache is empty. This is a probabilistic problem, not always can be reproduced. After analysis the booting instance and nova/neutron event mechanism workflow, I get the reproduce timeline: 1. neutronv2.api.allocate_for_instance when booting instance 2. neutronclient.update_port trigger neutron network_change event 3. nova get the port change event, start to dispose event 4. instance.get_by_uuid in external_instance_event , at this time instance.nw_info_cache is empty, because nw_info cache hadn't been added into db in booting instance thread. 5. booting instance thread start to save the instance nw_info cache into db. 6. event disposing thread start to update instance nw_info cache to empty. Face this issue in Juno. I add some breakpoints in order to reproduce this bug in my devstack. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1407664/+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 1417379] Re: KeyError returned when subnet-update enable_dhcp to False
** Changed in: neutron/kilo Status: Fix Committed => 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/1417379 Title: KeyError returned when subnet-update enable_dhcp to False Status in neutron: Fix Released Status in neutron kilo series: Fix Released Bug description: Keyerror outputed in the trace log after set enable_dhcp of subnet to False. [reproduce] neutron net-create test neutron dhcp-agent-network-add ID_of_DHCP_agent test neutron subnet-create test 192.168.100.0/24 --name test1 neutron subnet-create test 192.168.101.0/24 --name test2 neutron subnet-update test2 --enable_dhcp False tailf /opt/stack/logs/q-dhcp.log [Trace log] 2015-02-14 01:01:08.556 5436 DEBUG neutron.agent.dhcp.agent [-] resync (536ef879-baf5-405b-8402-303ff5e2e905): [KeyError(u'37f0b628-22e6-4446-8bb9-2c2176c5a646',)] _periodic_resync_helper /opt/stack/neutron/neutron/agent/dhcp/agent.py:189 2015-02-14 01:01:08.557 5436 DEBUG oslo_concurrency.lockutils [-] Lock "dhcp-agent" acquired by "sync_state" :: waited 0.000s inner /usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:430 2015-02-14 01:01:08.558 5436 INFO neutron.agent.dhcp.agent [-] Synchronizing state 2015-02-14 01:01:08.559 5436 DEBUG oslo_messaging._drivers.amqpdriver [-] MSG_ID is a0f460425e904cc0b045336351d961d5 _send /usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:378 2015-02-14 01:01:08.559 5436 DEBUG oslo_messaging._drivers.amqp [-] UNIQUE_ID is d3aff7b1f8744f5b909ef5bc6eded8d2. _add_unique_id /usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqp.py:224 2015-02-14 01:01:08.632 5436 DEBUG neutron.agent.dhcp.agent [-] Calling driver for network: 536ef879-baf5-405b-8402-303ff5e2e905 action: enable call_driver /opt/stack/neutron/neutron/agent/dhcp/agent.py:106 2015-02-14 01:01:08.633 5436 DEBUG neutron.agent.linux.utils [-] Unable to access /opt/stack/data/neutron/dhcp/536ef879-baf5-405b-8402-303ff5e2e905/pid get_value_from_file /opt/stack/neutron/neutron/agent/linux/utils.py:168 2015-02-14 01:01:08.633 5436 ERROR neutron.agent.dhcp.agent [-] Unable to enable dhcp for 536ef879-baf5-405b-8402-303ff5e2e905. 2015-02-14 01:01:08.633 5436 TRACE neutron.agent.dhcp.agent Traceback (most recent call last): 2015-02-14 01:01:08.633 5436 TRACE neutron.agent.dhcp.agent File "/opt/stack/neutron/neutron/agent/dhcp/agent.py", line 116, in call_driver 2015-02-14 01:01:08.633 5436 TRACE neutron.agent.dhcp.agent getattr(driver, action)(**action_kwargs) 2015-02-14 01:01:08.633 5436 TRACE neutron.agent.dhcp.agent File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 207, in enable 2015-02-14 01:01:08.633 5436 TRACE neutron.agent.dhcp.agent interface_name = self.device_manager.setup(self.network) 2015-02-14 01:01:08.633 5436 TRACE neutron.agent.dhcp.agent File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 934, in setup 2015-02-14 01:01:08.633 5436 TRACE neutron.agent.dhcp.agent port = self.setup_dhcp_port(network) 2015-02-14 01:01:08.633 5436 TRACE neutron.agent.dhcp.agent File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 924, in setup_dhcp_port 2015-02-14 01:01:08.633 5436 TRACE neutron.agent.dhcp.agent for fixed_ip in dhcp_port.fixed_ips] 2015-02-14 01:01:08.633 5436 TRACE neutron.agent.dhcp.agent KeyError: u'37f0b628-22e6-4446-8bb9-2c2176c5a646' 2015-02-14 01:01:08.633 5436 TRACE neutron.agent.dhcp.agent 2015-02-14 01:01:08.634 5436 INFO neutron.agent.dhcp.agent [-] Synchronizing state complete 2015-02-14 01:01:08.635 5436 DEBUG oslo_concurrency.lockutils [-] Lock "dhcp-agent" released by "sync_state" :: held 0.078s inner /usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:442 ・All DHCP agents looks fine :-) ・Restart changes nothing. :-( To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1417379/+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 1404268] Re: Missing nova context during spawn
** Changed in: nova/kilo Status: Fix Committed => 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/1404268 Title: Missing nova context during spawn Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: The nova request context tracks a security context and other request information, including a request id that is added to log entries associated with this request. The request context is passed around explicitly in many chunks of OpenStack code. But nova/context.py also stores the RequestContext in the thread's local store (when the RequestContext is created, or when it is explicitly stored through a call to update_store). The nova logger will use an explicitly passed context, or look for it in the local.store. A recent change in community openstack code has resulted in the context not being set for many nova log messages during spawn: https://bugs.launchpad.net/neutron/+bug/1372049 This change spawns a new thread in nova/compute/manager.py build_and_run_instance, and the spawn runs in that new thread. When the original RPC thread created the nova RequestContext, the context was set in the thread's local store. But the context does not get set in the newly-spawned thread. Example of log messages with missing req id during spawn: 014-12-13 22:20:30.987 18219 DEBUG nova.openstack.common.lockutils [-] Acquired semaphore "87c7fc32-042e-40b7-af46-44bff50fa1b4" lock /usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py:229 2014-12-13 22:20:30.987 18219 DEBUG nova.openstack.common.lockutils [-] Got semaphore / lock "_locked_do_build_and_run_instance" inner /usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py:271 2014-12-13 22:20:31.012 18219 AUDIT nova.compute.manager [req-bd959d69-86de-4eea-ae1d-a066843ca317 None] [instance: 87c7fc32-042e-40b7-af46-44bff50fa1b4] Starting instance... ... 2014-12-13 22:20:31.280 18219 DEBUG nova.openstack.common.lockutils [-] Created new semaphore "compute_resources" internal_lock /usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py:206 2014-12-13 22:20:31.281 18219 DEBUG nova.openstack.common.lockutils [-] Acquired semaphore "compute_resources" lock /usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py:229 2014-12-13 22:20:31.282 18219 DEBUG nova.openstack.common.lockutils [-] Got semaphore / lock "instance_claim" inner /usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py:271 2014-12-13 22:20:31.284 18219 DEBUG nova.compute.resource_tracker [-] Memory overhead for 512 MB instance; 0 MB instance_claim /usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py:1272014-12-13 22:20:31.290 18219 AUDIT nova.compute.claims [-] [instance: 87c7fc32-042e-40b7-af46-44bff50fa1b4] Attempting claim: memory 512 MB, disk 10 GB2014-12-13 22:20:31.292 18219 AUDIT nova.compute.claims [-] [instance: 87c7fc32-042e-40b7-af46-44bff50fa1b4] Total memory: 131072 MB, used: 12288.00 MB2014-12-13 22:20:31.296 18219 AUDIT nova.compute.claims [-] [instance: 87c7fc32-042e-40b7-af46-44bff50fa1b4] memory limit not specified, defaulting to unlimited2014-12-13 22:20:31.300 18219 AUDIT nova.compute.claims [-] [instance: 87c7fc32-042e-40b7-af46-44bff50fa1b4] Total disk: 2097152 GB, used: 60.00 GB2014-12-13 22:20:31.304 18219 AUDIT nova.compute.claims [-] [instance: 87c7fc32-042e-40b7-af46-44bff50fa1b4] disk limit not specified, defaulting to unlimited ... 2014-12-13 22:20:32.850 18219 DEBUG nova.network.neutronv2.api [-] [instance: 87c7fc32-042e-40b7-af46-44bff50fa1b4] get_instance_nw_info() _get_instance_nw_info /usr/lib/python2.6/site- packages/nova/network/neutronv2/api.py:611 Proposed patch: one new line of code at the beginning of nova/compute/manager.py _do_build_and_run_instance: context.update_store() To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1404268/+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 1300265] Re: some tests call assert_called_once() into a mock, this function doesn't exists, and gets auto-mocked, falsely passing tests
** Changed in: sahara/kilo Status: Fix Committed => 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/1300265 Title: some tests call assert_called_once() into a mock, this function doesn't exists, and gets auto-mocked, falsely passing tests Status in neutron: Fix Released Status in Sahara: Fix Released Status in Sahara kilo series: Fix Released Bug description: neutron/tests/unit/agent/linux/test_async_process.py: spawn.assert_called_once() neutron/tests/unit/agent/linux/test_async_process.py: func.assert_called_once() neutron/tests/unit/agent/linux/test_async_process.py: mock_start.assert_called_once() neutron/tests/unit/agent/linux/test_async_process.py: mock_kill_event.send.assert_called_once() neutron/tests/unit/agent/linux/test_async_process.py: mock_kill_process.assert_called_once(pid) neutron/tests/unit/test_dhcp_agent.py: log.error.assert_called_once() neutron/tests/unit/test_dhcp_agent.py: device.route.get_gateway.assert_called_once() neutron/tests/unit/test_dhcp_agent.py: device.route.get_gateway.assert_called_once() neutron/tests/unit/test_dhcp_agent.py: device.route.get_gateway.assert_called_once() neutron/tests/unit/test_dhcp_agent.py: device.route.get_gateway.assert_called_once() neutron/tests/unit/test_dhcp_agent.py: device.route.get_gateway.assert_called_once() neutron/tests/unit/test_dhcp_agent.py: device.route.get_gateway.assert_called_once() neutron/tests/unit/test_dhcp_agent.py: device.route.get_gateway.assert_called_once() neutron/tests/unit/test_post_mortem_debug.py: mock_post_mortem.assert_called_once() neutron/tests/unit/test_linux_interface.py: log.assert_called_once() neutron/tests/unit/test_l3_agent.py:self.send_arp.assert_called_once() neutron/tests/unit/test_l3_agent.py:self.send_arp.assert_called_once() neutron/tests/unit/test_l3_agent.py:self.send_arp.assert_called_once() neutron/tests/unit/test_l3_agent.py:self.send_arp.assert_called_once() neutron/tests/unit/test_l3_agent.py:self.send_arp.assert_called_once() neutron/tests/unit/cisco/test_nexus_plugin.py: mock_db.assert_called_once() neutron/tests/unit/linuxbridge/test_lb_neutron_agent.py: exec_fn.assert_called_once() neutron/tests/unit/services/firewall/agents/l3reference/test_firewall_l3_agent.py: mock_driver_update_firewall.assert_called_once( neutron/tests/unit/services/firewall/agents/l3reference/test_firewall_l3_agent.py: mock_driver_delete_firewall.assert_called_once( To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1300265/+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 1353939] Re: Rescue fails with 'Failed to terminate process: Device or resource busy' in the n-cpu log
** Changed in: nova/kilo Status: Fix Committed => 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/1353939 Title: Rescue fails with 'Failed to terminate process: Device or resource busy' in the n-cpu log Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Status in nova package in Ubuntu: New Bug description: [Impact] * Users may sometimes fail to shutdown an instance if the associated qemu process is on uninterruptable sleep (typically IO). [Test Case] * 1. create some IO load in a VM 2. look at the associated qemu, make sure it has STAT D in ps output 3. shutdown the instance 4. with the patch in place, nova will retry calling libvirt to shutdown the instance 3 times to wait for the signal to be delivered to the qemu process. [Regression Potential] * None message: "Failed to terminate process" AND message:'InstanceNotRescuable' AND message: 'Exception during message handling' AND tags:"screen-n-cpu.txt" The above log stash-query reports back only the failed jobs, the 'Failed to terminate process' close other failed rescue tests, but tempest does not always reports them as an error at the end. message: "Failed to terminate process" AND tags:"screen-n-cpu.txt" Usual console log: Details: (ServerRescueTestJSON:test_rescue_unrescue_instance) Server 0573094d-53da-40a5-948a-747d181462f5 failed to reach RESCUE status and task state "None" within the required time (196 s). Current status: SHUTOFF. Current task state: None. http://logs.openstack.org/82/107982/2/gate/gate-tempest-dsvm-postgres- full/90726cb/console.html#_2014-08-07_03_50_26_520 Usual n-cpu exception: http://logs.openstack.org/82/107982/2/gate/gate-tempest-dsvm-postgres-full/90726cb/logs/screen-n-cpu.txt.gz#_2014-08-07_03_32_02_855 2014-08-07 03:32:02.855 ERROR oslo.messaging.rpc.dispatcher [req-39ce7a3d-5ceb-41f5-8f9f-face7e608bd1 ServerRescueTestJSON-2035684545 ServerRescueTestJSON-1017508309] Exception during message handling: Instance 0573094d-53da-40a5-948a-747d181462f5 cannot be rescued: Driver Error: Failed to terminate process 26425 with SIGKILL: Device or resource busy 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher Traceback (most recent call last): 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 134, in _dispatch_and_reply 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher incoming.message)) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 177, in _dispatch 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return self._do_dispatch(endpoint, method, ctxt, args) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 123, in _do_dispatch 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher result = getattr(endpoint, method)(ctxt, **new_args) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/opt/stack/new/nova/nova/compute/manager.py", line 408, in decorated_function 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/opt/stack/new/nova/nova/exception.py", line 88, in wrapped 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher payload) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/opt/stack/new/nova/nova/openstack/common/excutils.py", line 82, in __exit__ 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/opt/stack/new/nova/nova/exception.py", line 71, in wrapped 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return f(self, context, *args, **kw) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/opt/stack/new/nova/nova/compute/manager.py", line 292, in decorated_function 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher pass 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/opt/stack/new/nova/nova/openstack/common/excutils.py", line 82, in __exit__ 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/opt/stack/new/nova/nova/comp
[Yahoo-eng-team] [Bug 1426324] Re: VFS blkid calls need to handle 0 or 2 return codes
** Changed in: nova/kilo Status: Fix Committed => 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/1426324 Title: VFS blkid calls need to handle 0 or 2 return codes Status in ubuntu-cloud-archive: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Status in nova package in Ubuntu: Fix Released Bug description: kilo-2 introduce blkid calls for fs detection on all new instances; if the specified key is not found on the block device, blkid will return 2 instead of 0 - nova needs to deal with this: 2015-02-27 10:48:51.270 3062 INFO nova.virt.disk.vfs.api [-] Unable to import guestfs, falling back to VFSLocalFS 2015-02-27 10:48:51.476 3062 ERROR nova.compute.manager [-] [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] Instance failed to spawn 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] Traceback (most recent call last): 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2328, in _build_resources 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] yield resources 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2198, in _build_and_run_instance 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] flavor=flavor) 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 2329, in spawn 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] admin_pass=admin_password) 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 2728, in _create_image 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] project_id=instance['project_id']) 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/imagebackend.py", line 230, in cache 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] *args, **kwargs) 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/imagebackend.py", line 507, in create_image 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] copy_qcow2_image(base, self.path, size) 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] File "/usr/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 431, in inner 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] return f(*args, **kwargs) 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/imagebackend.py", line 473, in copy_qcow2_image 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] disk.extend(target, size, use_cow=True) 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] File "/usr/lib/python2.7/dist-packages/nova/virt/disk/api.py", line 183, in extend 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] if not is_image_extendable(image, use_cow): 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] File "/usr/lib/python2.7/dist-packages/nova/virt/disk/api.py", line 235, in is_image_extendable 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] if fs.get_image_fs() in SUPPORTED_FS_TO_EXTEND: 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] File "/usr/lib/python2.7/dist-packages/nova/virt/disk/vfs/localfs.py", line 167, in get_image_fs 2015-02-27 10:48:51.476 3062 TRACE nova.compute.manager [instance: 1aa12a52-c91b-49b4-9636-63c39f7ba72b] run_as_root=True) 2015-02-27 10:48:51
[Yahoo-eng-team] [Bug 1427056] Re: shelved_image_id is deleted before completing unshelving instance on compute node
** Changed in: nova/kilo Status: Fix Committed => 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/1427056 Title: shelved_image_id is deleted before completing unshelving instance on compute node Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: Steps to reproduce: 1. Boot an instance from image. 2. Call Shelve instance, instance becomes SHELVED_OFFLOADED or SHELVED state depending on 'shelved_offload_time' configured in nova.conf. 3. Call unshelve instance. For shelved_offload_time >= 0: 3.1 nova-conductor calls RPC.Cast to nova-compute If some failure happens in nova-compute. e.g. "Instance failed to spawn" error from libvirt 3.2 nova-conductor deletes instance_system_metadata.shelved_image_id after RPC.cast for unshelving the instance. 3.3 Instance becomes SHELVED_OFFLOADED again by revert_task_state, but instance_system_metadata.shelved_image_id is already deleted for this instance For shelved_offload_time = -1: 3.1 nova-conductor calls RPC.Cast to nova-compute If some failure happens in nova-compute. e.g. "InstanceNotFound" error while starting the instance. 3.2 nova-conductor deletes snapshot and instance_system_metadata.shelved_image_id after RPC.cast to start the instance. 3.3 Instance becomes SHELVED again by revert_task_state, but snapshot and instance_system_metadata.shelved_image_id is already deleted for this instance Problems: 1. As there is no shelved_image_id, during unshelving the instance again, it gives error while getting image-meta in libvirt driver and instance remains in SHELVED_OFFLOADED state. 2. As there is no shelved_image_id, deleting the instance will try to delete "image_id=None" image from glance, but 404 error will be returned from glance, instance will be successfully deleted, and shelved image remains. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1427056/+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 1430042] Re: Virtual Machine could not be evacuated because virtual interface creation failed
** Changed in: nova/kilo Status: Fix Committed => 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/1430042 Title: Virtual Machine could not be evacuated because virtual interface creation failed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: I believe this issue is related to Question 257358 (https://answers.launchpad.net/ubuntu/+source/nova/+question/257358). On the source host we see the successful vif plug: 2015-03-09 01:22:12.363 629 DEBUG neutron.plugins.ml2.rpc [req-5de70341-d64b-4a3a-bc05-54eb2802f25d None] Device 14ac5edd-269f-4808-9a34-c4cc93e9ab70 up at agent ovs-agent-ipx update_device_up /usr/lib/python2.7/site-packages/neutron/plugins/ml2/rpc.py:156 2015-03-09 01:22:12.392 629 DEBUG oslo_concurrency.lockutils [req-5de70341-d64b-4a3a-bc05-54eb2802f25d ] Acquired semaphore "db-access" lock /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:377 2015-03-09 01:22:12.436 629 DEBUG oslo_concurrency.lockutils [req-5de70341-d64b-4a3a-bc05-54eb2802f25d ] Releasing semaphore "db-access" lock /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:390 2015-03-09 01:22:12.437 629 DEBUG oslo_messaging._drivers.amqp [req-5de70341-d64b-4a3a-bc05-54eb2802f25d ] UNIQUE_ID is 740634ca8c7a49418a39c429669f2f27. _add_unique_id /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqp.py:224 2015-03-09 01:22:12.439 629 DEBUG oslo_messaging._drivers.amqp [req-5de70341-d64b-4a3a-bc05-54eb2802f25d ] UNIQUE_ID is 3264e8d7dd7c492d9aa17d3e9892b1fc. _add_unique_id /usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqp.py:224 2015-03-09 01:22:14.436 629 DEBUG neutron.notifiers.nova [-] Sending events: [{'status': 'completed', 'tag': u'14ac5edd-269f-4808-9a34-c4cc93e9ab70', 'name': 'network-vif-plugged', 'server_uuid': u'2790be4a-5285-46aa-8ee2-c68f5b936c1d'}] send_events /usr/lib/python2.7/site-packages/neutron/notifiers/nova.py:237 Later, the destination host of the evacuation attempts to plug the vif but can't: 2015-03-09 02:15:41.441 629 DEBUG neutron.plugins.ml2.rpc [req-5ea6625c-a60c-48fb-9264-e2a5a3ed0d26 None] Device 14ac5edd-269f-4808-9a34-c4cc93e9ab70 up at agent ovs-agent-ipxx update_device_up /usr/lib/python2.7/site-packages/neutron/plugins/ml2/rpc.py:156 2015-03-09 02:15:41.485 629 DEBUG neutron.plugins.ml2.rpc [req-5ea6625c-a60c-48fb-9264-e2a5a3ed0d26 None] Device 14ac5edd-269f-4808-9a34-c4cc93e9ab70 not bound to the agent host ipx update_device_up /usr/lib/python2.7/site-packages/neutron/plugins/ml2/rpc.py:163 The cause of the problem seems to be that the neutron port does not have is binding:host_id properly updated on evacuation, the answer to question 257358 looks like the fix. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1430042/+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 1437855] Re: Floating IPs should be associated with the first fixed IPv4 address
** Changed in: nova/kilo Status: Fix Committed => 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/1437855 Title: Floating IPs should be associated with the first fixed IPv4 address Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: If a port attached to an instance has multiple fixed IPs and a floating IP is associated without specifying a fixed ip to associate, the behavior in Neutron is to reject the associate request. The behavior in Nova in the absence of a specified fixed ip, however, is to pick the first one from the list of fixed ips on the port. This is a problem if an IPv6 address is the first on the port because the floating IP will be NAT'ed to the IPv6 fixed address, which is not supported. Any attempts to reach the instance through its floating address will fail. This causes failures in certain scenario tests that use the Nova floating IP API when dual-stack IPv4+IPv6 is enabled, such as test_baremetal_basic_ops in check-tempest-dsvm-ironic-pxe_ssh in https://review.openstack.org/#/c/168063 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1437855/+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 1434429] Re: libvirt: _compare_cpu doesn't consider NotSupportedError
** Changed in: nova/kilo Status: Fix Committed => 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/1434429 Title: libvirt: _compare_cpu doesn't consider NotSupportedError Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: Issue = The libvirt driver method "_compare_cpu" doesn't consider that the underlying libvirt function could throw a NotSupportedError (like baselineCPU call in "host.py" module [1]) Steps to reproduce == * Create setup with at least 2 compute nodes * Create cinder volume with bootable image * Launch instance from that volume * Start live migration of instance to another host Expected behavior = If the target host has the same CPU architecture like the source host, the live migration should be triggered. Actual behavior === The live migration gets aborted and rolled back because all libvirt errors gets treated equally. Logs & Env. === section "libvirt" in "/etc/nova/nova.conf" in both nodes: [libvirt] live_migration_flag = VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE, VIR_MIGRATE_TUNNELLED disk_cachemodes = block=none vif_driver = nova.virt.libvirt.vif.LibvirtGenericVIFDriver inject_partition = -2 live_migration_uri = qemu+tcp://stack@%s/system use_usb_tablet = False cpu_mode = none virt_type = kvm Nova version /opt/stack/nova$ git log --oneline -n5 90ee915 Merge "Add api microvesion unit test case for wsgi.action" 7885b74 Merge "Remove db layer hard-code permission checks for flavor-manager" 416f310 Merge "Remove db layer hard-code permission checks for migrations_get*" ecb306b Merge "Remove db layer hard-code permission checks for migration_create/update" 6efc8ad Merge "libvirt: don't allow to resize down the default ephemeral disk" References == [1] baselineCPU call to libvirt catches NotSupportedError; https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L753 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1434429/+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 1440834] Re: Unit test tree does not match the structure of the code tree
** Changed in: neutron/kilo Status: Fix Committed => 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/1440834 Title: Unit test tree does not match the structure of the code tree Status in networking-brocade: Fix Released Status in networking-cisco: Fix Committed Status in neutron: Fix Released Status in neutron kilo series: Fix Released Bug description: The structure of the unit test tree does not currently correspond to the structure of the code under test. This makes it difficult for a developer to find the unit tests for a given module and complicates non-mechanical evaluation of coverage. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-brocade/+bug/1440834/+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 1443765] Re: Delete endpoint_group should remove project_endpoint_group at first
** Changed in: keystone/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1443765 Title: Delete endpoint_group should remove project_endpoint_group at first Status in Keystone: Fix Released Status in Keystone kilo series: Fix Released Bug description: Since the endpoint_group_id of table project_endpoint_group has a foreign key reference with the id of endpoint_group, so if we want to delete endpoint_group we need delete associated project_endpoint_group at first, or else, it will hit follow exceptions: {"error": {"message": "An unexpected error prevented the server from fulfilling your request: (IntegrityError) (1451, 'Cannot delete or update a parent row: a foreign key constraint fails (`keystone`.`project_endpoint_group`, CONSTRAINT `project_endpoint_group_ibfk_1` FOREIGN KEY (`endpoint_group_id`) REFERENCES `endpoint_group` (`id`))') 'DELETE FROM endpoint_group WHERE endpoint_group.id = %s' ('d5c86622fea04c43b0c0e3b540417e1f',) (Disable debug mode to suppress these details.)", "code": 500, "title": "Internal Server Error"}} To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1443765/+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 1443970] Re: nova-manage create networks with wrong dhcp_server in DB(nova)
** Changed in: nova/kilo Status: Fix Committed => 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/1443970 Title: nova-manage create networks with wrong dhcp_server in DB(nova) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: Using nova network and creating new network 'dhcp_server' values are wrong. command (example) /usr/bin/nova-manage network create novanetwork 10.0.0.0/16 3 8 --vlan_start 103 --dns1 8.8.8.8 --dns2 8.8.4.4 This happens because in file nova/network/manager.py in method _do_create_networks() the variable 'enable_dhcp' is incorrectly used in loop. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1443970/+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 1443186] Re: rebooted instances are shutdown by libvirt lifecycle event handling
** Changed in: nova/kilo Status: Fix Committed => 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/1443186 Title: rebooted instances are shutdown by libvirt lifecycle event handling Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: This is a continuation of bug 1293480 (which created bug 1433049). Those were reported against xen domains with the libvirt driver but we have a recreate with CONF.libvirt.virt_type=kvm, see the attached logs and reference the instance with uuid 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78. In this case, we're running a stress test of soft rebooting 30 active instances at once. Because of a delay in the libvirt lifecycle event handling, they are all shutdown after the reboot operation is complete and the instances go from ACTIVE to SHUTDOWN. This was reported to me against Icehouse code but the recreate is against Juno code with patch: https://review.openstack.org/#/c/169782/ For better logging. Snippets from the log: 2015-04-10 21:02:38.234 11195 AUDIT nova.compute.manager [req- b24d4f8d-4a10-44c8-81d7-f79f27e3a3e7 None] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] Rebooting instance 2015-04-10 21:03:47.703 11195 DEBUG nova.compute.manager [req- 8219e6cf-dce8-44e7-a5c1-bf1879e155b2 None] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] Received event network-vif- unplugged-0b2c7633-a5bc-4150-86b2-c8ba58ffa785 external_instance_event /usr/lib/python2.6/site-packages/nova/compute/manager.py:6285 2015-04-10 21:03:49.299 11195 INFO nova.virt.libvirt.driver [req- b24d4f8d-4a10-44c8-81d7-f79f27e3a3e7 None] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] Instance shutdown successfully. 2015-04-10 21:03:53.251 11195 DEBUG nova.compute.manager [req- 521a6bdb-172f-4c0c-9bef-855087d7dff0 None] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] Received event network-vif- plugged-0b2c7633-a5bc-4150-86b2-c8ba58ffa785 external_instance_event /usr/lib/python2.6/site-packages/nova/compute/manager.py:6285 2015-04-10 21:03:53.259 11195 INFO nova.virt.libvirt.driver [-] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] Instance running successfully. 2015-04-10 21:03:53.261 11195 INFO nova.virt.libvirt.driver [req- b24d4f8d-4a10-44c8-81d7-f79f27e3a3e7 None] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] Instance soft rebooted successfully. ** At this point we have successfully soft rebooted the instance ** now we get a lifecycle event from libvirt that the instance is stopped, since we're no longer running a task we assume the hypervisor is correct and we call the stop API 2015-04-10 21:04:01.133 11195 DEBUG nova.virt.driver [-] Emitting event Stopped> emit_event /usr/lib/python2.6/site-packages/nova/virt/driver.py:1298 2015-04-10 21:04:01.134 11195 INFO nova.compute.manager [-] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] VM Stopped (Lifecycle Event) 2015-04-10 21:04:01.245 11195 INFO nova.compute.manager [-] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] Synchronizing instance power state after lifecycle event "Stopped"; current vm_state: active, current task_state: None, current DB power_state: 1, VM power_state: 4 2015-04-10 21:04:01.334 11195 INFO nova.compute.manager [-] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from the hypervisor (4). Updating power_state in the DB to match the hypervisor. 2015-04-10 21:04:01.463 11195 WARNING nova.compute.manager [-] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] Instance shutdown by itself. Calling the stop API. Current vm_state: active, current task_state: None, original DB power_state: 1, current VM power_state: 4 ** now we get a lifecycle event from libvirt that the instance is started, but since the instance already has a task_state of 'powering-off' because of the previous stop API call from _sync_instance_power_state, we ignore it. ** 2015-04-10 21:04:02.085 11195 DEBUG nova.virt.driver [-] Emitting event Started> emit_event /usr/lib/python2.6/site-packages/nova/virt/driver.py:1298 2015-04-10 21:04:02.086 11195 INFO nova.compute.manager [-] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] VM Started (Lifecycle Event) 2015-04-10 21:04:02.190 11195 INFO nova.compute.manager [-] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] Synchronizing instance power state after lifecycle event "Started"; current vm_state: active, current task_state: powering-off, current DB power_state: 4, VM power_state: 1 2015-04-10 21:04:02.414 11195 INFO nova.compute.manager [-] [instance: 9ad8f6c5-a5dc-4820-9ea5-fa081e74ec78] During sync_power_state the instance has a pending task (powering-off).
[Yahoo-eng-team] [Bug 1442343] Re: Mapping openstack_project attribute in k2k assertions with different domains
** Changed in: keystone/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1442343 Title: Mapping openstack_project attribute in k2k assertions with different domains Status in Keystone: Fix Released Status in Keystone kilo series: Fix Released Bug description: We can have two projects with the same name in different domains. So if we have a "Project A" in "Domain X" and a "Project A" in "Domain Y", there is no way to differ what "Project A" is being used in a SAML assertion generated by this IdP (we have only the openstack_project attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442343/+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 1441400] Re: Move N1kv section from neutron tree's ml2_conf_cisco.ini to stackforge repo
** Changed in: neutron/kilo Status: Fix Committed => 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/1441400 Title: Move N1kv section from neutron tree's ml2_conf_cisco.ini to stackforge repo Status in networking-cisco: Fix Committed Status in neutron: Fix Released Status in neutron kilo series: Fix Released Bug description: The change includes moving the N1kv section from the neutron tree's ml2_conf_cisco.ini file to the stackforge/networking-cisco project. The change will also include addition of a new parameter -- 'sync_interval' to the N1kv section, after the section is moved to the stackforge repo. sync_interval: configurable parameter for Neutron - VSM (controller) sync duration. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-cisco/+bug/1441400/+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 1438638] Re: Hyper-V: Compute Driver doesn't start if there are instances with no VM Notes
** Changed in: nova/kilo Status: Fix Committed => 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/1438638 Title: Hyper-V: Compute Driver doesn't start if there are instances with no VM Notes Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: The Nova Hyper-V Compute Driver cannot start if there are instances with Notes = None. This can be caused by the users, by manually altering the VM Notes or if there are VMs created by the users. Logs: http://paste.openstack.org/show/197681/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1438638/+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 1443480] Re: Some of the neutron functional tests are failing with import error after unit test tree reorganization
** Changed in: neutron/kilo Status: Fix Committed => 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/1443480 Title: Some of the neutron functional tests are failing with import error after unit test tree reorganization Status in neutron: Fix Released Status in neutron kilo series: Fix Released Bug description: Some of the neutron functional tests are failing with import error after unit test tree reorganization Traceback (most recent call last): ImportError: Failed to import test module: neutron.tests.functional.scheduler.test_dhcp_agent_scheduler Traceback (most recent call last): File "/usr/lib64/python2.7/unittest/loader.py", line 254, in _find_tests module = self._get_module_from_name(name) File "/usr/lib64/python2.7/unittest/loader.py", line 232, in _get_module_from_name __import__(name) File "neutron/tests/functional/scheduler/test_dhcp_agent_scheduler.py", line 24, in from neutron.tests.unit import test_dhcp_scheduler as test_dhcp_sch ImportError: cannot import name test_dhcp_scheduler To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1443480/+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 1446583] Re: services no longer reliably stop in stable/kilo
** Changed in: nova/kilo Status: Fix Committed => 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/1446583 Title: services no longer reliably stop in stable/kilo Status in Cinder: Fix Released Status in Cinder kilo series: Fix Released Status in Keystone: Fix Released Status in Keystone kilo series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Status in oslo-incubator: Fix Released Bug description: In attempting to upgrade the upgrade branch structure to support stable/kilo -> master in devstack gate, we found the project could no longer pass Grenade testing. The reason is because pkill -g is no longer reliably killing off the services: http://logs.openstack.org/91/175391/5/gate/gate-grenade- dsvm/0ad4a94/logs/grenade.sh.txt.gz#_2015-04-21_03_15_31_436 It has been seen with keystone-all and cinder-api on this patch series: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiVGhlIGZvbGxvd2luZyBzZXJ2aWNlcyBhcmUgc3RpbGwgcnVubmluZ1wiIEFORCBtZXNzYWdlOlwiZGllXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0Mjk2MTU0NTQ2MzB9 There were a number of changes to the oslo-incubator service.py code during kilo, it's unclear at this point which is the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1446583/+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 1446082] Re: Instance without "extra" data crashes nova-compute
** Changed in: nova/kilo Status: Fix Committed => 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/1446082 Title: Instance without "extra" data crashes nova-compute Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: I'm upgrading from Icehouse to Kilo. I have a single instance that was created in Icehouse. After the upgrade, nova-compute crashes because it's looking for instance "extra" data that is not there. To fix this, we need to check if there is any "extra" data for the instance before trying to read properties such as "numa_topology". # dpkg -l | grep nova ii nova-common 1:2015.1~rc1-0ubuntu1~cloud0 all OpenStack Compute - common files ii nova-compute1:2015.1~rc1-0ubuntu1~cloud0 all OpenStack Compute - compute node base ii nova-compute-kvm1:2015.1~rc1-0ubuntu1~cloud0 all OpenStack Compute - compute node (KVM) ii nova-compute-libvirt1:2015.1~rc1-0ubuntu1~cloud0 all OpenStack Compute - compute node libvirt support ii python-nova 1:2015.1~rc1-0ubuntu1~cloud0 all OpenStack Compute Python libraries ii python-novaclient 1:2.22.0-0ubuntu1~cloud0 all client library for OpenStack Compute API nova-compute.log: 2015-04-20 17:35:09.214 15508 DEBUG oslo_concurrency.lockutils [req-43d3110a-cac7-425e-842c-f725bda91c10 - - - - -] Lock "compute_resources" acquired by "_update_available_resource" :: waited 0.000s inner /usr/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:444 2015-04-20 17:35:09.299 15508 DEBUG oslo_concurrency.lockutils [req-43d3110a-cac7-425e-842c-f725bda91c10 - - - - -] Lock "compute_resources" released by "_update_available_resource" :: held 0.085s inner /usr/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:456 Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 457, in fire_timers timer() File "/usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py", line 58, in __call__ cb(*args, **kw) File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 214, in main result = function(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/nova/openstack/common/service.py", line 497, in run_service service.start() File "/usr/lib/python2.7/dist-packages/nova/service.py", line 183, in start self.manager.pre_start_hook() File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1287, in pre_start_hook self.update_available_resource(nova.context.get_admin_context()) File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 6236, in update_available_resource rt.update_available_resource(context) File "/usr/lib/python2.7/dist-packages/nova/compute/resource_tracker.py", line 402, in update_available_resource self._update_available_resource(context, resources) File "/usr/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 445, in inner return f(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/nova/compute/resource_tracker.py", line 436, in _update_available_resource 'numa_topology']) File "/usr/lib/python2.7/dist-packages/nova/objects/base.py", line 163, in wrapper result = fn(cls, context, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/nova/objects/instance.py", line 1152, in get_by_host_and_node expected_attrs) File "/usr/lib/python2.7/dist-packages/nova/objects/instance.py", line 1068, in _make_instance_list expected_attrs=expected_attrs) File "/usr/lib/python2.7/dist-packages/nova/objects/instance.py", line 501, in _from_db_object db_inst.get('extra').get('numa_topology')) AttributeError: 'NoneType' object has no attribute 'get' 2015-04-20 17:35:09.301 15508 ERROR nova.openstack.common.threadgroup [req-12483464-12a6-4b74-a671-bc6bb943b265 - - - - -] 'NoneType' object has no attribute 'get' 2015-04-20 17:35:09.301 15508 TRACE nova.openstack.common.threadgroup Traceback (most recent call last): 2015-04-20 17:35:09.301 15508 TRACE nova.openstack.common.threadgroup File "/usr/lib/python2.7/dist-packages/nova/openstack/common/threadgroup.py", line 145, in wait 2015-04-20 17:35:09.301 15508 TRACE nova.openstack.common.threadgroup x.wait() 2015-04-20 17:35:09.301 15508 TRACE nova.openstack.common.threadgroup File "/usr/lib/python2.7/dist-packages/nova/openstack/common/threadgroup.py", line 47, in wait 2015-04-20 17:35:09.301 15508 TRACE nova.openstack.common.threadgroup return self.thread.w
[Yahoo-eng-team] [Bug 1444497] Re: Instance doesn't get an address via DHCP (nova-network) because of issue with live migration
** Changed in: nova/kilo Status: Fix Committed => 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/197 Title: Instance doesn't get an address via DHCP (nova-network) because of issue with live migration Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: When instance is migrated to another compute node, it's dhcp lease is not removed from the first compute node even after instance termination. If a new instance got the same IP which was present in the previous instance created on the the first compute node where dhcp lease for this IP remains, then the dnsmasq refuse DHCP request of the IP address for a new instance with different MAC. Steps to reproduce: Scenario: 1. Create cluster (CentOS, nova-network with Flat-DHCP , Ceph for images and volumes) 2. Add 1 node with controller and ceph OSD roles 3. Add 2 node with compute and ceph OSD roles 4. Deploy the cluster 5. Create a VM 6. Wait until the VM got IP address via DHCP (in VM console log) 7. Migrate the VM to another compute node. 8. Terminate the VM. 9. Repeat stages from 5 to 8 several times (in my case - 4..6 times was enough) until a new instance stops receiving IP address via DHCP. 10. Check dnsmasq-dhcp.log (/var/log/daemon.log on the compute node) for messages like : = 2014-11-09T20:28:29.671344+00:00 warning: not using configured address 10.0.0.2 because it is leased to fa:16:3e:65:70:be This means that: I. An instance was created on the compute node-1 and got a dhcp lease: nova-dhcpbridge.log 2014-11-09 20:12:03.811 27360 DEBUG nova.dhcpbridge [-] Called 'add' for mac 'fa:16:3e:65:70:be' with ip '10.0.0.2' main /usr/lib/python2.6/site-packages/nova/cmd/dhcpbridge.py:135 II. When the instance was migrating from compute node-1 to node-3, 'dhcp_release' was not performed on compute node-1, please check the time range in the logs : 2014-11-09 20:14:36-37 Running.log (node-1) 2014-11-09T20:14:36.647588+00:00 debug: cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf conntrack -D -r 10.0.0.2 ### But there is missing a command like: sudo nova-rootwrap /etc/nova/rootwrap.conf dhcp_release br100 10.0.0.2 fa:16:3e:65:70:be III. On the compute node-3, DHCP lease was added and it was successfully removed when the instance was terminated: Running.log (node-3) 2014-11-09T20:15:17.250243+00:00 debug: cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf dhcp_release br100 10.0.0.2 fa:16:3e:65:70:be IV. When an another instance got the same address '10.0.0.2' and was created on node-1, it didn't get IP address via DHCP: Running.log (node-1) 2014-11-09T20:28:29.671344+00:00 warning: not using configured address 10.0.0.2 because it is leased to fa:16:3e:65:70:be To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/197/+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 1451389] Re: Nova gate broke due to failed unit test
** Changed in: nova/kilo Status: Fix Committed => 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/1451389 Title: Nova gate broke due to failed unit test Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: [x] ft1.13172: nova.tests.unit.virt.vmwareapi.test_read_write_util.ReadWriteUtilTestCase.test_ipv6_host_read_StringException: Empty attachments: pythonlogging:'' stderr stdout Traceback (most recent call last): File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py", line 1201, in patched return func(*args, **keywargs) File "nova/tests/unit/virt/vmwareapi/test_read_write_util.py", line 49, in test_ipv6_host_read verify=False) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py", line 846, in assert_called_once_with return self.assert_called_with(*args, **kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py", line 835, in assert_called_with raise AssertionError(msg) AssertionError: Expected call: request('get', 'https://[fd8c:215d:178e:c51e:200:c9ff:fed1:584c]:7443/folder/tmp/fake.txt?dcPath=fake_dc&dsName=fake_ds', stream=True, headers={'User-Agent': 'OpenStack-ESX-Adapter'}, allow_redirects=True, verify=False) Actual call: request('get', 'https://[fd8c:215d:178e:c51e:200:c9ff:fed1:584c]:7443/folder/tmp/fake.txt?dcPath=fake_dc&dsName=fake_ds', stream=True, headers={'User-Agent': 'OpenStack-ESX-Adapter'}, allow_redirects=True, params=None, verify=False) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1451389/+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 1472458] Re: Arista ML2 VLAN driver should ignore non-VLAN network types
** Changed in: neutron/kilo Status: Fix Committed => 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/1472458 Title: Arista ML2 VLAN driver should ignore non-VLAN network types Status in neutron: Fix Released Status in neutron juno series: Fix Committed Status in neutron kilo series: Fix Released Bug description: Arista ML2 VLAN driver should process only VLAN based networks. Any other network type (e.g. vxlan) should be ignored. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1472458/+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 1446405] Re: Test discovery is broken for the api and functional paths
** Changed in: neutron/kilo Status: Fix Committed => 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/1446405 Title: Test discovery is broken for the api and functional paths Status in neutron: Fix Released Status in neutron kilo series: Fix Released Bug description: The following failures in test discovery were noted: https://review.openstack.org/#/c/169962/ https://bugs.launchpad.net/neutron/+bug/1443480 It was eventually determined that the use of the unittest discovery mechanism to perform manual discovery in package init for the api and functional subtrees was to blame. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1446405/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1448245] Re: VPNaaS UTs broken in neutron/tests/unit/extensions/test_l3.py
** Changed in: neutron/kilo Status: Fix Committed => 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/1448245 Title: VPNaaS UTs broken in neutron/tests/unit/extensions/test_l3.py Status in neutron: Fix Released Status in neutron kilo series: Fix Released Bug description: Recently, VPNaaS repo UTs are failing in tests that inherit from Neutron tests. The tests worked 4/22/2015 and are broken on 4/24/2015. Will try to bisect to find change in Neutron that affects tests. Example failure: 2015-04-24 06:40:39.838 | Captured pythonlogging: 2015-04-24 06:40:39.838 | ~~~ 2015-04-24 06:40:39.838 | 2015-04-24 06:40:38,704ERROR [neutron.api.extensions] Extension path 'neutron/tests/unit/extensions' doesn't exist! 2015-04-24 06:40:39.838 | 2015-04-24 06:40:39.838 | 2015-04-24 06:40:39.838 | Captured traceback: 2015-04-24 06:40:39.838 | ~~~ 2015-04-24 06:40:39.838 | Traceback (most recent call last): 2015-04-24 06:40:39.838 | File "neutron_vpnaas/tests/unit/db/vpn/test_vpn_db.py", line 886, in test_delete_router_interface_in_use_by_vpnservice 2015-04-24 06:40:39.839 | expected_code=webob.exc. 2015-04-24 06:40:39.839 | File "/home/jenkins/workspace/gate-neutron-vpnaas-python27/.tox/py27/src/neutron/neutron/tests/unit/extensions/test_l3.py", line 401, in _router_interface_action 2015-04-24 06:40:39.839 | self.assertEqual(res.status_int, expected_code, msg) 2015-04-24 06:40:39.839 | File "/home/jenkins/workspace/gate-neutron-vpnaas-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 350, in assertEqual 2015-04-24 06:40:39.839 | self.assertThat(observed, matcher, message) 2015-04-24 06:40:39.839 | File "/home/jenkins/workspace/gate-neutron-vpnaas-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 435, in assertThat 2015-04-24 06:40:39.839 | raise mismatch_error 2015-04-24 06:40:39.839 | testtools.matchers._impl.MismatchError: 200 != 409 2015-04-24 06:40:39.839 | 2015-04-24 06:40:39.839 | 2015-04-24 06:40:39.839 | Captured pythonlogging: 2015-04-24 06:40:39.839 | ~~~ 2015-04-24 06:40:39.840 | 2015-04-24 06:40:38,694 INFO [neutron.manager] Loading core plugin: neutron_vpnaas.tests.unit.db.vpn.test_vpn_db.TestVpnCorePlugin 2015-04-24 06:40:39.840 | 2015-04-24 06:40:38,694 INFO [neutron.manager] Service L3_ROUTER_NAT is supported by the core plugin 2015-04-24 06:40:39.840 | 2015-04-24 06:40:38,694 INFO [neutron.manager] Loading Plugin: neutron_vpnaas.services.vpn.plugin.VPNPlugin 2015-04-24 06:40:39.840 | 2015-04-24 06:40:38,704ERROR [neutron.api.extensions] Extension path 'neutron/tests/unit/extensions' doesn't exist! To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1448245/+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 1447884] Re: Boot from volume, block device allocate timeout cause VM error, but volume would be available later
** Changed in: nova/kilo Status: Fix Committed => 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/1447884 Title: Boot from volume, block device allocate timeout cause VM error, but volume would be available later Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: When we try to boot multi instances from volume (with a large image source) at the same time, we usually got a block device allocate error as the logs in nova-compute.log: 2015-03-30 23:22:46.920 6445 WARNING nova.compute.manager [-] Volume id: 551ea616-e1c4-4ef2-9bf3-b0ca6d4474dc finished being created but was not set as 'available' 2015-03-30 23:22:47.131 6445 ERROR nova.compute.manager [-] [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] Instance failed block device setup 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] Traceback (most recent call last): 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] File "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1829, in _prep_block_device 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] do_check_attach=do_check_attach) + 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] File "/usr/lib/python2.6/site-packages/nova/virt/block_device.py", line 407, in attach_block_devices 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] map(_log_and_attach, block_device_mapping) 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] File "/usr/lib/python2.6/site-packages/nova/virt/block_device.py", line 405, in _log_and_attach 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] bdm.attach(*attach_args, **attach_kwargs) 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] File "/usr/lib/python2.6/site-packages/nova/virt/block_device.py", line 339, in attach 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] do_check_attach=do_check_attach) 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] File "/usr/lib/python2.6/site-packages/nova/virt/block_device.py", line 46, in wrapped 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] ret_val = method(obj, context, *args, **kwargs) 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] File "/usr/lib/python2.6/site-packages/nova/virt/block_device.py", line 229, in attach 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] volume_api.check_attach(context, volume, instance=instance) 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] File "/usr/lib/python2.6/site-packages/nova/volume/cinder.py", line 305, in check_attach 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] raise exception.InvalidVolume(reason=msg) 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] InvalidVolume: Invalid volume: status must be 'available' 2015-03-30 23:22:47.131 6445 TRACE nova.compute.manager [instance: 483472b2-61b3-4574-95e2-8cd0304f90f6] This error cause the VM in "error" status: +--+++--+-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+++--+-+--+ | 1fa2d7aa-8bd9-4a22-8538-0a07d9dae8aa | inst02 | ERROR | block_device_mapping | NOSTATE | | +--+++--+-+--+ But the volume was in "available" status: ---+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +--+---+--+--+-+--+--+ | a9ab2dc2-b117-44ef-8678-f71067a9e770 | availab
[Yahoo-eng-team] [Bug 1451860] Re: Attached volume migration failed, due to incorrect arguments order passed to swap_volume
** Changed in: nova/kilo Status: Fix Committed => 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/1451860 Title: Attached volume migration failed, due to incorrect arguments order passed to swap_volume Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Status in openstack-ansible: Fix Released Bug description: Steps to reproduce: 1. create a volume in cinder 2. boot a server from image in nova 3. attach this volume to server 4. use ' cinder migrate --force-host-copy True 3fa956b6-ba59-46df-8a26-97fcbc18fc82 openstack-wangp11-02@pool_backend_1#Pool_1' log from nova compute:( see attched from detail info): 2015-05-05 00:33:31.768 ERROR root [req-b8424cde-e126-41b0-a27a-ef675e0c207f admin admin] Original exception being dropped: ['Traceback (most recent ca ll last):\n', ' File "/opt/stack/nova/nova/compute/manager.py", line 351, in decorated_function\nreturn function(self, context, *args, **kwargs)\n ', ' File "/opt/stack/nova/nova/compute/manager.py", line 4982, in swap_volume\ncontext, old_volume_id, instance_uuid=instance.uuid)\n', "Attribut eError: 'unicode' object has no attribute 'uuid'\n"] according to my debug result: # here parameters passed to swap_volume def swap_volume(self, ctxt, instance, old_volume_id, new_volume_id): return self.manager.swap_volume(ctxt, instance, old_volume_id, new_volume_id) # swap_volume function @wrap_exception() @reverts_task_state @wrap_instance_fault def swap_volume(self, context, old_volume_id, new_volume_id, instance): """Swap volume for an instance.""" context = context.elevated() bdm = objects.BlockDeviceMapping.get_by_volume_id( context, old_volume_id, instance_uuid=instance.uuid) connector = self.driver.get_volume_connector(instance) You can find: passed in order is "self, ctxt, instance, old_volume_id, new_volume_id" while function definition is "self, context, old_volume_id, new_volume_id, instance" this cause the 'unicode' object has no attribute 'uuid'\n" error when trying to access instance['uuid'] BTW: this problem was introduced in https://review.openstack.org/#/c/172152 affect both Kilo and master Thanks Peter To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1451860/+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
** Changed in: nova/kilo Status: Fix Committed => 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/1450594 Title: Instance deletion fails sometimes when serial_console is enabled Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Status in OpenStack Compute (nova) kilo series: Fix Released 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 add a test to see if isdefined is false and if it is, do not attempt to get the serial console for the nonexistent domain. To manage notifications about this bug go to: https://bugs.launchpad
[Yahoo-eng-team] [Bug 1453835] Re: Hyper-V: Nova cold resize / migration fails
** Changed in: nova/kilo Status: Fix Committed => 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/1453835 Title: Hyper-V: Nova cold resize / migration fails Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: Commit https://review.openstack.org/#/c/162999/ changed where the Hyper-V VM configuration files are stored. The files are being stored in the same folder as the instance. Performing a cold resize / migration will cause a os.rename call on the instance's folder, which fails as long as there are configuration files used by Hyper-V in that folder, thus resulting in a failed migration and the instance ending up in ERROR state. Logs: http://paste.openstack.org/show/219887/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1453835/+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 1466144] Re: dhcp fails if extra_dhcp_opts for stateless subnet enabled
** Changed in: neutron/kilo Status: Fix Committed => 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/1466144 Title: dhcp fails if extra_dhcp_opts for stateless subnet enabled Status in neutron: Fix Released Status in neutron kilo series: Fix Released Bug description: vm on a network having IPv4 and IPv6 dhcpv6 stateless subnets, fails to get IPv4 address, when vm uses a port with extra_dhcp_opts. neutron creates entries in dhcp host file for each subnet of a port. Each of these entries will have same mac address as first field, and may have client_id, fqdn, ipv4/ipv6 address for dhcp/dhcpv6 stateful, or tag as other fields. For dhcpv6 stateless subnet with extra_dhcp_opts, host file will have only mac address and tag. If the last entry in host file for the port with extra_dhcp_opts, is for dhcpv6 stateless subnet, then dhclient tries to use this entry, to resolve dhcp request even for IPv4, treats as 'no address found' and fails to send DHCPOFFER. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1466144/+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 1460673] Re: nova-manage flavor convert fails if instance has no flavor in sys_meta
** Changed in: nova/kilo Status: Fix Committed => 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/1460673 Title: nova-manage flavor convert fails if instance has no flavor in sys_meta Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: nova-manage fails if instance has no flavor in sys_meta when trying to move them all to instance_extra. But mostly the instance_type table includes the correct information, so it should be possible to copy it from there. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1460673/+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 1461777] Re: Random NUMA cell selection can leave NUMA cells unused
** Changed in: nova/kilo Status: Fix Committed => 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/1461777 Title: Random NUMA cell selection can leave NUMA cells unused Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: NUMA cell overcommit can leave NUMA cells unused When no NUMA configuration is defined for the guest (no flavor extra specs), nova identifies the NUMA topology of the host and tries to match the cpu placement to a NUMA cell ("cpuset"). The cpuset is selected randomly. pin_cpuset = random.choice(viable_cells_cpus) #nova/virt/libvirt/driver.py However, this can lead to NUMA cells not being used. This is particular noticeable when the flavor as the same number of vcpus as the host NUMA cells and in the host CPUs are not overcommit (cpu_allocation_ratio = 1) ### Particular use case: Compute nodes with the NUMA topology: No CPU overcommit: cpu_allocation_ratio = 1 Boot instances using a flavor with 8 vcpus. (No NUMA topology defined for the guest in the flavor) In this particular case the host can have 2 instances. (no cpu overcommit) Both instances can be allocated (random) with the same cpuset from the 2 options: 8 8 As consequence half of the host CPUs are not used. ### How to reproduce: Using: nova 2014.2.2 (not tested in trunk however the code path looks similar) 1. set cpu_allocation_ratio = 1 2. Identify the NUMA topology of the compute node 3. Using a flavor with a number of vcpus that matches a NUMA cell in the compute node, boot instances until fill the compute node. 4. Check the cpu placement "cpuset" used by the each instance. Notes: - at this point instances can use the same "cpuset" leaving NUMA cells unused. - the selection of the cpuset is random. Different tries may be needed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1461777/+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 1460176] Re: Reschedules sometimes do not allocate networks
** Changed in: nova/kilo Status: Fix Committed => 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/1460176 Title: Reschedules sometimes do not allocate networks Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: https://gist.github.com/jimrollenhagen/b6b45aa43878cdc89d89 Fixed by https://review.openstack.org/#/c/177470/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1460176/+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 1450624] Re: Nova waits for events from neutron on resize-revert that aren't coming
** Changed in: nova/kilo Status: Fix Committed => 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/1450624 Title: Nova waits for events from neutron on resize-revert that aren't coming Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: On resize-revert, the original host was waiting for plug events from neutron before restarting the instance. These aren't sent since we don't ever unplug the vifs. Thus, we'll always fail like this: 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher Traceback (most recent call last): 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py", line 134, in _dispatch_and_reply 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher incoming.message)) 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py", line 177, in _dispatch 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher return self._do_dispatch(endpoint, method, ctxt, args) 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py", line 123, in _do_dispatch 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher result = getattr(endpoint, method)(ctxt, **new_args) 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/nova/exception.py", line 88, in wrapped 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher payload) 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/nova/openstack/common/excutils.py", line 82, in __exit__ 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/nova/exception.py", line 71, in wrapped 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher return f(self, context, *args, **kw) 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/nova/compute/manager.py", line 298, in decorated_function 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher pass 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/nova/openstack/common/excutils.py", line 82, in __exit__ 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/nova/compute/manager.py", line 284, in decorated_function 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/nova/compute/manager.py", line 348, in decorated_function 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/nova/compute/manager.py", line 326, in decorated_function 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher kwargs['instance'], e, sys.exc_info()) 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/nova/openstack/common/excutils.py", line 82, in __exit__ 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-packages/nova/compute/manager.py", line 314, in decorated_function 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2015-04-30 19:45:42.602 23513 TRACE oslo.messaging.rpc.dispatcher File "/opt/bbc/openstack-10.0-bbc40/nova/local/lib/python2.7/site-p
[Yahoo-eng-team] [Bug 1456963] Re: VNC Console failed to load with IPv6 Addresses
** Changed in: nova/kilo Status: Fix Committed => 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/1456963 Title: VNC Console failed to load with IPv6 Addresses Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: Description of problem: After installation with packstack of openstack over IPv6 address(All components using IPv6) VNC console is unreachable Version-Release number of selected component (if applicable): Packstack version- packstack Kilo 2015.1.dev1537.gba5183c RHEL version - Red Hat Enterprise Linux Server release 7.1 (Maipo) openstack versions: 2015.1.0 novnc-0.5.1-2.el7.noarch openstack-nova-cert-2015.1.0-3.el7.noarch openstack-nova-compute-2015.1.0-3.el7.noarch openstack-nova-common-2015.1.0-3.el7.noarch python-nova-2015.1.0-3.el7.noarch openstack-nova-novncproxy-2015.1.0-3.el7.noarch openstack-nova-console-2015.1.0-3.el7.noarch openstack-nova-scheduler-2015.1.0-3.el7.noarch openstack-nova-conductor-2015.1.0-3.el7.noarch openstack-nova-api-2015.1.0-3.el7.noarch python-novaclient-2.23.0-1.el7.noarch How reproducible: Try to open noVNC console via the web browser with IPv6 address Steps to Reproduce: 1. Install openstack with IPv6 addresses for all components 2. Login to the horizon dashboard using IPv6 3. Launch an instance 4. try to activate console Actual results: Console failed to connect - error 1006 Expected results: Console should connect successfully Additional info: nova novnc log: 2015-05-12 10:25:33.961 15936 INFO nova.console.websocketproxy [-] WebSocket server settings: 2015-05-12 10:25:33.962 15936 INFO nova.console.websocketproxy [-] - Listen on ::0:6080 2015-05-12 10:25:33.962 15936 INFO nova.console.websocketproxy [-] - Flash security policy server 2015-05-12 10:25:33.962 15936 INFO nova.console.websocketproxy [-] - Web server. Web root: /usr/share/novnc 2015-05-12 10:25:33.963 15936 INFO nova.console.websocketproxy [-] - No SSL/TLS support (no cert file) 2015-05-12 10:25:33.965 15936 INFO nova.console.websocketproxy [-] - proxying from ::0:6080 to None:None 2015-05-13 10:33:12.084 15936 CRITICAL nova [-] UnboundLocalError: local variable 'exc' referenced before assignment 2015-05-13 10:33:12.084 15936 TRACE nova Traceback (most recent call last): 2015-05-13 10:33:12.084 15936 TRACE nova File "/usr/bin/nova-novncproxy", line 10, in 2015-05-13 10:33:12.084 15936 TRACE nova sys.exit(main()) 2015-05-13 10:33:12.084 15936 TRACE nova File "/usr/lib/python2.7/site-packages/nova/cmd/novncproxy.py", line 49, in main 2015-05-13 10:33:12.084 15936 TRACE nova port=CONF.novncproxy_port) 2015-05-13 10:33:12.084 15936 TRACE nova File "/usr/lib/python2.7/site-packages/nova/cmd/baseproxy.py", line 72, in proxy 2015-05-13 10:33:12.084 15936 TRACE nova RequestHandlerClass=websocketproxy.NovaProxyRequestHandler 2015-05-13 10:33:12.084 15936 TRACE nova File "/usr/lib/python2.7/site-packages/websockify/websocket.py", line 1018, in start_server 2015-05-13 10:33:12.084 15936 TRACE nova self.msg("handler exception: %s", str(exc)) 2015-05-13 10:33:12.084 15936 TRACE nova UnboundLocalError: local variable 'exc' referenced before assignment 2015-05-13 10:33:12.084 15936 TRACE nova 2015-05-13 10:52:41.893 3696 INFO nova.console.websocketproxy [-] WebSocket server settings: 2015-05-13 10:52:41.893 3696 INFO nova.console.websocketproxy [-] - Listen on ::0:6080 2015-05-13 10:52:41.894 3696 INFO nova.console.websocketproxy [-] - Flash security policy server 2015-05-13 10:52:41.894 3696 INFO nova.console.websocketproxy [-] - Web server. Web root: /usr/share/novnc 2015-05-13 10:52:41.894 3696 INFO nova.console.websocketproxy [-] - No SSL/TLS support (no cert file) 2015-05-13 10:52:41.920 3696 INFO nova.console.websocketproxy [-] - proxying from ::0:6080 to None:None 2015-05-13 10:54:04.345 3979 INFO oslo_messaging._drivers.impl_rabbit [req-e47dae76-1c51-4ce8-9100-d98022fc6e34 - - - - -] Connecting to AMQP server on 2001:77:77:77:f816:3eff:fe95:8683:5672 2015-05-13 10:54:04.380 3979 INFO oslo_messaging._drivers.impl_rabbit [req-e47dae76-1c51-4ce8-9100-d98022fc6e34 - - - - -] Connected to AMQP server on 2001:77:77:77:f816:3eff:fe95:8683:5672 2015-05-13 10:54:04.388 3979 INFO oslo_messaging._drivers.impl_rabbit [req-e47dae76-1c51-4ce8-9100-d98022fc6e34 - - - - -] Connecting to AMQP server on 2001:77:77:77:f816:3eff:fe95:8683:5672 2015-05-13 10:54:04.408 3979 INFO oslo_messaging._drivers.impl_rabbit [req-e47dae76-1c51-4ce8-9100-d98022fc6e34 - - - - -] Connected to AMQP server on 2001:77:77:77:f816:3eff:fe95:8683:5672 2015-05-13 10:54:04.554 3979 INFO nova.console.websocketproxy [req-
[Yahoo-eng-team] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled
** Changed in: keystone/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Released Status in Keystone juno series: In Progress Status in Keystone kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57 LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', { 'action': action, 'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "X" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+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 1453666] Re: libvirt: guestfs api makes nova-compute hang
** Changed in: nova/kilo Status: Fix Committed => 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/1453666 Title: libvirt: guestfs api makes nova-compute hang Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: Latest Kilo code. In inspect_capabilities() of nova/virt/disk/vfs/guestfs.py, guestfs api, which is C-extension, will hang nova-compute process when it is invoked. This problem will result in message queue time out error and instance booting failure. And example of this problem is: 2015-05-09 17:07:08.393 4449 DEBUG nova.virt.disk.vfs.api [req-1f7c1104-2679-43a5-bbcb-f73114ce9103 - - - - -] Using primary VFSGuestFS instance_for_image /usr/lib/python2.7/site-packages/nova/virt/disk/vfs/api.py:50 2015-05-09 17:08:35.443 4449 DEBUG nova.virt.disk.vfs.guestfs [req-1f7c1104-2679-43a5-bbcb-f73114ce9103 - - - - -] Setting up appliance for /var/lib/nova/instances/0517e2a9-469c-43f4-a129-f489fc1c8356/disk qcow2 setup /usr/lib/python2.7/site-packages/nova/virt/disk/vfs/guestfs.py:169 2015-05-09 17:08:35.457 4449 DEBUG nova.openstack.common.periodic_task [req-bb78b74b-bed7-450f-bd40-19686aab2c3e - - - - -] Running periodic task ComputeManager._instance_usage_audit run_periodic_tasks /usr/lib/python2.7/site-packages/nova/openstack/common/periodic_task.py:219 2015-05-09 17:08:35.461 4449 INFO oslo_messaging._drivers.impl_rabbit [req-bb78b74b-bed7-450f-bd40-19686aab2c3e - - - - -] Connecting to AMQP server on 127.0.0.1:5671 2015-05-09 17:08:35.472 4449 ERROR nova.compute.manager [-] Instance failed network setup after 1 attempt(s) 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager Traceback (most recent call last): 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1783, in _allocate_network_async 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager system_metadata=sys_meta) 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 739, in _instance_update 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager **kwargs) 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/conductor/api.py", line 308, in instance_update 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager updates, 'conductor') 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/conductor/rpcapi.py", line 194, in instance_update 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager service=service) 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 156, in call 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager retry=self.retry) 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 90, in _send 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager timeout=timeout, retry=retry) 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 350, in send 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager retry=retry) 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 339, in _send 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager result = self._waiter.wait(msg_id, timeout) 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 243, in wait 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager message = self.waiters.get(msg_id, timeout=timeout) 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 149, in get 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager 'to message ID %s' % msg_id) 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager MessagingTimeout: Timed out waiting for a reply to message ID 8ff07520ea8743c997b5017f6638a0df 2015-05-09 17:08:35.472 4449 TRACE nova.compute.manager To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1453666/+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 1447084] Re: view hypervisor details should be controlled by policy.json
** Changed in: nova/kilo Status: Fix Committed => 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/1447084 Title: view hypervisor details should be controlled by policy.json Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: When a user with non-admin permissions attempts to view the hypervisor details (/v2/2f8728e1c3214d8bb59903ba654ed6c1/os-hypervisors/1) , we see the following error : 2015-04-19 21:34:22.194 23179 ERROR nova.api.openstack.compute.contrib.hypervisors [req-5caab0db-31aa-4a24-9263-750af6555ef5 605c378ebded02d6a2deebe138c0ef9d6a0ddf39447297105dcc4eb18c7cc062 9b0d73e660af434481a0a9b6d6a3bab7 - - -] User does not have admin privileges 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors Traceback (most recent call last): 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/contrib/hypervisors.py", line 147, in show 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors service = self.host_api.service_get_by_compute_host(context, hyp.host) 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 3451, in service_get_by_compute_host 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors return objects.Service.get_by_compute_host(context, host_name) 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors File "/usr/lib/python2.7/site-packages/nova/objects/base.py", line 163, in wrapper 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors result = fn(cls, context, *args, **kwargs) 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors File "/usr/lib/python2.7/site-packages/nova/objects/service.py", line 151, in get_by_compute_host 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors db_service = db.service_get_by_compute_host(context, host) 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors File "/usr/lib/python2.7/site-packages/nova/db/api.py", line 139, in service_get_by_compute_host 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors use_slave=use_slave) 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors File "/usr/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py", line 214, in wrapper 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors nova.context.require_admin_context(args[0]) 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors File "/usr/lib/python2.7/site-packages/nova/context.py", line 235, in require_admin_context 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors raise exception.AdminRequired() 2015-04-19 21:34:22.194 23179 TRACE nova.api.openstack.compute.contrib.hypervisors AdminRequired: User does not have admin privileges This is caused because the /usr/lib/python2.7/site-packages/nova/db/sqlalchemy/api layer mandates that only an admin can perform this operation. This should not be the case. Instead the permissions should be controlled as per the rules defined in the nova policy.json. This used to work for non-admins till few days/weeks back To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1447084/+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 1465927] Re: varible'version' is undefine in function'_has_cpu_policy_support'
** Changed in: nova/kilo Status: Fix Committed => 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/1465927 Title: varible'version' is undefine in function'_has_cpu_policy_support' Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: My running environment is openstack-nova-compute-2015.1.0-3.el7.noarch python-nova-2015.1.0-3.el7.noarch openstack-nova-novncproxy-2015.1.0-3.el7.noarch openstack-nova-conductor-2015.1.0-3.el7.noarch openstack-nova-api-2015.1.0-3.el7.noarch openstack-nova-console-2015.1.0-3.el7.noarch openstack-nova-scheduler-2015.1.0-3.el7.noarch openstack-nova-serialproxy-2015.1.0-3.el7.noarch openstack-nova-common-2015.1.0-3.el7.noarch When boot a instance to a host with llibvirt version 1.2.10 and flavor key set with hw:cpu_policy=dedicated, there is log with below: File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 3404, in _has_cpu_policy_support File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 524, in _version_to_string TypeError: 'module' object is not iterable in nova/virt/libvirt/driver.py Souce Code of K verison is below: def _has_cpu_policy_support(self): for ver in BAD_LIBVIRT_CPU_POLICY_VERSIONS: if self._host.has_version(ver): ver_ = self._version_to_string(version) raise exception.CPUPinningNotSupported(reason=_( 'Invalid libvirt version %(version)s') % {'version': ver_}) return True I thought this func is mistake in writing with ver_ = self._version_to_string(version) So when libvirt version is BAD_LIBVIRT_CPU_POLICY_VERSIONS there will be a TypeError It should be ver_ = self._version_to_string(ver) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1465927/+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 1468828] Re: HA router-create breaks ML2 drivers that implement create_network such as Arista
** Changed in: neutron/kilo Status: Fix Committed => 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/1468828 Title: HA router-create breaks ML2 drivers that implement create_network such as Arista Status in neutron: Fix Released Status in neutron juno series: Fix Committed Status in neutron kilo series: Fix Released Bug description: This issue was discovered with Arista ML2 driver, when an HA router was created. However, this will impact any ML2 driver that implements create_network. When an admin creates HA router (neutron router-create --ha ), the HA framework invokes network_create() and sets tenant-id to '' (The empty string). network_create() ML2 mech driver API expects tenant-id to be set to a valid ID. Any ML2 driver, which relies on tenant-id, will fail/reject network_create() request, resulting in router-create to fail. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1468828/+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 1459758] Re: inline flavor migration fails with pre-kilo instances
** Changed in: nova/kilo Status: Fix Committed => 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/1459758 Title: inline flavor migration fails with pre-kilo instances Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: If instance.save() is used to migrate the flavor from sys_meta to instance_extra, this only works in that instance already has an instance_extra row. In the case where its missing, the update call silently fails to make any changes to the database, and you get lots of OrphanedInstanceErrors when listing instances, because the instance no longer has any flavors. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1459758/+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 1474074] Re: PciDeviceList is not versioned properly in liberty and kilo
** Changed in: nova/kilo Status: Fix Committed => 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/1474074 Title: PciDeviceList is not versioned properly in liberty and kilo Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: The following commit: https://review.openstack.org/#/c/140289/4/nova/objects/pci_device.py missed to bump the PciDeviceList version. We should do it now (master @ 4bfb094) and backport this to stable Kilo as well To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1474074/+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 1453274] Re: libvirt: resume instance with utf-8 name results in UnicodeDecodeError
** Changed in: nova/kilo Status: Fix Committed => 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/1453274 Title: libvirt: resume instance with utf-8 name results in UnicodeDecodeError Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: This bug is very similar to https://bugs.launchpad.net/nova/+bug/1388386. Resuming a server that has a unicode name after suspending it results in: 2015-05-08 15:22:30.148 4370 INFO nova.compute.manager [req-ac919325-aa2d-422c-b679-5f05ecca5d42 0688b01e6439ca32d698d20789d52169126fb41fb1a4ddafcebb97d854e836c9 6dfced8dd0df4d4d98e4a0db60526c8d - - -] [instance: 12371aa8-889d-4333-8fab-61a13f87a547] Resuming 2015-05-08 15:22:31.651 4370 ERROR nova.compute.manager [req-ac919325-aa2d-422c-b679-5f05ecca5d42 0688b01e6439ca32d698d20789d52169126fb41fb1a4ddafcebb97d854e836c9 6dfced8dd0df4d4d98e4a0db60526c8d - - -] [instance: 12371aa8-889d-4333-8fab-61a13f87a547] Setting instance vm_state to ERROR 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] Traceback (most recent call last): 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 6427, in _error_out_instance_on_exception 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] yield 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 4371, in resume_instance 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] block_device_info) 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2234, in resume 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] vifs_already_plugged=True) 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] File "/usr/lib/python2.7/site-packages/powervc_nova/virt/powerkvm/driver.py", line 2061, in _create_domain_and_network 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] disk_info=disk_info) 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4391, in _create_domain_and_network 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] power_on=power_on) 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4322, in _create_domain 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] LOG.error(err) 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 85, in __exit__ 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] six.reraise(self.type_, self.value, self.tb) 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4305, in _create_domain 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] err = _LE('Error defining a domain with XML: %s') % xml 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 297: ordinal not in range(128) 2015-05-08 15:22:31.651 4370 TRACE nova.compute.manager [instance: 12371aa8-889d-4333-8fab-61a13f87a547] The _create_domain() method has the following line: err = _LE('Error defining a domain with XML: %s') % xml which fails with the UnicodeDecodeError because the xml object has utf-8 encoding. The fix is to wrap the xml object in oslo.utils.encodeutils.safe_decode for the error message. I'm seeing the issue on Kilo, but it is also likely an issue on Juno as well. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1453274/+subscrip
[Yahoo-eng-team] [Bug 1450682] Re: nova unit tests failing with pbr 0.11
** Changed in: nova/kilo Status: Fix Committed => 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/1450682 Title: nova unit tests failing with pbr 0.11 Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) kilo series: Fix Released Bug description: test_version_string_with_package_is_good breaks with the release of pbr 0.11 nova.tests.unit.test_versions.VersionTestCase.test_version_string_with_package_is_good -- Captured traceback: ~~~ Traceback (most recent call last): File "nova/tests/unit/test_versions.py", line 33, in test_version_string_with_package_is_good version.version_string_with_package()) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 350, in assertEqual self.assertThat(observed, matcher, message) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 435, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: '5.5.5.5-g9ec3421' != '2015.2.0-g9ec3421' http://logs.openstack.org/27/169827/8/check/gate-nova-python27/2009c78/console.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1450682/+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 1451931] Re: ironic password config not marked as secret
** Changed in: nova/kilo Status: Fix Committed => 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/1451931 Title: ironic password config not marked as secret Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Compute (nova) kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: The ironic config option for the password and auth token are not marked as secret so the values will get logged during startup in debug mode. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1451931/+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 1419823] Re: Nullable image description crashes v2 client
** Changed in: glance/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1419823 Title: Nullable image description crashes v2 client Status in ubuntu-cloud-archive: Confirmed Status in Glance: Fix Released Status in Glance kilo series: Fix Released Status in glance package in Ubuntu: Confirmed Bug description: When you somehow set the image description to None the glanceclient v2 image-list crashes (as well as image-show, image-update for this particular image). The only way to show all images now is to use client v1, because it's more stable in this case. Steps to reproduce: 1. Open Horizon and go to the edit page of any image. 2. Set description to anything eg. "123" and save. 3. Open image edit page again, remove description and save it. 4. List all images using glanceclient v2: "glance --os-image-api-version 2 image-list" 5. Be sad, because of raised exception: None is not of type u'string' Failed validating u'type' in schema[u'additionalProperties']: {u'type': u'string'} On instance[u'description']: None During investigating the issue I've found that the additionalProperties schema is set to accept only string values, so it should be expanded to allow for null values as well. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1419823/+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 1427756] Re: Event listeners are not being attached to some modal windows
** Changed in: horizon/kilo Status: Fix Committed => 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/1427756 Title: Event listeners are not being attached to some modal windows Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: In some modal windows, form event listeners are not being attached correctly. For example the date picker that should be triggered on a focus event in the text box in [dashboard/admin/metering -> Modify Usage Report Parameters -> Other] is not. This might be a problem with the modal loading or a django issue. This issue is not present if the form is not in a modal window (like it was in juno release), the event listeners are attached regularly and work as expected if the form is in a page of its own. See attached files for reference. Steps to reproduce: 1) Open the dashboard and go to admin/metering 2) Press the 'Modify Usage Report Parameters' button. 3) When the modal window appear select 'Other' from the spinner. 4) Click the 'from' or 'to' text inputs, a datepicker should pop out from there but it does not. 5) If you repeat these steps in juno, the datepicker will appear since the admin/metering/create url is in a page of its own. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1427756/+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 1445827] Re: unit test failures: Glance insist on ordereddict
** Changed in: glance/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1445827 Title: unit test failures: Glance insist on ordereddict Status in Glance: Fix Released Status in Glance kilo series: Fix Released Status in Glance liberty series: Fix Released Status in taskflow: Fix Committed Bug description: There's no python-ordereddict package anymore in Debian, as this is normally included in Python 2.7. I have therefore patched requirements.txt to remove ordereddict. However, even after this, I get some bad unit test errors about it. This must be fixed upstream, because there's no way (modern) downstream distributions can fix it (as the ordereddict Python package will *not* come back). Below is the tracebacks for the 4 failed unit tests. FAIL: glance.tests.unit.test_opts.OptsTestCase.test_list_api_opts -- Traceback (most recent call last): _StringException: Traceback (most recent call last): File "/��PKGBUILDDIR��/glance/tests/unit/test_opts.py", line 143, in test_list_api_opts expected_opt_groups, expected_opt_names) File "/��PKGBUILDDIR��/glance/tests/unit/test_opts.py", line 45, in _test_entry_point list_fn = ep.load() File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2188, in load self.require(env, installer) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2202, in require items = working_set.resolve(reqs, env, installer) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 639, in resolve raise DistributionNotFound(req) DistributionNotFound: ordereddict == FAIL: glance.tests.unit.test_opts.OptsTestCase.test_list_cache_opts -- Traceback (most recent call last): _StringException: Traceback (most recent call last): File "/��PKGBUILDDIR��/glance/tests/unit/test_opts.py", line 288, in test_list_cache_opts expected_opt_groups, expected_opt_names) File "/��PKGBUILDDIR��/glance/tests/unit/test_opts.py", line 45, in _test_entry_point list_fn = ep.load() File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2188, in load self.require(env, installer) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2202, in require items = working_set.resolve(reqs, env, installer) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 639, in resolve raise DistributionNotFound(req) DistributionNotFound: ordereddict == FAIL: glance.tests.unit.test_opts.OptsTestCase.test_list_manage_opts -- Traceback (most recent call last): _StringException: Traceback (most recent call last): File "/��PKGBUILDDIR��/glance/tests/unit/test_opts.py", line 301, in test_list_manage_opts expected_opt_groups, expected_opt_names) File "/��PKGBUILDDIR��/glance/tests/unit/test_opts.py", line 45, in _test_entry_point list_fn = ep.load() File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2188, in load self.require(env, installer) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2202, in require items = working_set.resolve(reqs, env, installer) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 639, in resolve raise DistributionNotFound(req) DistributionNotFound: ordereddict == FAIL: glance.tests.unit.test_opts.OptsTestCase.test_list_registry_opts -- Traceback (most recent call last): _StringException: Traceback (most recent call last): File "/��PKGBUILDDIR��/glance/tests/unit/test_opts.py", line 192, in test_list_registry_opts expected_opt_groups, expected_opt_names) File "/��PKGBUILDDIR��/glance/tests/unit/test_opts.py", line 45, in _test_entry_point list_fn = ep.load() File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2188, in load self.require(env, installer) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2202, in require items = working_set.resolve(reqs, env, installer) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 639, in resolve raise DistributionNotFound(req) DistributionNotFound: ordereddict == FAIL: glance.tests.unit.test_opts.OptsTestCase.test_list_scrubber_opts --
[Yahoo-eng-team] [Bug 1263665] Re: Number of GET requests grows exponentially when multiple rows are being updated in the table
** Changed in: horizon/kilo Status: Fix Committed => 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/1263665 Title: Number of GET requests grows exponentially when multiple rows are being updated in the table Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) icehouse series: Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: 1. In Launch instance dialog select number of instances 10. 2. Create 10 instances. 2. While instances are being created and table rows are being updated the number of row update requests grows exponentially and a queue of pending requests still exists after all rows had beed updated. There is a request type: Request URL:http://donkey017/project/instances/?action=row_update&table=instances&obj_id=7c4eaf35-ebc0-4ea3-a702-7554c8c36cf2 Request Method:GET To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1263665/+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 1447288] Re: create volume from snapshot using horizon error
** Changed in: horizon/kilo Status: Fix Committed => 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/1447288 Title: create volume from snapshot using horizon error Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: When I try to create a volume from snapshot using the OpenStack UI it creates a new raw volume with correct size, but it's not created from a snapshot. $ cinder show 9d5d0ca1-3dd0-47b4-b9f4-86f97d65724e +---+--+ |Property |Value | +---+--+ | attachments | [] | | availability_zone | nova | |bootable |false | | consistencygroup_id | None | | created_at | 2015-04-22T18:08:53.00 | | description | None | | encrypted |False | | id | 9d5d0ca1-3dd0-47b4-b9f4-86f97d65724e | |metadata | {} | | multiattach |False | | name | v2s2 | | os-vol-host-attr:host | ubuntu@ns_nfs-1#nfs | | os-vol-mig-status-attr:migstat| None | | os-vol-mig-status-attr:name_id| None | | os-vol-tenant-attr:tenant_id | 4968203f183641b283e111a2f2db | | os-volume-replication:driver_data | None | | os-volume-replication:extended_status | None | | replication_status | disabled | | size | 2 | | snapshot_id | None | | source_volid | None | | status| available | |user_id| c8163c5313504306b40377a0775e9ffa | | volume_type | None | +---+--+ But when I use cinder command line everything seems to be fine. $ cinder create --snapshot-id 382a0e1d-168b-4cf6-a9ff-715d8ad385eb 1 +---+--+ |Property |Value | +---+--+ | attachments | [] | | availability_zone | nova | |bootable |false | | consistencygroup_id | None | | created_at | 2015-04-22T18:15:08.00 | | description | None | | encrypted |False | | id | b33ec1ef-9d29-4231-8d15-8cf22ca3c502 | |metadata | {} | | multiattach |False | | name | None | | os-vol-host-attr:host | ubuntu@ns_nfs-1#nfs | | os-vol-mig-status-attr:migstat| None | | os-vol-mig-status-attr:name_id| None | | os-vol-tenant-attr:tenant_id | 4968203f183641b283e111a2f2db | | os-volume-replication:driver_data | None | | os-volume-replication:extended_status | None | | replication_status | disabled | | size | 1
[Yahoo-eng-team] [Bug 1433849] Re: Horizon crashes which user click the "Confirm resize" action multiple times while an instance is resizing
** Changed in: horizon/kilo Status: Fix Committed => 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/1433849 Title: Horizon crashes which user click the "Confirm resize" action multiple times while an instance is resizing Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: Steps to reproduce: 1. Boot an instance 2. Resize that instance 3. When the instance is in Confirm resize state, click the "Confirm resize" action. 4. After the action is clicked once, the "Confirm resize" action still shows up, click it couple times. 5. You will see Horizon crashes with the following error: Cannot 'confirmResize' instance d1ba0033-4ce7-431d-a9dc-754fe0631fef while it is in vm_state active (HTTP 409) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1433849/+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 1450535] Re: [data processing] Create node group and cluster templates can fail
** Changed in: horizon/kilo Status: Fix Committed => 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/1450535 Title: [data processing] Create node group and cluster templates can fail Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: * Probably a kilo-backport candidate * In an environment that uses a rewrite / to /dashboard (or whatever), trying to create a node group, cluster template or job will fail when we try to do a urlresolver.resolve on the path. That operation isn't even necessary since the required kwargs are already available in request.resolver_match.kwargs. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1450535/+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 1415087] Re: [OSSA 2015-011] Format-guessing and file disclosure in image convert (CVE-2015-1850, CVE-2015-1851)
** Changed in: cinder/kilo Status: Fix Committed => 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/1415087 Title: [OSSA 2015-011] Format-guessing and file disclosure in image convert (CVE-2015-1850, CVE-2015-1851) Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Committed Status in Cinder kilo series: Fix Released Status in OpenStack Compute (nova): Triaged Status in OpenStack Security Advisory: Fix Committed Bug description: Cinder does not provide input format to several calls of "qemu-img convert". This allows the attacker to play the format guessing by providing a volume with a qcow2 signature. If this signature contains a base file, this file will be read by a process running as root and embedded in the output. This bug is similar to CVE-2013-1922. Tested with: lvm backed volume storage, it may apply to others as well Steps to reproduce: - create volume and attach to vm, - create a qcow2 signature with base-file[1] from within the vm and - trigger upload to glance with "cinder upload-to-image --disk-type qcow2"[2]. The image uploaded to glance will have /etc/passwd from the cinder-volume host embedded. Affected versions: tested on 2014.1.3, found while reading 2014.2.1 Fix: Always specify both input "-f" and output format "-O" to "qemu- img convert". The code is in module cinder.image.image_utils. Bastian Blank [1]: qemu-img create -f qcow2 -b /etc/passwd /dev/vdb [2]: The disk-type != raw triggers the use of "qemu-img convert" To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1415087/+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 1449260] Re: [OSSA 2015-009] Sanitation of metadata label (CVE-2015-3988)
** Changed in: horizon/kilo Status: Fix Committed => 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/1449260 Title: [OSSA 2015-009] Sanitation of metadata label (CVE-2015-3988) Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: 1) Start up Horizon 2) Go to Images 3) Next to an image, pick "Update Metadata" 4) From the dropdown button, select "Update Metadata" 5) In the Custom box, enter a value with some HTML like 'alert(1)//', click + 6) On the right-hand side, give it a value, like "ee" 7) Click "Save" 8) Pick "Update Metadata" for the image again, the page will fail to load, and the JavaScript console says: SyntaxError: invalid property id var existing_metadata = {" An alternative is if you change the URL to update_metadata for the image (for example, http://192.168.122.239/admin/images/fa62ba27-e731-4ab9-8487-f31bac355b4c/update_metadata/), it will actually display the alert box and a bunch of junk. I'm not sure if update_metadata is actually a page, though... can't figure out how to get to it other than typing it in. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1449260/+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 1371022] Re: Idle client connections can persist indefinitely
** Changed in: glance/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1371022 Title: Idle client connections can persist indefinitely Status in Cinder: Fix Released Status in Glance: Fix Released Status in Glance juno series: New Status in Glance kilo series: Fix Released Status in Manila: Fix Released Bug description: Idle client socket connections can persist forever, eg: $ nc localhost 8776 [never returns] To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1371022/+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 1458769] Re: horizon can't update subnet ip pool
** Changed in: horizon/kilo Status: Fix Committed => 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/1458769 Title: horizon can't update subnet ip pool Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: the update of ip pool in subnet reports success, but the refresh shows the data is not changed. steps to recreate: 1. admin/network/subnet 2. edit subnet/details/allocation pools 3. save the changes 4. check the subnet detail after success message shows To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1458769/+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 1453074] Re: [OSSA 2015-010] help_text parameter of fields is vulnerable to arbitrary html injection (CVE-2015-3219)
** Changed in: horizon/kilo Status: Fix Committed => 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/1453074 Title: [OSSA 2015-010] help_text parameter of fields is vulnerable to arbitrary html injection (CVE-2015-3219) Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: The Field class help_text attribute is vulnerable to code injection if the text is somehow taken from the user input. Heat UI allows to create stacks from the user input which define parameters. Those parameters are then converted to the input field which are vulnerable. The heat stack example exploit: description: Does not matter heat_template_version: '2013-05-23' outputs: {} parameters: param1: type: string label: normal_label description: hack=">alert('YOUR HORIZON IS PWNED')" resources: {} To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1453074/+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 1456171] Re: [sahara] relaunch job fail if job is created by saharaclient and no input args
** Changed in: horizon/kilo Status: Fix Committed => 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/1456171 Title: [sahara] relaunch job fail if job is created by saharaclient and no input args Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: If we launch a job from a job_template without input args by saharaclient directly (not in Horizon), and then relaunch it on Horizon, you will get an error. This is because Horizon thinks job_configs always have elements 'args'. You can refer to horizon/openstack_dashboard/dashboards/project/data_processing/jobs/workflows/launch.py, line 190 job_args = json.dumps(job_configs['args']) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1456171/+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 1452750] Re: dest_file in task convert is wrong
** Changed in: glance/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1452750 Title: dest_file in task convert is wrong Status in Glance: Fix Released Status in Glance kilo series: Fix Released Bug description: https://github.com/openstack/glance/commit/1b144f4c12fd6da58d7c48348bf7bab5873388e9 #diff-f02c20aafcce326b4d31c938376f6c2aR78 -> head -> desk The dest_path is not formated correctly, which ends up in converting the image to a path that is completely ignored by other tasks. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1452750/+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 1456157] Re: Updating image with invalid operation type raises 500
** Changed in: glance/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1456157 Title: Updating image with invalid operation type raises 500 Status in Glance: Fix Released Status in Glance kilo series: Fix Released Bug description: When trying to update an image using PATCH method I got Internal Server Error when 'op' (operation) has invalid value. We could consider changing this behavior to return some kind of 40x message (400 probably). Steps to reproduce: URL: http://localhost:9292/v2/images/ Headers: X-Auth-Token: XYZ Content-Type: application/openstack-images-v2.1-json-patch Data: [{"path": "/description", "value": "", "op": "axdd"}] Result: 500 Internal Server Error I'm opening it as `Opinion`, as there can be a reason why are we returning 500 instead of some 40x code. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1456157/+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 1462544] Re: Create Image: Uncaught TypeError: $form.on is not a function
** Changed in: horizon/kilo Status: Fix Committed => 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/1462544 Title: Create Image: Uncaught TypeError: $form.on is not a function Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: on master June 5 2015 Project -> Images -> Create Image dialog Stacktrace horizon.datatables.disable_actions_on_submit @ horizon.tables.js:185 (anonymous function) @ horizon.modals.js:26 jQuery.extend.each@ jquery.js:657 jQuery.fn.jQuery.each @ jquery.js:266 horizon.modals.initModal @ horizon.modals.js:25 (anonymous function) @ horizon.modals.js:177 jQuery.event.dispatch @ jquery.js:5095 jQuery.event.add.elemData.handle @ jquery.js:4766 jQuery.event.trigger @ jquery.js:5007 jQuery.event.trigger @ jquery-migrate.js:493 (anonymous function) @ jquery.js:5691 jQuery.extend.each@ jquery.js:657 jQuery.fn.jQuery.each @ jquery.js:266 jQuery.fn.extend.trigger @ jquery.js:5690 horizon.modals.success@ horizon.modals.js:48 horizon.modals._request.$.ajax.success@ horizon.modals.js:342 jQuery.Callbacks.fire @ jquery.js:3048 jQuery.Callbacks.self.fireWith@ jquery.js:3160 done @ jquery.js:8235 jQuery.ajaxTransport.send.callback@ jquery.js:8778 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1462544/+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 1459446] Re: can't update dns for an ipv6 subnet
** Changed in: horizon/kilo Status: Fix Committed => 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/1459446 Title: can't update dns for an ipv6 subnet Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: It's not possible to update ipv6 subnet info using Horizon. To recreate: Setup: create a new network (Admin->System->Networks->Create Network) create an ipv6 subnet in that network (new network Detail->Create Subnet) Network Address: fdc5:f49e:fe9e::/64 IP Version IPv6 Gateway IP: fdc5:f49e:fe9e::1 click create To view the problem: Edit the subnet (Admin->System->Networks>[detail]->Edit Subnet->Subnet Details attempt to add a DNS name server fdc5:f49e:fe9e::3 An error is returned: "Error: Failed to update subnet "fdc5:f49e:fe9e::/64": Cannot update read-only attribute ipv6_ra_mode" however, it's possible to make the update using neutron subnet-update --dns-nameserver [ip] [id] To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1459446/+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 1461776] Re: Error messages are encoded to HTML entity
** Changed in: glance/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1461776 Title: Error messages are encoded to HTML entity Status in Glance: Fix Released Status in Glance kilo series: Fix Released Bug description: If you pass min_disk or min_ram as -1 to the image create command, then it shows following error message on the command prompt. $ glance image-create --name test --container-format bare --disk-format raw --file --min-disk -1 400 Bad Request: Invalid value '-1' for parameter 'min_disk': Image min_disk must be >= 0 ('-1' specified). (HTTP 400) The above error message will be rendered correctly in the browser but it is not readable on the command prompt. This issue belongs to v1 API, in case of v2 api it returns proper error message: 400 Bad Request: Invalid value '-1' for parameter 'min_disk': Cannot be a negative value (HTTP 400) So we can make this error message consistent for both the APIs. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1461776/+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 1451429] Re: Kilo: I/O error uploading image
** Changed in: horizon/kilo Status: Fix Committed => 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/1451429 Title: Kilo: I/O error uploading image Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: Using a Ceph backend. Same configuration works just fine on Juno. Glance image creation from file using the API works. Horizon image creation from URL works too, but using file upload does not. Apache error.log: Unhandled exception in thread started by Traceback (most recent call last): File "/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/api/glance.py", line 112, in image_update exceptions.handle(request, ignore=True) File "/usr/lib/python2.7/dist-packages/horizon/exceptions.py", line 364, in handle six.reraise(exc_type, exc_value, exc_traceback) File "/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/api/glance.py", line 110, in image_update image = glanceclient(request).images.update(image_id, **kwargs) File "/usr/lib/python2.7/dist-packages/glanceclient/v1/images.py", line 329, in update resp, body = self.client.put(url, headers=hdrs, data=image_data) File "/usr/lib/python2.7/dist-packages/glanceclient/common/http.py", line 265, in put return self._request('PUT', url, **kwargs) File "/usr/lib/python2.7/dist-packages/glanceclient/common/http.py", line 206, in _request **kwargs) File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 455, in request resp = self.send(prep, **send_kwargs) File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 558, in send r = adapter.send(request, **kwargs) File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 350, in send for i in request.body: File "/usr/lib/python2.7/dist-packages/glanceclient/common/http.py", line 170, in chunk_body chunk = body.read(CHUNKSIZE) ValueError: I/O operation on closed file Horizon log: [req-0e69bfd9-c6ab-4131-b445-aa57c1a455f7 87d1da7fba6f4f5a9d4e7f78da344e91 ba35660ba55b4a5283c691a4c6d99f23 - - -] Failed to upload image 90a30bfb-946c-489d-9a04-5f601af0f821 Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/glance/api/v1/upload_utils.py", line 113, in upload_data_to_store context=req.context) File "/usr/lib/python2.7/dist-packages/glance_store/backend.py", line 339, in store_add_to_backend context=context) File "/usr/lib/python2.7/dist-packages/glance_store/capabilities.py", line 226, in op_checker return store_op_fun(store, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/glance_store/_drivers/rbd.py", line 384, in add self._delete_image(loc.image, loc.snapshot) File "/usr/lib/python2.7/dist-packages/glance_store/_drivers/rbd.py", line 290, in _delete_image with conn.open_ioctx(target_pool) as ioctx: File "/usr/lib/python2.7/dist-packages/rados.py", line 667, in open_ioctx raise make_ex(ret, "error opening pool '%s'" % ioctx_name) ObjectNotFound: error opening pool '90a30bfb-946c-489d-9a04-5f601af0f821' To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1451429/+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 1453068] Re: task: Image's locations empty after importing to store
** Changed in: glance/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1453068 Title: task: Image's locations empty after importing to store Status in Glance: Fix Released Status in Glance kilo series: Fix Released Bug description: The ImportToStore task is setting the image data correctly but not saving it after it's been imported. This causes the image's location to be lost and therefore the image is completely useless because there are no locations associated to it To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1453068/+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 1458928] Re: jshint failing on angular js in stable/kilo
** Changed in: horizon/kilo Status: Fix Committed => 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/1458928 Title: jshint failing on angular js in stable/kilo Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: http://logs.openstack.org/56/183656/1/check/gate-horizon- jshint/cd75430/console.html.gz#_2015-05-15_19_27_08_073 Looks like this started after 5/14, since there was a passing job before that: http://logs.openstack.org/21/183321/1/check/gate-horizon- jshint/90ca4dd/console.html.gz#_2015-05-14_22_50_02_203 The only difference I see in external libraries used is tox went from 1.9.2 (passing) to tox 2.0.1 (failing). So I'm thinking there is something with how the environment is defined for the jshint runs because it appears that .jshintrc isn't getting used, see the workaround fix here: https://review.openstack.org/#/c/185172/ From the tox 2.0 changelog: https://testrun.org/tox/latest/changelog.html (new) introduce environment variable isolation: tox now only passes the PATH and PIP_INDEX_URL variable from the tox invocation environment to the test environment and on Windows also SYSTEMROOT, PATHEXT, TEMP and TMP whereas on unix additionally TMPDIR is passed. If you need to pass through further environment variables you can use the new passenv setting, a space-separated list of environment variable names. Each name can make use of fnmatch-style glob patterns. All environment variables which exist in the tox-invocation environment will be copied to the test environment. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1458928/+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 1459625] Re: TemplateDoesNotExist when click manage/unmanage volume
** Changed in: horizon/kilo Status: Fix Committed => 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/1459625 Title: TemplateDoesNotExist when click manage/unmanage volume Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: manage/unmanage template includes wrong templates: project/volumes/volumes/_unmanage_volume.html project/volumes/volumes/_manage_volume.html it should be admin/volumes/... instead of project/volumes/... To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1459625/+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 1464461] Re: delete action always cause error ( in kilo)
** Changed in: horizon/kilo Status: Fix Committed => 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/1464461 Title: delete action always cause error ( in kilo) Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: When i did any delete actions (delete router, delete network etc...) in japanese environment , always get a error page. horizon error logs: - Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py", line 132, in get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py", line 36, in dec return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py", line 52, in dec return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py", line 36, in dec return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py", line 84, in dec return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/django/views/generic/base.py", line 71, in view return self.dispatch(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/django/views/generic/base.py", line 89, in dispatch return handler(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/tables/views.py", line 223, in post return self.get(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/tables/views.py", line 159, in get handled = self.construct_tables() File "/usr/lib/python2.7/site-packages/horizon/tables/views.py", line 150, in construct_tables handled = self.handle_table(table) File "/usr/lib/python2.7/site-packages/horizon/tables/views.py", line 125, in handle_table handled = self._tables[name].maybe_handle() File "/usr/lib/python2.7/site-packages/horizon/tables/base.py", line 1640, in maybe_handle return self.take_action(action_name, obj_id) File "/usr/lib/python2.7/site-packages/horizon/tables/base.py", line 1482, in take_action response = action.multiple(self, self.request, obj_ids) File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py", line 302, in multiple return self.handle(data_table, request, object_ids) File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py", line 828, in handle exceptions.handle(request, ignore=ignore) File "/usr/lib/python2.7/site-packages/horizon/exceptions.py", line 364, in handle six.reraise(exc_type, exc_value, exc_traceback) File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py", line 817, in handle (self._get_action_name(past=True), datum_display)) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 0: ordinal not in range(128) - It occurs in japanese,korean,chinese,french and deutsche, not occurs in english and spanish. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464461/+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 1466744] Re: Integration test test_image_register_unregister failing gate
** Changed in: horizon/kilo Status: Fix Committed => 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/1466744 Title: Integration test test_image_register_unregister failing gate Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: Following test is failing on gate. Traceback (most recent call last): File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/tests/test_sahara_image_registry.py", line 34, in test_image_register_unregister "Image was not registered.") File "/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/unittest2/case.py", line 678, in assertTrue raise self.failureException(msg) AssertionError: False is not true : Image was not registered. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1466744/+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 1464991] Re: Errors are not handled correctly during image updates
** Changed in: horizon/kilo Status: Fix Committed => 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/1464991 Title: Errors are not handled correctly during image updates Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: To reproduce: Log in to horizon as unprivileged user. Navigate to image editing, try to mark an image as public. Observed result: an error message, stating: Danger: There was an error submitting the form. Please try again. Logs indicate, that an UnboundLocalError occurrs File "/Users/teferi/murano/horizon/openstack_dashboard/api/glance.py", line 129, in image_update return image UnboundLocalError: local variable 'image' referenced before assignment This is because image variable is not handled correctly in image_update function. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464991/+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 1467982] Re: Profiler raises an error when it is enabled
** Changed in: glance/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1467982 Title: Profiler raises an error when it is enabled Status in Glance: Fix Released Status in Glance kilo series: Fix Released Status in Glance liberty series: Fix Released Bug description: Description: When OSProfiler is enabled in Glance API and Registry, they raise the following exception: CRITICAL glance [-] AttributeError: 'module' object has no attribute 'messaging' TRACE glance Traceback (most recent call last): TRACE glance File "/usr/bin/glance-api", line 10, in TRACE glance sys.exit(main()) TRACE glance File "/usr/lib/python2.7/site-packages/glance/cmd/api.py", line 80, in main TRACE glance notifier.messaging, {}, TRACE glance AttributeError: 'module' object has no attribute 'messaging' TRACE glance Steps to reproduce: 1. Enable profiler in glance-api.conf and glance-registry.conf [profiler] enabled = True 2. Restart API and Registry Services Expected Behavior: Start services with profiler enabled To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1467982/+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 1467950] Re: test_floatingip, test_keypair tests, test_create_delete_user are consistently failing
** Changed in: horizon/kilo Status: Fix Committed => 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/1467950 Title: test_floatingip, test_keypair tests, test_create_delete_user are consistently failing Status in OpenStack Dashboard (Horizon): New Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: The test above are failing with different reasons. Please note that they were working until yesterday (2015-06-22). test_floatingip: 2015-06-23 12:30:20.815 | 2015-06-23 12:30:20.797 | Traceback (most recent call last): 2015-06-23 12:30:20.817 | 2015-06-23 12:30:20.799 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/tests/test_floatingip.py", line 25, in test_floatingip 2015-06-23 12:30:20.819 | 2015-06-23 12:30:20.801 | floating_ip = floatingip_page.allocate_floatingip() 2015-06-23 12:30:20.821 | 2015-06-23 12:30:20.803 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/pages/project/compute/access_and_security/floatingipspage.py", line 62, in allocate_floatingip 2015-06-23 12:30:20.822 | 2015-06-23 12:30:20.804 | self.floatingips_table.allocate_ip_to_project.click() 2015-06-23 12:30:20.824 | 2015-06-23 12:30:20.806 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/regions/baseregion.py", line 59, in __getattr__ 2015-06-23 12:30:20.826 | 2015-06-23 12:30:20.808 | return self._dynamic_properties[name]() 2015-06-23 12:30:20.827 | 2015-06-23 12:30:20.810 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/regions/baseregion.py", line 78, in __call__ 2015-06-23 12:30:20.829 | 2015-06-23 12:30:20.811 | return result if self.index is None else result[self.index] 2015-06-23 12:30:20.830 | 2015-06-23 12:30:20.813 | IndexError: list index out of range Most likely the page was changed. test_keypair: 2015-06-23 12:30:22.598 | 2015-06-23 12:30:22.581 | Traceback (most recent call last): 2015-06-23 12:30:22.600 | 2015-06-23 12:30:22.582 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/tests/test_keypair.py", line 28, in test_keypair 2015-06-23 12:30:22.601 | 2015-06-23 12:30:22.583 | self.assertTrue(keypair_page.is_keypair_present(self.KEYPAIR_NAME)) 2015-06-23 12:30:22.603 | 2015-06-23 12:30:22.585 | File "/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/unittest2/case.py", line 678, in assertTrue 2015-06-23 12:30:22.604 | 2015-06-23 12:30:22.586 | raise self.failureException(msg) 2015-06-23 12:30:22.606 | 2015-06-23 12:30:22.588 | AssertionError: False is not true Either changed page, or an active polling of the "ready" state is needed. See for example http://logs.openstack.org/72/193072/1/gate/gate-horizon-dsvm-integration/dd294c6/console.html#_2015-06-23_12_30_20_817 The bug is to track the skip patch which will follow and the future investigations of the real issues, that needs to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1467950/+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 1473303] Re: horizon gate failing due to latest release of mock
** Changed in: horizon/kilo Status: Fix Committed => 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/1473303 Title: horizon gate failing due to latest release of mock Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: the latest release of mock exposed some bad test in horizon and the gate jobs are now failing To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1473303/+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 1465221] Re: Horizon running in newer django, the fields is now not sorted correctly.
** Changed in: horizon/kilo Status: Fix Committed => 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/1465221 Title: Horizon running in newer django, the fields is now not sorted correctly. Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: Create User form has wrong order of fields. Correct order : "name", "email", "password", "confirm_password", "project", "role". Current order : "password", "confirm_password", "name", "email", "project", "role". this becomes the cause for integration test(test_create_delete_user) fail. Traceback (most recent call last): /opt/stack/new/horizon/openstack_dashboard/test/integration_tests/tests/test_user_create_delete.py", line 26, in test_create_delete_user self.assertTrue(users_page.is_user_present(self.USER_NAME)) File"/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/unittest2/case.py", line 678, in assertTrue raise self.failureException(msg) AssertionError: False is not true Can be seen both on latest devstack, or gate-horizon-dsvm-integration gate job. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1465221/+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 1473369] Re: new mock release broke a bunch of unit tests
** Changed in: glance/kilo Status: Fix Committed => 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/1473369 Title: new mock release broke a bunch of unit tests Status in Glance: Fix Released Status in Glance kilo series: Fix Released Status in glance_store: Fix Released Status in murano: Fix Committed Status in murano kilo series: Fix Committed Status in neutron: Fix Released Status in neutron kilo series: In Progress Status in python-muranoclient: Fix Committed Status in python-muranoclient kilo series: In Progress Status in OpenStack Object Storage (swift): Fix Committed Bug description: http://lists.openstack.org/pipermail/openstack- dev/2015-July/069156.html To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1473369/+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 1468300] Re: changing user's email from user list deletes user password
** Changed in: horizon/kilo Status: Fix Committed => 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/1468300 Title: changing user's email from user list deletes user password Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: OS: Ubuntu Server 14.04.2 LTS Openstack: Kilo Openstack-dashboard package: 1:2015.1.0-0ubuntu1~cloud0 robcresswell: Seems to also occur on master as of 2015-06-24 While logged as an admin user in Dashboard (horizon), if you try to change an email address from another user directly on users list , it will change the email address properly but will turn to NULL that user's password. This behaviour doesn't seem to have effect while changing email address on "Edit" form. Before changing email address: > select * from user where name="demo"; +--+--+---+-+-+---+--+ | id | name | extra | password | enabled | domain_id | default_project_id | +--+--+---+-+-+---+--+ | 651261afa8654ed1a6431ed2b7405bd3 | demo | {"email": ""} | $6$rounds=4$mXk6yBRZo.00pnoU$rRfNvGXVW15gHq8k6p9caT9bDQwIaNgpN29dLE0aR8wSisIN56xvbdbiQRGs/2S6qmIrrKaTUAm3uso8jMIr61 | 1 | default | 7dd667e26b2e4169bb74cf3306eac352 | +--+--+---+-+-+---+--+ After: > select * from user where name="demo"; +--+--++--+-+---+--+ | id | name | extra | password | enabled | domain_id | default_project_id | +--+--++--+-+---+--+ | 651261afa8654ed1a6431ed2b7405bd3 | demo | {"email": "notrealin...@gti.uvigo.es"} | NULL | 1 | default | 7dd667e26b2e4169bb74cf3306eac352 | +--+--++--+-+---+--+ Due to security: No pass equals can't log in through dashboard also I tried logging in using a CLI without password and it doesn't seem to work. So, I guess it's not a security vulnerability. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1468300/+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 1479532] [NEW] Ironic driver needs to handle nodes in CLEANWAIT state
Public bug reported: Ironic recently added a new state 'CLEANWAIT' [1] so nodes that previously had their provision state as CLEANING will now be in either CLEANING or CLEANWAIT. The ironic driver in nova needs to be updated to know about this new CLEANWAIT state. In particular, when destroying an instance, from nova's perspective, the instance has been removed when a node is in CLEANWAIT state. [1] Ic2bc4f147f68947f53d341fda5e0c8d7b594a553 ** Affects: nova Importance: Undecided Assignee: Ruby Loo (rloo) Status: New ** Tags: ironic ** Tags added: ironic ** Changed in: nova Assignee: (unassigned) => Ruby Loo (rloo) -- 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/1479532 Title: Ironic driver needs to handle nodes in CLEANWAIT state Status in OpenStack Compute (nova): New Bug description: Ironic recently added a new state 'CLEANWAIT' [1] so nodes that previously had their provision state as CLEANING will now be in either CLEANING or CLEANWAIT. The ironic driver in nova needs to be updated to know about this new CLEANWAIT state. In particular, when destroying an instance, from nova's perspective, the instance has been removed when a node is in CLEANWAIT state. [1] Ic2bc4f147f68947f53d341fda5e0c8d7b594a553 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1479532/+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 1479523] [NEW] Stop using debug for insecure responses
Public bug reported: If you set debug=true in keystone.conf the server 1) logs at debug level, and 2) sends out insecure responses. Deployers might think that debug=true only does 1, not knowing about 2 since it's not documented in the sample config. The behaviors should be decoupled to improve security a bit. ** Affects: keystone Importance: Undecided Assignee: Brant Knudson (blk-u) Status: New ** Tags: security -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1479523 Title: Stop using debug for insecure responses Status in Keystone: New Bug description: If you set debug=true in keystone.conf the server 1) logs at debug level, and 2) sends out insecure responses. Deployers might think that debug=true only does 1, not knowing about 2 since it's not documented in the sample config. The behaviors should be decoupled to improve security a bit. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1479523/+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 1478503] Re: test_admin_version_v3 actually tests public app
*** This bug is a duplicate of bug 1478504 *** https://bugs.launchpad.net/bugs/1478504 ** This bug has been marked a duplicate of bug 1478504 test_admin_version_v3 actually tests public app -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1478503 Title: test_admin_version_v3 actually tests public app Status in Keystone: Invalid Bug description: VersionTestCase.test_admin_version_v3 (keystone/tests/unit/test_versions.py) in fact tests public app: def test_admin_version_v3(self): client = tests.TestClient(self.public_app) It makes sense only in case of V3 eventless setup where public app handles bot endpoints, but I believe it should be tested by a separate test like .test_admin_version_v3_eventlets which will be introduced as part of fix of bug #1381961. Also this behavior was introduced when 2 apps setup was used for eventless. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1478503/+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 1479514] [NEW] subnet-update of allocation_pool does not prevent overlap of existing gateway IP
Public bug reported: There are three variations here with the subnet-update command: 1) subnet-update of the gateway_ip such that the new gateway is placed in the existing subnet allocaton pool. This results in GatewayConflictWithAllocationPools. 2) subnet-update of both the gateway_ip and the allocation_poll . If the new gateway IP is located in the new allocation pool, then GatewayConflictWithAllocationPools is returned. 3) subnet-update of just the allocation_pool. If the new allocation pool includes the existing gateway_ip, no error is returned. Scenario 3 needs to be fixed to return same exception as (1) and (2). ** Affects: neutron Importance: Undecided Assignee: John Kasperski (jckasper) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => John Kasperski (jckasper) ** 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/1479514 Title: subnet-update of allocation_pool does not prevent overlap of existing gateway IP Status in neutron: In Progress Bug description: There are three variations here with the subnet-update command: 1) subnet-update of the gateway_ip such that the new gateway is placed in the existing subnet allocaton pool. This results in GatewayConflictWithAllocationPools. 2) subnet-update of both the gateway_ip and the allocation_poll . If the new gateway IP is located in the new allocation pool, then GatewayConflictWithAllocationPools is returned. 3) subnet-update of just the allocation_pool. If the new allocation pool includes the existing gateway_ip, no error is returned. Scenario 3 needs to be fixed to return same exception as (1) and (2). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1479514/+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 1477296] Re: docs: admin guide doesn't mention SSH settings for migration/resize
** Also affects: openstack-manuals 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/1477296 Title: docs: admin guide doesn't mention SSH settings for migration/resize Status in OpenStack Compute (nova): New Status in openstack-manuals: New Bug description: When doing a migration/resize to another host without having a shared storage, the compute nodes need SSH access to each other[1], which is not documented in the "admin guide" [2]. Right now one has to search for blogs which describe how to solve this [3]. I think this should either be documented in the OpenStack admin guide in the compute section or there could be a solution where the SSH access to another compute host is not necessary anymore. References: [1] OpenStack; Nova; libvirt driver; mkdir via SSH; https://github.com/openstack/nova/blob/2015.1.0/nova/virt/libvirt/driver.py#L6242 [2] OpenStack Cloud Admin Guide; Configure migrations; http://docs.openstack.org/admin-guide-cloud/content/section_configuring-compute-migrations.html [3] Sebastien Han; 2015-01-06; "OpenStack Configure VM Migrate Nova SSH"; http://www.sebastien-han.fr/blog/2015/01/06/openstack-configure-vm-migrate-nova-ssh/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1477296/+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 1478925] Re: Instances on the same compute node unable to connect to each other's ports
Is this a Nova issue or Neutron issue? :) ** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1478925 Title: Instances on the same compute node unable to connect to each other's ports Status in neutron: New Status in OpenStack Compute (nova): New Bug description: Openstack version: Icehouse 2014.1.5 Nova version: 2.17.0 I have two instances created on the same compute node connected to a virtual network. I am trying to connect via the virtual network from one instance to another to some port to which no process is listening to and I am expecting to get a 'Connection refused' message from the kernel. This works as expected with any two instances on the same virtual network that are located on different compute nodes, however, if the instances are created on the same compute node, the connection times out. I have noticed that a temporary fix has been to tamper with the input iptables rules by moving the rule which drops packets in an invalid state after the rules for the other instances are defined, as such: From: -A neutron-openvswi-ic05bb97b-2 -m state --state INVALID -j DROP -A neutron-openvswi-ic05bb97b-2 -m state --state RELATED,ESTABLISHED -j RETURN -A neutron-openvswi-ic05bb97b-2 -p tcp -m tcp --dport 22 -j RETURN -A neutron-openvswi-ic05bb97b-2 -p tcp -m tcp --dport 35357 -j RETURN -A neutron-openvswi-ic05bb97b-2 -p tcp -m tcp --dport 80 -j RETURN -A neutron-openvswi-ic05bb97b-2 -p tcp -m tcp --dport 5000 -j RETURN -A neutron-openvswi-ic05bb97b-2 -p tcp -m tcp -m multiport --dports 9000: -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.41/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.25/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 3.0.0.45/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.17/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 4.0.0.12/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.36/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 3.0.0.43/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.40/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.35/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 6.0.0.3/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.28/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 4.0.0.10/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.22/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 3.0.0.44/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 3.0.0.47/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.44/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.39/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.20/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.26/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.38/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.29/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 3.0.0.48/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 6.0.0.6/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.15/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.24/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 4.0.0.11/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.45/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.54/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.13/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.43/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.33/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 3.0.0.42/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.46/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.42/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.23/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 3.0.0.50/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.12/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.16/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.14/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.37/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 5.0.0.7/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 3.0.0.41/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 3.0.0.46/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.48/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.30/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.21/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.27/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 5.0.0.8/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 6.0.0.5/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 5.0.0.6/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -s 9.0.0.49/32 -j RETURN -A neutron-openvswi-ic05bb97b-2 -p icmp -j RETURN To: -A neutron-openvswi-ic05bb97b-2 -m state --state RELATED,ESTABLISHED -j RETURN -A neutron-openvswi-ic05bb97b-2 -p tcp -m tcp --dport 22 -j RETURN -A neutron-openvs
[Yahoo-eng-team] [Bug 1473278] Re: add vhost user constants to portbinding extention
** Changed in: neutron Status: Fix Committed => Fix Released ** Changed in: neutron Milestone: None => liberty-2 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1473278 Title: add vhost user constants to portbinding extention Status in neutron: Fix Released Bug description: during the kilo development cycle a new vif type VIF_TYPE_VHOST_USER was added to the nova libvit driver. in parallel a ovs dpdk mechanism driver was also created which consumes this new VIF type. as humans are error prone when multitasking i forgot to introduce the pathset to add vhost_user constants for port binding to https://github.com/openstack/neutron/blob/master/neutron/extensions/portbindings.py the rfe bug captures the addtion of the following binding constants for the vhost user interface. # - vhost_user_ovs_plug: Boolean used to inform Nova that the ovs plug # method should be used when binding the # vhost user vif. VHOST_USER_OVS_PLUG = 'vhostuser_ovs_plug' # - vhost_user_mode: String value used to declare how the mode of a # vhost-user socket VHOST_USER_MODE = 'vhostuser_mode' # - server: socket created by hypervisor VHOST_USER_MODE_SERVER = 'server' # - client: socket created by vswitch VHOST_USER_MODE_CLIENT = 'client' # - vhostuser_socket String value used to declare the vhostuser socket name VHOST_USER_SOCKET = 'vhostuser_socket' # - vif_type_vhost_user: vif type to enable use of the qemu vhost-user vif VIF_TYPE_VHOST_USER = 'vhostuser' # default location for vhostuser sockets VHOSTUSER_SOCKET_DIR = '/var/run/openvswitch' To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1473278/+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 1469080] Re: LBaaS Message of DeviceNotFoundOnAgent is still the default one
** Changed in: neutron Status: Fix Committed => Fix Released ** Changed in: neutron Milestone: None => liberty-2 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1469080 Title: LBaaS Message of DeviceNotFoundOnAgent is still the default one Status in neutron: Fix Released Bug description: The default message of an exception is "An unknown exception occurred.". Need to use 'message' instead of 'msg' for the following exception, otherwise the default message is logged. class DeviceNotFoundOnAgent(n_exc.NotFound): msg = _('Unknown device with loadbalancer_id %(loadbalancer_id)s') To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1469080/+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