[Yahoo-eng-team] [Bug 1895976] Re: Fail to get http openstack metadata if the Linux instance runs on Hyper-V
** Also affects: os-win Importance: Undecided Status: New ** Also affects: nova Importance: Undecided Status: New ** Also affects: compute-hyperv Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1895976 Title: Fail to get http openstack metadata if the Linux instance runs on Hyper-V Status in cloud-init: Incomplete Status in compute-hyperv: New Status in OpenStack Compute (nova): New Status in os-win: New Bug description: Because of the commit that introduced platform checks for enabling / using http openstack metadata (https://github.com/canonical/cloud- init/commit/1efa8a0a030794cec68197100f31a856d0d264ab), cloud-init on Linux machines will stop loading http metadata when running on "unsupported" platforms / hypervisors like Hyper-V, XEN, OracleCloud, VMware, OpenTelekomCloud - leading to a whole suite of bug reports and fixes to a non-issue. Let's try to solve this problem once for all the upcoming platforms / hypervisors by adding a configuration option on the metadata level: perform_platform_check or check_if_platform_is_supported (suggestions are welcome for the naming). The value of the config option should be true in order to maintain backwards compatibility. When set to true, cloud-init will check if the platform is supported. No one would like to patch well-working OpenStack environments for this kind of issues and it is always easier to control / build the images you use on private OpenStack. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1895976/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1775382] [NEW] neutron-openvswitch-agent cannot start on Windows
Public bug reported: Currently, the neutron-openvswitch-agent cannot start on Windows [1] due to various Linux-centric modules being imported on Windows. This issue only affects master. [1] http://paste.openstack.org/show/722788/ ** Affects: neutron Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1775382 Title: neutron-openvswitch-agent cannot start on Windows Status in neutron: In Progress Bug description: Currently, the neutron-openvswitch-agent cannot start on Windows [1] due to various Linux-centric modules being imported on Windows. This issue only affects master. [1] http://paste.openstack.org/show/722788/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1775382/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1761748] Re: hyperv: Unable to get ports details for devices: AttributeError: 'NoneType' object has no attribute 'startswith'
** Also affects: networking-hyperv
Importance: Undecided
Status: New
** Changed in: networking-hyperv
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/1761748
Title:
hyperv: Unable to get ports details for devices: AttributeError:
'NoneType' object has no attribute 'startswith'
Status in networking-hyperv:
New
Status in neutron:
New
Bug description:
In a failed hyperv CI run I'm seeing this in the hyperv agent logs:
http://cloudbase-ci.com/nova/324720/5/Hyper-
V_logs/192.168.3.143-compute01/neutron-hyperv-agent.log.gz
2018-04-06 02:43:29.230 588 91983184 MainThread INFO
networking_hyperv.neutron.agent.layer2 [-] Hyper-V VM vNIC added:
5d31e08c-957c-45a5-a13d-fa114ea68b56
2018-04-06 02:43:29.230 588 91983184 MainThread INFO
networking_hyperv.neutron.agent.layer2 [-] Hyper-V VM vNIC added: None
2018-04-06 02:43:29.246 588 91983184 MainThread INFO
networking_hyperv.neutron.agent.layer2 [-] Hyper-V VM vNIC added: None
2018-04-06 02:43:29.246 588 91983184 MainThread INFO
networking_hyperv.neutron.agent.layer2 [-] Hyper-V VM vNIC added: None
2018-04-06 02:43:29.262 588 91983184 MainThread INFO
networking_hyperv.neutron.agent.layer2 [-] Hyper-V VM vNIC added: None
2018-04-06 02:43:30.496 588 35292864 MainThread DEBUG
networking_hyperv.neutron.agent.layer2
[req-1c72ef49-f85f-4776-8219-ac410b3a00e6 - - - - -] Agent loop has new
devices! _work
c:\openstack\build\networking-hyperv\networking_hyperv\neutron\agent\layer2.py:427
2018-04-06 02:43:30.526 588 35292864 MainThread DEBUG
networking_hyperv.neutron.agent.layer2
[req-1c72ef49-f85f-4776-8219-ac410b3a00e6 - - - - -] Unable to get ports
details for devices set([u'5d31e08c-957c-45a5-a13d-fa114ea68b56', None]):
'NoneType' object has no attribute 'startswith'
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py",
line 163, in _process_incoming
res = self.dispatcher.dispatch(message)
File
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line
220, in dispatch
return self._do_dispatch(endpoint, method, ctxt, args)
File
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line
190, in _do_dispatch
result = func(ctxt, **new_args)
File "/opt/stack/neutron/neutron/plugins/ml2/rpc.py", line 157, in
get_devices_details_list
for device in kwargs.pop('devices', [])
File "/opt/stack/neutron/neutron/plugins/ml2/rpc.py", line 80, in
get_device_details
port_id = plugin._device_to_port_id(rpc_context, device)
File "/opt/stack/neutron/neutron/plugins/ml2/plugin.py", line 1864, in
_device_to_port_id
if device.startswith(prefix):
AttributeError: 'NoneType' object has no attribute 'startswith'
_treat_devices_added
c:\openstack\build\networking-hyperv\networking_hyperv\neutron\agent\layer2.py:360
In this test run, the nova-compute service is also being reported as
down, so the nova-scheduler is filtering it out and all server build
requests fail. I don't know if the two are related, but thta's how I
stumbled onto this error in the hyperv agent logs.
To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-hyperv/+bug/1761748/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1759609] [NEW] VMware: _detach_instance_volumes method fails due to wrong detach_volume call
Public bug reported: The method _detach_instance_volumes [1] calls self.detach_volume [2] with an invalid number of arguments (context argument is missing), causing it to fail. [1] https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/driver.py#L426 [2] https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/driver.py#L438 ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1759609 Title: VMware: _detach_instance_volumes method fails due to wrong detach_volume call Status in OpenStack Compute (nova): In Progress Bug description: The method _detach_instance_volumes [1] calls self.detach_volume [2] with an invalid number of arguments (context argument is missing), causing it to fail. [1] https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/driver.py#L426 [2] https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/driver.py#L438 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1759609/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1749215] [NEW] Allocations not deleted on failed resize
Public bug reported: Description === During a resize, an instance's allocations are removed and replaced by 2 sets of allocations instead. If a resize is completed sucessfully, one set of allocations is correctly removed, but in case of a failure, neither set of allocations is removed. Only one set of allocations are removed if the instance is deleted. This happens because the call self.compute_rpcapi.resize_instance [1] is an RPC cast (async), instead of a call (sync). Because of this, the Except branch [2] in which the allocation is cleared and the instance is rescheduled, is never called. Additionally, because not all of the allocations are cleared, the resources on the compute nodes will become "locked" and unusable. At some point, instances will no longer be scheduled to those compute nodes, due to all the resources being "allocated". [1] https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4085 [2] https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4123 Steps to reproduce == * Spawn an instance. * Observe that the table nova_api.allocations only has 1 set of allocations for the instance (VCPU, MEMORY, DISK). * Cold resize to an invalid flavor (e.g.: smaller disk). * Observe that the table nova_api.allocations has 2 sets of allocations for the instance. * Observe that the cold resize failed, and that the instance's task state has been reverted to its original state. * Observe that the table nova_api.allocations continues to have 2 sets of allocations. * Delete the instance. * Observe even after the instance has been destroyed, there is still 1 set of allocations for the instance. Expected result === After the cold resize failed, there should be only 1 set of allocations in the nova_api.allocations table, and after deleting the instance, there shouldn't be any. Actual result = After the cold resize failed, there are 2 sets of allocations in the nova_api.allocations table, after deleting the instance, there is 1 set of allocations. Environment === Branch: Queens Hypervisor: Hyper-V Server 2012 R2 (unrelated) ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1749215 Title: Allocations not deleted on failed resize Status in OpenStack Compute (nova): New Bug description: Description === During a resize, an instance's allocations are removed and replaced by 2 sets of allocations instead. If a resize is completed sucessfully, one set of allocations is correctly removed, but in case of a failure, neither set of allocations is removed. Only one set of allocations are removed if the instance is deleted. This happens because the call self.compute_rpcapi.resize_instance [1] is an RPC cast (async), instead of a call (sync). Because of this, the Except branch [2] in which the allocation is cleared and the instance is rescheduled, is never called. Additionally, because not all of the allocations are cleared, the resources on the compute nodes will become "locked" and unusable. At some point, instances will no longer be scheduled to those compute nodes, due to all the resources being "allocated". [1] https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4085 [2] https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4123 Steps to reproduce == * Spawn an instance. * Observe that the table nova_api.allocations only has 1 set of allocations for the instance (VCPU, MEMORY, DISK). * Cold resize to an invalid flavor (e.g.: smaller disk). * Observe that the table nova_api.allocations has 2 sets of allocations for the instance. * Observe that the cold resize failed, and that the instance's task state has been reverted to its original state. * Observe that the table nova_api.allocations continues to have 2 sets of allocations. * Delete the instance. * Observe even after the instance has been destroyed, there is still 1 set of allocations for the instance. Expected result === After the cold resize failed, there should be only 1 set of allocations in the nova_api.allocations table, and after deleting the instance, there shouldn't be any. Actual result = After the cold resize failed, there are 2 sets of allocations in the nova_api.allocations table, after deleting the instance, there is 1 set of allocations. Environment === Branch: Queens Hypervisor: Hyper-V Server 2012 R2 (unrelated) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1749215/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe :
[Yahoo-eng-team] [Bug 1735588] Re: Mock autospec not used, or not used properly
** Also affects: compute-hyperv 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/1735588 Title: Mock autospec not used, or not used properly Status in compute-hyperv: New Status in networking-hyperv: Fix Released Status in OpenStack Compute (nova): In Progress Status in os-win: Fix Released Status in oslotest: Fix Released Bug description: Description === In typical unit tests, almost all of the dependencies are mocked or patched (mock.patch), without any guarantee that the mocked methods actually exist, or if their signatures are respected (see below). Because of this, actual issues can easily be overlooked and missed, as the unit tests are wrongfully passing. [0] The mock.Mock class accepts a spec as an argument, which only solves half the problem: it only checks if an attribute exists, based on the given spec. It does not guarantee that the given attribute is actually a method, or if its signature is respected [1][2]. Some unit tests may pass the autospec argument, but mock doesn't support it at the moment. mock.patch, mock.patch.object, mock.patch.multiple accept an autospec argument, but because of a bug [3][4], it cannot be used properly. Steps to reproduce == import mock from mock.tests import testmock m = mock.Mock(spec=testmock.Something) # meth has the following signature: # def meth(self, a, b, c, d=None): m.meth() Expected result === TypeError should be raised. Actual result = A mock object is returned. Proposal Bug reports have been issues for the bugs mentioned above, see [1][2][3][4], but until then, the mock library can be patched to include the following changes: - add autospec argument to mock.Mock and mock.MagicMock. Unit test should then pass the autospec argument whenever possible. - fix the mock.patch autospec issue. - enable mock.patch autospec by default, unless otherwise specified. Links = [0] https://review.openstack.org/#/c/461689/ [1] https://github.com/testing-cabal/mock/issues/393 [2] https://bugs.python.org/issue30587 [3] https://github.com/testing-cabal/mock/issues/396 [4] https://bugs.python.org/issue32092 To manage notifications about this bug go to: https://bugs.launchpad.net/compute-hyperv/+bug/1735588/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1744032] [NEW] Hyper-V: log warning on PortBindingFailed exception
Public bug reported: Description === When spawning an Hyper-V instance with NICs having the vif_type "hyperv", neutron will fail to bind the port to the Hyper-V host if the neutron server doesn't have the "hyperv" mechanism driver installed and configured, resulting in a PortBindingFailed exception on the nova- compute side. When this exception is encountered, the logs will say to check the neutron-server logs, but the problem and its solution are not obvious or clear, resulting in plenty of questions / reports, all having the same solution: install networking-hyperv and configure neutron-server to use the "hyperv" mechanism_driver. Steps to reproduce == 1. Do not configure neutron-server with a "hyperv" mechanism_driver. 2. Spawn an instance having NICs with the vif_type "hyperv". Expected result === PortBindingFailed, and a clear explanation and / or solution for it. After the execution of the steps above, what should have happened if the issue wasn't present? Actual result = PortBindingFailed, telling users to check the neutron-server logs, which doesn't contain the obvious problem / solution. Environment === Hyper-V compute nodes, with neutron-hyperv-agent agent. Any OpenStack version. Logs & Configs == Logs: http://paste.openstack.org/show/646888/ ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v ** Tags added: hyper-v ** Changed in: nova Assignee: (unassigned) => Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1744032 Title: Hyper-V: log warning on PortBindingFailed exception Status in OpenStack Compute (nova): New Bug description: Description === When spawning an Hyper-V instance with NICs having the vif_type "hyperv", neutron will fail to bind the port to the Hyper-V host if the neutron server doesn't have the "hyperv" mechanism driver installed and configured, resulting in a PortBindingFailed exception on the nova-compute side. When this exception is encountered, the logs will say to check the neutron-server logs, but the problem and its solution are not obvious or clear, resulting in plenty of questions / reports, all having the same solution: install networking-hyperv and configure neutron-server to use the "hyperv" mechanism_driver. Steps to reproduce == 1. Do not configure neutron-server with a "hyperv" mechanism_driver. 2. Spawn an instance having NICs with the vif_type "hyperv". Expected result === PortBindingFailed, and a clear explanation and / or solution for it. After the execution of the steps above, what should have happened if the issue wasn't present? Actual result = PortBindingFailed, telling users to check the neutron-server logs, which doesn't contain the obvious problem / solution. Environment === Hyper-V compute nodes, with neutron-hyperv-agent agent. Any OpenStack version. Logs & Configs == Logs: http://paste.openstack.org/show/646888/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1744032/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1735588] [NEW] Mock autospec not used, or not used properly
Public bug reported: Description === In typical unit tests, almost all of the dependencies are mocked or patched (mock.patch), without any guarantee that the mocked methods actually exist, or if their signatures are respected (see below). Because of this, actual issues can easily be overlooked and missed, as the unit tests are wrongfully passing. [0] The mock.Mock class accepts a spec as an argument, which only solves half the problem: it only checks if an attribute exists, based on the given spec. It does not guarantee that the given attribute is actually a method, or if its signature is respected [1][2]. Some unit tests may pass the autospec argument, but mock doesn't support it at the moment. mock.patch, mock.patch.object, mock.patch.multiple accept an autospec argument, but because of a bug [3][4], it cannot be used properly. Steps to reproduce == import mock from mock.tests import testmock m = mock.Mock(spec=testmock.Something) # meth has the following signature: # def meth(self, a, b, c, d=None): m.meth() Expected result === TypeError should be raised. Actual result = A mock object is returned. Proposal Bug reports have been issues for the bugs mentioned above, see [1][2][3][4], but until then, the mock library can be patched to include the following changes: - add autospec argument to mock.Mock and mock.MagicMock. Unit test should then pass the autospec argument whenever possible. - fix the mock.patch autospec issue. - enable mock.patch autospec by default, unless otherwise specified. Links = [0] https://review.openstack.org/#/c/461689/ [1] https://github.com/testing-cabal/mock/issues/393 [2] https://bugs.python.org/issue30587 [3] https://github.com/testing-cabal/mock/issues/396 [4] https://bugs.python.org/issue32092 ** Affects: networking-hyperv Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Affects: os-win Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Affects: oslotest Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: In Progress ** Tags: testing ** Also affects: oslotest Importance: Undecided Status: New ** Also affects: os-win Importance: Undecided Status: New ** Also affects: networking-hyperv Importance: Undecided Status: New ** Changed in: nova Assignee: (unassigned) => Claudiu Belu (cbelu) ** Changed in: networking-hyperv Assignee: (unassigned) => Claudiu Belu (cbelu) ** Changed in: os-win Assignee: (unassigned) => Claudiu Belu (cbelu) ** Changed in: oslotest Assignee: (unassigned) => Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1735588 Title: Mock autospec not used, or not used properly Status in networking-hyperv: New Status in OpenStack Compute (nova): New Status in os-win: New Status in oslotest: In Progress Bug description: Description === In typical unit tests, almost all of the dependencies are mocked or patched (mock.patch), without any guarantee that the mocked methods actually exist, or if their signatures are respected (see below). Because of this, actual issues can easily be overlooked and missed, as the unit tests are wrongfully passing. [0] The mock.Mock class accepts a spec as an argument, which only solves half the problem: it only checks if an attribute exists, based on the given spec. It does not guarantee that the given attribute is actually a method, or if its signature is respected [1][2]. Some unit tests may pass the autospec argument, but mock doesn't support it at the moment. mock.patch, mock.patch.object, mock.patch.multiple accept an autospec argument, but because of a bug [3][4], it cannot be used properly. Steps to reproduce == import mock from mock.tests import testmock m = mock.Mock(spec=testmock.Something) # meth has the following signature: # def meth(self, a, b, c, d=None): m.meth() Expected result === TypeError should be raised. Actual result = A mock object is returned. Proposal Bug reports have been issues for the bugs mentioned above, see [1][2][3][4], but until then, the mock library can be patched to include the following changes: - add autospec argument to mock.Mock and mock.MagicMock. Unit test should then pass the autospec argument whenever possible. - fix the mock.patch autospec issue. - enable mock.patch autospec by default, unless otherwise specified. Links = [0] https://review.openstack.org/#/c/461689/ [1] https://github.com/testing-cabal/mock/iss
[Yahoo-eng-team] [Bug 1717892] [NEW] hyperv: Driver does not report disk_available_least
Public bug reported: Description === The Hyper-V driver does not report the disk_available_least field. Reporting the mentioned field can help mitigate the scheduling issue regarding hosts using the same shared storage. Steps to reproduce == Have a compute node having X GB total storage (reported as local_gb), out of which, just 1 GB is actually free (unreported). The compute node also reports local_gb_used, which is the sum of the allocated nova instances' flavor disk sizes. (local_gb > local_gb_used). Try to spawn an instance with a flavor's disk higher than 1.or disk size of 2 GB on the host. Expected result === Instance should be in ERROR state, it shouldn't be able to schedule to the compute node. Actual result = The instance is active. Environment === OpenStack Pike. Hyper-V 2012 R2 compute node. Logs & Configs == [1] compute node's resource view VS. actual reported resource view: http://paste.openstack.org/show/621318/ [2] compute node's resources (nova hypervisor-show), spawning an instance: http://paste.openstack.org/show/621319/ ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v ocata-backport-potential pike-backport-potential ** Changed in: nova Assignee: (unassigned) => Claudiu Belu (cbelu) ** Tags added: hyper-v ** Tags added: ocata-backport-potential pike-backport-potential -- 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/1717892 Title: hyperv: Driver does not report disk_available_least Status in OpenStack Compute (nova): New Bug description: Description === The Hyper-V driver does not report the disk_available_least field. Reporting the mentioned field can help mitigate the scheduling issue regarding hosts using the same shared storage. Steps to reproduce == Have a compute node having X GB total storage (reported as local_gb), out of which, just 1 GB is actually free (unreported). The compute node also reports local_gb_used, which is the sum of the allocated nova instances' flavor disk sizes. (local_gb > local_gb_used). Try to spawn an instance with a flavor's disk higher than 1.or disk size of 2 GB on the host. Expected result === Instance should be in ERROR state, it shouldn't be able to schedule to the compute node. Actual result = The instance is active. Environment === OpenStack Pike. Hyper-V 2012 R2 compute node. Logs & Configs == [1] compute node's resource view VS. actual reported resource view: http://paste.openstack.org/show/621318/ [2] compute node's resources (nova hypervisor-show), spawning an instance: http://paste.openstack.org/show/621319/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1717892/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1713499] [NEW] Cannot delete a neutron network, if the currently configured MTU is lower than the network's MTU
Public bug reported: Currently, the neutron API returns an error [1] when trying to delete a neutron network which has a higher MTU than the configured MTU[2][3]. This issue has been noticed in Pike. [1] Error: http://paste.openstack.org/show/619627/ [2] neutron.conf: http://paste.openstack.org/show/619629/ [3] ml2_conf.ini: http://paste.openstack.org/show/619630/ ** Affects: neutron Importance: Undecided Status: New ** Description changed: Currently, the neutron API returns an error [1] when trying to delete a neutron network which has a higher MTU than the configured MTU[2][3]. + This issue has been noticed in Pike. [1] Error: http://paste.openstack.org/show/619627/ [2] neutron.conf: http://paste.openstack.org/show/619629/ [3] ml2_conf.ini: http://paste.openstack.org/show/619630/ -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1713499 Title: Cannot delete a neutron network, if the currently configured MTU is lower than the network's MTU Status in neutron: New Bug description: Currently, the neutron API returns an error [1] when trying to delete a neutron network which has a higher MTU than the configured MTU[2][3]. This issue has been noticed in Pike. [1] Error: http://paste.openstack.org/show/619627/ [2] neutron.conf: http://paste.openstack.org/show/619629/ [3] ml2_conf.ini: http://paste.openstack.org/show/619630/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1713499/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1542415] Re: Hyper-V live-migration rollback leaves destination node in inconsistent state
Addressed by: https://review.openstack.org/#/c/478943/ ** Changed in: nova Assignee: (unassigned) => Claudiu Belu (cbelu) ** Changed in: nova Status: Expired => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1542415 Title: Hyper-V live-migration rollback leaves destination node in inconsistent state Status in OpenStack Compute (nova): In Progress Bug description: Roll-back of destination node in case of live-migration failure depends on block-migrate flag that passed by operator. So it's possible to leave destination node in inconsistent state by passing block-migrate flag, over api. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1542415/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1702150] [NEW] Instance sanitization in InstanceMetadata causes metadata_for_config_drive to fail
Public bug reported: A recent patch [1] has merged in nova, which sanitizes the nova instance object, making it picklable. The sanitized instance object no longer has a _context attribute, which means that lazy-loading attributes are no longer loadable [2]. This can be an issue whenever a config drive has to be built for an instance, as InstanceMetadata.metadata_for_config_drive needs some unloaded attributes (device_metadata). This issue has been seen to affect mostly rebuild, unshelve, rescue operations. [1] https://review.openstack.org/#/c/478991/ [2] http://paste.openstack.org/show/614328/ Logs: http://64.119.130.115/nova/479245/1/Hyper- V_logs/c2-r21-u36-n02-compute02/nova-compute.log.gz ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1702150 Title: Instance sanitization in InstanceMetadata causes metadata_for_config_drive to fail Status in OpenStack Compute (nova): New Bug description: A recent patch [1] has merged in nova, which sanitizes the nova instance object, making it picklable. The sanitized instance object no longer has a _context attribute, which means that lazy-loading attributes are no longer loadable [2]. This can be an issue whenever a config drive has to be built for an instance, as InstanceMetadata.metadata_for_config_drive needs some unloaded attributes (device_metadata). This issue has been seen to affect mostly rebuild, unshelve, rescue operations. [1] https://review.openstack.org/#/c/478991/ [2] http://paste.openstack.org/show/614328/ Logs: http://64.119.130.115/nova/479245/1/Hyper- V_logs/c2-r21-u36-n02-compute02/nova-compute.log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1702150/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1701511] [NEW] hyperv: Bad log message formating in livemigrationops
Public bug reported: In nova.virt.hyperv.livemigrationops, in the check_can_live_migrate_source method, the instance is passed as an argument to the logger, instead of as a key-value argument. Because of this, the log message is never printed: [1] [1] http://paste.openstack.org/show/614164/ ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: In Progress ** Tags: hyper-v ** Tags added: hyper-v -- 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/1701511 Title: hyperv: Bad log message formating in livemigrationops Status in OpenStack Compute (nova): In Progress Bug description: In nova.virt.hyperv.livemigrationops, in the check_can_live_migrate_source method, the instance is passed as an argument to the logger, instead of as a key-value argument. Because of this, the log message is never printed: [1] [1] http://paste.openstack.org/show/614164/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1701511/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1604078] Re: Hyper-V: planned vms are not cleaned up
** Also affects: os-win 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/1604078 Title: Hyper-V: planned vms are not cleaned up Status in compute-hyperv: New Status in OpenStack Compute (nova): Incomplete Status in os-win: New Bug description: We create a planned vm during live migration when having passthrough disks attached in order to properly configure the resources of the 'new' instance. The issue is that if the migration fails, this planned vm is not cleaned up. Although planned vms are destroyed at a second attempt to migrate the instance, this issue had an impact on the Hyper-V CI as planned vms persisted among CI runs and vms having the same name failed to spawn, as there were file handles kept open by the VMMS service, preventing the instance path from being cleaned up. Trace: http://paste.openstack.org/show/536149/ To manage notifications about this bug go to: https://bugs.launchpad.net/compute-hyperv/+bug/1604078/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1696685] [NEW] nova-manage cell_v2 simple_cell_setup creates an invalid cell0
Public bug reported: Description === If there are no cells created, nova-manage cell_v2 simple_cell_setup will also create cell0, but it creates it with an invalid database connection string: [1]. Having a database connection string like "mysql+pymysql://root:Passw0rd@127.0.0.1/nova?charset=utf8nova_cell0" will cause the rest of the cell setup to fail, with the following error: [2], as there is no valid charset named "utf8nova_cell0", and the second cell is never created. This issue has been observed in stable/ocata. Steps to reproduce == * Have no cells available (delete them). * run nova-manage cell_v2 simple_cell_setup --transport-url $url Expected result === * cell0 and a second cell to be created. Actual result = * cell0 created with a wrong database connection string. * no second cell. Environment === * devstack, on stable/ocata. * n_cpu service disabled (other nova-compute services are being run other nodes). Logs & Configs == [1] nova-manage: http://paste.openstack.org/show/611813/ [2] simple_cell_setup output(last bits): http://paste.openstack.org/show/611815/ ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1696685 Title: nova-manage cell_v2 simple_cell_setup creates an invalid cell0 Status in OpenStack Compute (nova): New Bug description: Description === If there are no cells created, nova-manage cell_v2 simple_cell_setup will also create cell0, but it creates it with an invalid database connection string: [1]. Having a database connection string like "mysql+pymysql://root:Passw0rd@127.0.0.1/nova?charset=utf8nova_cell0" will cause the rest of the cell setup to fail, with the following error: [2], as there is no valid charset named "utf8nova_cell0", and the second cell is never created. This issue has been observed in stable/ocata. Steps to reproduce == * Have no cells available (delete them). * run nova-manage cell_v2 simple_cell_setup --transport-url $url Expected result === * cell0 and a second cell to be created. Actual result = * cell0 created with a wrong database connection string. * no second cell. Environment === * devstack, on stable/ocata. * n_cpu service disabled (other nova-compute services are being run other nodes). Logs & Configs == [1] nova-manage: http://paste.openstack.org/show/611813/ [2] simple_cell_setup output(last bits): http://paste.openstack.org/show/611815/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1696685/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1694220] [NEW] Neutron agents fail to start on Windows
Public bug reported: The Neutron agents fail to start on Windows, due to an import issue: [1] The issue is caused by neutron.common.utils.import_modules_recursively, which expects the paths to be forwardslash separated, while on Windows they are backslash separated. [2] [1] http://64.119.130.115/nova/441183/10/Hyper-V_logs/c2-r22-u02-n02-compute01/process_error.txt.gz [2] https://github.com/openstack/neutron/blob/master/neutron/common/utils.py#L763 ** Affects: neutron Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1694220 Title: Neutron agents fail to start on Windows Status in neutron: In Progress Bug description: The Neutron agents fail to start on Windows, due to an import issue: [1] The issue is caused by neutron.common.utils.import_modules_recursively, which expects the paths to be forwardslash separated, while on Windows they are backslash separated. [2] [1] http://64.119.130.115/nova/441183/10/Hyper-V_logs/c2-r22-u02-n02-compute01/process_error.txt.gz [2] https://github.com/openstack/neutron/blob/master/neutron/common/utils.py#L763 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1694220/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1555699] Re: Hyper-V: failed cold migrations cannot be reverted
** Changed in: compute-hyperv Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1555699 Title: Hyper-V: failed cold migrations cannot be reverted Status in compute-hyperv: Fix Released Status in OpenStack Compute (nova): Fix Released Bug description: When performing a cold migration, the Hyper-V driver moves the instance files to a temporary folder, and from there, it copies them to the destination node. The instance folder is not moved entirely, as it will hold some Hyper-V specific files that cannot be deleted/moved while the instance exists, basically we just take the files that we care about, while leaving the folder there. If the migration fails, the driver tries to move the temporary directory to the actual instance path, but fails as there already is a folder. Trace: http://paste.openstack.org/show/490025/ To manage notifications about this bug go to: https://bugs.launchpad.net/compute-hyperv/+bug/1555699/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1687570] [NEW] hyperv: boot from volume with Generation 2 VM image fails
Public bug reported: Description === Spawning with boot from volume (created from a Generation 2 VM image) fails on Hyper-V due to [1]. Steps to reproduce == * create a glance image with the "hw_machine_type=hyperv-gen2" property. * create a volume from glance image. * spawn with boot from volume. Expected result === Instance is running. Actual result = Instance is in error state, spawn failed due to [1] Environment === * OpenStack Ocata release * Windows Hyper-V Server 2012 R2 compute nodes [1] Log: http://paste.openstack.org/show/608574/ ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyperv ocata-backport-potential -- 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/1687570 Title: hyperv: boot from volume with Generation 2 VM image fails Status in OpenStack Compute (nova): New Bug description: Description === Spawning with boot from volume (created from a Generation 2 VM image) fails on Hyper-V due to [1]. Steps to reproduce == * create a glance image with the "hw_machine_type=hyperv-gen2" property. * create a volume from glance image. * spawn with boot from volume. Expected result === Instance is running. Actual result = Instance is in error state, spawn failed due to [1] Environment === * OpenStack Ocata release * Windows Hyper-V Server 2012 R2 compute nodes [1] Log: http://paste.openstack.org/show/608574/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1687570/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1666949] [NEW] PCI devices cannot be detached if all the PCI devices are claimed
Public bug reported: Description === PCI devices are requested through flavor extra_specs, and they can de attached / detached by resizing to a flavor having more / fewer PCI devices in the extra_specs. But, if all the PCI devices have been claimed, they cannot be detached anymore as cold resize will fail. Steps to reproduce == * Let's say we have 2 PCI devices whitelisted on a compute node. * Create a flavor which requires both PCI devices. * Create an instance with said flavor. * Resize the instance to a flavor without any PCI devices. Expected result === The instance should be resized, and have no PCI devices attached. Actual result = The instance is in ERROR state, the cold resize failed. Logs & Configs == [1] resize attempt, n-api.log, n-sch.log: http://paste.openstack.org/show/598884/ [2] #openstack-nova discussion: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-02-14.log.html#t2017-02-14T19:45:02 ** Affects: nova Importance: Undecided Status: New ** Tags: pci resize scheduler -- 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/1666949 Title: PCI devices cannot be detached if all the PCI devices are claimed Status in OpenStack Compute (nova): New Bug description: Description === PCI devices are requested through flavor extra_specs, and they can de attached / detached by resizing to a flavor having more / fewer PCI devices in the extra_specs. But, if all the PCI devices have been claimed, they cannot be detached anymore as cold resize will fail. Steps to reproduce == * Let's say we have 2 PCI devices whitelisted on a compute node. * Create a flavor which requires both PCI devices. * Create an instance with said flavor. * Resize the instance to a flavor without any PCI devices. Expected result === The instance should be resized, and have no PCI devices attached. Actual result = The instance is in ERROR state, the cold resize failed. Logs & Configs == [1] resize attempt, n-api.log, n-sch.log: http://paste.openstack.org/show/598884/ [2] #openstack-nova discussion: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-02-14.log.html#t2017-02-14T19:45:02 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1666949/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1663238] [NEW] Hyper-V driver destroys and recreates the VM on cold migration / resize
Public bug reported: Currently, the nova Hyper-V driver destroys the instance on the source node and recreates it on the destination node. This can be an undesired effect for some users, as the guest OS might see different NICs attached (even though the MAC address is the same). This issue can be solved by importing the desired VM on the destination node, and updating the VM resources according to the new flavor. ** Affects: nova Importance: Undecided Status: New ** Affects: os-win Importance: Undecided Status: New ** Tags: hyper-v ** Also affects: nova Importance: Undecided Status: New ** Tags added: hyper-v -- 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/1663238 Title: Hyper-V driver destroys and recreates the VM on cold migration / resize Status in OpenStack Compute (nova): New Status in os-win: New Bug description: Currently, the nova Hyper-V driver destroys the instance on the source node and recreates it on the destination node. This can be an undesired effect for some users, as the guest OS might see different NICs attached (even though the MAC address is the same). This issue can be solved by importing the desired VM on the destination node, and updating the VM resources according to the new flavor. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1663238/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1661326] [NEW] neutron-ovs-agent fails to start on Windows due to Linux-specific imports
Public bug reported: Currently, the neutron-ovs-agent service cannot start on Windows, due to a few Linux-specific imports. [1][2] [1] http://paste.openstack.org/show/597391/ [2] http://paste.openstack.org/show/597392/ ** Affects: neutron Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1661326 Title: neutron-ovs-agent fails to start on Windows due to Linux-specific imports Status in neutron: In Progress Bug description: Currently, the neutron-ovs-agent service cannot start on Windows, due to a few Linux-specific imports. [1][2] [1] http://paste.openstack.org/show/597391/ [2] http://paste.openstack.org/show/597392/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1661326/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1614506] Re: Volume doesn't gets deleted upon instance termination
Hello,
Typically, volumes persist even after the instance they were attached to
is destroyed. I was not aware of delete_on_termination flag. I did some
digging around, and I've noticed that this flag is only mentioned by the
block_device_mapping_v1 api, but not the block_device_mapping_v2, which
you are using [1]. Can you try passing that flag in a
block_device_mapping_v1 request?
Finally, the nova-compute services do not delete volumes, something like
this would be done by the nova-api / nova-conductor services.
[1] http://docs.openstack.org/developer/nova/block_device_mapping.html
Best regards,
Claudiu Belu
** Project changed: compute-hyperv => nova
--
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/1614506
Title:
Volume doesn't gets deleted upon instance termination
Status in OpenStack Compute (nova):
New
Bug description:
Hello!
I have tried to create OpenStack compute instances from an image via
the following API requests (according to the API guide
<http://developer.openstack.org/api-ref-
compute-v2.1.html#createServer>):
---8<---
{
"server" : {
"name" : "test",
"flavorRef" : "http://openstack.example.com/flavors/2;,
"networks" : [{
"uuid" : "1beeab54-0125-4ac0-8ac1-3614a02e399f",
"tag": "instance-net"
}],
"imageRef": "61d15016-1b4f-4303-9d8a-6f8cb531a0f5",
"block_device_mapping_v2": [{
"uuid": "70a599e0-31e7-49b7-b260-868f441e862b",
"source_type": "image",
"destination_type": "volume",
"boot_index": 0,
"volume_size": "1",
"tag": "disk1",
"delete_on_termination": "true"
}],
"security_groups": [
{
"name": "default"
}
]
}
}
--->8---
---8<---
{
"server" : {
"name" : "test",
"flavorRef" : "http://openstack.example.com/flavors/2;,
"networks" : [{
"uuid" : "1beeab54-0125-4ac0-8ac1-3614a02e399f",
"tag": "instance-net"
}],
"imageRef": "61d15016-1b4f-4303-9d8a-6f8cb531a0f5",
"delete_on_termination": "true"
"security_groups": [
{
"name": "default"
}
]
}
}
--->8---
Both requests result in creation of instances, no errors present in
the server response, but when I then remove instances, volumes stay
there. URL where I submit requests looks as follows: https://:8774/v2/7d0f17355baf480ba2a317467cdf70fc/servers
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1614506/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1644122] Re: OVS port fails after hyper-v cluster live migration (Invalid argument)
** Also affects: compute-hyperv Importance: Undecided Status: New ** No longer affects: nova -- 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/1644122 Title: OVS port fails after hyper-v cluster live migration (Invalid argument) Status in compute-hyperv: New Bug description: Hi Team, I'm using Mitaka cluster driver for Hyper-V with OVS 2.5 Windows port. When I perform live migration, an instance loses network connection but succesfully migrates to another host. There was a bug in Liberty where ovs port had not been migrated to target hosts but now it is seems to be okay, ovs port is on target host but adds with errors. vswitchd.log (migration time) https://paste.ubuntu.com/23510786/ nova-compute.log (migration time) https://paste.ubuntu.com/23510782/ nova.conf https://paste.ubuntu.com/23510815/ neutron-ovs-agent.conf https://paste.ubuntu.com/23510816/ If I execute the command (ovs-vsctl --timeout=120 -- --if-exists del- port 4b26fd63-e779-49c9-b419-ac2c53ef8c9a ) logged in nova manually then I get network connection even without restarting the services. I can also restart hyper-v OVS and network connection becomes available. I've also logged OVS debug rpc (another try of migration) and it contains "protocols":"OpenFlow10","datapath_version":""} 2016-11-21T13:10:55.017Z|04642|netdevwindows|DBG|construct device 4b26fd63-e779-49c9-b419-ac2c53ef8c9a, ovstype: 0. 2016-11-21T13:10:55.017Z|04643|dpif|WARN|system@ovs-system: failed to add 4b26fd63-e779-49c9-b419-ac2c53ef8c9a as port: Invalid argument Another try: 2016-11-21T12:48:21.789Z|00444|dpif|DBG|system@ovs- system: device br-tun is on port 5 2016-11-21T12:48:21.789Z|00445|netlinksocket|DBG|received NAK error=0 (No such device) 2016-11-21T12:48:21.789Z|00446|netdevwindows|DBG|construct device 4b26fd63-e779-49c9-b419-ac2c53ef8c9a, ovstype: 0. 2016-11-21T12:48:21.789Z|00447|netlinksocket|DBG|received NAK error=0 (No such device) 2016-11-21T12:48:21.789Z|00448|netlink_socket|DBG|received NAK error=0 (Invalid argument) 2016-11-21T12:48:21.789Z|00449|dpif|WARN|system @ovs-system: failed to add 4b26fd63-e779-49c9-b419-ac2c53ef8c9a as port: Invalid argument https://paste.ubuntu.com/23511010/ To manage notifications about this bug go to: https://bugs.launchpad.net/compute-hyperv/+bug/1644122/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1580122] Re: Hyper-V: cannot attach volumes from local HA shares
** Changed in: os-win Status: In Progress => Fix Released ** Changed in: compute-hyperv Importance: Undecided => Medium ** Changed in: compute-hyperv Assignee: (unassigned) => Lucian Petrut (petrutlucian94) -- 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/1580122 Title: Hyper-V: cannot attach volumes from local HA shares Status in compute-hyperv: Fix Released Status in OpenStack Compute (nova): Triaged Status in os-win: Fix Released Bug description: At the moment, the Hyper-V driver uses the UNC path of images stored on SMB shares, regardless if the share is remote or not. Citing from the MS documentation, this is not supported: “Accessing a continuously available file share as a loopback share is not supported. For example, if Microsoft SQL Server or Hyper-V store data files on SMB file shares, they must run on computers that are not a member of the file server cluster for the SMB file shares.” This is troublesome for the Hyper-C scenario, as Hyper-V will attempt to modify the image ACLs, making them unusable. The easy fix is to simply check if the share is local, and use the local path in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/compute-hyperv/+bug/1580122/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1628776] Re: Release request of networking-hyperv and creation of stable/newton
Done. Let us know if there is anything else. ** Changed in: networking-hyperv Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1628776 Title: Release request of networking-hyperv and creation of stable/newton Status in networking-hyperv: Fix Released Status in neutron: Invalid Bug description: networking-hyperv has NOT yet branched a stable/newton branch and there is no tarball at http://tarballs.openstack.org/networking- hyperv/ To manage notifications about this bug go to: https://bugs.launchpad.net/networking-hyperv/+bug/1628776/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1628776] Re: Release request of networking-hyperv and creation of stable/newton
Hello, Thanks for bringing it up. stable/newton branch has been cut. 3.0.0.0rc1 has been released quite a while ago, and I've sent a request for a final Newton release (3.0.0). https://review.openstack.org/379331 ** Changed in: neutron Status: New => Invalid ** Changed in: networking-hyperv Status: New => In Progress ** Changed in: networking-hyperv Assignee: (unassigned) => Claudiu Belu (cbelu) ** Changed in: networking-hyperv Importance: Undecided => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1628776 Title: Release request of networking-hyperv and creation of stable/newton Status in networking-hyperv: In Progress Status in neutron: Invalid Bug description: networking-hyperv has NOT yet branched a stable/newton branch and there is no tarball at http://tarballs.openstack.org/networking- hyperv/ To manage notifications about this bug go to: https://bugs.launchpad.net/networking-hyperv/+bug/1628776/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1628854] [NEW] Hyper-V VMs cannot spawn due to missing image property
Public bug reported: The HyperVDriver currently fails to spawn instances due to missing "os_type" image property [1]. This image property is needed for VMs with UEFI Secure Boot enabled, but not needed if this feature is not required. This issue has been seen in the Hyper-V CI. [1] http://paste.openstack.org/show/583450/ [2] https://review.openstack.org/#/c/209581/ ** Affects: nova Importance: High Assignee: Claudiu Belu (cbelu) Status: In Progress ** Changed in: nova Importance: Undecided => High -- 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/1628854 Title: Hyper-V VMs cannot spawn due to missing image property Status in OpenStack Compute (nova): In Progress Bug description: The HyperVDriver currently fails to spawn instances due to missing "os_type" image property [1]. This image property is needed for VMs with UEFI Secure Boot enabled, but not needed if this feature is not required. This issue has been seen in the Hyper-V CI. [1] http://paste.openstack.org/show/583450/ [2] https://review.openstack.org/#/c/209581/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1628854/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1572543] Re: Request stable/liberty release for openstack/networking-hyperv
** Changed in: networking-hyperv Importance: Undecided => Medium ** Changed in: networking-hyperv Assignee: (unassigned) => Claudiu Belu (cbelu) ** Changed in: networking-hyperv Status: New => 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/1572543 Title: Request stable/liberty release for openstack/networking-hyperv Status in networking-hyperv: Fix Released Status in neutron: Won't Fix Bug description: Please release the new version for stable/liberty branch of networking-hyperv. commit id: 13401e80e3360b9f25797879c7ade7b768ca034f tag: 1.0.4 To manage notifications about this bug go to: https://bugs.launchpad.net/networking-hyperv/+bug/1572543/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1580122] Re: Hyper-V: cannot attach volumes from local HA shares
Addressed on master (os-win): https://review.openstack.org/#/c/314490 ** Also affects: os-win Importance: Undecided Status: New ** Changed in: os-win Importance: Undecided => Medium ** Changed in: os-win Assignee: (unassigned) => Lucian Petrut (petrutlucian94) ** Changed in: os-win Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1580122 Title: Hyper-V: cannot attach volumes from local HA shares Status in compute-hyperv: New Status in OpenStack Compute (nova): Triaged Status in os-win: Confirmed Bug description: At the moment, the Hyper-V driver uses the UNC path of images stored on SMB shares, regardless if the share is remote or not. Citing from the MS documentation, this is not supported: “Accessing a continuously available file share as a loopback share is not supported. For example, if Microsoft SQL Server or Hyper-V store data files on SMB file shares, they must run on computers that are not a member of the file server cluster for the SMB file shares.” This is troublesome for the Hyper-C scenario, as Hyper-V will attempt to modify the image ACLs, making them unusable. The easy fix is to simply check if the share is local, and use the local path in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/compute-hyperv/+bug/1580122/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1557498] Re: Using logging in the serial console worker blocks Nova
** Also affects: nova Importance: Undecided Status: New ** Tags added: hyper-v liberty-backport-potential ** Changed in: os-win Importance: Undecided => High ** Changed in: os-win Assignee: (unassigned) => Lucian Petrut (petrutlucian94) ** Changed in: nova Importance: Undecided => High ** Changed in: nova Assignee: (unassigned) => Lucian Petrut (petrutlucian94) ** Changed in: nova Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1557498 Title: Using logging in the serial console worker blocks Nova Status in OpenStack Compute (nova): In Progress Status in os-win: Fix Released Bug description: The worker used by Nova to log instance serial console output can log an exception message. The issue is that logging a message from a different thread causes Nova to hang. It seems that the logging file handler causes issues when greenthreads and multiple native threads are used at the same, and the native threads log messages. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1557498/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1580161] Re: hyper-v nova compute go down with error Error writing vm console log file from serial console pipe. Error: [Errno 2] No such file or directory
*** This bug is a duplicate of bug 1557498 *** https://bugs.launchpad.net/bugs/1557498 Marked as duplicate of bug #1557498. This issue has already been solved in Mitaka in os-win. The fix should be backported to liberty as well. ** This bug has been marked a duplicate of bug 1557498 Using logging in the serial console worker blocks Nova -- 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/1580161 Title: hyper-v nova compute go down with error Error writing vm console log file from serial console pipe. Error: [Errno 2] No such file or directory Status in OpenStack Compute (nova): Confirmed Bug description: Codebase : Liberty hyper-v nova compute go down with error Error writing vm console log file from serial console pipe. Error: [Errno 2] No such file or directory During scale test , hyper-v compute go down , its shown as down in nova service-list . Looks like nova-compute stops sending heartbeat to controller when it hits error "Error writing vm console log file from serial console pipe. Error: [Errno 2] No such file or directory: '.\\pipe\\2aace779-3ed7-44eb-9c58-ba2ecf614fe2' " To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1580161/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1572543] [NEW] Request stable/liberty release for openstack/networking-hyperv
Public bug reported: Please release the new version for stable/liberty branch of networking- hyperv. commit id: 13401e80e3360b9f25797879c7ade7b768ca034f tag: 1.0.4 ** Affects: neutron Importance: Undecided Status: New ** Tags: release-subproject -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1572543 Title: Request stable/liberty release for openstack/networking-hyperv Status in neutron: New Bug description: Please release the new version for stable/liberty branch of networking-hyperv. commit id: 13401e80e3360b9f25797879c7ade7b768ca034f tag: 1.0.4 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1572543/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : 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
** Changed in: networking-hyperv
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1470443
Title:
ICMP rules not getting deleted on the hyperv network adapter extended
acl set
Status in networking-hyperv:
Fix Released
Status in neutron:
Invalid
Status in neutron juno series:
Fix Released
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
[Yahoo-eng-team] [Bug 1466547] Re: Hyper-V: Cannot add ICMPv6 security group rule
** Changed in: networking-hyperv Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1466547 Title: Hyper-V: Cannot add ICMPv6 security group rule Status in networking-hyperv: Fix Released Status in neutron: Invalid Status in neutron juno series: Fix Released 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 1520054] Re: HyperV third-party code still present in neutron tree
** Changed in: networking-hyperv Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1520054 Title: HyperV third-party code still present in neutron tree Status in networking-hyperv: Fix Released Status in neutron: Fix Released Bug description: The HyperV ML2 mechanism driver and agent should be completely removed from the neutron tree. All HyperV code and artifacts should be contained in the networking-hyperv sub-project. See http://docs.openstack.org/developer/neutron/devref/contribute.html To manage notifications about this bug go to: https://bugs.launchpad.net/networking-hyperv/+bug/1520054/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1564983] [NEW] Request Mitaka release for openstack/networking-hyperv
Public bug reported: We are requesting that the networking-hyperv release 2.0.0 be created from the current head of the master branch. The stable/mitaka branch needs to be created as well. commit id: f0f7c187e57f2f2c476d7ffd5beec794f1aca43f Branch: stable/mitaka release version: 2.0.0 ** Affects: neutron Importance: Undecided Status: New ** Tags: release-subproject -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1564983 Title: Request Mitaka release for openstack/networking-hyperv Status in neutron: New Bug description: We are requesting that the networking-hyperv release 2.0.0 be created from the current head of the master branch. The stable/mitaka branch needs to be created as well. commit id: f0f7c187e57f2f2c476d7ffd5beec794f1aca43f Branch: stable/mitaka release version: 2.0.0 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1564983/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1298034] Re: Nova Hyper-V driver fails occasionally with a x_wmi_uninitialised_thread exception
Marked bug as invalid. The issue has not been observed in ~18 months.
Plus, in the meantime, we've given up WMI in favor of PyMI, which is a
lot more reliable.
** Changed in: networking-hyperv
Status: New => Invalid
** Changed in: nova
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1298034
Title:
Nova Hyper-V driver fails occasionally with a
x_wmi_uninitialised_thread exception
Status in networking-hyperv:
Invalid
Status in OpenStack Compute (nova):
Invalid
Bug description:
The Nova Hyper-V driver can fail occasionally with:
x_wmi_uninitialised_thread ("WMI returned a syntax error: you're
probably running inside a thread without first calling
pythoncom.CoInitialize[Ex]"
http://64.119.130.115/82904/14/Hyper-V_logs/hv-compute1/neutron-
hyperv-agent.log.gz
Each thread that uses COM needs to initialize COM by calling
pythoncom.CoInitialize or pythoncom.CoInitializeEx.
Error stack trace:
http://64.119.130.115/82904/14/Hyper-V_logs/hv-compute1/neutron-
hyperv-agent.log.gz
To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-hyperv/+bug/1298034/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1301368] Re: Hyper-V configdrive is not atatched after resizing an instance
Did a resize, configdrive is attached. Looking through the code, this should not be an issue, the config drive is attached on finish_migration (also called in case of a cold resize): [1]. This is included even in Kilo. The only reason why the instance wouldn't have the config drive attached is if it isn't required by the instance. Even then, there's the config option force_config_drive that can be set to True. Even if there is no config drive, metadata can still be fetched through the network. Reopen if I'm wrong in any way. @Li Wei, that's a bit strange. It is unrelated to the config drive though. There might a couple of reason why that happened: the neutron dhcp server didn't respond, or network issues, or the neutron-hyperv- agent was dead when you performed the resize, thus, the neutron ports were not bound to the VM's NICs. [1] https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py#L295 ** Changed in: nova Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1301368 Title: Hyper-V configdrive is not atatched after resizing an instance Status in OpenStack Compute (nova): Invalid Bug description: The following bug fix takes care of copying the configdrive to the resize target, but it does not attach it to the instance. https://bugs.launchpad.net/nova/+bug/1250324 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1301368/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1372823] Re: iSCSI LUN list not refreshed in Hyper-V 2012 R2 compute nodes
** No longer affects: nova
--
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/1372823
Title:
iSCSI LUN list not refreshed in Hyper-V 2012 R2 compute nodes
Status in os-win:
Fix Released
Bug description:
When an iSCSI volume is attached to Hyper-V, the OS has to refresh the
list of LUNs on the iSCSI target to discover the new one.
The current mechanism implemented only works for the first LUN because
the connection to the target is done after the LUN is exposed to the
hypervisor. The rest of LUNs exposed to the hypervisor hosted in the
same iSCSI target won't be refreshed on time to be discovered by the
machine.
This looks related with the wrong assumption of having one LUN per
iscsi target, but it's also possible to have several LUNs per iscsi
target.
The patch for this bug should refresh the list of LUNs when a new
attachment request is received. In our test environment (Hyper-V 2012
R2), a WMI call like the following one helped to solve this issue:
self._conn_storage.query("SELECT * FROM MSFT_iSCSISessionToDisk")
To manage notifications about this bug go to:
https://bugs.launchpad.net/os-win/+bug/1372823/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1372827] Re: Improve efficiency of Hyper-V attaching iSCSI volumes
No change was necessary to be done in nova. The issue has been addressed
in os-win. Removing nova.
** No longer affects: nova
--
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/1372827
Title:
Improve efficiency of Hyper-V attaching iSCSI volumes
Status in os-win:
Fix Released
Bug description:
The Hyper-V driver in Nova is not very efficient attaching Cinder
volumes to the VMs.
It always tries to refresh the entire connection to the iSCSI target:
https://github.com/openstack/nova/blob/master/nova/virt/hyperv/volumeutilsv2.py#L87
This is a time consuming task that also blocks additional calls during
this time.
The class should be refactored to work in a more efficient way.
Calling the 'Update' method everytime a volume is attached should be
replaced by a more intelligent mechanism. As reported in
https://bugs.launchpad.net/nova/+bug/1372823 a call to
'self._conn_storage.query("SELECT * FROM MSFT_iSCSISessionToDisk")'
could help.
To manage notifications about this bug go to:
https://bugs.launchpad.net/os-win/+bug/1372827/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1466515] Re: hyperv.vmutilsv2.destroy_vm fails with "HyperVException: Operation failed with return value: 32775" in hyper-v CI
No longer a problem. ** Changed in: nova Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1466515 Title: hyperv.vmutilsv2.destroy_vm fails with "HyperVException: Operation failed with return value: 32775" in hyper-v CI Status in OpenStack Compute (nova): Invalid Bug description: http://64.119.130.115/192406/2/Hyper-V_logs/hv-compute1/nova- compute.log.gz 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 ERROR oslo_messaging.rpc.dispatcher [req-94c604a7-e023-4792-8f82-d4af076cda6e 2412437eb041483c8fde2d31507bb324 f088b7dc181a416a8edd2abc122c2c3d - - -] Exception during message handling: Operation failed with return value: 32775 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher Traceback (most recent call last): 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\oslo_messaging\rpc\dispatcher.py", line 142, in _dispatch_and_reply 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher executor_callback)) 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\oslo_messaging\rpc\dispatcher.py", line 186, in _dispatch 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher executor_callback) 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\oslo_messaging\rpc\dispatcher.py", line 130, in _do_dispatch 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher result = func(ctxt, **new_args) 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\nova\exception.py", line 90, in wrapped 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher payload) 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\oslo_utils\excutils.py", line 119, in __exit__ 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\nova\exception.py", line 73, in wrapped 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher return f(self, context, *args, **kw) 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\nova\compute\manager.py", line 335, in decorated_function 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher LOG.warning(msg, e, instance_uuid=instance_uuid) 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\oslo_utils\excutils.py", line 119, in __exit__ 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\nova\compute\manager.py", line 306, in decorated_function 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\nova\compute\manager.py", line 385, in decorated_function 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\nova\compute\manager.py", line 363, in decorated_function 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher kwargs['instance'], e, sys.exc_info()) 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\oslo_utils\excutils.py", line 119, in __exit__ 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2015-06-18 02:12:02.546 3276 86374000 GreenThread-11 TRACE oslo_messaging.rpc.dispatcher File "C:\Python27\lib\site-packages\nova\compute\manager.py", line 351, in decorated_function 2015-06-18 02:12:02.546 3276 86374000
[Yahoo-eng-team] [Bug 1271751] Re: refactor looping of WMI Query for iscsi devices down into get_device_number_for_target
No longer affects nova, as the hyper-v specific code has moved to os- win. Addressed by commit: https://review.openstack.org/#/c/249291/ ** Also affects: os-win Importance: Undecided Status: New ** No longer affects: nova ** Changed in: os-win Importance: Undecided => Medium ** Changed in: os-win Assignee: (unassigned) => Lucian Petrut (petrutlucian94) ** Changed in: os-win Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1271751 Title: refactor looping of WMI Query for iscsi devices down into get_device_number_for_target Status in os-win: Fix Released Bug description: In the review of https://review.openstack.org/#/c/55449 the idea that perhaps the looping WMI query should be implemented within get_device_number_for_target so that the couple of places that call the function could all benefit from the change. Unfortunately the recommendation was made late in the review cycle. Given the late nature of the comment it was decided to move making the additional change out to this bug and go with the current implementation for the time being. To manage notifications about this bug go to: https://bugs.launchpad.net/os-win/+bug/1271751/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1220256] Re: Hyper-V driver needs tests for WMI WQL instructions
No longer affecting Nova, due to os-win, since Hyper-V specific code, such as those queries have been moved to os-win. ** Also affects: os-win Importance: Undecided Status: New ** Changed in: nova Status: Incomplete => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1220256 Title: Hyper-V driver needs tests for WMI WQL instructions Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in os-win: New Bug description: The Hyper-V Nova driver uses mainly WMI to access the hypervisor and OS features. Additional tests can be added in this area. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1220256/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1473291] Re: nova compute on hyperv don't wait for vif plugged event from neutron
** Also affects: compute-hyperv 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/1473291 Title: nova compute on hyperv don't wait for vif plugged event from neutron Status in compute-hyperv: New Status in OpenStack Compute (nova): Confirmed Bug description: 1. Exact version of Nova/OpenStack you are running: Juno/stable 2. Reproduce steps: * Launch a VM on a Hyper-V cloud. * Note the boot time of the Virtual Machine in nova-compute.log. * Note the port up status time in neutron DB for the port of the VM. The boot time of the Virtual machine is earlier than the port UP status, which should not be the case. Expected result: * The boot time of the Virtual Machine should be later than port UP status. * All port rules are applied before the VM is booted and presented to the user. Actual result: * VM boots before the port rules are applied by neutron and it results in VM not getting IP, missing rules to communicate etc. 4. Description When the port binding is complete, neutron uses notifier to notify the port UP event to Nova, so that Nova could power ON or resume the VM instance. On Nova compute for hyper-v, Nova doesn't wait for the Port Up event from neutron and boots the instance immediately once the disk preparation is done. This causes VM instances to boot without proper security rules and hence would result in VMs not getting IP or connectivity as desired by the user. To prevent this, Nova compute should wait for the vif plugged event from neutron and then do power ON operation. To manage notifications about this bug go to: https://bugs.launchpad.net/compute-hyperv/+bug/1473291/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1208301] Re: The VM will be destroyed on source host during resizing for Hyper-V
** Also affects: compute-hyperv 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/1208301 Title: The VM will be destroyed on source host during resizing for Hyper-V Status in compute-hyperv: New Status in OpenStack Compute (nova): Confirmed Bug description: This defect is originally be found in the following scenario: 1. Deploy one vm A with 100g disk and 1 cpu. 2. Resize it with 2 cpu and 200g disk 3. During resizing, the host of vm is down (power off ) 4. restart the host After investigation, I found that in the method of migrate_disk_and_power_off of the migrationops, which is called by the Hyper-V driver, the VM gets removed as its last step. https://github.com/openstack/nova/blob/master/nova/virt/hyperv/driver.py https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py Compared with the same scenario in KVM, the previous case works, which means the VM being resized won't be removed and after the host is up again, the resize can resume. Since I am not familiar with the orginal design and don't know why Hyper-V handle resizing like this. So open this defect for tracking and discussion. One question I can propose here is: is there a standard behavior among the hypervisors for resizing? if yes, what is it? To manage notifications about this bug go to: https://bugs.launchpad.net/compute-hyperv/+bug/1208301/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1153842] Re: nova volume-attach auto returns always /dev/sdb on Hyper-V
** Also affects: compute-hyperv 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/1153842 Title: nova volume-attach auto returns always /dev/sdb on Hyper-V Status in compute-hyperv: New Status in OpenStack Compute (nova): Confirmed Bug description: To reproduce the issue it's enough to attach two volumes to a VM without providing an explicit mount point. cinder create 1 cinder create 1 nova boot ... vm1 nova volume-attach vmid auto nova volume-attach vmid auto As a result: 1) When the machine is deleted only one of the volumes becomes available again on Cinder, the second one figures as still attached. 2) Live migration fails as only one volume is reported in the "block_device_info" dict. More inconsistent behaviours can happen, for example during cold migration / resize. Workaround: Always provide a mount point e.g.: nova volume-attach vmid /dev/sdb nova volume-attach vmid /dev/sdc To manage notifications about this bug go to: https://bugs.launchpad.net/compute-hyperv/+bug/1153842/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1177570] Re: Hyper-V tests can be refactored to avoid multiple mox.VerifyAll() calls
Tests have been refactored during Kilo and Liberty. Final patch that merged in Liberty: https://review.openstack.org/#/c/139798/ No longer valid. ** Changed in: nova Status: Triaged => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1177570 Title: Hyper-V tests can be refactored to avoid multiple mox.VerifyAll() calls Status in OpenStack Compute (nova): Invalid Bug description: The Hyper-V tests, specifically test_hypervap.py are currently using the mox framework for all the tests. As a result, it's possible to move the mox.VerifyAll() call from the single tests to tearDown(). The advantages are: 1) Less code bloathing due to duplicated VerifyAll() calls at the end of each individual test 2) Ensure that VerifyAll() is called in cases in which the developer might forget about adding it at the end of the test To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1177570/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1525739] Re: Hyper-V: stable/liberty, mismatched requirements causes CI jobs to fail.
** Changed in: networking-hyperv Status: In Progress => Fix Committed ** Changed in: networking-hyperv Importance: Undecided => High ** Changed in: networking-hyperv Assignee: (unassigned) => Tony Breeds (o-tony) ** No longer affects: nova -- 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/1525739 Title: Hyper-V: stable/liberty, mismatched requirements causes CI jobs to fail. Status in networking-hyperv: Fix Committed Bug description: CI JObs in (at least) stable/liberty nova are failing with "Can not start the nova-compute service. The manual run failed as well." . http://64.119.130.115/nova/256180/1/Hyper-V_logs/create-environment-c2-r2-u22.openstack.tld.log.gz indicates that nova-compute didn't start . http://64.119.130.115/nova/256180/1/Hyper-V_logs/c2-r2-u22/process_error.txt.gz Shows an issue with oslo.log semver . http://64.119.130.115/nova/256180/1/Hyper-V_logs/create-environment-c2-r2-u22.openstack.tld.log.gz Indicates that it's comming from networking-hyperv (oslo.log<1.12.0,>=1.8.0) Looking a little deeper it seems that we have some mitaka libraries installed which are incompatible with the liberty versions. Opening this bug as a focal point for fixes. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-hyperv/+bug/1525739/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1508066] [NEW] Hyper-V: Support for Hyper-V Server 2008 R2 has been removed in Mitaka
Public bug reported: Support for Windows / Hyper-V Server 2008 R2 has been deprecated in Liberty [1] and it is no longer supported in Mitaka. The Log warning should be removed, as well as removing any usage of *utils modules using the old WMI namespace 'root/virtualization' and the CONF.hyperv.force_hyperv_utils_v1 config option. [1] https://github.com/openstack/nova/commit/bb427da8581e6e952f221056745ce3cf3b990bd2 ** Affects: nova Importance: Low Assignee: Claudiu Belu (cbelu) Status: New ** Changed in: nova Importance: Undecided => Low ** Changed in: nova Assignee: (unassigned) => Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1508066 Title: Hyper-V: Support for Hyper-V Server 2008 R2 has been removed in Mitaka Status in OpenStack Compute (nova): New Bug description: Support for Windows / Hyper-V Server 2008 R2 has been deprecated in Liberty [1] and it is no longer supported in Mitaka. The Log warning should be removed, as well as removing any usage of *utils modules using the old WMI namespace 'root/virtualization' and the CONF.hyperv.force_hyperv_utils_v1 config option. [1] https://github.com/openstack/nova/commit/bb427da8581e6e952f221056745ce3cf3b990bd2 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1508066/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1507776] [NEW] Wrong OVS flows created for new networks
Public bug reported: neutron-openvswitch-agent seems to create wrong OVS flows for newly created networks. This causes package losses, including lost DHCP requests, resulting in instances that did not receive an IP. This can cause tempest tests to fail. Restarting the neutron-openvswitch-agent will result in properly created OVS flows, and the traffic flowing properly. This issue has been observed in the Liberty release. Details: http://paste.openstack.org/show/476764/ IRC discussion: http://eavesdrop.openstack.org/irclogs/%23openstack- neutron/%23openstack-neutron.2015-10-19.log.html#t2015-10-19T20:27:31 ** Affects: neutron Importance: Undecided Status: New ** Tags: liberty-backport-potential ovs ** Description changed: neutron-openvswitch-agent seems to create wrong OVS flows for newly created networks. This causes package losses, including lost DHCP requests, resulting in instances that did not receive an IP. This can cause tempest tests to fail. + + Restarting the neutron-openvswitch-agent will result in properly created + OVS flows, and the traffic flowing properly. This issue has been observed in the Liberty release. Details: http://paste.openstack.org/show/476764/ IRC discussion: http://eavesdrop.openstack.org/irclogs/%23openstack- neutron/%23openstack-neutron.2015-10-19.log.html#t2015-10-19T20:27:31 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1507776 Title: Wrong OVS flows created for new networks Status in neutron: New Bug description: neutron-openvswitch-agent seems to create wrong OVS flows for newly created networks. This causes package losses, including lost DHCP requests, resulting in instances that did not receive an IP. This can cause tempest tests to fail. Restarting the neutron-openvswitch-agent will result in properly created OVS flows, and the traffic flowing properly. This issue has been observed in the Liberty release. Details: http://paste.openstack.org/show/476764/ IRC discussion: http://eavesdrop.openstack.org/irclogs/%23openstack- neutron/%23openstack-neutron.2015-10-19.log.html#t2015-10-19T20:27:31 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1507776/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1505819] Re: HyperVDriver fails to initialize due to Linux specific import
Already addressed by: https://review.openstack.org/#/c/234696 ** Changed in: nova Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1505819 Title: HyperVDriver fails to initialize due to Linux specific import Status in OpenStack Compute (nova): Invalid Bug description: Commit https://review.openstack.org/#/c/209627/6 introduced a new import into nova.virt.images, which is also used by the Nova Hyper-V Driver. The mentioned import is called "resources", which is Linux specific: >>> import resource >>> resource.__file__ '/usr/lib/python2.7/lib-dynload/resource.x86_64-linux-gnu.so' This also affects the Hyper-V CI, as the nova-compute service cannot start on Hyper-V, as this import cannot be found. LOG: http://64.119.130.115/neutron/225319/11/Hyper- V_logs/c2-r17-u13/process_error.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1505819/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1505681] [NEW] Hyper-V creates VM memory file on the local disk for each VM
Public bug reported: For each started VM, Hyper-V creates on the local disk a memory file for each VM. The memory file has the same size as the assigned VM memory. For example, if an instance with 4 GB ram starts, a 4 GB file is created. This can cause scheduling issues, especially on hosts which have large quantities of memory, but not a very large local disk, resulting in instances failing to spawn due to "insufficient local disk". ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) 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/1505681 Title: Hyper-V creates VM memory file on the local disk for each VM Status in OpenStack Compute (nova): New Bug description: For each started VM, Hyper-V creates on the local disk a memory file for each VM. The memory file has the same size as the assigned VM memory. For example, if an instance with 4 GB ram starts, a 4 GB file is created. This can cause scheduling issues, especially on hosts which have large quantities of memory, but not a very large local disk, resulting in instances failing to spawn due to "insufficient local disk". To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1505681/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1505819] [NEW] HyperVDriver fails to initialize due to Linux specific import
Public bug reported: Commit https://review.openstack.org/#/c/209627/6 introduced a new import into nova.virt.images, which is also used by the Nova Hyper-V Driver. The mentioned import is called "resources", which is Linux specific: >>> import resource >>> resource.__file__ '/usr/lib/python2.7/lib-dynload/resource.x86_64-linux-gnu.so' This also affects the Hyper-V CI, as the nova-compute service cannot start on Hyper-V, as this import cannot be found. LOG: http://64.119.130.115/neutron/225319/11/Hyper- V_logs/c2-r17-u13/process_error.txt.gz ** Affects: nova Importance: Critical Assignee: Claudiu Belu (cbelu) Status: In Progress ** Tags: hyper-v -- 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/1505819 Title: HyperVDriver fails to initialize due to Linux specific import Status in OpenStack Compute (nova): In Progress Bug description: Commit https://review.openstack.org/#/c/209627/6 introduced a new import into nova.virt.images, which is also used by the Nova Hyper-V Driver. The mentioned import is called "resources", which is Linux specific: >>> import resource >>> resource.__file__ '/usr/lib/python2.7/lib-dynload/resource.x86_64-linux-gnu.so' This also affects the Hyper-V CI, as the nova-compute service cannot start on Hyper-V, as this import cannot be found. LOG: http://64.119.130.115/neutron/225319/11/Hyper- V_logs/c2-r17-u13/process_error.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1505819/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1491833] Re: n-cauth fails to start if the 'consoleauth_topic' configuration option is not set
Sorry, might have been some random error... can't reproduce the issue. ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1491833 Title: n-cauth fails to start if the 'consoleauth_topic' configuration option is not set Status in OpenStack Compute (nova): Invalid Bug description: Commit [1] removed the 'consoleauth_manager' configuration option, which means it was no longer imported in nova/cmd/consoleauth.py [2]. Because of this, the service fails to start, as the 'consoleauth_topic' configuration option [3] and its default value is not registered before it tries to access that config option. LOG: http://paste.openstack.org/show/444231/ [1] https://review.openstack.org/#/c/71184/ [2] https://github.com/openstack/nova/blob/master/nova/cmd/consoleauth.py [3] https://github.com/openstack/nova/blob/master/nova/consoleauth/__init__.py To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1491833/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1491833] [NEW] n-cauth fails to start if the 'consoleauth_topic' configuration option is not set
Public bug reported: Commit [1] removed the 'consoleauth_manager' configuration option, which means it was no longer imported in nova/cmd/consoleauth.py [2]. Because of this, the service fails to start, as the 'consoleauth_topic' configuration option [3] and its default value is not registered before it tries to access that config option. LOG: http://paste.openstack.org/show/444231/ [1] https://review.openstack.org/#/c/71184/ [2] https://github.com/openstack/nova/blob/master/nova/cmd/consoleauth.py [3] https://github.com/openstack/nova/blob/master/nova/consoleauth/__init__.py ** Affects: nova Importance: Undecided Status: New ** Description changed: Commit [1] removed the 'consoleauth_manager' configuration option, which means it was no longer imported in nova/cmd/consoleauth.py [2]. Because of this, the service fails to start, as the 'consoleauth_topic' configuration option [3] and its default value is not registered before it tries to access that config option. LOG: http://paste.openstack.org/show/444231/ [1] https://review.openstack.org/#/c/71184/ [2] https://github.com/openstack/nova/blob/master/nova/cmd/consoleauth.py - [3]https://github.com/openstack/nova/blob/master/nova/consoleauth/__init__.py + [3] https://github.com/openstack/nova/blob/master/nova/consoleauth/__init__.py -- 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/1491833 Title: n-cauth fails to start if the 'consoleauth_topic' configuration option is not set Status in OpenStack Compute (nova): New Bug description: Commit [1] removed the 'consoleauth_manager' configuration option, which means it was no longer imported in nova/cmd/consoleauth.py [2]. Because of this, the service fails to start, as the 'consoleauth_topic' configuration option [3] and its default value is not registered before it tries to access that config option. LOG: http://paste.openstack.org/show/444231/ [1] https://review.openstack.org/#/c/71184/ [2] https://github.com/openstack/nova/blob/master/nova/cmd/consoleauth.py [3] https://github.com/openstack/nova/blob/master/nova/consoleauth/__init__.py To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1491833/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1489874] [NEW] No logging is done if live-migration fails
Public bug reported: In [1] and [2], the live-migration recovery method is being called, meaning the operation failed, but there is no other information regarding the failure, making it hard to determine the issue. The exception is being handled without any logging: [3] [1] http://paste.openstack.org/show/430902/ [2] http://paste.openstack.org/show/430899/ [3] https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5004 ** Affects: nova Importance: Undecided Status: New ** Tags: live-migration -- 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/1489874 Title: No logging is done if live-migration fails Status in OpenStack Compute (nova): New Bug description: In [1] and [2], the live-migration recovery method is being called, meaning the operation failed, but there is no other information regarding the failure, making it hard to determine the issue. The exception is being handled without any logging: [3] [1] http://paste.openstack.org/show/430902/ [2] http://paste.openstack.org/show/430899/ [3] https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5004 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1489874/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1486458] [NEW] Hyper-V: snapshot fails if the instance is destroyed beforehand
Public bug reported: Instance destroy and Instance snapshot are locking operations, meaning that they can only occur sequencially. This is the result of the bugfix for https://bugs.launchpad.net/nova/+bug/1461970 . The problem is that the destroy instance can occur before snapshoting, resulting in a VM NotFound exception being raised while snapshoting, as the VM no longer exists. In the logs it can be observed that the lock was being held by do_terminate_instance, which was then aquired by instance_synchronized_snapshot. This causes failures in some tempest tests. Logs: http://paste.openstack.org/show/421642/ ** Affects: nova Importance: High Assignee: Claudiu Belu (cbelu) Status: In Progress ** Tags: hyper-v -- 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/1486458 Title: Hyper-V: snapshot fails if the instance is destroyed beforehand Status in OpenStack Compute (nova): In Progress Bug description: Instance destroy and Instance snapshot are locking operations, meaning that they can only occur sequencially. This is the result of the bugfix for https://bugs.launchpad.net/nova/+bug/1461970 . The problem is that the destroy instance can occur before snapshoting, resulting in a VM NotFound exception being raised while snapshoting, as the VM no longer exists. In the logs it can be observed that the lock was being held by do_terminate_instance, which was then aquired by instance_synchronized_snapshot. This causes failures in some tempest tests. Logs: http://paste.openstack.org/show/421642/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1486458/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1486410] [NEW] Hyper-V: detach_interface raises NotImplementedError during neutron event
Public bug reported: Neutron events have been added to nova. If the event network-vif- unplugged is received, the nova compute manager will proceed to call the compute driver's detach_interface method. The mentioned method is not implemented in the HyperVDriver, causing errors. See log. LOG: http://paste.openstack.org/show/421561/ ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v ** Tags added: hyper-v ** Changed in: nova Assignee: (unassigned) = Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1486410 Title: Hyper-V: detach_interface raises NotImplementedError during neutron event Status in OpenStack Compute (nova): New Bug description: Neutron events have been added to nova. If the event network-vif- unplugged is received, the nova compute manager will proceed to call the compute driver's detach_interface method. The mentioned method is not implemented in the HyperVDriver, causing errors. See log. LOG: http://paste.openstack.org/show/421561/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1486410/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1466547] [NEW] Hyper-V: Cannot add ICMPv6 security group rule
Public bug reported: 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/ ** Affects: networking-hyperv Importance: Medium Assignee: Claudiu Belu (cbelu) Status: In Progress ** Affects: neutron Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v juno-backport-potential ** Description changed: 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/ ** Also affects: neutron Importance: Undecided Status: New ** Tags added: juno-backport-potential ** Changed in: neutron Assignee: (unassigned) = Claudiu Belu (cbelu) -- 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 Hyper-V Networking Agent: In Progress Status in OpenStack Neutron (virtual network service): New 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 1465446] [NEW] Hyper-V: After live migration succeded, the only instance dirs on the source host are not cleaned up
Public bug reported: After the instance has succesfully live migrated to a new host, the instance dirs on the source host should be removed. Not doing so can cause useless clutter and used disk on the source node. This issue is more notably when hundreds, thousands of instances were deployed to a host. ** Affects: nova Importance: Low Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v kilo-backport-potential -- 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/1465446 Title: Hyper-V: After live migration succeded, the only instance dirs on the source host are not cleaned up Status in OpenStack Compute (Nova): New Bug description: After the instance has succesfully live migrated to a new host, the instance dirs on the source host should be removed. Not doing so can cause useless clutter and used disk on the source node. This issue is more notably when hundreds, thousands of instances were deployed to a host. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1465446/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1465443] [NEW] Hyper-V: Live migration does not copy configdrive to new host
Public bug reported: Performing a live migration on Hyper-V does not copy the configdrive to the destination. This can cause trouble, since the configdrive is esential. For example, performing a second live migration on the same instance will automatically result in an exception, since it tries to copy the configdrive (file does not exist) to another destination. This is caused by incorrectly copying the configdrive (wrong destination path). Log sample, after a LOG.info was introduced, in order to observe the error: 2015-06-15 15:43:31.242 14768 INFO nova.virt.hyperv.pathutils [req-a85a92e9-b562-4398-b2ae-8ccbf2d1f525 70a2dc588be9409c9aea370aa119391f 19c78e5db79444e7ac33c5af18ae29fc - - -] Copy file from C:\OpenStack\Instances\instance-5970\configdrive.iso to weighty-secreta 2015-06-15 15:43:31.273 14768 INFO nova.virt.hyperv.serialconsoleops [req-a85a92e9-b562-4398-b2ae-8ccbf2d1f525 70a2dc588be9409c9aea370aa119391f 19c78e5db79444e7ac33c5af18ae29fc - - -] Stopping instance instance-5970 serial console handler. 2015-06-15 15:43:31.289 14768 INFO nova.virt.hyperv.pathutils [req-a85a92e9-b562-4398-b2ae-8ccbf2d1f525 70a2dc588be9409c9aea370aa119391f 19c78e5db79444e7ac33c5af18ae29fc - - -] Copy file from C:\OpenStack\Instances\instance-5970\console.log to \\weighty-secreta\C$\OpenStack\Instances\instance-5970\console.log The log sample shows the incorrect copy of configdrive.iso from the source ``C:\OpenStack\Instances\instance-5970\configdrive.iso`` to the destination ``weighty-secreta``, which is incorrect (correct: ``\\weighty- secreta\C$\OpenStack\Instances\instance-5970\configdrive.iso``) . The console.log file paths are correct and it is copied correctly. Even though the configdrive.iso destination is wrong, the copy operation is completed succesfully, which is why no exception is raised. ** Affects: nova Importance: High Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v kilo-backport-potential -- 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/1465443 Title: Hyper-V: Live migration does not copy configdrive to new host Status in OpenStack Compute (Nova): New Bug description: Performing a live migration on Hyper-V does not copy the configdrive to the destination. This can cause trouble, since the configdrive is esential. For example, performing a second live migration on the same instance will automatically result in an exception, since it tries to copy the configdrive (file does not exist) to another destination. This is caused by incorrectly copying the configdrive (wrong destination path). Log sample, after a LOG.info was introduced, in order to observe the error: 2015-06-15 15:43:31.242 14768 INFO nova.virt.hyperv.pathutils [req-a85a92e9-b562-4398-b2ae-8ccbf2d1f525 70a2dc588be9409c9aea370aa119391f 19c78e5db79444e7ac33c5af18ae29fc - - -] Copy file from C:\OpenStack\Instances\instance-5970\configdrive.iso to weighty-secreta 2015-06-15 15:43:31.273 14768 INFO nova.virt.hyperv.serialconsoleops [req-a85a92e9-b562-4398-b2ae-8ccbf2d1f525 70a2dc588be9409c9aea370aa119391f 19c78e5db79444e7ac33c5af18ae29fc - - -] Stopping instance instance-5970 serial console handler. 2015-06-15 15:43:31.289 14768 INFO nova.virt.hyperv.pathutils [req-a85a92e9-b562-4398-b2ae-8ccbf2d1f525 70a2dc588be9409c9aea370aa119391f 19c78e5db79444e7ac33c5af18ae29fc - - -] Copy file from C:\OpenStack\Instances\instance-5970\console.log to \\weighty-secreta\C$\OpenStack\Instances\instance-5970\console.log The log sample shows the incorrect copy of configdrive.iso from the source ``C:\OpenStack\Instances\instance-5970\configdrive.iso`` to the destination ``weighty-secreta``, which is incorrect (correct: ``\\weighty- secreta\C$\OpenStack\Instances\instance-5970\configdrive.iso``) . The console.log file paths are correct and it is copied correctly. Even though the configdrive.iso destination is wrong, the copy operation is completed succesfully, which is why no exception is raised. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1465443/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1461217] Re: Kilo Docker: Hypervisor Type Not Defined
** Also affects: nova-docker 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/1461217 Title: Kilo Docker: Hypervisor Type Not Defined Status in OpenStack Compute (Nova): New Status in Nova Docker Driver: New Bug description: On a multinode setup, based on Ubuntu14.04, with nova version, below # dpkg -l | grep nova ii nova-common 1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute - common files ii nova-compute1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute - compute node base ii nova-compute-kvm1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute - compute node (KVM) ii nova-compute-libvirt1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute - compute node libvirt support ii python-nova 1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute Python libraries ii python-novaclient 1:2.22.0-0ubuntu1~cloud0 all client library for OpenStack Compute API , did the following: 1- Followed https://wiki.openstack.org/wiki/Docker procedure 2- Added nova to libvirtd group, to avoid /var/run/libvirt/libvirt-sock access problem 3- Updated nova-compute.conf to include compute_driver=novadocker.virt.docker.DockerDriver and virt_type=docker Upon starting a new docker instance, got the following error: 2015-06-01 17:02:59.784 42703 ERROR nova.openstack.common.threadgroup [req-9f37298d-828c-4ac5-9834-320cc082f92b - - - - -] 'module' object has no attribute 'DOCKER' 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup Traceback (most recent call last): 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/openstack/common/threadgroup.py, line 145, in wait 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup x.wait() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/openstack/common/threadgroup.py, line 47, in wait 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup return self.thread.wait() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 175, in wait 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup return self._exit_event.wait() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/eventlet/event.py, line 121, in wait 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup return hubs.get_hub().switch() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 294, in switch 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup return self.greenlet.switch() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 214, in main 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup result = function(*args, **kwargs) 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/openstack/common/service.py, line 497, in run_service 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup service.start() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/service.py, line 183, in start 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup self.manager.pre_start_hook() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 1291, in pre_start_hook 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup self.update_available_resource(nova.context.get_admin_context()) 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 6240, in update_available_resource 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup rt.update_available_resource(context) 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/compute/resource_tracker.py, line 376, in update_available_resource 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup resources = self.driver.get_available_resource(self.nodename) 2015-06-01 17:02:59.784 42703
[Yahoo-eng-team] [Bug 1453835] [NEW] Hyper-V: Nova cold resize / migration fails
Public bug reported: Commit https://review.openstack.org/#/c/162999/ changed where the Hyper-V VM configuration files are stored. The files are being stored in the same folder as the instance. Performing a cold resize / migration will cause a os.rename call on the instance's folder, which fails as long as there are configuration files used by Hyper-V in that folder, thus resulting in a failed migration and the instance ending up in ERROR state. Logs: http://paste.openstack.org/show/219887/ ** Affects: nova Importance: Undecided Status: New ** Tags: hyper-v juno-backport-potential kilo-backport-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1453835 Title: Hyper-V: Nova cold resize / migration fails Status in OpenStack Compute (Nova): New Bug description: Commit https://review.openstack.org/#/c/162999/ changed where the Hyper-V VM configuration files are stored. The files are being stored in the same folder as the instance. Performing a cold resize / migration will cause a os.rename call on the instance's folder, which fails as long as there are configuration files used by Hyper-V in that folder, thus resulting in a failed migration and the instance ending up in ERROR state. Logs: http://paste.openstack.org/show/219887/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1453835/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1362676] Re: Hyper-V agent doesn't create stateful security group rules
** Changed in: networking-hyperv
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1362676
Title:
Hyper-V agent doesn't create stateful security group rules
Status in Hyper-V Networking Agent:
Fix Released
Status in OpenStack Neutron (virtual network service):
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 1447653] [NEW] x509 keypair cannot be created if the given subject is too long
Public bug reported: Currently, the subject created for the x509 certificate is too long, resulting in exceptions and failing to create the keypair. ( https://github.com/openstack/nova/blob/master/nova/crypto.py#L370 ) Bug detected during novaclient functional tests for commit: https://review.openstack.org/#/c/136458/ Logs: http://logs.openstack.org/58/136458/24/check/check-novaclient- dsvm- functional/ae7b130/logs/screen-n-api.txt.gz#_2015-04-23_09_23_16_289 ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Changed in: nova Assignee: (unassigned) = Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1447653 Title: x509 keypair cannot be created if the given subject is too long Status in OpenStack Compute (Nova): New Bug description: Currently, the subject created for the x509 certificate is too long, resulting in exceptions and failing to create the keypair. ( https://github.com/openstack/nova/blob/master/nova/crypto.py#L370 ) Bug detected during novaclient functional tests for commit: https://review.openstack.org/#/c/136458/ Logs: http://logs.openstack.org/58/136458/24/check/check-novaclient- dsvm- functional/ae7b130/logs/screen-n-api.txt.gz#_2015-04-23_09_23_16_289 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1447653/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : 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] [NEW] Hyper-V: Compute Driver doesn't start if there are instances with no VM Notes
Public bug reported: 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/ ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: In Progress ** Changed in: nova Assignee: (unassigned) = Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1438638 Title: Hyper-V: Compute Driver doesn't start if there are instances with no VM Notes Status in OpenStack Compute (Nova): In Progress 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 1430239] [NEW] Hyper-V: *DataRoot paths are not set for instances
Public bug reported: 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. ** Affects: nova Importance: Undecided Assignee: Dorin Paslaru (dpaslaru) Status: New ** Description changed: 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. This - can cause issues for small C:\ partitions, as some of these files can be - large. + 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. -- 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): 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 1362676] Re: Hyper-V agent doesn't create stateful security group rules
** Project changed: neutron = networking-hyperv
** Also affects: neutron
Importance: Undecided
Status: New
** Changed in: neutron
Assignee: (unassigned) = Claudiu Belu (cbelu)
--
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 Hyper-V Networking Agent:
In Progress
Status in OpenStack Neutron (virtual network service):
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 1412993] [NEW] Nova resize for boot-from-volume instance does not resize volume
Public bug reported: Resizing an instance which booted from a volume to a new flavor with a bigger disk will not cause the volume to resize accordingly. This can cause confusion among the users, which will expect to have instances with bigger storage. Scenario: 1. Have a glance image. 2. Create a bootable volume from glance image. 3. Create instance using volume and flavor having 10GB disk. 4. Perform nova resize on instance to a new flavor having 20GB disk. 5. After resize, see that the instance still has 10GB storage. Cinder volume still has the same size. This issue has been discussed on #openstack-nova and it was agreed upon to fail the resize operation, if the given instance is booted from volume and the given new flavor has a different disk size. ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: volumes ** Changed in: nova Assignee: (unassigned) = Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1412993 Title: Nova resize for boot-from-volume instance does not resize volume Status in OpenStack Compute (Nova): New Bug description: Resizing an instance which booted from a volume to a new flavor with a bigger disk will not cause the volume to resize accordingly. This can cause confusion among the users, which will expect to have instances with bigger storage. Scenario: 1. Have a glance image. 2. Create a bootable volume from glance image. 3. Create instance using volume and flavor having 10GB disk. 4. Perform nova resize on instance to a new flavor having 20GB disk. 5. After resize, see that the instance still has 10GB storage. Cinder volume still has the same size. This issue has been discussed on #openstack-nova and it was agreed upon to fail the resize operation, if the given instance is booted from volume and the given new flavor has a different disk size. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1412993/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1412480] [NEW] Hyper-V: Instance booted from volume fails to resize
Public bug reported: Hyper-V instances which are booted from volume fail during nova resize with the message: HyperVException: Cannot find boot VHD file for instance: instance-000d Since the instance boots from an ISCSI volume, there is no VHD file for it, so this error is wrong. This causes the instance to be put in ERROR state and be destroyed. Log: http://paste.openstack.org/show/158889/ ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v ** Tags added: hyper-v ** Changed in: nova Assignee: (unassigned) = Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1412480 Title: Hyper-V: Instance booted from volume fails to resize Status in OpenStack Compute (Nova): New Bug description: Hyper-V instances which are booted from volume fail during nova resize with the message: HyperVException: Cannot find boot VHD file for instance: instance-000d Since the instance boots from an ISCSI volume, there is no VHD file for it, so this error is wrong. This causes the instance to be put in ERROR state and be destroyed. Log: http://paste.openstack.org/show/158889/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1412480/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1399127] [NEW] Hyper-V: copy_vm_console_logs does not behave as expected
Public bug reported: The method nova.virt.hyperv.vmops.VMOps.copy_vm_console_logs does not behave as expected. For example, it should copy the local files 'local.file', 'local.file.1' to the remote locations 'remote.file', 'remote.file.1' respectively. Instead it copies 'local.file' to 'local.file.1' and 'remote.file' to 'remote.file.1'. This issue was discovered while creating unit tests: https://review.openstack.org/#/c/138934/ Trace: 2014-12-04 08:25:51.623 | Traceback (most recent call last): 2014-12-04 08:25:51.624 | File nova/tests/unit/virt/hyperv/test_vmops.py, line 868, in test_copy_vm_console_logs 2014-12-04 08:25:51.624 | mock.sentinel.FAKE_PATH, mock.sentinel.FAKE_REMOTE_PATH) 2014-12-04 08:25:51.624 | File /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py, line 846, in assert_called_once_with 2014-12-04 08:25:51.624 | return self.assert_called_with(*args, **kwargs) 2014-12-04 08:25:51.625 | File /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py, line 835, in assert_called_with 2014-12-04 08:25:51.625 | raise AssertionError(msg) 2014-12-04 08:25:51.625 | AssertionError: Expected call: copy(sentinel.FAKE_PATH, sentinel.FAKE_REMOTE_PATH) 2014-12-04 08:25:51.626 | Actual call: copy(sentinel.FAKE_PATH, sentinel.FAKE_PATH_ARCHIVED) ** Affects: nova Importance: Undecided Status: New ** Tags: hyper-v juno-backport-potential ** Tags added: juno-backport-potential -- 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/1399127 Title: Hyper-V: copy_vm_console_logs does not behave as expected Status in OpenStack Compute (Nova): New Bug description: The method nova.virt.hyperv.vmops.VMOps.copy_vm_console_logs does not behave as expected. For example, it should copy the local files 'local.file', 'local.file.1' to the remote locations 'remote.file', 'remote.file.1' respectively. Instead it copies 'local.file' to 'local.file.1' and 'remote.file' to 'remote.file.1'. This issue was discovered while creating unit tests: https://review.openstack.org/#/c/138934/ Trace: 2014-12-04 08:25:51.623 | Traceback (most recent call last): 2014-12-04 08:25:51.624 | File nova/tests/unit/virt/hyperv/test_vmops.py, line 868, in test_copy_vm_console_logs 2014-12-04 08:25:51.624 | mock.sentinel.FAKE_PATH, mock.sentinel.FAKE_REMOTE_PATH) 2014-12-04 08:25:51.624 | File /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py, line 846, in assert_called_once_with 2014-12-04 08:25:51.624 | return self.assert_called_with(*args, **kwargs) 2014-12-04 08:25:51.625 | File /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py, line 835, in assert_called_with 2014-12-04 08:25:51.625 | raise AssertionError(msg) 2014-12-04 08:25:51.625 | AssertionError: Expected call: copy(sentinel.FAKE_PATH, sentinel.FAKE_REMOTE_PATH) 2014-12-04 08:25:51.626 | Actual call: copy(sentinel.FAKE_PATH, sentinel.FAKE_PATH_ARCHIVED) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1399127/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : 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] [NEW] Hyper-V agent cannot disconnect orphaned switch ports
Public bug reported: 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/ ** Affects: neutron Importance: Undecided Status: New ** Tags: hyper-v -- 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 OpenStack Neutron (virtual network service): New 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/neutron/+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 1367229] [NEW] securitygroups_rpc is_firewall_enabled should return False if it is not a valid driver combination
Public bug reported: In neutron.agent.securitygroups_rpc, the method is_firewall_enabled, there is the code: def is_firewall_enabled(): if not _is_valid_driver_combination(): LOG.warn(_(Driver configuration doesn't match with enable_security_group)) return cfg.CONF.SECURITYGROUP.enable_security_group The function should return False if not _is_valid_driver_combination. Otherwise, it could return True in a case it shouldn't: cfg.CONF.SECURITYGROUP.firewall_driver = 'neutron.agent.firewall.NoopFirewallDriver' cfg.CONF.SECURITYGROUP.enable_security_group = True ** Affects: neutron Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Changed in: neutron Assignee: (unassigned) = Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1367229 Title: securitygroups_rpc is_firewall_enabled should return False if it is not a valid driver combination Status in OpenStack Neutron (virtual network service): New Bug description: In neutron.agent.securitygroups_rpc, the method is_firewall_enabled, there is the code: def is_firewall_enabled(): if not _is_valid_driver_combination(): LOG.warn(_(Driver configuration doesn't match with enable_security_group)) return cfg.CONF.SECURITYGROUP.enable_security_group The function should return False if not _is_valid_driver_combination. Otherwise, it could return True in a case it shouldn't: cfg.CONF.SECURITYGROUP.firewall_driver = 'neutron.agent.firewall.NoopFirewallDriver' cfg.CONF.SECURITYGROUP.enable_security_group = True To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1367229/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1362676] [NEW] Hyper-V agent doesn't create stateful security group rules
Public bug reported:
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.
** Affects: neutron
Importance: Undecided
Assignee: Claudiu Belu (cbelu)
Status: New
** Changed in: neutron
Assignee: (unassigned) = Claudiu Belu (cbelu)
** Description changed:
Hyper-V agent does not create stateful security group rules (ACLs),
- which doesn't allow any traffic response to pass through.
+ 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.
--
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 OpenStack Neutron (virtual network service):
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/neutron/+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 1356971] Re: Unit tests fail on Jenkins on Hyper-V module
** Changed in: nova Status: In Progress = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1356971 Title: Unit tests fail on Jenkins on Hyper-V module Status in OpenStack Compute (Nova): Invalid Bug description: Jenkins fails on gate-nova-python26 and gate-nova-python27 due to tests in the Hyper-V module. 2014-08-14 14:18:22.785 | 2014-08-14 14:18:22.785 | Traceback (most recent call last): 2014-08-14 14:18:22.785 | File nova/tests/virt/hyperv/test_vmops.py, line 32, in setUp 2014-08-14 14:18:22.785 | self._vmops = vmops.VMOps() 2014-08-14 14:18:22.785 | File nova/virt/hyperv/vmops.py, line 100, in __init__ 2014-08-14 14:18:22.785 | self._vmutils = utilsfactory.get_vmutils() 2014-08-14 14:18:22.785 | File nova/virt/hyperv/utilsfactory.py, line 65, in get_vmutils 2014-08-14 14:18:22.785 | if not get_hostutils().check_min_windows_version(6, 2): 2014-08-14 14:18:22.785 | File nova/virt/hyperv/hostutils.py, line 67, in check_min_windows_version 2014-08-14 14:18:22.786 | version_str = self.get_windows_version() 2014-08-14 14:18:22.786 | File nova/virt/hyperv/hostutils.py, line 71, in get_windows_version 2014-08-14 14:18:22.786 | return self._conn_cimv2.Win32_OperatingSystem()[0].Version 2014-08-14 14:18:22.786 | AttributeError: 'HostUtils' object has no attribute '_conn_cimv2' 2014-08-14 14:18:22.786 | == 2014-08-14 14:18:22.786 | FAIL: nova.tests.virt.hyperv.test_vmutils.WMIObjectWrapperTestCase.test_setattr_wmi_exception 2014-08-14 14:18:22.786 | tags: worker-6 Full log: http://logs.openstack.org/51/114251/2/check/gate-nova-python26/b22d740/console.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1356971/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1356884] [NEW] Hyper-V agent fails while creating isntance on Windows / Hyper-V Server 2008
Public bug reported: Creating an instance on a Hyper-V / Windows Server 2008 compute node fails due to a WMI exception. This happens while creating creating and configuring the resources to be added to the VM. The resources already have set default values for certain properties, while other properties have NULL. Trying to set a new value over the NULL causes the exception: code: drive = self._get_new_resource_setting_data(res_sub_type) drive.Parent = ctrller_path exception: 2014-08-13 09:57:07.507 2468 TRACE nova.compute.manager [instance: a30cd0c2-77ce-43d1-8399-5a876aa9a4f6] x_wmi: x_wmi: Unexpected COM Error (-2147352567, 'Exception occurred.', (0, u'SWbemObjectEx', u'Provider is not capable of the attempted operation ', None, 0, -2147217372), None) Trace: http://paste.openstack.org/show/94293/ ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v ** Changed in: nova Assignee: (unassigned) = Claudiu Belu (cbelu) ** Tags added: hyper-v -- 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/1356884 Title: Hyper-V agent fails while creating isntance on Windows / Hyper-V Server 2008 Status in OpenStack Compute (Nova): New Bug description: Creating an instance on a Hyper-V / Windows Server 2008 compute node fails due to a WMI exception. This happens while creating creating and configuring the resources to be added to the VM. The resources already have set default values for certain properties, while other properties have NULL. Trying to set a new value over the NULL causes the exception: code: drive = self._get_new_resource_setting_data(res_sub_type) drive.Parent = ctrller_path exception: 2014-08-13 09:57:07.507 2468 TRACE nova.compute.manager [instance: a30cd0c2-77ce-43d1-8399-5a876aa9a4f6] x_wmi: x_wmi: Unexpected COM Error (-2147352567, 'Exception occurred.', (0, u'SWbemObjectEx', u'Provider is not capable of the attempted operation ', None, 0, -2147217372), None) Trace: http://paste.openstack.org/show/94293/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1356884/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1344036] [NEW] Hyper-V agent generates exception when force_hyperv_utils_v1 is True on Windows Server / Hyper-V Server 2012 R2
Public bug reported: WMI root\virtualization namespace v1 (in Hyper-V) has been removed from Windows Server / Hyper-V Server 2012 R2, according to: http://technet.microsoft.com/en-us/library/dn303411.aspx Because of this, setting the force_hyperv_utils_v1 option on the Windows Server 2012 R2 nova compute agent's nova.conf will cause exceptions, since it will try to use the removed root\virtualization namespace v1. Logs: http://paste.openstack.org/show/87125/ ** Affects: nova Importance: Undecided Assignee: Dorin Paslaru (dpaslaru) 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/1344036 Title: Hyper-V agent generates exception when force_hyperv_utils_v1 is True on Windows Server / Hyper-V Server 2012 R2 Status in OpenStack Compute (Nova): New Bug description: WMI root\virtualization namespace v1 (in Hyper-V) has been removed from Windows Server / Hyper-V Server 2012 R2, according to: http://technet.microsoft.com/en-us/library/dn303411.aspx Because of this, setting the force_hyperv_utils_v1 option on the Windows Server 2012 R2 nova compute agent's nova.conf will cause exceptions, since it will try to use the removed root\virtualization namespace v1. Logs: http://paste.openstack.org/show/87125/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1344036/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1342348] [NEW] Hyper-V agent IDE/SCSI related refactoring necessary
Public bug reported: Hyper-V Server 2012 R2 introduces a new feature for virtual machines named generation 2, consisting mainly in a new firmware and better support for synthetic devices. Generation 2 VMs don't support IDE devices, which means that local boot, ephemeral disks and DVD Drives must be attached as SCSI, instead of IDE for generation 1 VMs. Since the Virtual Hard Disks and Virtual CD/DVD Disks can be attached to IDE controllers or SCSI controllers (generation 2 only), some constants, variables and methods have been improperly named, having the IDE prefix. e.g.: _IDE_DISK_RES_SUB_TYPE will have to be renamed to _HARD_DISK_RES_SUB_TYPE ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v ** Changed in: nova Assignee: (unassigned) = Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1342348 Title: Hyper-V agent IDE/SCSI related refactoring necessary Status in OpenStack Compute (Nova): New Bug description: Hyper-V Server 2012 R2 introduces a new feature for virtual machines named generation 2, consisting mainly in a new firmware and better support for synthetic devices. Generation 2 VMs don't support IDE devices, which means that local boot, ephemeral disks and DVD Drives must be attached as SCSI, instead of IDE for generation 1 VMs. Since the Virtual Hard Disks and Virtual CD/DVD Disks can be attached to IDE controllers or SCSI controllers (generation 2 only), some constants, variables and methods have been improperly named, having the IDE prefix. e.g.: _IDE_DISK_RES_SUB_TYPE will have to be renamed to _HARD_DISK_RES_SUB_TYPE To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1342348/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1299156] [NEW] Hyper-V agent does not disable security group rules
Public bug reported: A new config option was introduced recently, enable_security_group. This config option specifies if the agent should have the security group enabled or not. The Hyper-V agent does not take this config option into account, which means the security groups rules are always applied. ** Affects: neutron Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v ** Changed in: neutron Assignee: (unassigned) = Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1299156 Title: Hyper-V agent does not disable security group rules Status in OpenStack Neutron (virtual network service): New Bug description: A new config option was introduced recently, enable_security_group. This config option specifies if the agent should have the security group enabled or not. The Hyper-V agent does not take this config option into account, which means the security groups rules are always applied. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1299156/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1290403] [NEW] Hyper-V agent does not enable disk metrics for individual disks
Public bug reported: The Hyper-V agent is currently enabling metrics collection per vm, instead of per disk. This leads to erroneous values collected for disk metrics. ** Affects: nova Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v ** Tags added: hyper-v ** Changed in: nova Assignee: (unassigned) = Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1290403 Title: Hyper-V agent does not enable disk metrics for individual disks Status in OpenStack Compute (Nova): New Bug description: The Hyper-V agent is currently enabling metrics collection per vm, instead of per disk. This leads to erroneous values collected for disk metrics. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1290403/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1289007] [NEW] Hyper-V agent does not count metrics for individual ports
Public bug reported: The Hyper-V agent is currently obtaining aggregated metrics instead of values for each individual port. This leads to erroneous values in case instances have multiple ports. ** Affects: neutron Importance: Undecided Assignee: Claudiu Belu (cbelu) Status: New ** Tags: hyper-v ** Tags added: hyper-v ** Changed in: neutron Assignee: (unassigned) = Claudiu Belu (cbelu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1289007 Title: Hyper-V agent does not count metrics for individual ports Status in OpenStack Neutron (virtual network service): New Bug description: The Hyper-V agent is currently obtaining aggregated metrics instead of values for each individual port. This leads to erroneous values in case instances have multiple ports. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1289007/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
