from:"Alexey Stupnikov"

[Yahoo-eng-team] [Bug 2039972] [NEW] [CI] TestVolumeBootPattern.test_volume_boot_pattern failed because test file wasn't found

2023-10-20 Thread Alexey Stupnikov

Public bug reported:

nova-ceph-multistore failed for one of my patches because
TestVolumeBootPattern.test_volume_boot_pattern failed to find test file.

test_volume_boot_pattern() [1] has quite simple logic:

- Create in Cinder some bootable volume importing a Glance image
- Boot an instance from the bootable volume
- Write content to the volume
- Delete an instance and Boot a new instance from the volume
- Check written content in the instance # FAILED
- Create a volume snapshot while the instance is running
- Boot an additional instance from the new snapshot based volume
- Check written content in the instance booted from snapshot

For some reason test file in /tmp folder was missing after new instance
was created with this volume attached. I have no idea what may cause it
other than some cleanup operation against /tmp folder on OS level.
Reporting this bug just in case, maybe there is some obvious problem.

Logs:
https://zuul.opendev.org/t/openstack/build/42a6c06ff5f545a5bb610d7c0d454032/logs

[1]
https://github.com/openstack/tempest/blob/d1742bad94e94ebabe875ed24415d1ff510a5ae7/tempest/scenario/test_volume_boot_pattern.py#L58

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: testing

-- 
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/2039972

Title:
  [CI] TestVolumeBootPattern.test_volume_boot_pattern failed because
  test file wasn't found

Status in OpenStack Compute (nova):
  New

Bug description:
  nova-ceph-multistore failed for one of my patches because
  TestVolumeBootPattern.test_volume_boot_pattern failed to find test
  file.

  test_volume_boot_pattern() [1] has quite simple logic:

  - Create in Cinder some bootable volume importing a Glance image
  - Boot an instance from the bootable volume
  - Write content to the volume
  - Delete an instance and Boot a new instance from the volume
  - Check written content in the instance # FAILED
  - Create a volume snapshot while the instance is running
  - Boot an additional instance from the new snapshot based volume
  - Check written content in the instance booted from snapshot

  For some reason test file in /tmp folder was missing after new
  instance was created with this volume attached. I have no idea what
  may cause it other than some cleanup operation against /tmp folder on
  OS level. Reporting this bug just in case, maybe there is some obvious
  problem.

  Logs:
  
https://zuul.opendev.org/t/openstack/build/42a6c06ff5f545a5bb610d7c0d454032/logs

  [1]
  
https://github.com/openstack/tempest/blob/d1742bad94e94ebabe875ed24415d1ff510a5ae7/tempest/scenario/test_volume_boot_pattern.py#L58

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/2039972/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2020813] [NEW] OVS hardware offload for non admin users requires custom Neutron API policy

2023-05-25 Thread Alexey Stupnikov

Public bug reported:

OVS hardware offload was originally intended to be a feature used by
normal users. But bugfix
https://review.opendev.org/c/openstack/neutron/+/499203 for bug #1713590
removed the ability for non-admins to use OVS hardware offload without
changing neutron default policy in a non-secure manner: "switchdev"
capability must be added to port binding profile after port is created.

At the same time, libvirt node device driver reports "switchdev"
capability and we can translate it from NIC PCI device object to port
binding profile when port is attached.

** Affects: nova
 Importance: Undecided
     Assignee: Alexey Stupnikov (astupnikov)
 Status: In Progress


** Tags: pci

-- 
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/2020813

Title:
  OVS hardware offload for non admin users requires custom Neutron API
  policy

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  OVS hardware offload was originally intended to be a feature used by
  normal users. But bugfix
  https://review.opendev.org/c/openstack/neutron/+/499203 for bug
  #1713590 removed the ability for non-admins to use OVS hardware
  offload without changing neutron default policy in a non-secure
  manner: "switchdev" capability must be added to port binding profile
  after port is created.

  At the same time, libvirt node device driver reports "switchdev"
  capability and we can translate it from NIC PCI device object to port
  binding profile when port is attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/2020813/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2020358] [NEW] Allow to limit conntrack entries per tenant to avoid "nf_conntrack: table full, dropping packet"

2023-05-22 Thread Alexey Stupnikov

Public bug reported:

Description of problem:

A tenant can cause network issues for other tenants: nf_conntrack: table
full, dropping packet.

In our cloud had a jmeter performance test running on two instances
caused network issues for other tenants.

In the /var/log/messages on the compute node we see the following message:
"nf_conntrack: table full, dropping packet."

This gerrit https://review.openstack.org/#/c/275769/ increases the limit
to 500.000 but this is a workaround as a tenant can still increase usage
up to this new limit.

Neutron allows to limit bandwidth on a port, but you cannot limit the
conntrack sessions for an instance, port or tenant.


RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1399987

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: rfe

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2020358

Title:
  Allow to limit conntrack entries per tenant to avoid "nf_conntrack:
  table full, dropping packet"

Status in neutron:
  New

Bug description:
  Description of problem:

  A tenant can cause network issues for other tenants: nf_conntrack:
  table full, dropping packet.

  In our cloud had a jmeter performance test running on two instances
  caused network issues for other tenants.

  In the /var/log/messages on the compute node we see the following message:
  "nf_conntrack: table full, dropping packet."

  This gerrit https://review.openstack.org/#/c/275769/ increases the
  limit to 500.000 but this is a workaround as a tenant can still
  increase usage up to this new limit.

  Neutron allows to limit bandwidth on a port, but you cannot limit the
  conntrack sessions for an instance, port or tenant.

  
  RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1399987

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2020358/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2017370] [NEW] stable/zed nova.tests.functional.wsgi.test_services.TestServicesAPI.test_resize_revert_after_deleted_source_compute sporadic failures

2023-04-22 Thread Alexey Stupnikov

Public bug reported:

A strange failure happens for one of my patches:
nova.tests.functional.wsgi.test_services.TestServicesAPI.test_resize_revert_after_deleted_source_compute
test fails because of OpenStackApiNotFoundException error.

