[Yahoo-eng-team] [Bug 1501451] Re: Inconsistency in dhcp-agent when filling hosts and opts files
** Also affects: neutron/juno 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/1501451 Title: Inconsistency in dhcp-agent when filling hosts and opts files Status in neutron: Fix Committed Status in neutron juno series: New Bug description: We have bunch of subnets created in pre-Icehouse era, that have ipv6_address_mode and ipv6_ra_mode unset. For dhcpv6 functionality we rely on enable_dhcp setting for a subnet. However, in _iter_hosts port is skipped iff ipv6_address_mode set to SLAAC, but in _generate_opts_per_subnet subnet is skipped when ipv6_address_mode id SLAAC or unset. Since we can not update ipv6_address_mode attribute in existing subnets (allow_put is False), this breaks DHCPv6 for these VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1501451/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1498163] Re: [OSSA 2015-020] Glance storage quota bypass when token is expired (CVE-2015-5286)
** Also affects: glance/juno Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1498163 Title: [OSSA 2015-020] Glance storage quota bypass when token is expired (CVE-2015-5286) Status in Glance: Fix Released Status in Glance juno series: New Status in OpenStack Security Advisory: Fix Released Bug description: About a year ago it was a vulnerability called 'Glance user storage quota bypass': https://security.openstack.org/ossa/OSSA-2015-003.html, where any user could overcome the quota and clog up the storage. The fix was proposed in master and all other stable branches, but it turned out, that it doesn't completely remove the issue and any user still can exceed the quota. It happens in case if user token is expired during file upload and when glance tries to update image status from 'saving' to 'active'. Then glance gets Unauthenticated exception from registry server and fails with 500 error. On the other side garbage file is left in storage. Steps to reproduce mostly coincide with the related from the previous bug, but in general it is: 1. Set some value (like 1Gb) to user_storage_quota in glance-api.conf and restart the server. 2. Make sure that your token will expire soon, when you'll be able to create an image instance in DB and begin the upload, but the token will expire during it. 3. Create an image, begin the upload and quickly remove the image with 'glance image-delete'. 4. After the upload check that image is not in the list, i.e. it's deleted, and file is still located in the store. 5. Perform steps 2-4 several times to make sure that user quota is exceeded. Related script (test_images.py from here https://bugs.launchpad.net/glance/+bug/1398830) works fine, too, but it's better to reduce token life time in keystone config to 1 or 2 minutes, just for not to wait for one hour. Glance api v2 is affected as well, but only if registry db_api is enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1498163/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1501779] Re: Failing to delete an linux bridge causes log littering
** Also affects: neutron/juno 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/1501779 Title: Failing to delete an linux bridge causes log littering Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: Fix Released Bug description: I saw this in some ansible jobs in the gate: 2015-09-30 22:37:21.805 26634 ERROR neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [req-23466df3-f59e-4897-9a22-1abb7c99dfd9 9a365636c1b44c41a9770a26ead28701 cbddab88045d45eeb3d2027a3e265b78 - - -] Cannot delete bridge brq33213e3f-2b, does not exist http://logs.openstack.org/57/227957/3/gate/gate-openstack-ansible- dsvm-commit/de3daa3/logs/aio1-neutron/neutron-linuxbridge-agent.log https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py#L533 That should not be an ERROR message, it could be INFO at best. If you're racing with RPC and a thing is already gone, which you were going to delete anyway, it's not an error. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1501779/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1490581] Re: the items will never be deleted from metering_info
** Also affects: neutron/juno 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/1490581 Title: the items will never be deleted from metering_info Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: Fix Released Bug description: The function _purge_metering_info of MeteringAgent class has a bug. The items of metering_info dictionary will never be deleted: if info['last_update'] > ts + report_interval: del self.metering_info[label_id] I this situation last_update will always be less than current timestamp. Also this function is not covered by the unit tests. Also again, the purge_metering_info function uses metering_info dict but it should use the metering_infos dict. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1490581/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1482371] Re: [OSSA 2015-019] Image status can be changed by passing header 'x-image-meta-status' with PUT operation using v1 (CVE-2015-5251)
** Also affects: glance/juno Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1482371 Title: [OSSA 2015-019] Image status can be changed by passing header 'x -image-meta-status' with PUT operation using v1 (CVE-2015-5251) Status in Glance: Fix Released Status in Glance juno series: New Status in OpenStack Security Advisory: Fix Released Bug description: Using Glance v1, one is able to change the status of an image to any one of the valid statuses by passing the header 'x-image-meta-status' with PUT on /images/. This bug provides a way for an image to transition states that are otherwise not possible in an image's lifecycle. See http://paste.openstack.org/show/pNL7kvIZUz7cWJQwX64d/ for a reproduction of this behavior on devstack. As shown in the above paste, though one is able to change the status of an active image to queued, uploading data after re-setting the status to queued fails with a 400[1]. Though the purpose of [1] appears to be slightly different, it's fortunately saving us from badly breaking the immutability guarantees of glance images. [1] https://github.com/openstack/glance/blob/master/glance/api/v1/images.py#L760-L765 NOTE: Marking this as a security vulnerability for now as users would be able to activate the deactivated images on their own. This probably affects deployments only where v1 is exposed publicly. However, it's probably worth discussing this from a security perspective as well. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1482371/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1481692] Re: Neutron usage_audit's router and floating IP reporting doesn't work with ML2 plugin
** Also affects: neutron/juno 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/1481692 Title: Neutron usage_audit's router and floating IP reporting doesn't work with ML2 plugin Status in neutron: Fix Released Status in neutron juno series: New Bug description: Neutron usage_audit's router and floating IP reporting doesn't work with ML2 plugin as router functionality has been moved to L3 plugin. The bug has been noted earlier http://lists.openstack.org/pipermail/openstack/2014-September/009371.html but I couldn't find a bug report from launchpad. The error in neutron-usage-audit.log looks like this 2015-08-05 12:00:04.295 30126 CRITICAL neutron [req-74df5d30-7070-4152-86d3-cc4e2ef4fefa None] 'Ml2Plugin' object has no attribute 'get_routers' 2015-08-05 12:00:04.295 30126 TRACE neutron Traceback (most recent call last): 2015-08-05 12:00:04.295 30126 TRACE neutron File "/usr/bin/neutron-usage-audit", line 10, in 2015-08-05 12:00:04.295 30126 TRACE neutron sys.exit(main()) 2015-08-05 12:00:04.295 30126 TRACE neutron File "/usr/lib/python2.6/site-packages/neutron/cmd/usage_audit.py", line 55, in main 2015-08-05 12:00:04.295 30126 TRACE neutron for router in plugin.get_routers(cxt): 2015-08-05 12:00:04.295 30126 TRACE neutron AttributeError: 'Ml2Plugin' object has no attribute 'get_routers' 2015-08-05 12:00:04.295 30126 TRACE neutron I found the bug on icehouse but the relevant code is same in HEAD. My plan is to submit a patch to fix the bug, the fix is quite trivial. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1481692/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1477253] Re: ovs arp_responder unsuccessfully inserts IPv6 address into arp table
** Also affects: neutron/juno 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/1477253 Title: ovs arp_responder unsuccessfully inserts IPv6 address into arp table Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: Fix Released Bug description: The ml2 openvswitch arp_responder agent attempts to install IPv6 addresses into the OVS arp response tables. The action obviously fails, reporting: ovs-ofctl: -:4: 2001:db8::x:x:x:x invalid IP address The end result is that the OVS br-tun arp tables are incomplete. The submitted patch verifies that the address is IPv4 before attempting to add the address to the table. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1477253/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1473556] Re: Error log is generated when API operation is PolicyNotAuthorized and returns 404
** Also affects: neutron/juno 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/1473556 Title: Error log is generated when API operation is PolicyNotAuthorized and returns 404 Status in neutron: Fix Released Status in neutron juno series: New Bug description: neutron.policy module can raises webob.exc.HTTPNotFound when PolicyNotAuthorized is raised. In this case, neutron.api.resource outputs a log with error level. It should be INFO level as it occurs by user API requests. One of the easiest way is to reproduce this bug is as follows: (1) create a shared network by admin user (2) try to delete the shared network by regular user (A regular user can know a ID of the shared network, so the user can request to delete the shared network.) As a result we get the following log. It is confusing from the point of log monitoring. 2015-07-11 05:28:33.914 DEBUG neutron.policy [req-5aef6df6-1fb7-4187-9980-4e41fc648ad7 demo 1e942c3c210b42ff8c45f42962da33b4] Enforcing rules: ['delete_network', 'delete_network:provider:physical_network ', 'delete_network:shared', 'delete_network:provider:network_type', 'delete_network:provider:segmentation_id'] from (pid=1439) log_rule_list /opt/stack/neutron/neutron/policy.py:319 2015-07-11 05:28:33.914 DEBUG neutron.policy [req-5aef6df6-1fb7-4187-9980-4e41fc648ad7 demo 1e942c3c210b42ff8c45f42962da33b4] Failed policy check for 'delete_network' from (pid=1439) enforce /opt/stack/n eutron/neutron/policy.py:393 2015-07-11 05:28:33.914 ERROR neutron.api.v2.resource [req-5aef6df6-1fb7-4187-9980-4e41fc648ad7 demo 1e942c3c210b42ff8c45f42962da33b4] delete failed 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource Traceback (most recent call last): 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource result = method(request=request, **args) 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 146, in wrapper 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource ectxt.value = e.inner_exc 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 119, in __exit__ 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 136, in wrapper 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource return f(*args, **kwargs) 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource File "/opt/stack/neutron/neutron/api/v2/base.py", line 495, in delete 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource raise webob.exc.HTTPNotFound(msg) 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource HTTPNotFound: The resource could not be found. 2015-07-11 05:28:33.914 TRACE neutron.api.v2.resource To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1473556/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1489111] Re: [OSSA 2015-018] IP, MAC, and DHCP spoofing rules can by bypassed by changing device_owner (CVE-2015-5240)
** Also affects: neutron/juno 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/1489111 Title: [OSSA 2015-018] IP, MAC, and DHCP spoofing rules can by bypassed by changing device_owner (CVE-2015-5240) Status in neutron: Fix Released Status in neutron juno series: New Status in OpenStack Security Advisory: Fix Released Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. -- The anti-IP spoofing rules, anti-MAC spoofing rules, and anti-DHCP spoofing rules can be bypassed by changing the device_owner field of a compute node's port to something that starts with 'network:'. Steps to reproduce: Create a port on the target network: neutron port-create some_network Start a repeated update of the device_owner field to immediately change it back after nova sets it to 'compute:' on VM attachment. (This has to be done quickly because the owner has to be set to 'network:something' before the L2 agent wires up the security group rules.) watch neutron port-update --device-owner network:hello Then boot the VM with the port UUID: nova boot test --nic port-id= --flavor m1.tiny --image cirros-0.3.4-x86_64-uec This VM will now have no iptables rules applied because it will be treated as a network owned port (e.g. router interface, DHCP interface, etc). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1489111/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1460741] Re: security groups iptables can block legitimate traffic as INVALID
** Also affects: neutron/juno 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/1460741 Title: security groups iptables can block legitimate traffic as INVALID Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: Fix Released Bug description: The iptables implementation of security groups includes a default rule to drop any INVALID packets (according to the Linux connection state tracking system.) It looks like this: -A neutron-openvswi-od0518220-e -m state --state INVALID -j DROP This is placed near the top of the rule stack, before any security group rules added by the user. See: https://github.com/openstack/neutron/blob/stable/kilo/neutron/agent/linux/iptables_firewall.py#L495 https://github.com/openstack/neutron/blob/stable/kilo/neutron/agent/linux/iptables_firewall.py#L506-L510 However, there are some cases where you would not want traffic marked as INVALID to be dropped here. Specifically, our use case: We have a load balancing scheme where requests from the LB are tunneled as IP-in-IP encapsulation between the LB and the VM. Response traffic is configured for DSR, so the responses go directly out the default gateway of the VM. The results of this are iptables on the hypervisor does not see the initial SYN from the LB to VM (because it is encapsulated in IP-in- IP), and thus it does not make it into the connection table. The response that comes out of the VM (not encapsulated) hits iptables on the hypervisor and is dropped as invalid. I'd like to see a Neutron option to enable/disable the population of this INVALID state rule, so that operators (such as us) can disable it if desired. Obviously it's better in general to keep it in there to drop invalid packets, but there are cases where you would like to not do this. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1460741/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1460562] Re: ipset can't be destroyed when last sg rule is deleted
** Also affects: neutron/juno 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/1460562 Title: ipset can't be destroyed when last sg rule is deleted Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: Fix Released Bug description: reproduce steps: 1. a VM A in default security group 2. default security group has rules: 1. allow all traffic out; 2. allow it self as remote_group in 3. firstly delete rule 1, then delete rule2 I found the iptables in compute node which VM A resids didn't be reload, and the relevant ipset didn't be destroyed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1460562/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1464377] Re: Keystone v2.0 api accepts tokens deleted with v3 api
** Also affects: keystone/juno Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1464377 Title: Keystone v2.0 api accepts tokens deleted with v3 api Status in OpenStack Identity (keystone): Expired Status in OpenStack Identity (keystone) juno series: New Bug description: Keystone tokens that are deleted using the v3 api are still accepted by the v2 api. Steps to reproduce: 1. Request a scoped token as a member of a tenant. 2. Delete it using DELETE /v3/auth/tokens 3. Request the tenants you can access with GET v2.0/tenants 4. The token is accepted and keystone returns the list of tenants The token was a PKI token. Admin tokens appear to be deleted correctly. This could be a problem if a user's access needs to be revoked but they are still able to access v2 functions. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1464377/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1463363] Re: NSX-mh: Decimal RXTX factor not honoured
** Also affects: neutron/juno 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/1463363 Title: NSX-mh: Decimal RXTX factor not honoured Status in neutron: In Progress Status in neutron juno series: New Status in neutron kilo series: New Status in vmware-nsx: Fix Committed Bug description: A decimal RXTX factor, which is allowed by nova flavors, is not honoured by the NSX-mh plugin, but simply truncated to integer. To reproduce: * Create a neutron queue * Create a neutron net / subnet using the queue * Create a new flavor which uses an RXTX factor other than an integer value * Boot a VM on the net above using the flavor * View the NSX queue for the VM's VIF -- notice it does not have the RXTX factor applied correctly (for instance if it's 1.2 it does not multiply it at all, if it's 3.4 it applies a RXTX factor of 3) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1463363/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1460220] Re: ipset functional tests assume system capability
** Also affects: neutron/juno 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/1460220 Title: ipset functional tests assume system capability Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: New Bug description: Production code uses ipset in the root namespace, but functional testing uses them in non-root namespaces. As it turns out, that functionality requires versions of the kernel and ipset not found in all versions of all distributions. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1460220/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1456822] Re: AgentNotFoundByTypeHost exception logged when L3-agent starts up
** Also affects: neutron/juno 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/1456822 Title: AgentNotFoundByTypeHost exception logged when L3-agent starts up Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: New Bug description: On my single-node devstack setup running the latest neutron code, there is one AgentNotFoundByTypeHost exception found for the L3-agent. However, the AgentNotFoundByTypeHost exception is not logged for the DHCP, OVS, or metadata agents. This fact would point to a problem with how the L3-agent is starting up. Exception found in the L3-agent log: 2015-05-19 11:27:57.490 23948 DEBUG oslo_messaging._drivers.amqpdriver [-] MSG_ID is 1d0f3e0a8a6744c9a9fc43eb3fdc5153 _send /usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:311^M 2015-05-19 11:27:57.550 23948 ERROR neutron.agent.l3.agent [-] Failed synchronizing routers due to RPC error^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent Traceback (most recent call last):^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 517, in fetch_and_sync_all_routers^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent routers = self.plugin_rpc.get_routers(context)^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 91, in get_routers^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent router_ids=router_ids)^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 156, in call^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent retry=self.retry)^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 90, in _send^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent timeout=timeout, retry=retry)^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 350, in send^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent retry=retry)^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 341, in _send^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent raise result^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent RemoteError: Remote error: AgentNotFoundByTypeHost Agent with agent_type=L3 agent and host=DVR-Ctrl2 could not be found^M 2015-05-19 11:27:57.550 23948 TRACE neutron.agent.l3.agent [u'Traceback (most recent call last):\n', u' File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 142, in _dispatch_and_reply\nexecutor_callback))\n', u' File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 186, in _dispatch\nexecutor_callback)\n', u' File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 130, in _do_dispatch\nresult = func(ctxt, **new_args)\n', u' File "/opt/stack/neutron/neutron/api/rpc/handlers/l3_rpc.py", line 81, in sync_routers\ncontext, host, router_ids))\n', u' File "/opt/stack/neutron/neutron/db/l3_agentschedulers_db.py", line 290, in list_active_sync_routers_on_active_l3_agent\ncontext, constants.AGENT_TYPE_L3, host)\n', u' File "/opt/stack/neutron/neutron/db/agents_db.py", line 197, in _get_agent_by_type_and_host\nhost=host)\n', u'AgentNotFoundByTypeHost: Agent with agent_ty pe=L3 agent and host=DVR-Ctrl2 could not be found\n'].^M To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1456822/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1459467] Re: port update multiple fixed IPs anticipating allocation fails with mac address error
** Also affects: neutron/juno
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/1459467
Title:
port update multiple fixed IPs anticipating allocation fails with mac
address error
Status in neutron:
Fix Released
Status in neutron icehouse series:
Fix Released
Status in neutron juno series:
New
Status in neutron kilo series:
New
Bug description:
A port update with multiple fixed IP specifications, one with a subnet
ID and one with a fixed IP that conflicts with the address picked by
the one specifying the subnet ID will result in a dbduplicate entry
which is presented to the user as a mac address error.
~$ neutron port-update 7521786b-6c7f-4385-b5e1-fb9565552696 --fixed-ips
type=dict
{subnet_id=ca9dd2f0-cbaf-4997-9f59-dee9a39f6a7d,ip_address=42.42.42.42}
Unable to complete operation for network
0897a051-bf56-43c1-9083-3ac38ffef84e. The mac address None is in use.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1459467/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1457900] Re: dhcp_agents_per_network > 1 cause conflicts (NACKs) from dnsmasqs (break networks)
** Also affects: neutron/juno 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/1457900 Title: dhcp_agents_per_network > 1 cause conflicts (NACKs) from dnsmasqs (break networks) Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: New Status in neutron kilo series: New Bug description: If neutron was configured to have more than one DHCP agent per network (option dhcp_agents_per_network=2), it causes dnsmasq to reject leases of others dnsmasqs, creating mess and stopping instances to boot normally. Symptoms: Cirros (at the log): Sending discover... Sending select for 188.42.216.146... Received DHCP NAK Usage: /sbin/cirros-dhcpc Sending discover... Sending select for 188.42.216.146... Received DHCP NAK Usage: /sbin/cirros-dhcpc Sending discover... Sending select for 188.42.216.146... Received DHCP NAK Steps to reproduce: 1. Set up neutron with VLANs and dhcp_agents_per_network=2 option in neutron.conf 2. Set up two or more different nodes with enabled neutron-dhcp-agent 3. Create VLAN neutron network with --enable-dhcp option 4. Create instance with that network Expected behaviour: Instance recieve IP address via DHCP without problems or delays. Actual behaviour: Instance stuck in the network boot for long time. There are complains about NACKs in the logs of dhcp client. There are multiple NACKs on tcpdump on interfaces Additional analysis: It is very complex, so I attach example of two parallel tcpdumps from two dhcp namespaces in HTML format. Version: 2014.2.3 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1457900/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1456823] Re: address pair rules not matched in iptables counter-preservation code
** Also affects: neutron/juno 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/1456823 Title: address pair rules not matched in iptables counter-preservation code Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: New Bug description: There are a couple of issues with the way our iptables rules are formed that prevent them from being matched in the code that looks at existing rules to preserve counters. So the counters end up getting wiped out. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1456823/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1454434] Re: NoNetworkFoundInMaximumAllowedAttempts during concurrent network creation
** Also affects: neutron/juno 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/1454434 Title: NoNetworkFoundInMaximumAllowedAttempts during concurrent network creation Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: New Bug description: NoNetworkFoundInMaximumAllowedAttempts could be thrown if networks are created by multiple threads simultaneously. This is related to https://bugs.launchpad.net/bugs/1382064 Currently DB logic works correctly, however 11 attempts that code does right now might not be enough in some rare unlucky cases under extreme concurrency. We need to randomize segmentation_id selection to avoid such issues. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1454434/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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)
** Also affects: horizon/juno
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/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) juno series:
New
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 1453855] Re: HA routers may fail to send out GARPs when node boots
** Also affects: neutron/juno 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/1453855 Title: HA routers may fail to send out GARPs when node boots Status in neutron: Fix Released Status in neutron juno series: New Bug description: When a node boots, it starts the OVS and L3 agents. As an example, in RDO systemd unit files, these services have no dependency. This means that the L3 agent can start before the OVS agent. It can start configuring routers before the OVS agent finished syncing with the server and starts processing ovsdb monitor updates. The result is that when the L3 agent finishes configuring an HA router, it starts up keepalived, which under certain conditions will transition to master and send our gratuitous ARPs before the OVS agent finishes plugging its ports. This means that the gratuitous ARP will be lost, but with the router acting as master, this can cause black holes. Possible solutions: * Introduce systemd dependencies, but this has its set of intricacies and it's hard to solve the above problem comprehensively just with this approach. * Regardless, it's a good idea to use new keepalived flags: garp_master_repeat how often the gratuitous ARP after MASTER state transition should be repeated? garp_master_refresh Periodic delay in seconds sending gratuitous ARP while in MASTER state These will be configurable and have sane defaults. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1453855/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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)
** Also affects: horizon/juno
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1449260
Title:
[OSSA 2015-009] Sanitation of metadata label (CVE-2015-3988)
Status in OpenStack Dashboard (Horizon):
Fix Released
Status in OpenStack Dashboard (Horizon) juno series:
New
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 1447883] Re: Restrict netmask of CIDR to avoid DHCP resync is not enough
** Also affects: neutron/juno
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/1447883
Title:
Restrict netmask of CIDR to avoid DHCP resync is not enough
Status in neutron:
Fix Released
Status in neutron icehouse series:
Fix Released
Status in neutron juno series:
New
Status in neutron kilo series:
Fix Released
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
Restrict netmask of CIDR to avoid DHCP resync is not enough.
https://bugs.launchpad.net/neutron/+bug/1443798
I'd like to prevent following case:
[Condition]
- Plugin: ML2
- subnet with "enable_dhcp" is True
[Operations]
A. Specify "[]"(empty list) at "allocation_pools" when create/update-subnet
---
$ $ curl -X POST -d '{"subnet": {"name": "test_subnet", "cidr":
"192.168.200.0/24", "ip_version": 4, "network_id":
"649c5531-338e-42b5-a2d1-4d49140deb02", "allocation_pools": []}}' -H
"x-auth-token:$TOKEN" -H "content-type:application/json"
http://127.0.0.1:9696/v2.0/subnets
Then, the dhcp-agent creates own DHCP-port, it is reproduced resync
bug.
B. Create port and exhaust allocation_pools
---
1. Create subnet with 192.168.1.0/24. And, DHCP-port has alteady created.
gateway_ip: 192.168.1.1
DHCP-port: 192.168.1.2
allocation_pools{"start": 192.168.1.2, "end": 192.168.1.254}
the number of availability ip_addresses is 252.
2. Create non-dhcp port and exhaust ip_addresses in allocation_pools
In this case, user creates a port 252 times.
the number of availability ip_addresses is 0.
3. User deletes the DHCP-port(192.168.1.2)
the number of availability ip_addresses is 1.
4. User creates a non-dhcp port.
the number of availability ports are 0.
Then, dhcp-agent tries to create DHCP-port. It is reproduced resync bug.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1447883/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1447344] Re: DHCP agent: metadata network broken for DVR
** Also affects: neutron/juno 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/1447344 Title: DHCP agent: metadata network broken for DVR Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: New Bug description: When the 'metadata network' feature is enabled, the DHCP at [1] will not spawn a metadata proxy for DVR routers. This should be fixed. [1] http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/dhcp/agent.py#n357 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1447344/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1439857] Re: live-migration failure leave the port to BUILD state
** Also affects: neutron/juno 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/1439857 Title: live-migration failure leave the port to BUILD state Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: Fix Released Bug description: I've set up a lab where live migration can occur in block mode It seems that if I leave the default config, block live-migration fails; I can see that the port is left in BUILD state after the failure, but the VM is still running on the source host. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1439857/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1445412] Re: performance of plugin_rpc.get_routers is bad
** Also affects: neutron/juno 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/1445412 Title: performance of plugin_rpc.get_routers is bad Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: New Bug description: the get_routers plugin call that the l3 agent makes is serviced by a massive amount of SQL queries that lead the whole process to take on the order of hundreds of milliseconds to process a request for 10 routers. This will be a blanket bug for a series of performance improvements that will reduce that time by at least an order of magnitude. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1445412/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1444397] Re: single allowed address pair rule can exhaust entire ipset space
** Also affects: neutron/juno 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/1444397 Title: single allowed address pair rule can exhaust entire ipset space Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: Fix Released Bug description: The hash type used by the ipsets is 'ip' which explodes a CIDR into every member address (i.e. 10.100.0.0/16 becomes 65k entries). The allowed address pairs extension allows CIDRs so a single allowed address pair set can exhaust the entire IPset and break the security group rules for a tenant. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1444397/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1439817] Re: IP set full error in kernel log
** Also affects: neutron/juno 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/1439817 Title: IP set full error in kernel log Status in neutron: Fix Released Status in neutron juno series: New Bug description: This is appearing in some logs upstream: http://logs.openstack.org/73/170073/1/experimental/check-tempest-dsvm- neutron-full-non- isolated/ac882e3/logs/kern_log.txt.gz#_Apr__2_13_03_06 And it has also been reported by andreaf in IRC as having been observed downstream. Logstash is not very helpful as this manifests only with a job currently in the experimental queue. As said job runs in non-isolated mode, accruing of elements in the IPset until it reaches saturation is onet things that might need to be investigated. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1439817/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1442494] Re: test_add_list_remove_router_on_l3_agent race-y for dvr
** Also affects: neutron/juno 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/1442494 Title: test_add_list_remove_router_on_l3_agent race-y for dvr Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: Fix Released Bug description: Logstash: message:"in test_add_list_remove_router_on_l3_agent" AND build_name :"check-tempest-dsvm-neutron-dvr" http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiaW4gdGVzdF9hZGRfbGlzdF9yZW1vdmVfcm91dGVyX29uX2wzX2FnZW50XCIgQU5EIGJ1aWxkX25hbWU6XCJjaGVjay10ZW1wZXN0LWRzdm0tbmV1dHJvbi1kdnJcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyODY0OTgxNDY3MSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== Change [1], enabled by [2], exposed an intermittent failure when determining whether an agent is eligible for binding or not. [1] https://review.openstack.org/#/c/154289/ [2] https://review.openstack.org/#/c/165246/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1442494/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1441523] Re: changing flavor details on running instances will result in errors popping up for users
** Also affects: horizon/juno Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1441523 Title: changing flavor details on running instances will result in errors popping up for users Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) juno series: New Bug description: 1. Install/use and all-in-one w/ demo project 2. As admin, create a flavor and assign to the demo project 3. Log out as admin and log in as demo (must not have admin privs) 4. As demo, launch an instance on this flavor in the demo project 5. Log out as demo and log in as admin 6. As admin, change the amount of RAM for the flavor 7. Log out as admin, log in as demo 8. Check the instances page and size should show "Not available" and there should be an error in the upper right saying "Error: Unable to retrieve instance size information." The error is only shown for non-admin users. what happens here: when editing flavors, nova silently deletes the old flavor, creating a new one. running instances are not touched. the old flavor is marked as deleted, and normal users can not get specifics of that flavor any more. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1441523/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1438040] Re: fdb entries can't be removed when a VM is migrated
** Also affects: neutron/juno 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/1438040 Title: fdb entries can't be removed when a VM is migrated Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: Fix Released Bug description: this problem can be reprodeced as bellow: 1. vm A in computeA, vm B in computeB, l2 pop enable; 2. vmB continue ping vmA 3. live migrate vmA to computeB 4. when live-migrate finish, vmB ping vmA failed the reason is bellow, in l2pop driver, when vmA migrate to computeB, port status change form BUILD to ACTIVE, it add the port to self.migrated_ports when port status is ACTIVE, but 'remove_fdb_entries' in port status is BUILD : def update_port_postcommit(self, context): ... ... elif (context.host != context.original_host and context.status == const.PORT_STATUS_ACTIVE and not self.migrated_ports.get(orig['id'])): # The port has been migrated. We have to store the original # binding to send appropriate fdb once the port will be set # on the destination host self.migrated_ports[orig['id']] = ( (orig, context.original_host)) elif context.status != context.original_status: if context.status == const.PORT_STATUS_ACTIVE: self._update_port_up(context) elif context.status == const.PORT_STATUS_DOWN: fdb_entries = self._update_port_down( context, port, context.host) self.L2populationAgentNotify.remove_fdb_entries( self.rpc_ctx, fdb_entries) elif context.status == const.PORT_STATUS_BUILD: orig = self.migrated_ports.pop(port['id'], None) if orig: original_port = orig[0] original_host = orig[1] # this port has been migrated: remove its entries from fdb fdb_entries = self._update_port_down( context, original_port, original_host) self.L2populationAgentNotify.remove_fdb_entries( self.rpc_ctx, fdb_entries) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1438040/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1424096] Re: DVR routers attached to shared networks aren't being unscheduled from a compute node after deleting the VMs using the shared net
** Also affects: neutron/juno 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/1424096 Title: DVR routers attached to shared networks aren't being unscheduled from a compute node after deleting the VMs using the shared net Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: New Bug description: As the administrator, a DVR router is created and attached to a shared network. The administrator also created the shared network. As a non-admin tenant, a VM is created with the port using the shared network. The only VM using the shared network is scheduled to a compute node. When the VM is deleted, it is expected the qrouter namespace of the DVR router is removed. But it is not. This doesn't happen with routers attached to networks that are not shared. The environment consists of 1 controller node and 1 compute node. Routers having the problem are created by the administrator attached to shared networks that are also owned by the admin: As the administrator, do the following commands on a setup having 1 compute node and 1 controller node: 1. neutron net-create shared-net -- --shared True Shared net's uuid is f9ccf1f9-aea9-4f72-accc-8a03170fa242. 2. neutron subnet-create --name shared-subnet shared-net 10.0.0.0/16 3. neutron router-create shared-router Router's UUID is ab78428a-9653-4a7b-98ec-22e1f956f44f. 4. neutron router-interface-add shared-router shared-subnet 5. neutron router-gateway-set shared-router public As a non-admin tenant (tenant-id: 95cd5d9c61cf45c7bdd4e9ee52659d13), boot a VM using the shared-net network: 1. neutron net-show shared-net +-+--+ | Field | Value| +-+--+ | admin_state_up | True | | id | f9ccf1f9-aea9-4f72-accc-8a03170fa242 | | name| shared-net | | router:external | False| | shared | True | | status | ACTIVE | | subnets | c4fd4279-81a7-40d6-a80b-01e8238c1c2d | | tenant_id | 2a54d6758fab47f4a2508b06284b5104 | +-+--+ At this point, there are no VMs using the shared-net network running in the environment. 2. Boot a VM that uses the shared-net network: nova boot ... --nic net-id=f9ccf1f9-aea9-4f72-accc-8a03170fa242 ... vm_sharednet 3. Assign a floating IP to the VM "vm_sharednet" 4. Delete "vm_sharednet". On the compute node, the qrouter namespace of the shared router (qrouter-ab78428a-9653-4a7b-98ec-22e1f956f44f) is left behind stack@DVR-CN2:~/DEVSTACK/manage$ ip netns qrouter-ab78428a-9653-4a7b-98ec-22e1f956f44f ... This is consistent with the output of "neutron l3-agent-list-hosting-router" command. It shows the router is still being hosted on the compute node. $ neutron l3-agent-list-hosting-router ab78428a-9653-4a7b-98ec-22e1f956f44f +--+++---+ | id | host | admin_state_up | alive | +--+++---+ | 42f12eb0-51bc-4861-928a-48de51ba7ae1 | DVR-Controller | True | :-) | | ff869dc5-d39c-464d-86f3-112b55ec1c08 | DVR-CN2| True | :-) | +--+++---+ Running the "neutron l3-agent-router-remove" command removes the qrouter namespace from the compute node: $ neutron l3-agent-router-remove ff869dc5-d39c-464d-86f3-112b55ec1c08 ab78428a-9653-4a7b-98ec-22e1f956f44f Removed router ab78428a-9653-4a7b-98ec-22e1f956f44f from L3 agent stack@DVR-CN2:~/DEVSTACK/manage$ ip netns stack@DVR-CN2:~/DEVSTACK/manage$ This is a workaround to get the qrouter namespace deleted from the compute node. The L3-agent scheduler should have removed the router from the compute node when the VM is deleted. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1424096/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1416933] Re: Race condition in Ha router updating port status
** Also affects: neutron/juno 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/1416933 Title: Race condition in Ha router updating port status Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: Fix Released Bug description: When L2 agent call 'get_devices_details_list', the ports in this l2 agent will firstly be updated to BUILD, then 'update_device_up' will update them to ACTIVE, but for a Ha router which has two l3 agents, there will be race condition. reproduce progress(not always happen, but much time): 1. 'router-interface-add' add a subnet to Ha router 2. 'router-gateway-set' set router gateway the gateway port status sometimes will always be BUILD in 'get_device_details', the port status will be update, but I think if a port status is ACTIVE and port['admin_state_up'] is True, this port should not be update, def get_device_details(self, rpc_context, **kwargs): .. .. new_status = (q_const.PORT_STATUS_BUILD if port['admin_state_up'] else q_const.PORT_STATUS_DOWN) if port['status'] != new_status: plugin.update_port_status(rpc_context, port_id, new_status, host) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1416933/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1422504] Re: floating ip delete deadlock
** Also affects: neutron/juno
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/1422504
Title:
floating ip delete deadlock
Status in neutron:
Fix Released
Status in neutron juno series:
New
Status in neutron kilo series:
New
Bug description:
rdo juno:
2015-02-16 13:54:11.772 3612 ERROR neutron.api.v2.resource
[req-5c6e13d3-56d6-476b-a961-e767aea637e5 None] delete failed
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource Traceback (most
recent call last):
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/api/v2/resource.py", line 87, in
resource
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource result =
method(request=request, **args)
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 476, in delete
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource
obj_deleter(request.context, id, **kwargs)
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/db/l3_dvr_db.py", line 183, in
delete_floatingip
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource
self).delete_floatingip(context, id)
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/db/l3_db.py", line 1178, in
delete_floatingip
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource router_id =
self._delete_floatingip(context, id)
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/db/l3_db.py", line 840, in
_delete_floatingip
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource
l3_port_check=False)
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/plugin.py", line 984, in
delete_port
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource port_db,
binding = db.get_locked_port_and_binding(session, id)
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/db.py", line 141, in
get_locked_port_and_binding
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource
with_lockmode('update').
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py", line 2369, in one
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource ret =
list(self)
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py", line 2411, in
__iter__
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource
self.session._autoflush()
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 1198, in
_autoflush
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource self.flush()
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 1919, in
flush
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource
self._flush(objects)
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 2037, in
_flush
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource
transaction.rollback(_capture_exception=True)
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib64/python2.7/site-packages/sqlalchemy/util/langhelpers.py", line 60,
in __exit__
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource
compat.reraise(exc_type, exc_value, exc_tb)
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py", line 2001, in
_flush
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource
flush_context.execute()
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/unitofwork.py", line 372, in
execute
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource
rec.execute(self)
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/unitofwork.py", line 555, in
execute
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource uow
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/persistence.py", line 117,
in delete_obj
2015-02-16 13:54:11.772 3612 TRACE neutron.api.v2.resource
cached_connections, mapper, table, delete)
2015-02-16 13:54:11.772 36
[Yahoo-eng-team] [Bug 1411383] Re: Arista ML2 plugin incorrectly syncs with EOS
** Also affects: neutron/juno 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/1411383 Title: Arista ML2 plugin incorrectly syncs with EOS Status in neutron: In Progress Status in neutron juno series: New Bug description: The Arista ML2 plugin periodically compares the data in the Neutron DB with EOS to ensure that they are in sync. If EOS reboots, then the data might be out of sync and the plugin needs to push data from Neutron DB to EOS. As an optimization, the plugin gets and stores the time at which the data on EOS was modified. Just before a sync, the plugin compares the stored time with the timestamp on EOS and performs the sync only if the timestamps differ. Due to a bug, the timestamp is incorrectly stored in the plugin because of which the sync never takes place and the only way to force a sync is to restart the neutron server. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1411383/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1403068] Re: Tests fail with python 2.7.9
** Also affects: keystone/juno
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/1403068
Title:
Tests fail with python 2.7.9
Status in Cinder:
Fix Released
Status in Cinder icehouse series:
Fix Released
Status in Cinder juno series:
Fix Released
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) icehouse series:
Fix Released
Status in OpenStack Identity (keystone) juno series:
New
Status in Manila:
Fix Released
Status in neutron:
Fix Released
Status in neutron icehouse series:
Fix Released
Status in neutron juno series:
Fix Released
Bug description:
Tests that require SSL fail on python 2.7.9 due to the change in
python uses SSL certificates.
==
FAIL: cinder.tests.test_wsgi.TestWSGIServer.test_app_using_ipv6_and_ssl
cinder.tests.test_wsgi.TestWSGIServer.test_app_using_ipv6_and_ssl
--
_StringException: Traceback (most recent call last):
File "/tmp/buildd/cinder-2014.2/cinder/tests/test_wsgi.py", line 237, in
test_app_using_ipv6_and_ssl
response = open_no_proxy('https://[::1]:%d/' % server.port)
File "/tmp/buildd/cinder-2014.2/cinder/tests/test_wsgi.py", line 47, in
open_no_proxy
return opener.open(*args, **kwargs)
File "/usr/lib/python2.7/urllib2.py", line 431, in open
response = self._open(req, data)
File "/usr/lib/python2.7/urllib2.py", line 449, in _open
'_open', req)
File "/usr/lib/python2.7/urllib2.py", line 409, in _call_chain
result = func(*args)
File "/usr/lib/python2.7/urllib2.py", line 1240, in https_open
context=self._context)
File "/usr/lib/python2.7/urllib2.py", line 1197, in do_open
raise URLError(err)
URLError:
Traceback (most recent call last):
_StringException: Empty attachments:
stderr
stdout
Traceback (most recent call last):
File "/tmp/buildd/cinder-2014.2/cinder/tests/test_wsgi.py", line 237, in
test_app_using_ipv6_and_ssl
response = open_no_proxy('https://[::1]:%d/' % server.port)
File "/tmp/buildd/cinder-2014.2/cinder/tests/test_wsgi.py", line 47, in
open_no_proxy
return opener.open(*args, **kwargs)
File "/usr/lib/python2.7/urllib2.py", line 431, in open
response = self._open(req, data)
File "/usr/lib/python2.7/urllib2.py", line 449, in _open
'_open', req)
File "/usr/lib/python2.7/urllib2.py", line 409, in _call_chain
result = func(*args)
File "/usr/lib/python2.7/urllib2.py", line 1240, in https_open
context=self._context)
File "/usr/lib/python2.7/urllib2.py", line 1197, in do_open
raise URLError(err)
URLError:
Traceback (most recent call last):
_StringException: Empty attachments:
stderr
stdout
Traceback (most recent call last):
File "/tmp/buildd/cinder-2014.2/cinder/tests/test_wsgi.py", line 237, in
test_app_using_ipv6_and_ssl
response = open_no_proxy('https://[::1]:%d/' % server.port)
File "/tmp/buildd/cinder-2014.2/cinder/tests/test_wsgi.py", line 47, in
open_no_proxy
return opener.open(*args, **kwargs)
File "/usr/lib/python2.7/urllib2.py", line 431, in open
response = self._open(req, data)
File "/usr/lib/python2.7/urllib2.py", line 449, in _open
'_open', req)
File "/usr/lib/python2.7/urllib2.py", line 409, in _call_chain
result = func(*args)
File "/usr/lib/python2.7/urllib2.py", line 1240, in https_open
context=self._context)
File "/usr/lib/python2.7/urllib2.py", line 1197, in do_open
raise URLError(err)
URLError:
==
FAIL: cinder.tests.test_wsgi.TestWSGIServer.test_app_using_ssl
cinder.tests.test_wsgi.TestWSGIServer.test_app_using_ssl
--
_StringException: Traceback (most recent call last):
File "/tmp/buildd/cinder-2014.2/cinder/tests/test_wsgi.py", line 212, in
test_app_using_ssl
response = open_no_proxy('https://127.0.0.1:%d/' % server.port)
File "/tmp/buildd/cinder-2014.2/cinder/tests/test_wsgi.py", line 47, in
open_no_proxy
return opener.open(*args, **kwargs)
File "/usr/lib/python2.7/urllib2.py", line 431, in open
response = self._open(req, data)
File "/usr/lib/python2.7/urllib2.py", line 449, in _open
'_open', req)
File "/usr/lib/python2.7/urllib2.py", line 409, in _call_chain
result = func(*args)
File "/usr/lib/python2.7/urllib2.py", line 1240, in https_open
context=self._context)
File "/usr/lib/python2.7/urllib2.py", line 1197, in do_open
raise URLError(err)
URLError:
Traceback (most recent call last):
_StringException: Empty attach
[Yahoo-eng-team] [Bug 1405049] Re: Can't see the router in the network topology page, if neutron l3 agent HA is enabled.
** Also affects: horizon/juno Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1405049 Title: Can't see the router in the network topology page, if neutron l3 agent HA is enabled. Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) juno series: New Bug description: When I enabled the neutron l3 agent ha, by setting the properties in neutron.conf, I create a router from horizon. But I can't see the router from the "Network Topology" page. But everything works fine, for example adding gateway, adding interface. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1405049/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1398468] Re: Unable to terminate instance from Network Topology screen
** Also affects: horizon/juno
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1398468
Title:
Unable to terminate instance from Network Topology screen
Status in OpenStack Dashboard (Horizon):
Fix Released
Status in OpenStack Dashboard (Horizon) juno series:
New
Bug description:
I get Server error in JS console and the following traceback in web
server:
Traceback (most recent call last):
File "/usr/lib/python2.7/wsgiref/handlers.py", line 85, in run
self.result = application(self.environ, self.start_response)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/django/contrib/staticfiles/handlers.py",
line 67, in __call__
return self.application(environ, start_response)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py",
line 206, in __call__
response = self.get_response(request)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/django/core/handlers/base.py",
line 194, in get_response
response = self.handle_uncaught_exception(request, resolver,
sys.exc_info())
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/django/core/handlers/base.py",
line 112, in get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/home/timur/develop/horizon/horizon/decorators.py", line 36, in dec
return view_func(request, *args, **kwargs)
File "/home/timur/develop/horizon/horizon/decorators.py", line 52, in dec
return view_func(request, *args, **kwargs)
File "/home/timur/develop/horizon/horizon/decorators.py", line 36, in dec
return view_func(request, *args, **kwargs)
File "/home/timur/develop/horizon/horizon/decorators.py", line 84, in dec
return view_func(request, *args, **kwargs)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/django/views/generic/base.py",
line 69, in view
return self.dispatch(request, *args, **kwargs)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/django/views/generic/base.py",
line 87, in dispatch
return handler(request, *args, **kwargs)
File "/home/timur/develop/horizon/horizon/tables/views.py", line 157, in get
handled = self.construct_tables()
File "/home/timur/develop/horizon/horizon/tables/views.py", line 148, in
construct_tables
handled = self.handle_table(table)
File "/home/timur/develop/horizon/horizon/tables/views.py", line 120, in
handle_table
data = self._get_data_dict()
File "/home/timur/develop/horizon/horizon/tables/views.py", line 185, in
_get_data_dict
self._data = {self.table_class._meta.name: self.get_data()}
File
"/home/timur/develop/horizon/openstack_dashboard/dashboards/project/instances/views.py",
line 60, in get_data
search_opts = self.get_filters({'marker': marker, 'paginate': True})
File
"/home/timur/develop/horizon/openstack_dashboard/dashboards/project/instances/views.py",
line 124, in get_filters
filter_field = self.table.get_filter_field()
File "/home/timur/develop/horizon/horizon/tables/base.py", line 1239, in
get_filter_field
param_name = '%s_field' % filter_action.get_param_name()
AttributeError: 'NoneType' object has no attribute 'get_param_name'
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1398468/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1392316] Re: Hypervisors returns TemplateSyntaxError instead of error message
** Also affects: horizon/juno Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1392316 Title: Hypervisors returns TemplateSyntaxError instead of error message Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) juno series: New Bug description: When trying to list hypervisor at /admin/hypervisors/ I got TemplateSyntaxError. It happens when novaclient (nova-api) cannot fulfil the request. The exception in Horizon: Error while rendering table rows. Traceback (most recent call last): File "/opt/stack/horizon/horizon/tables/base.py", line 1751, in get_rows for datum in self.filtered_data: TypeError: 'NoneType' object is not iterable Internal Server Error: /admin/hypervisors/ Traceback (most recent call last): ... File "/opt/stack/horizon/horizon/tables/base.py", line 1751, in get_rows for datum in self.filtered_data: TemplateSyntaxError: 'NoneType' object is not iterable IMO it should be more robust and just return error message. It would be more consistent with how other views handles unavailable services. To reproduce the error it is enough that novaclient raise exception. Example for this is my case was when zookeeper as servicegroup driver is used, but nova-conductor hasn't yet prepared the required namespace (because of bug [1]) - which ends that nova-api had internal error: nova.api.openstack ServiceGroupUnavailable: The service from servicegroup driver ZooKeeperDriver is temporarily unavailable. This overall result is that whole hypervisor list page was unaccessible only because is was not possible to list nova services. [1] https://bugs.launchpad.net/nova/+bug/1389782 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1392316/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1394051] Re: Can't display port list on a shared network in "Manage Floating IP Associations" page
** Also affects: horizon/juno
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1394051
Title:
Can't display port list on a shared network in "Manage Floating IP
Associations" page
Status in OpenStack Dashboard (Horizon):
Fix Released
Status in OpenStack Dashboard (Horizon) juno series:
New
Bug description:
I used below command to configure floating IP. Juno on CentOS 7.
neutron net-create public --shared --router:external True
--provider:network_type vlan --provider:physical_network physnet2
--provider:segmentation_id 125
neutron subnet-create public --name public-subnet \
--allocation-pool start=125.2.249.170,end=125.2.249.248 \
--disable-dhcp --gateway 125.2.249.1 --dns-nameserver 125.1.166.20
125.2.249.0/24
neutron net-create --shared OAM120 \
--provider:network_type vlan --provider:physical_network physnet2
--provider:segmentation_id 120
neutron subnet-create --name oam120-subnet \
--allocation-pool start=192.168.120.1,end=192.168.120.200 \
--gateway 192.168.120.254 --dns-nameserver 10.1.1.1 --dns-nameserver
125.1.166.20 OAM120 192.168.120.0/24
neutron router-create my-router
neutron router-interface-add my-router oam120-subnet
neutron router-gateway-set my-router public
Just checked the dashborad code, It seems that there are some errors in below
code.
/usr/share/openstack-dashboard/openstack_dashboard/api/neutron.py
def _get_reachable_subnets(self, ports):
# Retrieve subnet list reachable from external network
ext_net_ids = [ext_net.id for ext_net in self.list_pools()]
gw_routers = [r.id for r in router_list(self.request)
if (r.external_gateway_info and
r.external_gateway_info.get('network_id')
in ext_net_ids)]
reachable_subnets = set([p.fixed_ips[0]['subnet_id'] for p in ports
if ((p.device_owner ==
'network:router_interface')
and (p.device_id in gw_routers))])
return reachable_subnets
Why only list "device_owner = 'network:router_interface'", I guess it should
list all "device_owner = 'compute:xxx'"
Here is my work around:
diff output:
/usr/share/openstack-dashboard
[root@jn-controller openstack-dashboard]# diff
./openstack_dashboard/api/neutron.py.orig ./openstack_dashboard/api/neutron.py
413,415c415
< if ((p.device_owner ==
< 'network:router_interface')
< and (p.device_id in gw_routers))])
---
> if
(p.device_owner.startswith('compute:'))])
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1394051/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1388764] Re: Horizon fail to load resources usage if ceilometer configured with SSL
** Also affects: horizon/juno
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1388764
Title:
Horizon fail to load resources usage if ceilometer configured with SSL
Status in OpenStack Dashboard (Horizon):
Fix Released
Status in OpenStack Dashboard (Horizon) juno series:
New
Bug description:
When ceilometer is configured in SSL, within Horizon configured as
below for the local_setting
OPENSTACK_SSL_CACERT=
OPENSTACK_SSL_NO_VERIFY=false
Horizon fail to load the meter-list from ceilometer while ceilometer
will get the meter-list with the same cert via command line.
With checking the code of Horizon. Found that, It uses the wrong arguments to
pass the cacert: It should be 'cacert' instead of 'ca_file'
https://github.com/openstack/python-
ceilometerclient/blob/master/ceilometerclient/v2/client.py#L53
In openstack_dashboard/api/ceilometer.py:
@memoized
def ceilometerclient(request):
"""Initialization of Ceilometer client."""
endpoint = base.url_for(request, 'metering')
insecure = getattr(settings, 'OPENSTACK_SSL_NO_VERIFY', False)
cacert = getattr(settings, 'OPENSTACK_SSL_CACERT', None)
return ceilometer_client.Client('2', endpoint,
token=(lambda: request.user.token.id),
insecure=insecure,
ca_file=cacert)
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1388764/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1389985] Re: CLI will fail one time after restarting DB
*** This bug is a duplicate of bug 1374497 ***
https://bugs.launchpad.net/bugs/1374497
** Also affects: ceilometer/juno
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/1389985
Title:
CLI will fail one time after restarting DB
Status in Ceilometer:
Fix Committed
Status in Ceilometer juno series:
New
Status in Glance:
In Progress
Status in OpenStack Identity (keystone):
Incomplete
Status in OpenStack Compute (nova):
Incomplete
Status in oslo.db:
New
Bug description:
After restarting database, the first command will fail. for example:
after restarting Database, and wait for a few minutes.
Then run heat stack-list, result will be like below:
ERROR: Remote error: DBConnectionError (OperationalError)
ibm_db_dbi::OperationalError: SQLNumResultCols failed: [IBM][CLI Driver]
SQL30081N A communication error has been detected. Communication protocol
being used: "TCP/IP". Communication API being used: "SOCKETS". Location where
the error was detected: "10.11.1.14". Communication function detecting the
error: "send". Protocol specific error code(s): "2", "*", "*". SQLSTATE=08001
SQLCODE=-30081 'SELECT stack.status_reason AS stack_status_reason,
stack.created_at AS stack_created_at, stack.deleted_at AS stack_deleted_at,
stack.action AS stack_action, stack.status AS stack_status, stack.id AS
stack_id, stack.name AS stack_name, stack.raw_template_id AS
stack_raw_template_id, stack.username AS stack_username, stack.tenant AS
stack_tenant, stack.parameters AS stack_parameters, stack.user_creds_id AS
stack_user_creds_id, stack.owner_id AS stack_owner_id, stack.timeout AS
stack_timeout, stack.disable_rollback AS stack_disable_rol
lback, stack.stack_user_project_id AS stack_stack_user_project_id,
stack.backup AS stack_backup, stack.updated_at AS stack_updated_at \nFROM stack
\nWHERE stack.deleted_at IS NULL AND stack.owner_id IS NULL AND stack.tenant =
? ORDER BY stack.created_at DESC, stack.id DESC'
('a3a14c6f82bd4ce88273822407a0829b',)
[u'Traceback (most recent call last):\n', u' File
"/usr/lib/python2.6/site-packages/oslo/messaging/rpc/dispatcher.py", line 134,
in _dispatch_and_reply\nincoming.message))\n', u' File
"/usr/lib/python2.6/site-packages/oslo/messaging/rpc/dispatcher.py", line 177,
in _dispatch\nreturn self._do_dispatch(endpoint, method, ctxt, args)\n', u'
File "/usr/lib/python2.6/site-packages/oslo/messaging/rpc/dispatcher.py", line
123, in _do_dispatch\nresult = getattr(endpoint, method)(ctxt,
**new_args)\n', u' File
"/usr/lib/python2.6/site-packages/heat/engine/service.py", line 69, in
wrapped\nreturn func(self, ctx, *args, **kwargs)\n', u' File
"/usr/lib/python2.6/site-packages/heat/engine/service.py", line 490, in
list_stacks\nreturn [api.format_stack(stack) for stack in stacks]\n', u'
File "/usr/lib/python2.6/site-packages/heat/engine/stack.py", line 264, in
load_all\nshow_deleted, show_nested) or []\n', u' File
"/usr/lib/python2.6/site-packages/heat/db/api.py", li
ne 130, in stack_get_all\nshow_deleted, show_nested)\n', u' File
"/usr/lib/python2.6/site-packages/heat/db/sqlalchemy/api.py", line 368, in
stack_get_all\nmarker, sort_dir, filters).all()\n', u' File
"/usr/lib64/python2.6/site-packages/sqlalchemy/orm/query.py", line 2241, in
all\nreturn list(self)\n', u' File
"/usr/lib64/python2.6/site-packages/sqlalchemy/orm/query.py", line 2353, in
__iter__\nreturn self._execute_and_instances(context)\n', u' File
"/usr/lib64/python2.6/site-packages/sqlalchemy/orm/query.py", line 2368, in
_execute_and_instances\nresult = conn.execute(querycontext.statement,
self._params)\n', u' File
"/usr/lib64/python2.6/site-packages/sqlalchemy/engine/base.py", line 662, in
execute\nparams)\n', u' File
"/usr/lib64/python2.6/site-packages/sqlalchemy/engine/base.py", line 761, in
_execute_clauseelement\ncompiled_sql, distilled_params\n', u' File
"/usr/lib64/python2.6/site-packages/sqlalchemy/engine/base.py", line 874, in
_execute_c
ontext\ncontext)\n', u' File
"/usr/lib/python2.6/site-packages/oslo/db/sqlalchemy/compat/handle_error.py",
line 125, in _handle_dbapi_exception\nsix.reraise(type(newraise), newraise,
sys.exc_info()[2])\n', u' File
"/usr/lib/python2.6/site-packages/oslo/db/sqlalchemy/compat/handle_error.py",
line 102, in _handle_dbapi_exception\nper_fn = fn(ctx)\n', u' File
"/usr/lib/python2.6/site-packages/oslo/db/sqlalchemy/exc_filters.py", line 323,
in handler\ncontext.is_disconnect)\n', u' File
"/usr/lib/python2.6/site-packages/oslo/db/sqlalchemy/exc_filters.py", line 263,
in _is_db_connection_error\nraise
exception.DBConnectionError(operational_error)\n', u'DBConnectionError:
(OperationalError) ibm_db_dbi::OperationalError: SQLNumResultCols failed:
[IBM][CLI Driv
[Yahoo-eng-team] [Bug 1374473] Re: 500 error on router-gateway-set for DVR on second external network
** Also affects: neutron/juno 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/1374473 Title: 500 error on router-gateway-set for DVR on second external network Status in neutron: Fix Released Status in neutron juno series: New Bug description: Under some circumstances this operation may fail. Steps to reproduce: 1) Run Devstack with DVR *on* (devstack by default creates an external network and sets the gateway to the router) 2) Create an external network 3) Create a router 4) Set the gateway to the router 5) Observe the Internal Server Error Expected outcome: the gateway is correctly set. This occurs with the latest Juno code. The underlying error is an attempted double binding of the router to the L3 agent. More details in: http://paste.openstack.org/show/115614/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1374473/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1382064] Re: Failure to allocate tunnel id when creating networks concurrently
** Also affects: neutron/juno
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/1382064
Title:
Failure to allocate tunnel id when creating networks concurrently
Status in neutron:
Fix Released
Status in neutron juno series:
New
Status in neutron kilo series:
New
Bug description:
When multiple networks are created concurrently, the following trace
is observed:
WARNING neutron.plugins.ml2.drivers.helpers
[req-34103ce8-b6d0-459b-9707-a24e369cf9de None] Allocate gre segment from pool
failed after 10 failed attempts
DEBUG neutron.context [req-2995f877-e3e6-4b32-bdae-da6295e492a1 None]
Arguments dropped when creating context: {u'project_name': None, u'tenant':
None} __init__ /usr/lib/python2.7/dist-packages/neutron/context.py:83
DEBUG neutron.plugins.ml2.drivers.helpers
[req-3541998d-44df-468f-b65b-36504e893dfb None] Allocate gre segment from pool,
attempt 1 failed with segment {'gre_id': 300L}
allocate_partially_specified_segment
/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/helpers.py:138
DEBUG neutron.context [req-6dcfb91d-2c5b-4e4f-9d81-55ba381ad232 None]
Arguments dropped when creating context: {u'project_name': None, u'tenant':
None} __init__ /usr/lib/python2.7/dist-packages/neutron/context.py:83
ERROR neutron.api.v2.resource [req-34103ce8-b6d0-459b-9707-a24e369cf9de None]
create failed
TRACE neutron.api.v2.resource Traceback (most recent call last):
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 87, in
resource
TRACE neutron.api.v2.resource result = method(request=request, **args)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 448, in create
TRACE neutron.api.v2.resource obj = obj_creator(request.context, **kwargs)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/plugin.py", line 497, in
create_network
TRACE neutron.api.v2.resource tenant_id)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/managers.py", line 160,
in create_network_segments
TRACE neutron.api.v2.resource segment = self.allocate_tenant_segment(session)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/managers.py", line 189,
in allocate_tenant_segment
TRACE neutron.api.v2.resource segment =
driver.obj.allocate_tenant_segment(session)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/type_tunnel.py",
line 115, in allocate_tenant_segment
TRACE neutron.api.v2.resource alloc =
self.allocate_partially_specified_segment(session)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/helpers.py", line
143, in allocate_partially_specified_segment
TRACE neutron.api.v2.resource raise
exc.NoNetworkFoundInMaximumAllowedAttempts()
TRACE neutron.api.v2.resource NoNetworkFoundInMaximumAllowedAttempts: Unable
to create the network. No available network found in maximum allowed attempts.
TRACE neutron.api.v2.resource
Additional conditions: multiserver deployment and mysql.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1382064/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1378558] Re: Plugin panel not listed in configured panel group
** Also affects: horizon/juno Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1378558 Title: Plugin panel not listed in configured panel group Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) juno series: New Status in OpenStack Dashboard (Horizon) kilo series: Fix Released Bug description: When adding panel Foo to the Admin dashboard's System panel group via the openstack_dashboard/local/enabled/ directory, with something like: PANEL = 'foo' PANEL_DASHBOARD = 'admin' PANEL_GROUP = 'admin' ADD_PANEL = 'openstack_dashboard.dashboards.admin.foo.panel.Foo' Foo appears under the panel group Other instead of System. This is the error in the Apache log: Could not process panel foo: 'tuple' object has no attribute 'append' To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1378558/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1367189] Re: multipath not working with Storwize backend if CHAP enabled
** Also affects: cinder/juno 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/1367189 Title: multipath not working with Storwize backend if CHAP enabled Status in Cinder: Fix Released Status in Cinder juno series: New Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Status in os-brick: Fix Released Bug description: if I try to attach a volume to a VM while having multipath enabled in nova and CHAP enabled in the storwize backend, it fails: 2014-09-09 11:37:14.038 22944 ERROR nova.virt.block_device [req-f271874a-9720-4779-96a8-01575641a939 a315717e20174b10a39db36b722325d6 76d25b1928e7407392a69735a894c7fc] [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] Driver failed to attach volume c460f8b7-0f1d-4657-bdf7-e142ad34a132 at /dev/vdb 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] Traceback (most recent call last): 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/virt/block_device.py", line 239, in attach 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] device_type=self['device_type'], encryption=encryption) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 1235, in attach_volume 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] disk_info) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 1194, in volume_driver_method 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] return method(connection_info, *args, **kwargs) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/openstack/common/lockutils.py", line 249, in inner 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] return f(*args, **kwargs) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py", line 280, in connect_volume 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] check_exit_code=[0, 255])[0] \ 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py", line 579, in _run_iscsiadm_bare 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] check_exit_code=check_exit_code) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/utils.py", line 165, in execute 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] return processutils.execute(*cmd, **kwargs) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/openstack/common/processutils.py", line 193, in execute 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] cmd=' '.join(cmd)) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] ProcessExecutionError: Unexpected error while running command. 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] Command: sudo nova-rootwrap /etc/nova/rootwrap.conf iscsiadm -m discovery -t sendtargets -p 192.168.1.252:3260 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] Exit code: 5 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] Stdout: '' 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] Stderr: 'iscsiadm: Connection to Discovery Address 192.168.1.252 closed\niscsiadm: Login I/O error, failed to receive a PDU\niscsiadm: retrying discovery login to 192.168.1.252\niscsiadm: Connection to Discovery Address 192.168.1.252 close
[Yahoo-eng-team] [Bug 1362676] Re: Hyper-V agent doesn't create stateful security group rules
** Also affects: neutron/juno
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/1362676
Title:
Hyper-V agent doesn't create stateful security group rules
Status in networking-hyperv:
Fix Released
Status in neutron:
New
Status in neutron juno series:
New
Bug description:
Hyper-V agent does not create stateful security group rules (ACLs),
meaning it doesn't allow any response traffic to pass through.
For example, the following security group rule:
{"direction": "ingress", "remote_ip_prefix": null, "protocol": "tcp",
"port_range_max": 22, "port_range_min": 22, "ethertype": "IPv4"}
Allows tcp inbound traffic through port 22, but since the Hyper-V agent does
not add this rule as stateful, the reply traffic never received, unless
specifically added an egress security group rule as well.
To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-hyperv/+bug/1362676/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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
** Also affects: glance/juno 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/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 Glance juno series: New Status in heat: Fix Released Status in heat kilo series: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) juno series: Fix Committed Status in OpenStack Identity (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: Won't Fix Status in Sahara: Fix Committed 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://laun
[Yahoo-eng-team] [Bug 1329050] Re: Creating a PanelGroup produces group with name "Other"
** Also affects: horizon/juno
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1329050
Title:
Creating a PanelGroup produces group with name "Other"
Status in OpenStack Dashboard (Horizon):
Fix Released
Status in OpenStack Dashboard (Horizon) juno series:
New
Bug description:
Creating a PanelGroup that is made up of one or more panels that exist
in a subdirectory does not yield a group with the correct name.
Instead, it gives a Panel Group with a display name of "Other".
Example code:
In project/dashboard.py, I added a new PanelGroup
class DataProcessingPanels(horizon.PanelGroup):
name = _("Data Processing")
slug = "data_processing"
panels = ("data_processing.plugins",)
and added it to the panels for the "Project" dashboard.
The code for the "data_processing.plugins" panel is in
.dashboards/project/data_processing/plugins
This results in a Panel Group showing up in the UI with a display name
of "Other". The "plugins" panel is correctly listed in there and it
seems to have full functionality. The only bit that looks to be
broken is the display name.
As a part of my debugging effort, I changed the panel from
"data_processing.plugins" to another panel that is not in a subdirectory and
then the "Data Processing" group name displayed correctly.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1329050/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1328546] Re: Race condition when hard rebooting instance
** Also affects: neutron/juno 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/1328546 Title: Race condition when hard rebooting instance Status in neutron: Fix Released Status in neutron juno series: New Bug description: Condition for this to happen: == 1. Agent: neutron-linuxbridge-agent. 2. Only 1 instance is running on the hypervisor that belong to this network. 3. Timing, it's a race condition after all ;-) Remarked behavior: After hard reboot instance end up in ERROR state and the nova-compute log an error saying that: Cannot get interface MTU on 'brqf9d0e8cf-bd': No such device What happen: === When nova do a hard reboot, the instance is first destroyed, which imply that the tap device is deleted from the linux bridge (which result to an empty bridge b/c of 2 condition above), than re-created afterward, but in between neutron-linuxbridge-agent may clean up this empty bridge as part of his remove_empty_bridges()[1], but for this error to happen neutron-linuxbridge-agent should do that after plug_vifs()[2] and before domain.createWithFlags() finish. [1]: https://github.com/openstack/neutron/blob/stable/icehouse/neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py#L449. [2]: https://github.com/openstack/nova/blob/stable/icehouse/nova/virt/libvirt/driver.py#L3648-3656 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1328546/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1332917] Re: Deadlock when deleting from ipavailabilityranges
** Also affects: neutron/juno
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/1332917
Title:
Deadlock when deleting from ipavailabilityranges
Status in neutron:
Fix Released
Status in neutron juno series:
New
Bug description:
Traceback:
TRACE neutron.api.v2.resource Traceback (most recent call last):
TRACE neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/resource.py", line 87, in resource
TRACE neutron.api.v2.resource result = method(request=request, **args)
TRACE neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/base.py", line 477, in delete
TRACE neutron.api.v2.resource obj_deleter(request.context, id, **kwargs)
TRACE neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/plugins/ml2/plugin.py", line 608, in
delete_subnet
TRACE neutron.api.v2.resource break
TRACE neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 463,
in __exit__
TRACE neutron.api.v2.resource self.rollback()
TRACE neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line
57, in __exit__
TRACE neutron.api.v2.resource compat.reraise(exc_type, exc_value, exc_tb)
TRACE neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 460,
in __exit__
TRACE neutron.api.v2.resource self.commit()
TRACE neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 370,
in commit
TRACE neutron.api.v2.resource self._prepare_impl()
TRACE neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 350,
in _prepare_impl
TRACE neutron.api.v2.resource self.session.flush()
TRACE neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/openstack/common/db/sqlalchemy/session.py",
line 444, in _wrap
TRACE neutron.api.v2.resource _raise_if_deadlock_error(e,
self.bind.dialect.name)
TRACE neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/openstack/common/db/sqlalchemy/session.py",
line 427, in _raise_if_deadlock_error
TRACE neutron.api.v2.resource raise
exception.DBDeadlock(operational_error)
TRACE neutron.api.v2.resource DBDeadlock: (OperationalError) (1213,
'Deadlock found when trying to get lock; try restarting transaction') 'DELETE
FROM ipavailabilityranges WHERE ipavailabilityranges.allocation_pool_id = %s
AND ipavailabilityranges.first_ip = %s AND ipavailabilityranges.last_ip = %s'
('b19b08b6-90f2-43d6-bfe1-9cbe6e0e1d93', '10.100.0.2', '10.100.0.14')
http://logs.openstack.org/21/76021/12/check/check-tempest-dsvm-
neutron-
full/7577c27/logs/screen-q-svc.txt.gz?level=TRACE#_2014-06-21_18_39_47_122
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1332917/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1263665] Re: Number of GET requests grows exponentially when multiple rows are being updated in the table
** Also affects: horizon/juno Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/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) juno series: New 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 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning
** Also affects: neutron/juno 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/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in neutron: Fix Released Status in neutron juno series: New Status in neutron kilo series: Fix Released Status in OpenStack Security Advisory: Invalid Status in OpenStack Security Notes: Fix Released Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1187102] Re: quantum-ns-metadata-proxy listens on external interfaces too
** Also affects: neutron/juno 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/1187102 Title: quantum-ns-metadata-proxy listens on external interfaces too Status in neutron: Fix Released Status in neutron juno series: New Status in OpenStack Security Advisory: Invalid Bug description: Running Grizzy 2013.1 on Ubuntu 12.04. Three nodes: controller, network and compute. netnode# ip netns exec qrouter-7a44de32-3ac0-4f3e-92cc-1a37d8211db8 netstat -anp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 0.0.0.0:96970.0.0.0:* LISTEN 18462/python So this router is uplinked to an external network: netnode# ip netns exec qrouter-7a44de32-3ac0-4f3e-92cc-1a37d8211db8 ip -4 a 14: lo: mtu 16436 qdisc noqueue state UNKNOWN inet 127.0.0.1/8 scope host lo 23: qr-123f9b7f-43: mtu 1500 qdisc noqueue state UNKNOWN inet 172.17.17.1/24 brd 172.17.17.255 scope global qr-123f9b7f-43 24: qg-c8a6a6cd-6d: mtu 1500 qdisc noqueue state UNKNOWN inet 192.168.101.2/24 brd 192.168.101.255 scope global qg-c8a6a6cd-6d Now from outside can do: $ nmap 192.168.101.2 -p 9697 Starting Nmap 6.00 ( http://nmap.org ) at 2013-06-03 13:45 IST Nmap scan report for 192.168.101.2 Host is up (0.0018s latency). PORT STATE SERVICE 9697/tcp open unknown As a test I tried changing namespace_proxy.py so it would not bind to 0.0.0.0 proxy.start(handler, self.port, host='127.0.0.1') but the metadata stopped working. In iptables this rule is being hit: -A quantum-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697 I'm guessing the intention of that rule is also change the destination address to 127.0.0.1 ? as there is this: -A quantum-l3-agent-INPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 9697 -j ACCEPT but the counters show that this rule is not being hit. Anyway the default policy for INPUT is ACCEPT. From the iptables man page: REDIRECT "... It redirects the packet to the machine itself by changing the destination IP to the primary address of the incoming interface (locally-generated packets are mapped to the 127.0.0.1 address). ..." so the primary address of the incoming interface is 172.17.17.1, not 127.0.0.1. So I manually deleted the "-j REDIRECT --to-ports 9697" and added "-j DNAT --to-destination 127.0.0.1:9697" but that didn't work - seems like it is not possible: http://serverfault.com/questions/351816/dnat- to-127-0-0-1-with-iptables-destination-access-control-for-transparent- soc So I tried changing the ns proxy to listen on 172.17.17.1. I think this is the one and only address it should bind to anyway. proxy.start(handler, self.port, host='172.17.17.1') # hardwire as a test Stopped the l3-agent, killed the quantum-ns-metadata-proxy and restarted the l3-agent. But the ns proxy gave an error: Stderr: 'cat: /proc/10850/cmdline: No such file or directory\n' 2013-06-03 15:05:18ERROR [quantum.wsgi] Unable to listen on 172.17.17.1:9697 Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/quantum/wsgi.py", line 72, in start backlog=backlog) File "/usr/lib/python2.7/dist-packages/eventlet/convenience.py", line 38, in listen sock.bind(addr) File "/usr/lib/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) error: [Errno 99] Cannot assign requested address The l3-agent.log shows the agent deleted the port qr-123f9b7f-43 at 15:05:10 and did not recreate it until 15:05:19 - ie a second too late for the ns proxy. From looking at the code it seems the l3-agent spawns the ns proxy just before it plugs its ports. I was able to start the ns proxy manually with the command line from the l3-agent log, and the metadata worked and was not reachable from outside. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1187102/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1475411] Re: During post_live_migration the nova libvirt driver assumes that the destination connection info is the same as the source, which is not always true
** Also affects: nova/juno 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/1475411 Title: During post_live_migration the nova libvirt driver assumes that the destination connection info is the same as the source, which is not always true 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: The post_live_migration step for Nova libvirt driver is currently making a bad assumption about the source and destination connector information. The destination connection info may be different from the source which ends up causing LUNs to be left dangling on the source as the BDM has overridden the connection info with that of the destination. Code section where this problem is occuring: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L6036 At line 6038 the potentially wrong connection info will be passed to _disconnect_volume which then ends up not finding the proper LUNs to remove (and potentially removes the LUNs for a different volume instead). By adding debug logging after line 6036 and then comparing that to the connection info of the source host (by making a call to Cinder's initialize_connection API) you can see that the connection info does not match: http://paste.openstack.org/show/TjBHyPhidRuLlrxuGktz/ Version of nova being used: commit 35375133398d862a61334783c1e7a90b95f34cdb Merge: 83623dd b2c5542 Author: Jenkins Date: Thu Jul 16 02:01:05 2015 + Merge "Port crypto to Python 3" To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1475411/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1450682] Re: nova unit tests failing with pbr 0.11
** Also affects: nova/juno 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/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) juno series: New 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 1439223] Re: misleading power state logging in _sync_instance_power_state
** Also affects: nova/juno 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/1439223 Title: misleading power state logging in _sync_instance_power_state Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: Commit aa1792eb4c1d10e9a192142ce7e20d37871d916a added more verbose logging of the various database and hypervisor states when _sync_instance_power_state is called (which can be called from handle_lifecycle_event - triggered by the libvirt driver, or from the _sync_power_states periodic task). The current instance power_state from the DB's POV and the power state from the hypervisor's POV (via handle_lifecycle_event) can be different and if they are different, the database is updated with the power_state from the hypervisor and the local db_power_state variable is updated to be the same as the vm_power_state (from the hypervisor). Then later, the db_power_state value is used to log the different states when we have conditions like the database says an instance is running / active but the hypervisor says it's stopped, so we call compute_api.stop(). We should be logging the original database power state and the power_state from the hypervisor to more accurately debug when we're out of sync. This is already fixed on master: https://review.openstack.org/#/c/159263/ I'm reporting the bug so it this can be backported to stable/juno. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1439223/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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
** Also affects: nova/juno 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/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) juno series: New 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/b
[Yahoo-eng-team] [Bug 1443186] Re: rebooted instances are shutdown by libvirt lifecycle event handling
** Also affects: nova/juno 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/1443186 Title: rebooted instances are shutdown by libvirt lifecycle event handling 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: 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
[Yahoo-eng-team] [Bug 1431404] Re: Don't trace when @reverts_task_state fails on InstanceNotFound
** Also affects: nova/juno 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/1431404 Title: Don't trace when @reverts_task_state fails on InstanceNotFound Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: This change https://review.openstack.org/#/c/163515/ added a warning when the @reverts_task_state decorator in the compute manager fails rather than just pass, because we were getting KeyErrors and never noticing them which broke the decorator. However, now we're tracing on InstanceNotFound which is a normal case if we're deleting the instance after a failure (tempest will delete the instance immediately after failures when tearing down a test): http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRmFpbGVkIHRvIHJldmVydCB0YXNrIHN0YXRlIGZvciBpbnN0YW5jZVwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI4NjQwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MjYxNzA3MDE2OTV9 http://logs.openstack.org/98/163798/1/check/check-tempest-dsvm- postgres- full/6eff665/logs/screen-n-cpu.txt.gz#_2015-03-12_13_11_36_304 2015-03-12 13:11:36.304 WARNING nova.compute.manager [req-a5f3b37e-19e9-4e1d-9be7-bbb9a8e7f4c1 DeleteServersTestJSON-706956764 DeleteServersTestJSON-535578435] [instance: 6de2ad51-3155-4538-830d-f02de39b4be3] Failed to revert task state for instance. Error: Instance 6de2ad51-3155-4538-830d-f02de39b4be3 could not be found. Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 142, in inner return func(*args, **kwargs) File "/opt/stack/new/nova/nova/conductor/manager.py", line 134, in instance_update columns_to_join=['system_metadata']) File "/opt/stack/new/nova/nova/db/api.py", line 774, in instance_update_and_get_original columns_to_join=columns_to_join) File "/opt/stack/new/nova/nova/db/sqlalchemy/api.py", line 143, in wrapper return f(*args, **kwargs) File "/opt/stack/new/nova/nova/db/sqlalchemy/api.py", line 2395, in instance_update_and_get_original columns_to_join=columns_to_join) File "/opt/stack/new/nova/nova/db/sqlalchemy/api.py", line 181, in wrapped return f(*args, **kwargs) File "/opt/stack/new/nova/nova/db/sqlalchemy/api.py", line 2434, in _instance_update columns_to_join=columns_to_join) File "/opt/stack/new/nova/nova/db/sqlalchemy/api.py", line 1670, in _instance_get_by_uuid raise exception.InstanceNotFound(instance_id=uuid) InstanceNotFound: Instance 6de2ad51-3155-4538-830d-f02de39b4be3 could not be found. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1431404/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1433049] Re: libvirt-xen: Instance status in nova may be different than real status
** Also affects: nova/juno 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/1433049 Title: libvirt-xen: Instance status in nova may be different than real status Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: Tempest test ServerActionsTestJSON:test_resize_server_confirm_from_stopped and other similaire test from_stopped may fail with libvirt-xen driver due to the test timing out on waiting the instance to be SHUTOFF, but nova is reporting the instance to be ACTIVE. Traceback (most recent call last): File "/opt/stack/tempest/tempest/api/compute/servers/test_server_actions.py", line 230, in test_resize_server_confirm_from_stopped self._test_resize_server_confirm(stop=True) File "/opt/stack/tempest/tempest/api/compute/servers/test_server_actions.py", line 209, in _test_resize_server_confirm self.client.wait_for_server_status(self.server_id, expected_status) File "/opt/stack/tempest/tempest/services/compute/json/servers_client.py", line 183, in wait_for_server_status ready_wait=ready_wait) File "/opt/stack/tempest/tempest/common/waiters.py", line 93, in wait_for_server_status raise exceptions.TimeoutException(message) tempest.exceptions.TimeoutException: Request timed out Details: (ServerActionsTestJSON:test_resize_server_confirm_from_stopped) Server a0f07187-4e08-4664-ad48-a03cffb87873 failed to reach SHUTOFF status and task state "None" within the required time (196 s). Current status: ACTIVE. Current task state: None. From nova log, I could see "VM Started (Lifecycle Event)" being reported while the instance is shutdown and being resized. After tracking done this bug, the issue may comes from the Change-Id I690d3d700ab4d057554350da143ff77d78b509c6, Delay STOPPED lifecycle event for Xen domains. A way to reproduce would be to run this script on a Xen machine using a small Cirros instance: nova boot --image 'cirros-0.3.2-x86_64-uec' --flavor 42 instance nova stop instance # wait sometime (around 20s) so we start with SHUTDOWN state nova start instance nova stop instance nova resize instance 84 nova resize-confirm instance # check new state, should be shutoff. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1433049/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1439302] Re: "FixedIpNotFoundForAddress: Fixed ip not found for address None." traces in gate runs
** Also affects: nova/juno 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/1439302 Title: "FixedIpNotFoundForAddress: Fixed ip not found for address None." traces in gate runs Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: Seeing this quite a bit in normal gate runs: http://logs.openstack.org/53/169753/2/check/check-tempest-dsvm-full- ceph/07dcae0/logs/screen-n-cpu.txt.gz?level=TRACE#_2015-04-01_14_34_37_110 http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRml4ZWRJcE5vdEZvdW5kRm9yQWRkcmVzczogRml4ZWQgaXAgbm90IGZvdW5kIGZvciBhZGRyZXNzIE5vbmUuXCIgQU5EIHRhZ3M6XCJzY3JlZW4tbi1jcHUudHh0XCIgQU5EIHRhZ3M6XCJtdWx0aWxpbmVcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyNzkwMjQ0NTg4OSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] FixedIpNotFoundForAddress: Fixed ip not found for address None. 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] Traceback (most recent call last): 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 142, in _dispatch_and_reply 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] executor_callback)) 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 186, in _dispatch 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] executor_callback) 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 130, in _do_dispatch 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] result = func(ctxt, **new_args) 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] File "/opt/stack/new/nova/nova/network/floating_ips.py", line 186, in deallocate_for_instance 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] super(FloatingIP, self).deallocate_for_instance(context, **kwargs) 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] File "/opt/stack/new/nova/nova/network/manager.py", line 558, in deallocate_for_instance 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] instance=instance) 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] File "/opt/stack/new/nova/nova/network/manager.py", line 214, in deallocate_fixed_ip 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] context, address, expected_attrs=['network']) 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] File "/opt/stack/new/nova/nova/objects/base.py", line 161, in wrapper 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] args, kwargs) 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] 2015-04-01 14:34:37.110 674 TRACE nova.compute.manager [instance: 2fc5caf4-8ff7-45bc-940f-c13d696a1d9d] File "/opt/stack/new/nova/nova/conductor/rpcapi.py", line 329, in object_class_action 2015-
[Yahoo-eng-team] [Bug 1444630] Re: nova-compute should stop handling virt lifecycle events when it's shutting down
** Also affects: nova/juno 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/1444630 Title: nova-compute should stop handling virt lifecycle events when it's shutting down 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: This is a follow on to bug 1293480 and related to bug 1408176 and bug 1443186. There can be a race when rebooting a compute host where libvirt is shutting down guest VMs and sending STOPPED lifecycle events up to nova compute which then tries to stop them via the stop API, which sometimes works and sometimes doesn't - the compute service can go down with a vm_state of ACTIVE and task_state of powering-off which isn't resolve on host reboot. Sometimes the stop API completes and the instance is stopped with power_state=4 (shutdown) in the nova database. When the host comes back up and libvirt restarts, it starts up the guest VMs which sends the STARTED lifecycle event and nova handles that but because the vm_state in the nova database is STOPPED and the power_state is 1 (running) from the hypervisor, nova things it started up unexpectedly and stops it: http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py?id=2015.1.0rc1#n6145 So nova shuts the running guest down. Actually the block in: http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py?id=2015.1.0rc1#n6145 conflicts with the statement in power_state.py: http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/power_state.py?id=2015.1.0rc1#n19 "The hypervisor is always considered the authority on the status of a particular VM, and the power_state in the DB should be viewed as a snapshot of the VMs's state in the (recent) past." Anyway, that's a different issue but the point is when nova-compute is shutting down it should stop accepting lifecycle events from the hypervisor (virt driver code) since it can't really reliably act on them anyway - we can leave any sync up that needs to happen in init_host() in the compute manager. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1444630/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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
** Also affects: nova/juno 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/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) juno series: New 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 1429093] Re: nova allows to boot images with virtual size > root_gb specified in flavor
** Also affects: nova/juno 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/1429093 Title: nova allows to boot images with virtual size > root_gb specified in flavor Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Status in OpenStack Compute (nova) kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: It's currently possible to boot an instance from a QCOW2 image, which has the virtual size larger than root_gb size specified in the given flavor. Steps to reproduce: 1. Download a QCOW2 image (e.g. Cirros - https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-i386-disk.img) 2. Resize the image to a reasonable size: qemu-img resize cirros-0.3.0-i386-disk.img +9G 3. Upload the image to Glance: glance image-create --file cirros-0.3.0-i386-disk.img --name cirros- 10GB --is-public True --progress --container-format bare --disk-format qcow2 4. Boot the first VM using a 'correct' flavor (root_gb > virtual size of the Cirros image), e.g. m1.small (root_gb = 20) nova boot --image cirros-10GB --flavor m1.small demo-ok 5. Wait until the VM boots. 6. Boot the second VM using an 'incorrect' flavor (root_gb < virtual size of the Cirros image), e.g. m1.tiny (root_gb = 1): nova boot --image cirros-10GB --flavor m1.tiny demo-should-fail 7. Wait until the VM boots. Expected result: demo-ok is in ACTIVE state demo-should-fail is in ERROR state (failed with FlavorDiskTooSmall) Actual result: demo-ok is in ACTIVE state demo-should-fail is in ACTIVE state To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1429093/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1420032] Re: remove_router_interface doesn't scale well with dvr routers
** Also affects: neutron/juno 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/1420032 Title: remove_router_interface doesn't scale well with dvr routers Status in neutron: Fix Released Status in neutron juno series: New Bug description: With dvr enabled , neutron remove-router-interface significantly degrades in response time as the number of l3_agents and the number of routers increases. A significant contributor to the poor performance is due to check_ports_exist_on_l3agent. The call to get_subnet_ids_on_router returns an empty list since the port has already been deleted by this point. The empty subnet list is then used as a filter to the subsequent call core_plugin.get_ports which unexpectedly returns all ports instead of an empty list of ports. Erroneously looping through the entire list of ports is the biggest contributor to the poor scalability. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1420032/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1427343] Re: missing entry point for cisco apic topology agent
** Also affects: neutron/juno 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/1427343 Title: missing entry point for cisco apic topology agent Status in neutron: Fix Released Status in neutron juno series: New Bug description: Cisco APIC topology agent [0] is missing the entry point. [0] neutron.plugins.ml2.drivers.cisco.apic.apic_topology.ApicTopologyService To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1427343/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1430239] Re: Hyper-V: *DataRoot paths are not set for instances
** Also affects: nova/juno 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/1430239 Title: Hyper-V: *DataRoot paths are not set for instances Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: The Nova Hyper-V Driver does not set the Data Root path locations for the newly created instances to the same location as the instances. By default. Hyper-V sets the location on C:\. This can cause issues for small C:\ partitions, as some of these files can be large. The path locations that needs to be set are: ConfigurationDataRoot, LogDataRoot, SnapshotDataRoot, SuspendDataRoot, SwapFileDataRoot. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1430239/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1423772] Re: During live-migration Nova expects identical IQN from attached volume(s)
** Also affects: nova/juno
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/1423772
Title:
During live-migration Nova expects identical IQN from attached
volume(s)
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:
When attempting to do a live-migration on an instance with one or more
attached volumes, Nova expects that the IQN will be exactly the same
as it's attaching the volume(s) to the new host. This conflicts with
the Cinder settings such as "hp3par_iscsi_ips" which allows for
multiple IPs for the purpose of load balancing.
Example:
An instance on Host A has a volume attached at
"/dev/disk/by-path/ip-10.10.220.244:3260-iscsi-iqn.2000-05.com.3pardata:22210002ac002a13-lun-2"
An attempt is made to migrate the instance to Host B.
Cinder sends the request to attach the volume to the new host.
Cinder gives the new host
"/dev/disk/by-path/ip-10.10.120.244:3260-iscsi-iqn.2000-05.com.3pardata:22210002ac002a13-lun-2"
Nova looks for the volume on the new host at the old location
"/dev/disk/by-path/ip-10.10.220.244:3260-iscsi-iqn.2000-05.com.3pardata:22210002ac002a13-lun-2"
The following error appears in n-cpu in this case:
2015-02-19 17:09:05.574 ERROR nova.virt.libvirt.driver [-] [instance:
b6fa616f-4e78-42b1-a747-9d081a4701df] Live Migration failure: Failed to open
file
'/dev/disk/by-path/ip-10.10.220.244:3260-iscsi-iqn.2000-05.com.3pardata:22210002ac002a13-lun-2':
No such file or directory
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/poll.py", line
115, in wait
listener.cb(fileno)
File "/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py", line
212, in main
result = function(*args, **kwargs)
File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 5426, in
_live_migration
recover_method(context, instance, dest, block_migration)
File "/opt/stack/nova/nova/openstack/common/excutils.py", line 82, in
__exit__
six.reraise(self.type_, self.value, self.tb)
File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 5393, in
_live_migration
CONF.libvirt.live_migration_bandwidth)
File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 183,
in doit
result = proxy_call(self._autowrap, f, *args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 141,
in proxy_call
rv = execute(f, *args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 122,
in execute
six.reraise(c, e, tb)
File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 80,
in tworker
rv = meth(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1582, in
migrateToURI2
if ret == -1: raise libvirtError ('virDomainMigrateToURI2() failed',
dom=self)
libvirtError: Failed to open file
'/dev/disk/by-path/ip-10.10.220.244:3260-iscsi-iqn.2000-05.com.3pardata:22210002ac002a13-lun-2':
No such file or directory
Removing descriptor: 3
When looking at the nova DB, this is the state of block_device_mapping prior
to the migration attempt:
mysql> select * from block_device_mapping where
instance_uuid='b6fa616f-4e78-42b1-a747-9d081a4701df' and deleted=0;
+-+-+++-+---+-+--+-+---+---+--+-+-+--+--+-+--++--+
| created_at | updated_at | deleted_at | id | device_name |
delete_on_termination | snapshot_id | volume_id|
volume_size | no_device | connection_info
[Yahoo-eng-team] [Bug 1417745] Re: Cells connecting pool tracking
** Also affects: nova/juno 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/1417745 Title: Cells connecting pool tracking Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: Cells has a rpc driver for inter-cell communication. A oslo.messaging.Transport is created for each inter-cell message. In previous versions of oslo.messaging, connection pool references were maintained within the RabbitMQ driver abstraction in oslo.messaging. As of oslo.messaging commit f3370da11a867bae287d7f549a671811e8b399ef, the application must maintain a single reference to Transport or references to the connection pool will be lost. The net effect of this is that cells constructs a new broker connection pool (and a connection) on every message sent between cells. This is leaking references to connections. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1417745/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1414065] Re: Nova can lose track of running VM if live migration raises an exception
** Also affects: nova/juno 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/1414065 Title: Nova can lose track of running VM if live migration raises an exception Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: There is a fairly serious bug in VM state handling during live migration, with a result that if libvirt raises an error *after* the VM has successfully live migrated to the target host, Nova can end up thinking the VM is shutoff everywhere, despite it still being active. The consequences of this are quite dire as the user can then manually start the VM again and corrupt any data in shared volumes and the like. The fun starts in the _live_migration method in nova.virt.libvirt.driver, if the 'migrateToURI2' method fails *after* the guest has completed migration. At start of migration, we see an event received by Nova for the new QEMU process starting on target host 2015-01-23 15:39:57.743 DEBUG nova.compute.manager [-] [instance: 12bac45e-aca8-40d1-8f39-941bc6bb59f0] Synchronizing instance power state after lifecycle event "Started"; current vm_state: active, current task_state: migrating, current DB power_state: 1, VM power_state: 1 from (pid=19494) handle_lifecycle_event /home/berrange/src/cloud/nova/nova/compute/manager.py:1134 Upon migration completion we see CPUs start running on the target host 2015-01-23 15:40:02.794 DEBUG nova.compute.manager [-] [instance: 12bac45e-aca8-40d1-8f39-941bc6bb59f0] Synchronizing instance power state after lifecycle event "Resumed"; current vm_state: active, current task_state: migrating, current DB power_state: 1, VM power_state: 1 from (pid=19494) handle_lifecycle_event /home/berrange/src/cloud/nova/nova/compute/manager.py:1134 And finally an event saying that the QEMU on the source host has stopped 2015-01-23 15:40:03.629 DEBUG nova.compute.manager [-] [instance: 12bac45e-aca8-40d1-8f39-941bc6bb59f0] Synchronizing instance power state after lifecycle event "Stopped"; current vm_state: active, current task_state: migrating, current DB power_state: 1, VM power_state: 4 from (pid=23081) handle_lifecycle_event /home/berrange/src/cloud/nova/nova/compute/manager.py:1134 It is the last event that causes the trouble. It causes Nova to mark the VM as shutoff at this point. Normally the '_live_migrate' method would succeed and so Nova would then immediately & explicitly mark the guest as running on the target host. If an exception occurrs though, this explicit update of VM state doesn't happen so Nova considers the guest shutoff, even though it is still running :-( The lifecycle events from libvirt have an associated "reason", so we could see that the shutoff event from libvirt corresponds to a migration being completed, and so not mark the VM as shutoff in Nova. We would also have to make sure the target host processes the 'resume' event upon migrate completion. An safer approach though, might be to just mark the VM as in an ERROR state if any exception occurs during migration. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1414065/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1419785] Re: VMware: running a redundant nova compute deletes running instances
** Also affects: nova/juno 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/1419785 Title: VMware: running a redundant nova compute deletes running instances Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: When running more than one nova compute configured for the same cluster, rebooting one of the computes will delete all running instances. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1419785/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1408176] Re: Nova instance not boot after host restart but still show as Running
** Also affects: nova/juno 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/1408176 Title: Nova instance not boot after host restart but still show as Running Status in OpenStack Compute (nova): Confirmed Status in OpenStack Compute (nova) juno series: New Bug description: The nova host lost power and after restarted, the previous running instance is still shown in "Running" state but actually not started: root@allinone-controller0-esenfmnxzcvk:~# nova list +--++++-+---+ | ID | Name | Status | Task State | Power State | Networks | +--++++-+---+ | 13d9eead-191e-434e-8813-2d3bf8d3aae4 | alexcloud-controller0-rr5kdtqmv7qz | ACTIVE | - | Running | default-net=172.16.0.15, 30.168.98.61 | +--++++-+---+ root@allinone-controller0-esenfmnxzcvk:~# ps -ef |grep -i qemu root 95513 90291 0 14:46 pts/000:00:00 grep --color=auto -i qemu Please note the resume_guests_state_on_host_boot flag is False. Log file is attached. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1408176/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1406486] Re: Suspending an instance fails when using vnic_type=direct
** Also affects: nova/juno 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/1406486 Title: Suspending an instance fails when using vnic_type=direct Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Status in python-glanceclient: New Bug description: When launching an instance with a pre-created port with binding:vnic_type='direct' and suspending the instance fails with error 'NoneType' object has no attribute 'encode' Nova compute log: http://paste.openstack.org/show/155141/ Version == openstack-nova-common-2014.2.1-3.el7ost.noarch openstack-nova-compute-2014.2.1-3.el7ost.noarch python-novaclient-2.20.0-1.el7ost.noarch python-nova-2014.2.1-3.el7ost.noarch How to Reproduce === # neutron port-create tenant1-net1 --binding:vnic-type direct # nova boot --flavor m1.small --image rhel7 --nic port-id= vm1 # nova suspend # nova show To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1406486/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1399244] Re: rbd resize revert fails
** Also affects: nova/juno 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/1399244 Title: rbd resize revert fails Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: In Ceph CI, the revert-resize server test is failing. It appears that revert_resize() does not take shared storage into account and deletes the orignal volume, which causes the start of the original instance to fail. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1399244/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1398999] Re: Block migrate with attached volumes copies volumes to themselves
** Also affects: nova/juno 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/1398999 Title: Block migrate with attached volumes copies volumes to themselves Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) juno series: New Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Triaged Status in libvirt source package in Trusty: Confirmed Status in nova source package in Trusty: Triaged Status in libvirt source package in Utopic: Won't Fix Status in nova source package in Utopic: Won't Fix Status in libvirt source package in Vivid: Confirmed Status in nova source package in Vivid: Triaged Status in libvirt source package in Wily: Fix Released Status in nova source package in Wily: Triaged Bug description: When an instance with attached Cinder volumes is block migrated, the Cinder volumes are block migrated along with it. If they exist on shared storage, then they end up being copied, over the network, from themselves to themselves. At a minimum, this is horribly slow and de- sparses a sparse volume; at worst, this could cause massive data corruption. More details at http://lists.openstack.org/pipermail/openstack- dev/2014-June/038152.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1398999/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1383465] Re: [pci-passthrough] nova-compute fails to start
*** This bug is a duplicate of bug 1415768 ***
https://bugs.launchpad.net/bugs/1415768
** Also affects: nova/juno
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/1383465
Title:
[pci-passthrough] nova-compute fails to start
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Compute (nova) juno series:
New
Bug description:
Created a guest using nova with a passthrough device, shutdown that
guest, and disabled nova-compute (openstack-service stop). Went to
turn things back on, and nova-compute fails to start.
The trace:
2014-10-20 16:06:45.734 48553 ERROR nova.openstack.common.threadgroup [-] PCI
device request ({'requests':
[InstancePCIRequest(alias_name='rook',count=2,is_new=False,request_id=None,spec=[{product_id='10fb',vendor_id='8086'}])],
'code': 500}equests)s failed
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
Traceback (most recent call last):
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/nova/openstack/common/threadgroup.py", line
125, in wait
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
x.wait()
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/nova/openstack/common/threadgroup.py", line
47, in wait
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
return self.thread.wait()
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/eventlet/greenthread.py", line 173, in wait
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
return self._exit_event.wait()
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/eventlet/event.py", line 121, in wait
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
return hubs.get_hub().switch()
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 293, in switch
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
return self.greenlet.switch()
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/eventlet/greenthread.py", line 212, in main
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
result = function(*args, **kwargs)
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/nova/openstack/common/service.py", line 492,
in run_service
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
service.start()
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/nova/service.py", line 181, in start
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
self.manager.pre_start_hook()
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1152, in
pre_start_hook
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
self.update_available_resource(nova.context.get_admin_context())
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5949, in
update_available_resource
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
rt.update_available_resource(context)
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py", line 332,
in update_available_resource
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
return self._update_available_resource(context, resources)
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/nova/openstack/common/lockutils.py", line
272, in inner
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
return f(*args, **kwargs)
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py", line 349,
in _update_available_resource
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup
self._update_usage_from_instances(context, resources, instances)
2014-10-20 16:06:45.734 48553 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py", line 708,
in _update_usage_from_instances
2014-10-20 16:06:45.734 48553 TRACE nova.op
[Yahoo-eng-team] [Bug 1379212] Re: Attaching volume to iso instance is failure because of duplicate device name 'hda'.
** Also affects: nova/juno 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/1379212 Title: Attaching volume to iso instance is failure because of duplicate device name 'hda'. Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: I try to attach a volume to iso instance, return code of volume-attach api is 200 ok, but the volume can't be attached to instance in fact, there are some error messages in nova-compute.log like this 'libvirtError: Requested operation is not valid: target hda already exists'. The root device of iso instance is hda, nova-compute should not assign hda to cinder volume again. The following is reproduce steps: 1. boot instance from iso image. 2. create a cinder volume. 3. try to attach the volume to iso instance. Attaching volume is failed, I can find libvirt error in nova- compute.log. http://paste.openstack.org/show/105144/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1379212/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1383345] Re: PCI-Passthrough : TypeError: pop() takes at most 1 argument (2 given
** Also affects: nova/juno
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/1383345
Title:
PCI-Passthrough : TypeError: pop() takes at most 1 argument (2 given
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Compute (nova) juno series:
New
Bug description:
Setting the below causes nova to fail.
# White list of PCI devices available to VMs. For example:
# pci_passthrough_whitelist = [{"vendor_id": "8086",
# "product_id": "0443"}] (multi valued)
#pci_passthrough_whitelist=
pci_passthrough_whitelist=[{"vendor_id":"8086","product_id":"10fb"}]
Fails with :
CRITICAL nova [-] TypeError: pop() takes at most 1 argument (2 given)
2014-10-17 15:28:59.968 7153 CRITICAL nova [-] TypeError: pop() takes at most
1 argument (2 given)
2014-10-17 15:28:59.968 7153 TRACE nova Traceback (most recent call last):
2014-10-17 15:28:59.968 7153 TRACE nova File "/usr/bin/nova-compute", line
10, in
2014-10-17 15:28:59.968 7153 TRACE nova sys.exit(main())
2014-10-17 15:28:59.968 7153 TRACE nova File
"/usr/lib/python2.7/site-packages/nova/cmd/compute.py", line 72, in main
2014-10-17 15:28:59.968 7153 TRACE nova
db_allowed=CONF.conductor.use_local)
2014-10-17 15:28:59.968 7153 TRACE nova File
"/usr/lib/python2.7/site-packages/nova/service.py", line 275, in create
2014-10-17 15:28:59.968 7153 TRACE nova db_allowed=db_allowed)
2014-10-17 15:28:59.968 7153 TRACE nova File
"/usr/lib/python2.7/site-packages/nova/service.py", line 148, in __init__
2014-10-17 15:28:59.968 7153 TRACE nova self.manager =
manager_class(host=self.host, *args, **kwargs)
2014-10-17 15:28:59.968 7153 TRACE nova File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 631, in
__init__
2014-10-17 15:28:59.968 7153 TRACE nova self.driver =
driver.load_compute_driver(self.virtapi, compute_driver)
2014-10-17 15:28:59.968 7153 TRACE nova File
"/usr/lib/python2.7/site-packages/nova/virt/driver.py", line 1402, in
load_compute_driver
2014-10-17 15:28:59.968 7153 TRACE nova virtapi)
2014-10-17 15:28:59.968 7153 TRACE nova File
"/usr/lib/python2.7/site-packages/nova/openstack/common/importutils.py", line
50, in import_object_ns
2014-10-17 15:28:59.968 7153 TRACE nova return
import_class(import_value)(*args, **kwargs)
2014-10-17 15:28:59.968 7153 TRACE nova File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 405, in
__init__
2014-10-17 15:28:59.968 7153 TRACE nova self.dev_filter =
pci_whitelist.get_pci_devices_filter()
2014-10-17 15:28:59.968 7153 TRACE nova File
"/usr/lib/python2.7/site-packages/nova/pci/pci_whitelist.py", line 88, in
get_pci_devices_filter
2014-10-17 15:28:59.968 7153 TRACE nova return
PciHostDevicesWhiteList(CONF.pci_passthrough_whitelist)
2014-10-17 15:28:59.968 7153 TRACE nova File
"/usr/lib/python2.7/site-packages/nova/pci/pci_whitelist.py", line 68, in
__init__
2014-10-17 15:28:59.968 7153 TRACE nova self.specs =
self._parse_white_list_from_config(whitelist_spec)
2014-10-17 15:28:59.968 7153 TRACE nova File
"/usr/lib/python2.7/site-packages/nova/pci/pci_whitelist.py", line 49, in
_parse_white_list_from_config
2014-10-17 15:28:59.968 7153 TRACE nova spec =
pci_devspec.PciDeviceSpec(jsonspec)
2014-10-17 15:28:59.968 7153 TRACE nova File
"/usr/lib/python2.7/site-packages/nova/pci/pci_devspec.py", line 132, in
__init__
2014-10-17 15:28:59.968 7153 TRACE nova self._init_dev_details()
2014-10-17 15:28:59.968 7153 TRACE nova File
"/usr/lib/python2.7/site-packages/nova/pci/pci_devspec.py", line 137, in
_init_dev_details
2014-10-17 15:28:59.968 7153 TRACE nova self.vendor_id =
details.pop("vendor_id", ANY)
Changing the config to:
pci_passthrough_whitelist={"vendor_id":"8086","product_id":"10fb"}
Fixes the above.
In Icehouse, PCI Passthrough worked with passing a list, in Juno it is
broken.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1383345/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1378132] Re: Hard-reboots ignore root_device_name
** Also affects: nova/juno 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/1378132 Title: Hard-reboots ignore root_device_name Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: Hard-rebooting an instance causes the root_device_name to get ignored/reset, which can cause wailing and gnashing of teeth if the guest operating system is expecting it to not do that. Steps to reproduce: 1. Stand up a devstack 2. Load the openrc with admin credentials 3. glance image-update --property root_device_name=sda SOME_CIRROS_IMAGE 4. Spawn a cirros instance using the above image. The root filesystem should present as being mounted on /dev/sda1, and the libvirt.xml should show the disk with a target of "scsi" 5. Hard-reboot the instance Expected Behaviour The instance comes back up with the same hardware configuration as it had when initially spawned, i.e., with its root filesystem attached to a SCSI bus Actual Behaviour The instance comes back with its root filesystem attached to an IDE bus. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1378132/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1376586] Re: pre_live_migration is missing some disk information in case of block migration
** Also affects: nova/juno 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/1376586 Title: pre_live_migration is missing some disk information in case of block migration Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: The pre_live_migration API is called with a disk retrieved by a call to driver.get_instance_disk_info when doing a block migration. Unfortunately block device information is not passed, so Nova is calling LibvirtDriver._create_images_and_backing with partial disk_info. As a result, for example when migrating a volume with a NFS volume attached, a useless file is created in the instance directory. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1376586/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1367189] Re: multipath not working with Storwize backend if CHAP enabled
** Also affects: nova/juno 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/1367189 Title: multipath not working with Storwize backend if CHAP enabled Status in Cinder: Fix Released Status in Cinder juno series: New Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Status in os-brick: Fix Released Bug description: if I try to attach a volume to a VM while having multipath enabled in nova and CHAP enabled in the storwize backend, it fails: 2014-09-09 11:37:14.038 22944 ERROR nova.virt.block_device [req-f271874a-9720-4779-96a8-01575641a939 a315717e20174b10a39db36b722325d6 76d25b1928e7407392a69735a894c7fc] [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] Driver failed to attach volume c460f8b7-0f1d-4657-bdf7-e142ad34a132 at /dev/vdb 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] Traceback (most recent call last): 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/virt/block_device.py", line 239, in attach 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] device_type=self['device_type'], encryption=encryption) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 1235, in attach_volume 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] disk_info) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 1194, in volume_driver_method 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] return method(connection_info, *args, **kwargs) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/openstack/common/lockutils.py", line 249, in inner 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] return f(*args, **kwargs) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py", line 280, in connect_volume 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] check_exit_code=[0, 255])[0] \ 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py", line 579, in _run_iscsiadm_bare 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] check_exit_code=check_exit_code) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/utils.py", line 165, in execute 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] return processutils.execute(*cmd, **kwargs) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] File "/usr/lib/python2.7/dist-packages/nova/openstack/common/processutils.py", line 193, in execute 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] cmd=' '.join(cmd)) 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] ProcessExecutionError: Unexpected error while running command. 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] Command: sudo nova-rootwrap /etc/nova/rootwrap.conf iscsiadm -m discovery -t sendtargets -p 192.168.1.252:3260 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] Exit code: 5 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] Stdout: '' 2014-09-09 11:37:14.038 22944 TRACE nova.virt.block_device [instance: 108a81d0-eeb5-49a8-b3eb-e593f44bf897] Stderr: 'iscsiadm: Connection to Discovery Address 192.168.1.252 closed\niscsiadm: Login I/O error, failed to receive a PDU\niscsiadm: retrying discovery login to 192.168.1.252\niscsiadm: Connection to Discovery Address 192.168.1.252 closed\
[Yahoo-eng-team] [Bug 1313573] Re: nova backup fails to backup an instance with attached volume (libvirt, LVM backed)
** Also affects: nova/juno 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/1313573 Title: nova backup fails to backup an instance with attached volume (libvirt, LVM backed) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: Description of problem: An instance has an attached volume, after running the command: # nova backup snapshot An image has been created (type backup) and the status is stuck in 'queued'. Version-Release number of selected component (if applicable): openstack-nova-compute-2013.2.3-6.el6ost.noarch openstack-nova-conductor-2013.2.3-6.el6ost.noarch openstack-nova-novncproxy-2013.2.3-6.el6ost.noarch openstack-nova-scheduler-2013.2.3-6.el6ost.noarch openstack-nova-api-2013.2.3-6.el6ost.noarch openstack-nova-cert-2013.2.3-6.el6ost.noarch python-glance-2013.2.3-2.el6ost.noarch python-glanceclient-0.12.0-2.el6ost.noarch openstack-glance-2013.2.3-2.el6ost.noarch How reproducible: 100% Steps to Reproduce: 1. launch an instance from a volume. 2. backup the instance. Actual results: The backup is stuck in queued state. Expected results: the backup should be available as an image in Glance. Additional info: The nova-compute error & the glance logs are attached. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1313573/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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
** Also affects: nova/juno 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/1296414 Title: quotas not updated when periodic tasks or startup finish deletes Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) juno series: New 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 1305897] Re: Hyper-V driver failing with dynamic memory due to virtual NUMA
** Also affects: nova/juno 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/1305897 Title: Hyper-V driver failing with dynamic memory due to virtual NUMA Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: Starting with Windows Server 2012, Hyper-V provides the Virtual NUMA functionality. This option is enabled by default in the VMs depending on the underlying hardware. However, it's not compatible with dynamic memory. The Hyper-V driver is not aware of this constraint and it's not possible to boot new VMs if the nova.conf parameter 'dynamic_memory_ratio' > 1. The error in the logs looks like the following: 2014-04-09 16:33:43.615 18600 TRACE nova.virt.hyperv.vmops HyperVException: WMI job failed with status 10. Error details: Failed to modify device 'Memory'. 2014-04-09 16:33:43.615 18600 TRACE nova.virt.hyperv.vmops 2014-04-09 16:33:43.615 18600 TRACE nova.virt.hyperv.vmops Dynamic memory and virtual NUMA cannot be enabled on the same virtual machine. - 'instance-0001c90c' failed to modify device 'Memory'. (Virtual machine ID F4CB4E4D-CA06-4149-9FA3-CAD2E0C6CEDA) 2014-04-09 16:33:43.615 18600 TRACE nova.virt.hyperv.vmops 2014-04-09 16:33:43.615 18600 TRACE nova.virt.hyperv.vmops Dynamic memory and virtual NUMA cannot be enabled on the virtual machine 'instance-0001c90c' because the features are mutually exclusive. (Virtual machine ID F4CB4E4D-CA06-4149-9FA3-CAD2E0C6CEDA) - Error code: 32773 In order to solve this problem, it's required to change the field 'VirtualNumaEnabled' in 'Msvm_VirtualSystemSettingData' (option available only in v2 namespace) while creating the VM when dynamic memory is used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1305897/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1327218] Re: Volume detach failure because of invalid bdm.connection_info
** Also affects: nova/juno 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/1327218 Title: Volume detach failure because of invalid bdm.connection_info Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Status in nova package in Ubuntu: Fix Released Status in nova source package in Trusty: Confirmed Bug description: Example of this here: http://logs.openstack.org/33/97233/1/check/check-grenade- dsvm/f7b8a11/logs/old/screen-n-cpu.txt.gz?level=TRACE#_2014-06-02_14_13_51_125 File "/opt/stack/old/nova/nova/compute/manager.py", line 4153, in _detach_volume connection_info = jsonutils.loads(bdm.connection_info) File "/opt/stack/old/nova/nova/openstack/common/jsonutils.py", line 164, in loads return json.loads(s) File "/usr/lib/python2.7/json/__init__.py", line 326, in loads return _default_decoder.decode(s) File "/usr/lib/python2.7/json/decoder.py", line 366, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) TypeError: expected string or buffer and this was in grenade with stable/icehouse nova commit 7431cb9 There's nothing unusual about the test which triggers this - simply attaches a volume to an instance, waits for it to show up in the instance and then tries to detach it logstash query for this: message:"Exception during message handling" AND message:"expected string or buffer" AND message:"connection_info = jsonutils.loads(bdm.connection_info)" AND tags:"screen-n-cpu.txt" but it seems to be very rare To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1327218/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1288039] Re: live-migration cinder boot volume target_lun id incorrect
** Also affects: nova/juno
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/1288039
Title:
live-migration cinder boot volume target_lun id incorrect
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:
When nova goes to cleanup _post_live_migration on the source host, the
block_device_mapping has incorrect data.
I can reproduce this 100% of the time with a cinder iSCSI backend,
such as 3PAR.
This is a Fresh install on 2 new servers with no attached storage from Cinder
and no VMs.
I create a cinder volume from an image.
I create a VM booted from that Cinder volume. That vm shows up on host1 with
a LUN id of 0.
I live migrate that vm. The vm moves to host 2 and has a LUN id of 0. The
LUN on host1 is now gone.
I create another cinder volume from image.
I create another VM booted from the 2nd cinder volume. The vm shows up on
host1 with a LUN id of 0.
I live migrate that vm. The VM moves to host 2 and has a LUN id of 1.
_post_live_migrate is called on host1 to clean up, and gets failures, because
it's asking cinder to delete the volume
on host1 with a target_lun id of 1, which doesn't exist. It's supposed to be
asking cinder to detach LUN 0.
First migrate
HOST2
2014-03-04 19:02:07.870 WARNING nova.compute.manager
[req-24521cb1-8719-4bc5-b488-73a4980d7110 admin admin] pre_live_migrate:
{'block_device_mapping': [{'guest_format': None, 'boot_index': 0,
'mount_device': u'vda', 'connection_info': {u'd
river_volume_type': u'iscsi', 'serial':
u'83fb6f13-905e-45f8-a465-508cb343b721', u'data': {u'target_discovered': True,
u'qos_specs': None, u'target_iqn':
u'iqn.2000-05.com.3pardata:20810002ac00383d', u'target_portal':
u'10.10.120.253:3260'
, u'target_lun': 0, u'access_mode': u'rw'}}, 'disk_bus': u'virtio',
'device_type': u'disk', 'delete_on_termination': False}]}
HOST1
2014-03-04 19:02:16.775 WARNING nova.compute.manager [-]
_post_live_migration: block_device_info {'block_device_mapping':
[{'guest_format': None, 'boot_index': 0, 'mount_device': u'vda',
'connection_info': {u'driver_volume_type': u'iscsi',
u'serial': u'83fb6f13-905e-45f8-a465-508cb343b721', u'data':
{u'target_discovered': True, u'qos_specs': None, u'target_iqn':
u'iqn.2000-05.com.3pardata:20810002ac00383d', u'target_portal':
u'10.10.120.253:3260', u'target_lun': 0, u'access_mode': u'rw'}}, 'disk_bus':
u'virtio', 'device_type': u'disk', 'delete_on_termination': False}]}
Second Migration
This is in _post_live_migration on the host1. It calls libvirt's driver.py
post_live_migration with the volume information returned from the new volume on
host2, hence the target_lun = 1. It should be calling libvirt's driver.py to
clean up the original volume on the source host, which has a target_lun = 0.
2014-03-04 19:24:51.626 WARNING nova.compute.manager [-]
_post_live_migration: block_device_info {'block_device_mapping':
[{'guest_format': None, 'boot_index': 0, 'mount_device': u'vda',
'connection_info': {u'driver_volume_type': u'iscsi', u'serial':
u'f0087595-804d-4bdb-9bad-0da2166313ea', u'data': {u'target_discovered': True,
u'qos_specs': None, u'target_iqn':
u'iqn.2000-05.com.3pardata:20810002ac00383d', u'target_portal':
u'10.10.120.253:3260', u'target_lun': 1, u'access_mode': u'rw'}}, 'disk_bus':
u'virtio', 'device_type': u'disk', 'delete_on_termination': False}]}
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1288039/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1293480] Re: Reboot host didn't restart instances due to libvirt lifecycle event change instance's power_stat as shutdown
** Also affects: nova/juno 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/1293480 Title: Reboot host didn't restart instances due to libvirt lifecycle event change instance's power_stat as shutdown Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Bug description: 1. Libvirt driver can receive libvirt lifecycle events(registered in https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1004), then handle it in https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L969 , that means shutdown a domain will send out shutdown lifecycle event and nova compute will try to sync the instance's power_state. 2. When reboot compute service , compute service is trying to reboot instance which were running before reboot. https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L911. Compute service only checks the power_state in database. the value of power_state can be changed in 3. That leads out reboot host, some instances which were running before reboot can't be restarted. 3. When reboot the host, the code path like 1)libvirt-guests will shutdown all the domain, 2)then sendout lifecycle event , 3)nova compute receive it and 4)save power_state 'shutoff' in db , 5)then try to stop it. Compute service may be killed in any step, In my test enviroment, two running instances , only one instance was restarted succefully. another was set power_state with 'shutoff', task_state with 'power off' in step 4) . So it can't pass the check in https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L911. won't be restarted. Not sure this is a bug , wonder if there is solution for this . To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1293480/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1516226] [NEW] Keystone V2 User API can access users outside of the default domain
Public bug reported: The Keystone V2 API is not mean to be able to "see" any user, groups or projects outside of the default domain. APIs that list these entities are careful to filter out any that are in non-default-domains. However, if you know your entity ID we don't prevent you from doing direct lookup - i.e.. Get /users/ will work via the V2 API even if the user is out side of the default domain. The same is true for projects. Since the V2 API does not have the concept of groups, there is no issue in that case. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1516226 Title: Keystone V2 User API can access users outside of the default domain Status in OpenStack Identity (keystone): New Bug description: The Keystone V2 API is not mean to be able to "see" any user, groups or projects outside of the default domain. APIs that list these entities are careful to filter out any that are in non-default- domains. However, if you know your entity ID we don't prevent you from doing direct lookup - i.e.. Get /users/ will work via the V2 API even if the user is out side of the default domain. The same is true for projects. Since the V2 API does not have the concept of groups, there is no issue in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1516226/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1323658] Re: Nova resize/restart results in guest ending up in inconsistent state with Neutron
Retested this with latest devstack configuration. Based on description from other bug (duplicate of this: https://bugs.launchpad.net/nova/+bug/1364588) I'm not able to reproduce this problem. Resized about 20 times on running and disabled servers. All the time, everything is OK. There are no problems with "ERROR" state or losing connectivity. Logstash doesn't show any similar problems with this issue. Closing as works-for-me, fix probably was already released. If anyone has another experiences, please reopen with additional info. ** Changed in: neutron Status: Confirmed => Fix Released ** Changed in: nova Assignee: (unassigned) => Dariusz Smigiel (smigiel-dariusz) ** Changed in: nova Status: Confirmed => 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/1323658 Title: Nova resize/restart results in guest ending up in inconsistent state with Neutron Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Bug description: Was looking at this when investigating bug 1310852, so that might be a duplicate of this, but the "Public network connectivity check failed" message doesn't show up in the logs for that bug, so opening a new one. This is also maybe related to or regressions of bug 1194026 and/or bug 1253896. The error in the console log: 2014-05-27 13:34:49.707 | 2014-05-27 13:33:24,369 Creating ssh connection to '172.24.4.110' as 'cirros' with public key authentication 2014-05-27 13:34:49.707 | 2014-05-27 13:33:24,491 Failed to establish authenticated ssh connection to cirros@172.24.4.110 ([Errno 111] Connection refused). Number attempts: 1. Retry after 2 seconds. 2014-05-27 13:34:49.707 | 2014-05-27 13:33:27,162 Failed to establish authenticated ssh connection to cirros@172.24.4.110 ([Errno 111] Connection refused). Number attempts: 2. Retry after 3 seconds. 2014-05-27 13:34:49.707 | 2014-05-27 13:33:32,049 starting thread (client mode): 0x9e9cf10L 2014-05-27 13:34:49.707 | 2014-05-27 13:33:32,050 EOF in transport thread 2014-05-27 13:34:49.707 | 2014-05-27 13:33:32,051 Public network connectivity check failed 2014-05-27 13:34:49.707 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops Traceback (most recent call last): 2014-05-27 13:34:49.707 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops File "tempest/scenario/test_network_advanced_server_ops.py", line 119, in _check_public_network_connectivity 2014-05-27 13:34:49.707 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops should_connect=should_connect) 2014-05-27 13:34:49.708 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops File "tempest/scenario/manager.py", line 779, in _check_vm_connectivity 2014-05-27 13:34:49.708 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops linux_client.validate_authentication() 2014-05-27 13:34:49.708 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops File "tempest/common/utils/linux/remote_client.py", line 53, in validate_authentication 2014-05-27 13:34:49.708 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops self.ssh_client.test_connection_auth() 2014-05-27 13:34:49.708 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops File "tempest/common/ssh.py", line 150, in test_connection_auth 2014-05-27 13:34:49.708 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops connection = self._get_ssh_connection() 2014-05-27 13:34:49.708 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops File "tempest/common/ssh.py", line 75, in _get_ssh_connection 2014-05-27 13:34:49.708 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops timeout=self.channel_timeout, pkey=self.pkey) 2014-05-27 13:34:49.708 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops File "/usr/local/lib/python2.7/dist-packages/paramiko/client.py", line 242, in connect 2014-05-27 13:34:49.709 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops t.start_client() 2014-05-27 13:34:49.709 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops File "/usr/local/lib/python2.7/dist-packages/paramiko/transport.py", line 346, in start_client 2014-05-27 13:34:49.709 | 2014-05-27 13:33:32.051 10354 TRACE tempest.scenario.test_network_advanced_server_ops raise e 2014-05-27 13:34:49.709 | 2
[Yahoo-eng-team] [Bug 1466547] Re: Hyper-V: Cannot add ICMPv6 security group rule
** Also affects: neutron Importance: Undecided Status: New ** Also affects: neutron/juno Importance: Undecided Status: New ** Changed in: neutron Status: New => Invalid ** Changed in: neutron/juno Status: New => Fix Committed ** Changed in: neutron/juno Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1466547 Title: Hyper-V: Cannot add ICMPv6 security group rule Status in networking-hyperv: Fix Committed Status in neutron: Invalid Status in neutron juno series: Fix Committed Bug description: Security Group rules created with ethertype 'IPv6' and protocol 'icmp' cannot be added by the Hyper-V Security Groups Driver, as it cannot add rules with the protocol 'icmpv6'. This can be easily fixed by having the Hyper-V Security Groups Driver create rules with protocol '58' instead. [1] These rules will also have to be stateless, as ICMP rules cannot be stateful on Hyper-V. This bug is causing the test tempest.scenario.test_network_v6.TestGettingAddress.test_slaac_from_os to fail on Hyper-V. [1] http://www.iana.org/assignments/protocol-numbers/protocol- numbers.xhtml Log: http://paste.openstack.org/show/301866/ Security Groups: http://paste.openstack.org/show/301870/ To manage notifications about this bug go to: https://bugs.launchpad.net/networking-hyperv/+bug/1466547/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1423427] Re: tempest baremetal client is creating node with wrong property keys
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: nova
Status: New => Invalid
** Also affects: nova/juno
Importance: Undecided
Status: New
** Changed in: nova/juno
Status: New => Fix Committed
** Changed in: nova/juno
Importance: Undecided => High
** Changed in: nova/juno
Assignee: (unassigned) => Adam Gandelman (gandelman-a)
--
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/1423427
Title:
tempest baremetal client is creating node with wrong property keys
Status in OpenStack Compute (nova):
Invalid
Status in OpenStack Compute (nova) juno series:
Fix Committed
Status in tempest:
Fix Released
Bug description:
A new test has been added to tempest to stress the os-baremetal-nodes
API extension. The test periodically fails in the gate with traceback
in n-api log:
[req-01dcd35b-55f4-4688-ba18-7fe0c6defd52
BaremetalNodesAdminTestJSON-1864409967 BaremetalNodesAdminTestJSON-1481542636]
Caught error: 'cpus'
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack Traceback (most recent
call last):
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/opt/stack/new/nova/nova/api/openstack/__init__.py", line 125, in __call__
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack return
req.get_response(self.application)
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/usr/lib/python2.7/dist-packages/webob/request.py", line 1320, in send
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack application,
catch_exc_info=False)
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/usr/lib/python2.7/dist-packages/webob/request.py", line 1284, in
call_application
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack app_iter =
application(self.environ, start_response)
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/usr/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack return
resp(environ, start_response)
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token.py", line
977, in __call__
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack return
self._call_app(env, start_response)
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token.py", line
902, in _call_app
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack return
self._app(env, _fake_start_response)
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/usr/local/lib/python2.7/dist-packages/routes/middleware.py", line 136, in
__call__
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack response =
self.app(environ, start_response)
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/usr/lib/python2.7/dist-packages/webob/dec.py", line 130, in __call__
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack resp =
self.call_func(req, *args, **self.kwargs)
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/usr/lib/python2.7/dist-packages/webob/dec.py", line 195, in call_func
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack return
self.func(req, *args, **kwargs)
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/opt/stack/new/nova/nova/api/openstack/wsgi.py", line 749, in __call__
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack content_type, body,
accept)
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/opt/stack/new/nova/nova/api/openstack/wsgi.py", line 814, in _process_stack
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack action_result =
self.dispatch(meth, request, action_args)
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/opt/stack/new/nova/nova/api/openstack/wsgi.py", line 904, in dispatch
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack return
method(req=request, **action_args)
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack File
"/opt/stack/new/nova/nova/api/openstack/compute/contrib/baremetal_nodes.py",
line 123, in index
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack 'cpus':
inode.properties['cpus'],
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack KeyError: 'cpus'
2015-02-19 01:37:41.910 2521 TRACE nova.api.openstack
This hits only periodically and only when another tempest baremetal
test is running in parallel to the new test. The other tests
(tempest.api.baremetal.*) create some nodes in Ironic with node
properties that are not the standard resource properties the
nova->ironic proxy expects (from
nova/api/openstack/compute/contrib/baremetal_nodes.py:201):
for inode in ironic_nodes:
node = {'i
[Yahoo-eng-team] [Bug 1385295] [NEW] use_syslog=True does not log to syslog via /dev/log anymore
You have been subscribed to a public bug: python-oslo.log SRU: [Impact] * Nova services not able to write log to syslog [Test Case] * 1. Set use_syslog to True in nova.conf/cinder.conf 2. stop rsyslog service 3. restart nova/cinder services 4. restart rsyslog service 5. Log is not written to syslog after rsyslog is brought up. [Regression Potential] * none Reproduced on: https://github.com/openstack-dev/devstack 514c82030cf04da742d16582a23cc64962fdbda1 /opt/stack/keystone/keystone.egg-info/PKG-INFO:Version: 2015.1.dev95.g20173b1 /opt/stack/heat/heat.egg-info/PKG-INFO:Version: 2015.1.dev213.g8354c98 /opt/stack/glance/glance.egg-info/PKG-INFO:Version: 2015.1.dev88.g6bedcea /opt/stack/cinder/cinder.egg-info/PKG-INFO:Version: 2015.1.dev110.gc105259 How to reproduce: Set use_syslog=True syslog_log_facility=LOG_SYSLOG for Openstack config files and restart processes inside their screens Expected: Openstack logs logged to syslog as well Actual: Nothing goes to syslog ** Affects: oslo.log Importance: High Assignee: John Stanford (jxstanford) Status: Fix Released ** Affects: cinder (Ubuntu) Importance: Medium Status: Invalid ** Affects: nova Importance: Medium Status: Invalid ** Affects: python-oslo.log (Ubuntu) Importance: High Assignee: Liang Chen (cbjchen) Status: In Progress ** Tags: in-stable-kilo patch -- use_syslog=True does not log to syslog via /dev/log anymore https://bugs.launchpad.net/bugs/1385295 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1385295] Re: use_syslog=True does not log to syslog via /dev/log anymore
** Package changed: nova (Ubuntu) => nova ** Also affects: nova/juno Importance: Undecided Status: New ** Changed in: nova/juno Status: New => Fix Committed ** Changed in: nova/juno Importance: Undecided => Medium ** Changed in: nova/juno Assignee: (unassigned) => Pádraig Brady (p-draigbrady) -- 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/1385295 Title: use_syslog=True does not log to syslog via /dev/log anymore Status in OpenStack Compute (nova): Invalid Status in OpenStack Compute (nova) juno series: Fix Committed Status in oslo.log: Fix Released Status in cinder package in Ubuntu: Invalid Status in python-oslo.log package in Ubuntu: In Progress Bug description: python-oslo.log SRU: [Impact] * Nova services not able to write log to syslog [Test Case] * 1. Set use_syslog to True in nova.conf/cinder.conf 2. stop rsyslog service 3. restart nova/cinder services 4. restart rsyslog service 5. Log is not written to syslog after rsyslog is brought up. [Regression Potential] * none Reproduced on: https://github.com/openstack-dev/devstack 514c82030cf04da742d16582a23cc64962fdbda1 /opt/stack/keystone/keystone.egg-info/PKG-INFO:Version: 2015.1.dev95.g20173b1 /opt/stack/heat/heat.egg-info/PKG-INFO:Version: 2015.1.dev213.g8354c98 /opt/stack/glance/glance.egg-info/PKG-INFO:Version: 2015.1.dev88.g6bedcea /opt/stack/cinder/cinder.egg-info/PKG-INFO:Version: 2015.1.dev110.gc105259 How to reproduce: Set use_syslog=True syslog_log_facility=LOG_SYSLOG for Openstack config files and restart processes inside their screens Expected: Openstack logs logged to syslog as well Actual: Nothing goes to syslog To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1385295/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1361211] Re: Hyper-V agent does not add new VLAN ids to the external port's trunked list on Hyper-V 2008 R2
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Invalid ** Also affects: neutron/juno Importance: Undecided Status: New ** Changed in: neutron/juno Status: New => Fix Committed ** Changed in: neutron/juno Importance: Undecided => Medium ** Changed in: neutron/juno Assignee: (unassigned) => Claudiu Belu (cbelu) ** Tags removed: in-stable-juno -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1361211 Title: Hyper-V agent does not add new VLAN ids to the external port's trunked list on Hyper-V 2008 R2 Status in networking-hyperv: Fix Released Status in neutron: Invalid Status in neutron juno series: Fix Committed Bug description: This issue affects Hyper-V 2008 R2 and does not affect Hyper-V 2012 and above. The Hyper-V agent is correctly setting the VLAN ID and access mode settings on the vmswitch ports associated with a VM, but not on the trunked list associated with an external port. This is a required configuration. A workaround consists in setting the external port trunked list to contain all possible VLAN ids expected to be used in neutron's network configuration as provided by the following script: https://github.com/cloudbase/devstack-hyperv- incubator/blob/master/trunked_vlans_workaround_2008r2.ps1 To manage notifications about this bug go to: https://bugs.launchpad.net/networking-hyperv/+bug/1361211/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1374108] Re: Hyper-V agent cannot disconnect orphaned switch ports
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Invalid ** Also affects: neutron/juno Importance: Undecided Status: New ** Changed in: neutron/juno Status: New => Fix Committed ** Changed in: neutron/juno Importance: Undecided => Low ** Changed in: neutron/juno Assignee: (unassigned) => Claudiu Belu (cbelu) ** Tags removed: in-stable-juno -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1374108 Title: Hyper-V agent cannot disconnect orphaned switch ports Status in networking-hyperv: Fix Released Status in neutron: Invalid Status in neutron juno series: Fix Committed Bug description: On Windows / Hyper-V Server 2008 R2, when a switch port have to be disconnected because the VM using it was removed, DisconnectSwitchPort will fail, returning an error code and a HyperVException is raised. If the exception is raised, the switch port is not removed and will make the WMI operations more expensive. If the VM's VNIC has been removed, disconnecting the switch port is no longer necessary and it should be removed. Trace: http://paste.openstack.org/show/115297/ To manage notifications about this bug go to: https://bugs.launchpad.net/networking-hyperv/+bug/1374108/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1471050] Re: VLANs are not configured on VM migration
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Invalid ** Also affects: neutron/juno Importance: Undecided Status: New ** Changed in: neutron/juno Status: New => Fix Committed ** Changed in: neutron/juno Assignee: (unassigned) => Shashank Hegde (hegde-shashank) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1471050 Title: VLANs are not configured on VM migration Status in networking-arista: New Status in neutron: Invalid Status in neutron juno series: Fix Committed Bug description: Whenever a VM migrates from one compute node to the other, the VLAN is not provisioned on the new compute node. The correct behaviour should be to remove the VLAN on the interface on the old switch interface and provision the VLAN on the new switch interface. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-arista/+bug/1471050/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1462973] Re: Network gateway flat connection fail because of None tenant_id
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Invalid ** Also affects: neutron/juno Importance: Undecided Status: New ** Changed in: neutron/juno Status: New => Fix Committed ** Changed in: neutron/juno Assignee: (unassigned) => Salvatore Orlando (salvatore-orlando) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1462973 Title: Network gateway flat connection fail because of None tenant_id Status in neutron: Invalid Status in neutron juno series: Fix Committed Status in vmware-nsx: Fix Committed Bug description: The NSX-mh backend does not accept "None" values for tags. Tags are applied to all NSX-mh ports. In particular there is always a tag with the neutron tenant_id (q_tenant_id) _get_tenant_id_for_create now in admin context returns the tenant_id of the resource being created, if there is one. Otherwise still returns context.tenant_id. The default L2 gateway unfortunately does not have a tenant_id, but has the tenant_id attribute in its data structure. This means that _get_tenant_id_for_create will return None, and NSX-mh will reject the request. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1462973/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1462974] Re: Network gateway vlan connection fails because of int conversion
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Status: New => Invalid ** Also affects: neutron/juno Importance: Undecided Status: New ** Changed in: neutron/juno Importance: Undecided => High ** Changed in: neutron/juno Assignee: (unassigned) => Salvatore Orlando (salvatore-orlando) ** Changed in: neutron/juno Status: New => Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1462974 Title: Network gateway vlan connection fails because of int conversion Status in neutron: Invalid Status in neutron juno series: Fix Committed Status in vmware-nsx: Fix Committed Bug description: So far there has been an implicit assumption that segmentation_id would be an integer. In fact, it is a string value, which was been passed down to NSX. This means that passing a string value, like "xyz", rather than a validation error would have triggered a backend error. Moreover, the check for validity of the VLAN tag is now in the form min < tag < max, and this does not work unless tag is converted to integer. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1462974/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1470443] Re: ICMP rules not getting deleted on the hyperv network adapter extended acl set
** Also affects: neutron
Importance: Undecided
Status: New
** Changed in: neutron
Status: New => Invalid
** Also affects: neutron/juno
Importance: Undecided
Status: New
** Changed in: neutron/juno
Status: New => Fix Committed
** Changed in: neutron/juno
Assignee: (unassigned) => Krishna Kanth (krishna-kanth-mallela)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1470443
Title:
ICMP rules not getting deleted on the hyperv network adapter extended
acl set
Status in networking-hyperv:
Fix Committed
Status in neutron:
Invalid
Status in neutron juno series:
Fix Committed
Bug description:
1. Create a security group with icmp rule
2. spawn a vm with the above secuirty-grop-rule
3. ping works from dhcp namespace
4. delete the rule from secuirty-group which will trigger the port-update
5. however the rule is still there on compute for the vm even after
port-update
rootcause: icmp rule is created with locacal port as empty('').
however during remove_security_rule the rule is matched for port "ANY" which
does not match any rule, hence rule not deleted.
solution: introduce the check to match empty loalport incase of deleting icmp
rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-hyperv/+bug/1470443/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