Logs and traces are available at
https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_ab9/870053/2/gate/nova-
tox-functional-py38/ab97c5a/job-output.txt

2023-04-21 06:27:36.066489 | ubuntu-focal | Captured traceback:
2023-04-21 06:27:36.066493 | ubuntu-focal | ~~~
2023-04-21 06:27:36.066497 | ubuntu-focal | Traceback (most recent call 
last):
2023-04-21 06:27:36.066502 | ubuntu-focal |
2023-04-21 06:27:36.066506 | ubuntu-focal |   File 
"/home/zuul/src/opendev.org/openstack/nova/nova/tests/functional/wsgi/test_services.py",
 line 218, in test_resize_revert_after_deleted_source_compute
2023-04-21 06:27:36.066511 | ubuntu-focal | server = 
self._boot_and_check_allocations(flavor1, 'host1')
2023-04-21 06:27:36.066516 | ubuntu-focal |
2023-04-21 06:27:36.066520 | ubuntu-focal |   File 
"/home/zuul/src/opendev.org/openstack/nova/nova/tests/functional/integrated_helpers.py",
 line 932, in _boot_and_check_allocations
2023-04-21 06:27:36.066552 | ubuntu-focal | server = 
self._wait_for_state_change(created_server, 'ACTIVE')
2023-04-21 06:27:36.066556 | ubuntu-focal |
2023-04-21 06:27:36.066560 | ubuntu-focal |   File 
"/home/zuul/src/opendev.org/openstack/nova/nova/tests/functional/integrated_helpers.py",
 line 144, in _wait_for_state_change
2023-04-21 06:27:36.066564 | ubuntu-focal | return 
self._wait_for_server_parameter(
2023-04-21 06:27:36.066569 | ubuntu-focal |
2023-04-21 06:27:36.066573 | ubuntu-focal |   File 
"/home/zuul/src/opendev.org/openstack/nova/nova/tests/functional/integrated_helpers.py",
 line 130, in _wait_for_server_parameter
2023-04-21 06:27:36.066578 | ubuntu-focal | server = 
api.get_server(server['id'])
2023-04-21 06:27:36.066582 | ubuntu-focal |
2023-04-21 06:27:36.066586 | ubuntu-focal |   File 
"/home/zuul/src/opendev.org/openstack/nova/nova/tests/functional/api/client.py",
 line 248, in get_server
2023-04-21 06:27:36.066591 | ubuntu-focal | return 
self.api_get('/servers/%s' % server_id).body['server']
2023-04-21 06:27:36.066595 | ubuntu-focal |
2023-04-21 06:27:36.066599 | ubuntu-focal |   File 
"/home/zuul/src/opendev.org/openstack/nova/nova/tests/functional/api/client.py",
 line 205, in api_get
2023-04-21 06:27:36.066603 | ubuntu-focal | return 
APIResponse(self.api_request(relative_uri, **kwargs))
2023-04-21 06:27:36.066608 | ubuntu-focal |
2023-04-21 06:27:36.066612 | ubuntu-focal |   File 
"/home/zuul/src/opendev.org/openstack/nova/nova/tests/functional/api/client.py",
 line 187, in api_request
2023-04-21 06:27:36.066616 | ubuntu-focal | raise 
OpenStackApiNotFoundException(response=response)
2023-04-21 06:27:36.066621 | ubuntu-focal |
2023-04-21 06:27:36.066625 | ubuntu-focal | 
nova.tests.functional.api.client.OpenStackApiNotFoundException: Item not found

In Nova logs I can see that hypervisor and instance itself simply
disappeared after successfull startup, so nova-api returned 404:

2023-04-21 06:26:17.760125 | ubuntu-focal | 2023-04-21 06:26:14,598 INFO 
[nova.api.openstack.requestlog] 127.0.0.1 "GET 
/v2.1/servers/6fe74316-77a0-4c99-826a-3c4b85613ee5" status: 200 len: 1770 
microversion: 2.93 time: 0.026509
2023-04-21 06:26:17.760129 | ubuntu-focal | 2023-04-21 06:26:14,683 INFO 
[placement.requestlog] 127.0.0.1 "GET 
/placement/allocation_candidates?in_tree=7cf25e47-3e14-4944-91ea-ee3c5377f440=1000=DISK_GB%3A1%2CMEMORY_MB%3A512%2CVCPU%3A1_required=%21COMPUTE_STATUS_DISABLED"
 status: 200 len: 793 microversion: 1.36
2023-04-21 06:26:17.760136 | ubuntu-focal | 2023-04-21 06:26:14,711 INFO 
[nova.scheduler.host_manager] Host filter forcing available hosts to host1
2023-04-21 06:26:17.760140 | ubuntu-focal | 2023-04-21 06:26:14,718 INFO 
[placement.requestlog] 127.0.0.1 "GET 
/placement/allocations/6fe74316-77a0-4c99-826a-3c4b85613ee5" status: 200 len: 
19 microversion: 1.28
2023-04-21 06:26:17.760148 | ubuntu-focal | 2023-04-21 06:26:14,764 INFO 
[placement.requestlog] 127.0.0.1 "PUT 
/placement/allocations/6fe74316-77a0-4c99-826a-3c4b85613ee5" status: 204 len: 0 
microversion: 1.36
2023-04-21 06:26:17.760152 | ubuntu-focal | 2023-04-21 06:26:17,081 INFO 
[nova.api.openstack.requestlog] 127.0.0.1 "GET 
/v2.1/servers/6fe74316-77a0-4c99-826a-3c4b85613ee5" status: 200 len: 1787 
microversion: 2.93 time: 0.504291
2023-04-21 06:26:17.760156 | ubuntu-focal | 2023-04-21 06:26:17,128 INFO 
[placement.requestlog] 127.0.0.1 "GET 
/placement/allocations/6fe74316-77a0-4c99-826a-3c4b85613ee5" status: 200 len: 
230 microversion: 1.28
2023-04-21 06:26:17.760160 | ubuntu-focal | 2023-04-21 06:26:17,131 INFO 
[nova.compute.claims] Claim successful on node host1
2023-04-21 06:26:17.760167 | ubuntu-focal | 2023-04-21 06:26:17,169 INFO

[Yahoo-eng-team] [Bug 2015092] [NEW] Instance sticks in BUILD when scheduling with a port assigned invalid MAC

2023-04-03 Thread Alexey Stupnikov

Public bug reported:

This is a copy of downstream
https://bugzilla.redhat.com/show_bug.cgi?id=1949703 caused by
combination of Neutron bug (addressed in
https://bugs.launchpad.net/neutron/+bug/1926273) and Nova inability to
process ValueError raised by oslo_versionedobjects.

Steps to reproduce (before Neutron bug was fixed):

1. Create bad port
$ openstack port create --mac-address 40:28:0:00:2:6 --disable-port-security 
--network ess-dpdk-1370 test-port-bad-mac_user-dpdk2

2. Create server using bad port
$ openstack server create --flavor m1.tiny  --image cirros --nic 
port-id=023abee9-a896-4678-b6fe-d4abae9066f0 dpdk-instance-bad-mac2


Expected outcome:
Instance is in ERROR state

Actual outcome:
Instance is sticks in BUILD state

** Affects: nova
 Importance: Undecided
 Assignee: Alexey Stupnikov (astupnikov)
 Status: New


** Tags: compute

-- 
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/2015092

Title:
  Instance sticks in BUILD when scheduling with a port assigned invalid
  MAC

Status in OpenStack Compute (nova):
  New

Bug description:
  This is a copy of downstream
  https://bugzilla.redhat.com/show_bug.cgi?id=1949703 caused by
  combination of Neutron bug (addressed in
  https://bugs.launchpad.net/neutron/+bug/1926273) and Nova inability to
  process ValueError raised by oslo_versionedobjects.

  Steps to reproduce (before Neutron bug was fixed):

  1. Create bad port
  $ openstack port create --mac-address 40:28:0:00:2:6 --disable-port-security 
--network ess-dpdk-1370 test-port-bad-mac_user-dpdk2

  2. Create server using bad port
  $ openstack server create --flavor m1.tiny  --image cirros --nic 
port-id=023abee9-a896-4678-b6fe-d4abae9066f0 dpdk-instance-bad-mac2

  
  Expected outcome:
  Instance is in ERROR state

  Actual outcome:
  Instance is sticks in BUILD state

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/2015092/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2009156] [NEW] stable/victoria tests are very unstable because of tempest test_live_block_migration_with_attached_volume

2023-03-03 Thread Alexey Stupnikov

Public bug reported:

stable/victoria merge process is effectively blocked because
test_live_block_migration_with_attached_volume tempest test (called as
tempest.api.compute.admin.test_live_migration.LiveMigrationTest.test_live_block_migration_with_attached_volume
and
tempest.api.compute.admin.test_live_migration.LiveAutoBlockMigrationV225Test.test_live_block_migration_with_attached_volume)
is failing sporadically. As a result, nova-grenade-multinode or nova-
live-migration are failing sporadically: one of these jobs fails almost
every time.

I have used failed tests for review
https://review.opendev.org/c/openstack/nova/+/833436 to analyze the
problem.

Picture is always the same:

1. Tempest deletes volume attachment [1]
2. nova-compute fails to detach volume because of error [2]

It looks like a communication problem between nova-compute and libvirt.

[1]
2023-02-28 12:43:25.610324 | controller | 2023-02-28 12:40:08,991 6532 INFO 
[tempest.lib.common.rest_client] Request 
(LiveAutoBlockMigrationV225Test:_run_cleanups): 202 DELETE 
http://213.32.76.87/compute/v2.1/servers/e49ccfac-97fc-4b8d-a15a-6a319d8c9a9b/os-volume_attachments/e0d103c8-cc39-4ccc-a91e-a415ff68bdee
 0.217s

[2]
Feb 28 12:45:26.707716 np0033291896 nova-compute[15752]: ERROR 
oslo_messaging.rpc.server   File 
"/opt/stack/old/nova/nova/virt/libvirt/guest.py", line 472, in 
_do_wait_and_retry_detach
Feb 28 12:45:26.707716 np0033291896 nova-compute[15752]: ERROR 
oslo_messaging.rpc.server device=alternative_device_name, reason=reason)
Feb 28 12:45:26.707716 np0033291896 nova-compute[15752]: ERROR 
oslo_messaging.rpc.server nova.exception.DeviceDetachFailed: Device detach 
failed for vdb: Unable to detach the device from the live config.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: testing

-- 
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/2009156

Title:
  stable/victoria tests are very unstable because of tempest
  test_live_block_migration_with_attached_volume

Status in OpenStack Compute (nova):
  New

Bug description:
  stable/victoria merge process is effectively blocked because
  test_live_block_migration_with_attached_volume tempest test (called as
  
tempest.api.compute.admin.test_live_migration.LiveMigrationTest.test_live_block_migration_with_attached_volume
  and
  
tempest.api.compute.admin.test_live_migration.LiveAutoBlockMigrationV225Test.test_live_block_migration_with_attached_volume)
  is failing sporadically. As a result, nova-grenade-multinode or nova-
  live-migration are failing sporadically: one of these jobs fails
  almost every time.

  I have used failed tests for review
  https://review.opendev.org/c/openstack/nova/+/833436 to analyze the
  problem.

  Picture is always the same:

  1. Tempest deletes volume attachment [1]
  2. nova-compute fails to detach volume because of error [2]

  It looks like a communication problem between nova-compute and
  libvirt.

  [1]
  2023-02-28 12:43:25.610324 | controller | 2023-02-28 12:40:08,991 6532 INFO   
  [tempest.lib.common.rest_client] Request 
(LiveAutoBlockMigrationV225Test:_run_cleanups): 202 DELETE 
http://213.32.76.87/compute/v2.1/servers/e49ccfac-97fc-4b8d-a15a-6a319d8c9a9b/os-volume_attachments/e0d103c8-cc39-4ccc-a91e-a415ff68bdee
 0.217s

  [2]
  Feb 28 12:45:26.707716 np0033291896 nova-compute[15752]: ERROR 
oslo_messaging.rpc.server   File 
"/opt/stack/old/nova/nova/virt/libvirt/guest.py", line 472, in 
_do_wait_and_retry_detach
  Feb 28 12:45:26.707716 np0033291896 nova-compute[15752]: ERROR 
oslo_messaging.rpc.server device=alternative_device_name, reason=reason)
  Feb 28 12:45:26.707716 np0033291896 nova-compute[15752]: ERROR 
oslo_messaging.rpc.server nova.exception.DeviceDetachFailed: Device detach 
failed for vdb: Unable to detach the device from the live config.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/2009156/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2007860] [NEW] master nova-tox-functional-py310 fails because of VDPAServersTest.test_suspend_and_resume

2023-02-20 Thread Alexey Stupnikov

Public bug reported:

nova.tests.functional.libvirt.test_pci_sriov_servers.VDPAServersTest.test_suspend_and_resume
failed for one of my patches. Failure itself looks sporadic, but may be
a sign of underlying problems.

Complete log:
https://3597fc80eb5e70afafd6-8fe1ce567603c46a794844f7885416e9.ssl.cf1.rackcdn.com/873388/2/check/nova-
tox-functional-py310/6921a72/job-output.txt

My understanding:
- "Original exception" [1] is logged when nova-conductor is started
- This exception triggers calls, which in turn cause libvirt import and trigger 
ImportError exception:

2023-02-17 11:43:02.536761 | ubuntu-jammy | 2023-02-17 11:26:59,887
WARNING [nova.tests.fixtures.nova] !!!---!!! TestCase ID
nova.tests.functional.libvirt.test_pci_sriov_servers.VDPAServersTest.test_suspend_and_resume
hit the import poison while importing libvirt. If you see this in a
failed functional test then please let #openstack-nova on IRC know about
it. !!!---!!!

It looks like original issue is caused by some RPC call related to live
migration.

This problem seem to be sporadic and is not a blocker, but it looks
quite interesting and could affect CI in general, so I am reporting this
bug.

[1]
2023-02-17 11:43:02.529191 | ubuntu-jammy | 2023-02-17 11:26:59,782 ERROR 
[root] Original exception being dropped: ['Traceback (most recent call 
last):\n', '  File 
"/home/zuul/src/opendev.org/openstack/nova/.tox/functional-py310/lib/python3.10/site-packages/oslo_messaging/_drivers/impl_fake.py",
 line 207, in _send\nreply, failure = reply_q.get(timeout=timeout)\n', '  
File 
"/home/zuul/src/opendev.org/openstack/nova/.tox/functional-py310/lib/python3.10/site-packages/eventlet/queue.py",
 line 322, in get\nreturn waiter.wait()\n', '  File 
"/home/zuul/src/opendev.org/openstack/nova/.tox/functional-py310/lib/python3.10/site-packages/eventlet/queue.py",
 line 141, in wait\nreturn get_hub().switch()\n', '  File 
"/home/zuul/src/opendev.org/openstack/nova/.tox/functional-py310/lib/python3.10/site-packages/eventlet/hubs/hub.py",
 line 313, in switch\nreturn self.greenlet.switch()\n', '_queue.Empty\n', 
'\nDuring handling of the above exception, another exception occurred:\n\n', 
'Tra
 ceback (most recent call last):\n', '  File 
"/home/zuul/src/opendev.org/openstack/nova/nova/compute/manager.py", line 203, 
in decorated_function\nreturn function(self, context, *args, **kwargs)\n', 
'  File "/home/zuul/src/opendev.org/openstack/nova/nova/compute/manager.py", 
line 9306, in _post_live_migration\n
self._update_scheduler_instance_info(ctxt, instance)\n', '  File 
"/home/zuul/src/opendev.org/openstack/nova/nova/compute/manager.py", line 2225, 
in _update_scheduler_instance_info\n
self.query_client.update_instance_info(context, self.host,\n', '  File 
"/home/zuul/src/opendev.org/openstack/nova/nova/scheduler/client/query.py", 
line 69, in update_instance_info\n
self.scheduler_rpcapi.update_instance_info(context, host_name,\n', '  File 
"/home/zuul/src/opendev.org/openstack/nova/nova/scheduler/rpcapi.py", line 174, 
in update_instance_info\ncctxt.cast(ctxt, \'update_instance_info\', 
host_name=host_name,\n', '  File 
"/home/zuul/src/opendev.org/openstack/nova/.tox/
 
functional-py310/lib/python3.10/site-packages/fixtures/_fixtures/monkeypatch.py",
 line 86, in avoid_get\nreturn captured_method(*args, **kwargs)\n', '  File 
"/home/zuul/src/opendev.org/openstack/nova/.tox/functional-py310/lib/python3.10/site-packages/oslo_messaging/rpc/client.py",
 line 190, in c
2023-02-17 11:43:02.529623 | ubuntu-jammy | all\nresult = 
self.transport._send(\n', '  File 
"/home/zuul/src/opendev.org/openstack/nova/.tox/functional-py310/lib/python3.10/site-packages/oslo_messaging/transport.py",
 line 123, in _send\nreturn self._driver.send(target, ctxt, message,\n', '  
File 
"/home/zuul/src/opendev.org/openstack/nova/.tox/functional-py310/lib/python3.10/site-packages/oslo_messaging/_drivers/impl_fake.py",
 line 222, in send\nreturn self._send(target, ctxt, message, 
wait_for_reply, timeout,\n', '  File 
"/home/zuul/src/opendev.org/openstack/nova/.tox/functional-py310/lib/python3.10/site-packages/oslo_messaging/_drivers/impl_fake.py",
 line 213, in _send\nraise oslo_messaging.MessagingTimeout(\n', 
'oslo_messaging.exceptions.MessagingTimeout: No reply on topic scheduler\n']
2023-02-17 11:43:02.529678 | ubuntu-jammy | 2023-02-17 11:26:59,881 WARNING 
[nova.virt.libvirt.driver] Error monitoring migration: 
(sqlite3.OperationalError) no such table: compute_nodes

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: testing

-- 
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/2007860

Title:
  master nova-tox-functional-py310 fails because of
  VDPAServersTest.test_suspend_and_resume

Status in OpenStack Compute (nova):
  New

Bug description:

[Yahoo-eng-team] [Bug 2006952] [NEW] Ambigous error when trying to boot SEV based instances from volume

2023-02-10 Thread Alexey Stupnikov

12:29:28.207 12 ERROR nova.api.openstack.wsgi 
validate_pci=validate_pci)
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi   File 
"/usr/lib/python3.6/site-packages/nova/compute/api.py", line 747, in 
_validate_flavor_image_numa_pci
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi 
API._validate_flavor_image_mem_encryption(instance_type, image_meta)
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi   File 
"/usr/lib/python3.6/site-packages/nova/compute/api.py", line 778, in 
_validate_flavor_image_mem_encryption
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi 
hardware.get_mem_encryption_constraint(instance_type, image)
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi   File 
"/usr/lib/python3.6/site-packages/nova/virt/hardware.py", line 1273, in 
get_mem_encryption_constraint
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi 
_check_mem_encryption_uses_uefi_image(requesters, image_meta)
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi   File 
"/usr/lib/python3.6/site-packages/nova/virt/hardware.py", line 1310, in 
_check_mem_encryption_uses_uefi_image
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi 'image_name': 
image_meta.name}
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi   File 
"/usr/lib/python3.6/site-packages/oslo_versionedobjects/base.py", line 67, in 
getter
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi 
self.obj_load_attr(name)
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi   File 
"/usr/lib/python3.6/site-packages/oslo_versionedobjects/base.py", line 603, in 
obj_load_attr
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi _("Cannot load 
'%s' in the base class") % attrname)
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi NotImplementedError: 
Cannot load 'name' in the base class
2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi

RH BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1967606

** Affects: nova
 Importance: Undecided
 Assignee: Alexey Stupnikov (astupnikov)
 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/2006952

Title:
  Ambigous error when trying to boot SEV based instances from volume

Status in OpenStack Compute (nova):
  New

Bug description:
  More image_meta.name use in hardware.py causing failures when
  presented with an empty ImageMeta object:

  $ openstack flavor show  m1.sev_med
  ++--+
  | Field  | Value|
  ++--+
  | OS-FLV-DISABLED:disabled   | False|
  | OS-FLV-EXT-DATA:ephemeral  | 0|
  | access_project_ids | None |
  | description| None |
  | disk   | 2|
  | extra_specs| {'hw:mem_encryption': 'True'}|
  | id | 3952db4d-e71a-4669-9bb7-666adaef6c36 |
  | name   | m1.sev_med   |
  | os-flavor-access:is_public | True |
  | properties | hw:mem_encryption='True' |
  | ram| 2048 |
  | rxtx_factor| 1.0  |
  | swap   | 0|
  | vcpus  | 4|
  ++--+
  $ openstack volume create --bootable --size 1 blank
  $ openstack server create --volume blank --flavor m1.sev_med --network 
private test
  Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ 
and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-c6d1a319-b4b0-4d1f-869c-dcbec2fd2554)

  2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi 
[req-c6d1a319-b4b0-4d1f-869c-dcbec2fd2554 cd40fe796ff84e3a8ba5e473a6d61f05 
025f8a0d412642f693782ae20ba415ec - default default] Unexpected exception in API 
method: NotImplementedError: Cannot load 'name' in the base class
  2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi Traceback (most 
recent call last):
  2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi   File 
"/usr/lib/python3.6/site-packages/nova/api/openstack/wsgi.py", line 671, in 
wrapped
  2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi return f(*args, 
**kwargs)
  2021-06-03 12:29:28.207 12 ERROR nova.api.openstack.wsgi   File 
"/usr/lib/python3.6/site-packages/nova/api/validation/__init__.p

[Yahoo-eng-team] [Bug 1994983] [NEW] Instance is stopped on destination node after evacuation if stop call was issued before evacuation

2022-10-27 Thread Alexey Stupnikov

Public bug reported:

Steps to reproduce:

1. Start an instance on a compute node (src compute).
2. Destroy src compute. Wait till nova-compute server will go down. 
3. Run 'openstack server stop' for an instance.
4. Run 'server set --state error' to the instance to be able to evacuate the 
instance (no longer needed if fix for bug #1978983 presents)
5. Evacuate the instance to another compute node (dst compute).
6. Start src compute.
7. Confirm that the evacuated instance is stopped after src compute come online.

This behavior is a bug because src compute could come up after few
months and shutdown some important instance. It looks like this behavior
is caused by cast RPC call for SRC compute to stop an instance which
sits in the queue until compute is back online and then causes DB state
change.

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2130112

** Affects: nova
 Importance: Undecided
 Assignee: Alexey Stupnikov (astupnikov)
 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/1994983

Title:
  Instance is stopped on destination node after evacuation if stop call
  was issued before evacuation

Status in OpenStack Compute (nova):
  New

Bug description:
  Steps to reproduce:

  1. Start an instance on a compute node (src compute).
  2. Destroy src compute. Wait till nova-compute server will go down. 
  3. Run 'openstack server stop' for an instance.
  4. Run 'server set --state error' to the instance to be able to evacuate the 
instance (no longer needed if fix for bug #1978983 presents)
  5. Evacuate the instance to another compute node (dst compute).
  6. Start src compute.
  7. Confirm that the evacuated instance is stopped after src compute come 
online.

  This behavior is a bug because src compute could come up after few
  months and shutdown some important instance. It looks like this
  behavior is caused by cast RPC call for SRC compute to stop an
  instance which sits in the queue until compute is back online and then
  causes DB state change.

  RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2130112

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1994983/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1960412] [NEW] Live migration artifacts are not cleaned up properly when queued live migration is aborted

2022-02-09 Thread Alexey Stupnikov

Public bug reported:

Bug #1949808 describes one of the problems affecting aborted queued live
migrations: VM's status is not reverted back to ACTIVE and VM is left in
MIGRATING state.

However that's not the single problem with aborted queued live
migrations: some changes (port bindings on destination host, resource
allocations and possibly instance's pci_requests) are introduced by Nova
control plane before live migration actually started by source compute
host. Those left-overs should also be removed.

** Affects: nova
 Importance: Undecided
 Assignee: Alexey Stupnikov (astupnikov)
 Status: New

** Description changed:

- Bug #1949808 describes one of the problems affecting aborted queued
- live migrations: VM's status is not reverted back to ACTIVE and
- VM is left in MIGRATING state.
+ Bug #1949808 describes one of the problems affecting aborted queued live
+ migrations: VM's status is not reverted back to ACTIVE and VM is left in
+ MIGRATING state.
  
  However that's not the single problem with aborted queued live
- migrations: some changes (port bindings on destination host,
- resource allocations and possibly instance's pci_requests)
- are introduced by Nova control plane before live migration
- actually started by source compute host. Those left-overs
- should also be removed.
+ migrations: some changes (port bindings on destination host, resource
+ allocations and possibly instance's pci_requests) are introduced by Nova
+ control plane before live migration actually started by source compute
+ host. Those left-overs should also be removed.

** Changed in: nova
 Assignee: (unassigned) => Alexey Stupnikov (astupnikov)

-- 
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/1960412

Title:
  Live migration artifacts are not cleaned up properly when queued live
  migration is aborted

Status in OpenStack Compute (nova):
  New

Bug description:
  Bug #1949808 describes one of the problems affecting aborted queued
  live migrations: VM's status is not reverted back to ACTIVE and VM is
  left in MIGRATING state.

  However that's not the single problem with aborted queued live
  migrations: some changes (port bindings on destination host, resource
  allocations and possibly instance's pci_requests) are introduced by
  Nova control plane before live migration actually started by source
  compute host. Those left-overs should also be removed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1960412/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1949808] [NEW] After nova live-migration-abort canceled "queued" live-migration, instance status remains "MIGRATING"

2021-11-04 Thread Alexey Stupnikov

Public bug reported:

OpenStack supports cancelling "queued" live-migration by "nova live-
migration-abort", but state of canceled instance remains "MIGRATING".

** Affects: nova
 Importance: Undecided
 Assignee: Alexey Stupnikov (astupnikov)
 Status: New


** Tags: live-migration

** Bug watch added: Red Hat Bugzilla #1729366
   https://bugzilla.redhat.com/show_bug.cgi?id=1729366

-- 
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/1949808

Title:
  After nova live-migration-abort canceled "queued" live-migration,
  instance status remains "MIGRATING"

Status in OpenStack Compute (nova):
  New

Bug description:
  OpenStack supports cancelling "queued" live-migration by "nova live-
  migration-abort", but state of canceled instance remains "MIGRATING".

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1949808/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1849802] Re: Live-migration fails without a logged root cause

2021-10-18 Thread Alexey Stupnikov

I have used my lab to understand original report and what is actually
going on. Shortly speaking, Nova is unable to live migrate an instance
because Neutron fails to create port binding on destination host (it
already exists) when Nova Conductor tries to create port binding on
destination host.

There could be multiple causes of such behavior and this bug is not
about solving a root cause. Instead, the problem is that it is hard to
isolate the issue using Neutron Server logs.

When debug is enabled Neutron generates logs [1] for such kinds of
requests. It looks like for some reason the following exception raised
by Neutron is not logged properly on Neutron side: we can see it in Nova
logs, but not in Neutron Server logs.
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L2463-L2466

As a result, it looks like this problem should be solved by improving
logging for Neutron extensions in general or this particular function.

With that being said, I am changing affected product to Neutron and
unassigning this bug.

[1]
  2021-10-18 14:15:58.081 18 DEBUG neutron.api.v2.base 
[req-c237e714-0085-47c6-abab-e7e15cec7ea1 d79d0393fbb04564bc8fd3c62d290087 
b8715d57125f4787a6701319d38f61e3 - default default] Request body: {'binding': 
{'host': 'compute-0.redhat.local', 'vnic_type': 'normal', 'profile': {}}} 
prepare_request_body /usr/lib/python3.6/site-packages/neutron/api/v2/base.py:719
  2021-10-18 14:15:58.081 18 DEBUG neutron.api.v2.base 
[req-c237e714-0085-47c6-abab-e7e15cec7ea1 d79d0393fbb04564bc8fd3c62d290087 
b8715d57125f4787a6701319d38f61e3 - default default] Unknown quota resources 
['binding']. _create /usr/lib/python3.6/site-packages/neutron/api/v2/base.py:490
  2021-10-18 14:15:58.135 18 INFO neutron.api.v2.resource 
[req-c237e714-0085-47c6-abab-e7e15cec7ea1 d79d0393fbb04564bc8fd3c62d290087 
b8715d57125f4787a6701319d38f61e3 - default default] create failed (client 
error): There was a conflict when trying to complete your request.
  2021-10-18 14:15:58.137 18 INFO neutron.wsgi 
[req-c237e714-0085-47c6-abab-e7e15cec7ea1 d79d0393fbb04564bc8fd3c62d290087 
b8715d57125f4787a6701319d38f61e3 - default default] 172.17.1.17 "POST 
/v2.0/ports/7542a977-0586-423a-ae35-86e3ff791060/bindings HTTP/1.1" status: 409 
 len: 364 time: 0.3800023
  2021-10-18 14:15:58.316 21 DEBUG neutron_lib.callbacks.manager 
[req-334ebddd-4e81-4c12-829c-64f3b0a278ff - - - - -] Notify callbacks 
['neutron.services.segments.db._update_segment_host_mapping_for_agent-8793714910767',
 'neutron.plugins.ml2.plugin.Ml2Plugin._retry_binding_revived_agents-16758855'] 
for agent, after_update _notify_loop 
/usr/lib/python3.6/site-packages/neutron_lib/callbacks/manager.py:193

** Changed in: nova
 Assignee: Alexey Stupnikov (astupnikov) => (unassigned)

** Project changed: nova => neutron

** Changed in: neutron
   Status: Triaged => New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1849802

Title:
  Live-migration fails without a logged root cause

Status in neutron:
  New

Bug description:
  Operating system distribution and version: Ubuntu 18.04

  Neutron package version: 2:14.0.2-0ubuntu1~cloud0
  Nova package version: 2:19.0.1-0ubuntu2.1~cloud0

  Cloud was deploying (using Juju charms) as rocky, then upgraded to
  stein.

  There are a number of instances that I need to migrate from one
  compute node to another, but:

  $ openstack server migrate --block-migration 
8703d9db-81b0-4e86-a2ef-c4ba5250556c --live shinx --disk-overcommit
  Migration pre-check error: Binding failed for port 
5a3c5d23-8727-47d2-af72-a53b495358d2, please check neutron logs for more 
information. (HTTP 400) (Request-ID: req-7c41ae70-6f5b-48a8-9d09-add2bbbe2b7e)
  $ 

  However, even with debug logging enabled, all that shows up in the
  neutron-api logs is:

  2019-10-25 09:34:12.147 1569534 INFO neutron.wsgi [req-
  ac358ed5-cfec-4618-b765-f2defd5a3aac 92e98c5c687a46d29ec28aca3025f3da
  7555fff7e7eb4a0eb28149905b266a2b - 207337407e3647798c0f68a0a28a0f8b
  207337407e3647798c0f68a0a28a0f8b] 10.x.y.z,127.0.0.1 "POST
  /v2.0/ports/5a3c5d23-8727-47d2-af72-a53b495358d2/bindings HTTP/1.1"
  status: 409  len: 371 time: 0.1632745

  Which suggests that for some reason, the API call to retrieve port
  bindings is failing, but there's no further information in the logs
  for me to debug exactly why.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1849802/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1718606] Re: doc: Outdated XenServer document

2021-08-04 Thread Alexey Stupnikov

XenAPI driver was deprecated during Train release cycle and removed
during Victoria cycle. This bug doesn't longer reflect actual situation
and is invalid for master branch of Nova.

References:

https://review.opendev.org/c/openstack/nova/+/680732
https://review.opendev.org/c/openstack/nova/+/749304
https://docs.openstack.org/releasenotes/nova/victoria.html

** Changed in: nova
 Assignee: (unassigned) => Alexey Stupnikov (astupnikov)

** Changed in: nova
   Status: Confirmed => Invalid

** Tags removed: low-hanging-fruit

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1718606

Title:
  doc: Outdated XenServer document

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  In the following document, os-xenapi version is 0.1.0.
  Currently it is 0.3.1.
  The guide needs a serious look at and probably it should be revised.

  https://docs.openstack.org/nova/latest/admin/configuration/hypervisor-
  xen-api.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1718606/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1747167] Re: Neutron driver handles incorrectly 404 errors

2020-05-23 Thread Alexey Stupnikov

Changing bug's status to fix released as recent releases are no longer
affected

** Changed in: nova
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1747167

Title:
  Neutron driver handles incorrectly 404 errors

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Neutronclient transforms errors using exception_handler_v20[1].
  In particular, it transforms 404 responses into:
   1) [2] neutronclient.common.exceptions.Client if response body 
contains a type attribute (with value , type examples: NetworkNotFound, 
PortNotFound) and Client exists
   2) [3] neutronclient.common.NotFound otherwise

  Nova neutron driver[4] supports mostly 1) but not 2).
  But Neutron in case of 404 returns the following body:

    {"message": "The resource could not be found.\n\n\n",
  "code": "404 Not Found", "title": "Not Found"}

  and we end in 2) and Nova Neutron driver doesn't catch the error
  correctly and raises a 500

  You can reproduce it indirectly using:
   openstack server add fixed ip  

  which queries:
   nova-base-url/os-networks/

  assuming it would return the network or a 404 but it returns 500.


  This trouble can be solved by catching NotFound instead of
  NetworkNotFoundClient/PortNotFoundClient as there are subclasses of
  NotFound.


  
  [1] 
https://github.com/openstack/python-neutronclient/blob/6a2112e1824980af1bc9216441fa58a7dfd00988/neutronclient/v2_0/client.py#L47-L93
  [2] 
https://github.com/openstack/python-neutronclient/blob/6a2112e1824980af1bc9216441fa58a7dfd00988/neutronclient/v2_0/client.py#L71
  [3] 
https://github.com/openstack/python-neutronclient/blob/6a2112e1824980af1bc9216441fa58a7dfd00988/neutronclient/v2_0/client.py#L85
  [4] nova.network.neutronv2.api

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1747167/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1747344] Re: nova-manage db online migration base message

2020-05-01 Thread Alexey Stupnikov

This bug was actually fixed in https://review.opendev.org/#/c/420060/

Closing as Fix Released.

** Changed in: nova
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1747344

Title:
  nova-manage db online migration base message

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  env:
  Mitaka upgraded to Ocata

  Use command "su -s /bin/sh -c "nova-manage db sync" nova", the message was "
  Please run `nova-manage db online_migrations' on Newton code before 
continuing.There are still 6 unmigrated flavors. "

  The migration command was "nova-manage db online_data_migrations"  not
  "nova-manage db online_migrations".

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1747344/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1537062] Re: Fail to boot vm when set AggregateImagePropertiesIsolation filter and add custom metadata in the Host Aggregate

2016-08-02 Thread Alexey Stupnikov

Removed MOS project from the list of affected products since I have
opened separate bug #1608937. I will try to cherry-pick this issue to
stable/mitaka and then sync it to MOS.

@l-ivan, please check my comment above ^^^

** No longer affects: mos

** Tags removed: customer-found

-- 
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/1537062

Title:
  Fail to boot vm when set AggregateImagePropertiesIsolation filter and
  add custom metadata in the Host Aggregate

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Image has no custom metadata, should not affect the
  AggregateImagePropertiesIsolation filter

  Reproduce steps:

  (1) add Host Aggregate with custom metadata
  ++---+---+--++
  | Id | Name  | Availability Zone | Hosts| Metadata   |
  ++---+---+--++
  | 1  | linux-agg | - | 'controller' | 'os=linux' |
  ++---+---+--++

  (2) add  AggregateImagePropertiesIsolation filter
  scheduler_default_filters = 
RetryFilter,AggregateImagePropertiesIsolation,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,SameHostFilter,DifferentHostFilter

  (3) boot vm and error log:
  2016-01-22 21:00:10.834 ERROR oslo_messaging.rpc.dispatcher 
[req-1cded809-cfe6-4657-8e31-b494f1b3278d admin admin] Exception during messa
  ge handling: ImageMetaProps object has no attribute 'os'
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher Traceback (most 
recent call last):
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", l
  ine 143, in _dispatch_and_reply
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher 
executor_callback))
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", l
  ine 189, in _dispatch
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher 
executor_callback)
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", l
  ine 130, in _do_dispatch
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher result = 
func(ctxt, **new_args)
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line
  150, in inner
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher return 
func(*args, **kwargs)
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/nova/nova/scheduler/manager.py", line 78, in select_destin
  ations
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher dests = 
self.driver.select_destinations(ctxt, spec_obj)
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/nova/nova/scheduler/filter_scheduler.py", line 53, in sele
  ct_destinations
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher 
selected_hosts = self._schedule(context, spec_obj)
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/nova/nova/scheduler/filter_scheduler.py", line 113, in _sc
  hedule
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher spec_obj, 
index=num)
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/nova/nova/scheduler/host_manager.py", line 532, in get_fil
  tered_hosts
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher hosts, 
spec_obj, index)
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/nova/nova/filters.py", line 89, in get_filtered_objects
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher list_objs = 
list(objs)
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/nova/nova/filters.py", line 44, in filter_all
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher if 
self._filter_one(obj, spec_obj):
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/nova/nova/scheduler/filters/__init__.py", line 26, in _filter_one
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher return 
self.host_passes(obj, filter_properties)
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/nova/nova/scheduler/filters/aggregate_image_properties_isolation.py",
 line 48, in host_passes
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher prop = 
image_props.get(key)
  2016-01-22 21:00:10.834 TRACE oslo_messaging.rpc.dispatcher   File

[Yahoo-eng-team] [Bug 1563419] Re: [UI] sahara uses UTC time instead of set timezone

2016-06-15 Thread Alexey Stupnikov

This bug is also found in Horizon's kilo and liberty branches.

** Also affects: horizon
   Importance: Undecided
   Status: New

** Changed in: horizon
 Assignee: (unassigned) => Alexey Stupnikov (astupnikov)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1563419

Title:
  [UI] sahara uses UTC time instead of set timezone

Status in OpenStack Dashboard (Horizon):
  New
Status in Sahara:
  Fix Released

Bug description:
  All time values that are shown in sahara dashboard are in UTC no
  matter what kind of timezone we have set in settings. It affects the
  Data Sources, Job Execution detail views and Cluster provision steps
  table

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1563419/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2039972] [NEW] [CI] TestVolumeBootPattern.test_volume_boot_pattern failed because test file wasn't found

[Yahoo-eng-team] [Bug 2020813] [NEW] OVS hardware offload for non admin users requires custom Neutron API policy

[Yahoo-eng-team] [Bug 2020358] [NEW] Allow to limit conntrack entries per tenant to avoid "nf_conntrack: table full, dropping packet"

[Yahoo-eng-team] [Bug 2017370] [NEW] stable/zed nova.tests.functional.wsgi.test_services.TestServicesAPI.test_resize_revert_after_deleted_source_compute sporadic failures

[Yahoo-eng-team] [Bug 2015092] [NEW] Instance sticks in BUILD when scheduling with a port assigned invalid MAC

[Yahoo-eng-team] [Bug 2009156] [NEW] stable/victoria tests are very unstable because of tempest test_live_block_migration_with_attached_volume

[Yahoo-eng-team] [Bug 2007860] [NEW] master nova-tox-functional-py310 fails because of VDPAServersTest.test_suspend_and_resume

[Yahoo-eng-team] [Bug 2006952] [NEW] Ambigous error when trying to boot SEV based instances from volume

[Yahoo-eng-team] [Bug 1994983] [NEW] Instance is stopped on destination node after evacuation if stop call was issued before evacuation

[Yahoo-eng-team] [Bug 1960412] [NEW] Live migration artifacts are not cleaned up properly when queued live migration is aborted

[Yahoo-eng-team] [Bug 1949808] [NEW] After nova live-migration-abort canceled "queued" live-migration, instance status remains "MIGRATING"

[Yahoo-eng-team] [Bug 1849802] Re: Live-migration fails without a logged root cause

[Yahoo-eng-team] [Bug 1718606] Re: doc: Outdated XenServer document

[Yahoo-eng-team] [Bug 1747167] Re: Neutron driver handles incorrectly 404 errors

[Yahoo-eng-team] [Bug 1747344] Re: nova-manage db online migration base message

[Yahoo-eng-team] [Bug 1537062] Re: Fail to boot vm when set AggregateImagePropertiesIsolation filter and add custom metadata in the Host Aggregate

[Yahoo-eng-team] [Bug 1563419] Re: [UI] sahara uses UTC time instead of set timezone

17 matches

Site Navigation

Mail list logo

Footer information