[Yahoo-eng-team] [Bug 2081847] Re: [RFE] Implement a new DHCP backend for Ironic and Neutron
** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2081847 Title: [RFE] Implement a new DHCP backend for Ironic and Neutron Status in Ironic: New Status in neutron: New Bug description: dnsmasq has become unreliable, causing issues while performing DHCP operations. Here's an RFE proposal to implement Kea DHCP as a new backend and alternative DHCP provider option in Ironic and Neutron. Kea is actively maintained by ISC, extensible with hooks modules and provides a good balance of modern features and compatibility with existing systems. My Findings about Kea DHCP: https://etherpad.opendev.org/p/research_cid RFE spec: Proposed Change Draft: To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/2081847/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2077195] Re: RFE: Add support for "igb" VIF model
Being tracked in https://blueprints.launchpad.net/nova/+spec/igb-vif- model ** 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/2077195 Title: RFE: Add support for "igb" VIF model Status in OpenStack Compute (nova): Invalid Bug description: qemu now supports a network driver called "igb" that simulates SR-IOV VFs[1]. Current versions of most OS distributions now include a version of qemu with this driver included. We would like to use that in the OpenStack gates to test SR-IOV functionality in Octavia. Currently nova does not allow the "igb" driver to be specified using "hw_vif_model=igb" because it is not on the list of valid VIF_MODELS here: https://opendev.org/openstack/nova/src/branch/master/nova/network/model.py#L156 This RFE is a request to add support for the igb driver to nova. I have also registered a blueprint for this here: https://blueprints.launchpad.net/nova/+spec/igb-vif-model [1] https://www.qemu.org/docs/master/system/devices/igb.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2077195/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2081870] [NEW] neutron.tests.functional.agent.linux.test_process_monitor.TestProcessMonitor.test_respawn_handler failed with "RuntimeError: Not all children (re)spawned."
Public bug reported: This happened in functional job here: https://fc7da22d605cc199ea32-a05951a0ad29f0907f5578ce9b824040.ssl.cf1.rackcdn.com/929793/3/check/neutron- functional-with-uwsgi/ba361f4/testr_results.html Traceback: ``` ft1.1: neutron.tests.functional.agent.linux.test_process_monitor.TestProcessMonitor.test_respawn_handlertesttools.testresult.real._StringException: Traceback (most recent call last): File "/home/zuul/src/opendev.org/openstack/neutron/neutron/common/utils.py", line 740, in wait_until_true eventlet.sleep(sleep) File "/home/zuul/src/opendev.org/openstack/neutron/.tox/dsvm-functional-gate/lib/python3.10/site-packages/eventlet/greenthread.py", line 38, in sleep hub.switch() File "/home/zuul/src/opendev.org/openstack/neutron/.tox/dsvm-functional-gate/lib/python3.10/site-packages/eventlet/hubs/hub.py", line 310, in switch return self.greenlet.switch() eventlet.timeout.Timeout: 6 seconds During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/base.py", line 178, in func return f(self, *args, **kwargs) File "/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/functional/agent/linux/test_process_monitor.py", line 110, in test_respawn_handler self.wait_for_all_children_spawned() File "/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/functional/agent/linux/test_process_monitor.py", line 92, in wait_for_all_children_spawned utils.wait_until_true( File "/home/zuul/src/opendev.org/openstack/neutron/neutron/common/utils.py", line 744, in wait_until_true raise exception RuntimeError: Not all children (re)spawned. ``` ** Affects: neutron Importance: Undecided Status: New ** Tags: functional-tests gate-failure ** Tags added: functional-tests gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2081870 Title: neutron.tests.functional.agent.linux.test_process_monitor.TestProcessMonitor.test_respawn_handler failed with "RuntimeError: Not all children (re)spawned." Status in neutron: New Bug description: This happened in functional job here: https://fc7da22d605cc199ea32-a05951a0ad29f0907f5578ce9b824040.ssl.cf1.rackcdn.com/929793/3/check/neutron- functional-with-uwsgi/ba361f4/testr_results.html Traceback: ``` ft1.1: neutron.tests.functional.agent.linux.test_process_monitor.TestProcessMonitor.test_respawn_handlertesttools.testresult.real._StringException: Traceback (most recent call last): File "/home/zuul/src/opendev.org/openstack/neutron/neutron/common/utils.py", line 740, in wait_until_true eventlet.sleep(sleep) File "/home/zuul/src/opendev.org/openstack/neutron/.tox/dsvm-functional-gate/lib/python3.10/site-packages/eventlet/greenthread.py", line 38, in sleep hub.switch() File "/home/zuul/src/opendev.org/openstack/neutron/.tox/dsvm-functional-gate/lib/python3.10/site-packages/eventlet/hubs/hub.py", line 310, in switch return self.greenlet.switch() eventlet.timeout.Timeout: 6 seconds During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/base.py", line 178, in func return f(self, *args, **kwargs) File "/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/functional/agent/linux/test_process_monitor.py", line 110, in test_respawn_handler self.wait_for_all_children_spawned() File "/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/functional/agent/linux/test_process_monitor.py", line 92, in wait_for_all_children_spawned utils.wait_until_true( File "/home/zuul/src/opendev.org/openstack/neutron/neutron/common/utils.py", line 744, in wait_until_true raise exception RuntimeError: Not all children (re)spawned. ``` To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2081870/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2081868] [NEW] neutron.tests.unit.services.logapi.common.test_db_api.LoggingDBApiTestCase.test_get_logs_bound_sg fails with "webob.exc.HTTPClientError: The server could not compl
Public bug reported: This failed here in gate on a patch that doesn't even touch this code: https://5d6811448796d11c6047-40ec7889760df9011e4354628420e100.ssl.cf5.rackcdn.com/929793/3/check/openstack- tox-py39/9d559dc/testr_results.html There is nothing of interest in the full logs either: https://5d6811448796d11c6047-40ec7889760df9011e4354628420e100.ssl.cf5.rackcdn.com/929793/3/check/openstack- tox-py39/9d559dc/tox/py39/3-commands%5B1%5D.log I don't know how frequent it is, but clearly it's some instability issue in unit tests, which is not very common for this type of tests. ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure unittest ** Tags added: gate-failure unittest -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2081868 Title: neutron.tests.unit.services.logapi.common.test_db_api.LoggingDBApiTestCase.test_get_logs_bound_sg fails with "webob.exc.HTTPClientError: The server could not comply with the request since it is either malformed or otherwise incorrect." Status in neutron: New Bug description: This failed here in gate on a patch that doesn't even touch this code: https://5d6811448796d11c6047-40ec7889760df9011e4354628420e100.ssl.cf5.rackcdn.com/929793/3/check/openstack- tox-py39/9d559dc/testr_results.html There is nothing of interest in the full logs either: https://5d6811448796d11c6047-40ec7889760df9011e4354628420e100.ssl.cf5.rackcdn.com/929793/3/check/openstack- tox-py39/9d559dc/tox/py39/3-commands%5B1%5D.log I don't know how frequent it is, but clearly it's some instability issue in unit tests, which is not very common for this type of tests. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2081868/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2081871] [NEW] Fullstack neutron.tests.fullstack.test_l3_agent.TestHAL3Agent.test_ha_router failed with "eventlet.timeout.Timeout: 90 seconds" while waiting on self._is_ha_router
Public bug reported:
This failed here:
https://zuul.opendev.org/t/openstack/build/1a8c094b185d40a4b0df78f4afe25d2e
Traceback:
```
File
"/home/zuul/src/opendev.org/openstack/neutron/neutron/common/utils.py", line
740, in wait_until_true
eventlet.sleep(sleep)
File
"/home/zuul/src/opendev.org/openstack/neutron/.tox/dsvm-fullstack-gate/lib/python3.10/site-packages/eventlet/greenthread.py",
line 38, in sleep
hub.switch()
File
"/home/zuul/src/opendev.org/openstack/neutron/.tox/dsvm-fullstack-gate/lib/python3.10/site-packages/eventlet/hubs/hub.py",
line 310, in switch
return self.greenlet.switch()
eventlet.timeout.Timeout: 90 seconds
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/base.py", line 178,
in func
return f(self, *args, **kwargs)
File
"/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/fullstack/test_l3_agent.py",
line 420, in test_ha_router
common_utils.wait_until_true(
File
"/home/zuul/src/opendev.org/openstack/neutron/neutron/common/utils.py", line
745, in wait_until_true
raise WaitTimeout(_("Timed out after %d seconds") % timeout)
neutron.common.utils.WaitTimeout: Timed out after 90 seconds
```
The output of the failure is not very helpful. One idea here to improve
the log message could be to make wait_until_true and/or the passed
predicate function to report additional information on timeout. Then the
next time it hits, we may have more information.
** Affects: neutron
Importance: Undecided
Status: New
** Tags: fullstack gate-failure l3-ha
** Tags added: fullstack gate-failure
** Tags added: l3-ha
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2081871
Title:
Fullstack
neutron.tests.fullstack.test_l3_agent.TestHAL3Agent.test_ha_router
failed with "eventlet.timeout.Timeout: 90 seconds" while waiting on
self._is_ha_router_active_on_one_agent
Status in neutron:
New
Bug description:
This failed here:
https://zuul.opendev.org/t/openstack/build/1a8c094b185d40a4b0df78f4afe25d2e
Traceback:
```
File
"/home/zuul/src/opendev.org/openstack/neutron/neutron/common/utils.py", line
740, in wait_until_true
eventlet.sleep(sleep)
File
"/home/zuul/src/opendev.org/openstack/neutron/.tox/dsvm-fullstack-gate/lib/python3.10/site-packages/eventlet/greenthread.py",
line 38, in sleep
hub.switch()
File
"/home/zuul/src/opendev.org/openstack/neutron/.tox/dsvm-fullstack-gate/lib/python3.10/site-packages/eventlet/hubs/hub.py",
line 310, in switch
return self.greenlet.switch()
eventlet.timeout.Timeout: 90 seconds
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/base.py", line 178,
in func
return f(self, *args, **kwargs)
File
"/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/fullstack/test_l3_agent.py",
line 420, in test_ha_router
common_utils.wait_until_true(
File
"/home/zuul/src/opendev.org/openstack/neutron/neutron/common/utils.py", line
745, in wait_until_true
raise WaitTimeout(_("Timed out after %d seconds") % timeout)
neutron.common.utils.WaitTimeout: Timed out after 90 seconds
```
The output of the failure is not very helpful. One idea here to
improve the log message could be to make wait_until_true and/or the
passed predicate function to report additional information on timeout.
Then the next time it hits, we may have more information.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2081871/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1483639] Re: Nova and Horizon allow inappropriate actions to be performed on baremetal nodes
** Changed in: ironic Status: Incomplete => Invalid -- 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/1483639 Title: Nova and Horizon allow inappropriate actions to be performed on baremetal nodes Status in OpenStack Dashboard (Horizon): Confirmed Status in Ironic: Invalid Status in OpenStack Compute (nova): Confirmed Bug description: Ironic baremetal nodes do not support all variety of operations that nova virtual instances do. But Nova and Horizon still offers to perform actions with ironic baremetal nodes that can be applied to virtual instances only. Examples of steps: root@node-1:~# nova pause NEW1 root@node-1:~# nova suspend NEW1 As result Nova silently accepts commands without any warning or error messages. Same actions can be performed via Horizon with green "Success" popup. Also see list of actions over baremetal node on screenshot. One more example: Backup to image baremetal instance: root@node-1:~# nova image-create --poll --show NEW1 IMAGENEW1 Server snapshotting... 0% complete and process stalls showing 0% in console infinitely. Expected that nova will not try do this with baremetal node at all. Currently baremetal nodes do not support following actions: a) Create Snapshot b) Pause c) Suspend d) Migrate e) Live Migrate f) Only one kind or reboot should be supported (Hard reboot?) g) Resize These actions should be disabled for baremetal machines in Nova and Horizon. Currently there are no destructive aftermaths detected, therefore this bug affects user by confusing him when using Horizon and Nova. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1483639/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2081859] [NEW] Nova not initializing os-brick
Public bug reported: In the Zed release os-brick started needing to be initialized by calling a `setup` method before the library could be used. At that time there was only 1 feature that depended on it and it was possible to introduce a failsafe for that instance so things wouldn't break. In the Antelope release that failsafe should have been removed from os- brick and all projects should have been calling the `setup` method. Currently nova is not initializing os-brick, so if os-brick removes the failsafe the behavior in os-brick locks will break backward compatibility. Related os-brick patch: https://review.opendev.org/c/openstack/os- brick/+/849324 ** Affects: nova Importance: Undecided 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/2081859 Title: Nova not initializing os-brick Status in OpenStack Compute (nova): In Progress Bug description: In the Zed release os-brick started needing to be initialized by calling a `setup` method before the library could be used. At that time there was only 1 feature that depended on it and it was possible to introduce a failsafe for that instance so things wouldn't break. In the Antelope release that failsafe should have been removed from os-brick and all projects should have been calling the `setup` method. Currently nova is not initializing os-brick, so if os-brick removes the failsafe the behavior in os-brick locks will break backward compatibility. Related os-brick patch: https://review.opendev.org/c/openstack/os- brick/+/849324 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2081859/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2081853] [NEW] Booting two VMs with anti-affinity in parallel to the same host results in both failing
Public bug reported: The compute manager late anti-affinity policy check rejects both parallel VM boot requests even though one of them could be accepted to the host. To reproduce: * create server group with anti-affinity policy * select a single compute and disable the rest of your computes * boot two VMs in parallel Expected: One of the two VMs succeeds to boot the other VM fails with NoValidHost. Actual: If you are (un)lucky then both VMs will fail with nova.exception.GroupAffinityViolation ``` ❯ journalctl -D sosreport-compute-1-2024-09-17-tzgxrpu/var/log/journal/730eba01f47f493698df59515d1c213a -u edpm_nova_compute | grep 9d115f6b-bb02-4390-a161-15fb8f83c0cc | grep nova.exception.GroupAffinityViolation: Sep 17 02:05:36 compute-1 nova_compute[84038]: 2024-09-17 00:05:36.406 2 ERROR nova.compute.manager [None req-a5316266-aca0-4d11-90f9-631e26d058ab 188fff18565b4e46b0c04391ec532b3e b698d1d3bfeb4a75bf32b7a80d19dd46 - - default default] [instance: 9d115f6b-bb02-4390-a161-15fb8f83c0cc] Failed to build and run instance: nova.exception.GroupAffinityViolation: Anti-affinity instance group policy was violated Sep 17 02:05:36 compute-1 nova_compute[84038]: 2024-09-17 00:05:36.406 2 ERROR nova.compute.manager [instance: 9d115f6b-bb02-4390-a161-15fb8f83c0cc] nova.exception.GroupAffinityViolation: Anti-affinity instance group policy was violated ❯ journalctl -D sosreport-compute-1-2024-09-17-tzgxrpu/var/log/journal/730eba01f47f493698df59515d1c213a -u edpm_nova_compute | grep ea192e6a-4685-45ae-839b-315dfd36697d | grep nova.exception.GroupAffinityViolation Sep 17 02:05:36 compute-1 nova_compute[84038]: 2024-09-17 00:05:36.132 2 ERROR nova.compute.manager [None req-b37d5098-75bf-4a3c-a85d-6f2ccdf0104f 188fff18565b4e46b0c04391ec532b3e b698d1d3bfeb4a75bf32b7a80d19dd46 - - default default] [instance: ea192e6a-4685-45ae-839b-315dfd36697d] Failed to build and run instance: nova.exception.GroupAffinityViolation: Anti-affinity instance group policy was violated Sep 17 02:05:36 compute-1 nova_compute[84038]: 2024-09-17 00:05:36.132 2 ERROR nova.compute.manager [instance: ea192e6a-4685-45ae-839b-315dfd36697d] nova.exception.GroupAffinityViolation: Anti-affinity instance group policy was violated ``` There is a functional reproduce pushed in https://review.opendev.org/c/openstack/nova/+/930326 ** Affects: nova Importance: Undecided Status: New ** Tags: compute scheduler ** Tags added: compute scheduler ** Description changed: The compute manager late anti-affinity policy check rejects both parallel VM boot requests even though one of them could be accepted to the host. To reproduce: * create server group with anti-affinity policy * select a single compute and disable the rest of your computes * boot two VMs in parallel Expected: One of the two VMs succeeds to boot the other VM fails with NoValidHost. Actual: - If you are (un)lucky then both VM will fail with nova.exception.GroupAffinityViolation + If you are (un)lucky then both VMs will fail with nova.exception.GroupAffinityViolation ``` ❯ journalctl -D sosreport-compute-1-2024-09-17-tzgxrpu/var/log/journal/730eba01f47f493698df59515d1c213a -u edpm_nova_compute | grep 9d115f6b-bb02-4390-a161-15fb8f83c0cc | grep nova.exception.GroupAffinityViolation: Sep 17 02:05:36 compute-1 nova_compute[84038]: 2024-09-17 00:05:36.406 2 ERROR nova.compute.manager [None req-a5316266-aca0-4d11-90f9-631e26d058ab 188fff18565b4e46b0c04391ec532b3e b698d1d3bfeb4a75bf32b7a80d19dd46 - - default default] [instance: 9d115f6b-bb02-4390-a161-15fb8f83c0cc] Failed to build and run instance: nova.exception.GroupAffinityViolation: Anti-affinity instance group policy was violated Sep 17 02:05:36 compute-1 nova_compute[84038]: 2024-09-17 00:05:36.406 2 ERROR nova.compute.manager [instance: 9d115f6b-bb02-4390-a161-15fb8f83c0cc] nova.exception.GroupAffinityViolation: Anti-affinity instance group policy was violated ❯ journalctl -D sosreport-compute-1-2024-09-17-tzgxrpu/var/log/journal/730eba01f47f493698df59515d1c213a -u edpm_nova_compute | grep ea192e6a-4685-45ae-839b-315dfd36697d | grep nova.exception.GroupAffinityViolation Sep 17 02:05:36 compute-1 nova_compute[84038]: 2024-09-17 00:05:36.132 2 ERROR nova.compute.manager [None req-b37d5098-75bf-4a3c-a85d-6f2ccdf0104f 188fff18565b4e46b0c04391ec532b3e b698d1d3bfeb4a75bf32b7a80d19dd46 - - default default] [instance: ea192e6a-4685-45ae-839b-315dfd36697d] Failed to build and run instance: nova.exception.GroupAffinityViolation: Anti-affinity instance group policy was violated Sep 17 02:05:36 compute-1 nova_compute[84038]: 2024-09-17 00:05:36.132 2 ERROR nova.compute.manager [instance: ea192e6a-4685-45ae-839b-315dfd36697d] nova.exception.GroupAffinityViolation: Anti-affinity instance group policy was violated ``` There is a functional reproduce pushed in https://review.opendev.org/c/openstack/nova/+/930326 -- You received this bug n
[Yahoo-eng-team] [Bug 2081879] [NEW] Allow the default for "Delete Volume on Instance Delete" instance creation option to be configurable
Public bug reported:
When creating an instance with the "Create New Volume" option selected
(the default), there's an option to "Delete Volume on Instance Delete"
which defaults to "No". This default is hard-coded, and is a sensible
default, but there are situations when an operator may wish to change
the default to "Yes". I'm in that position where we have a more
controlled use case and don't want users accidentally leaving orphaned
volumes behind.
A simple change to allow this is:
---
horizon-24.0.0.orig/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/launch-instance-model.service.js
+++
horizon-24.0.0/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/launch-instance-model.service.js
@@ -309,6 +309,9 @@
if ('default_availability_zone' in defaults) {
model.default_availability_zone = defaults.default_availability_zone;
}
+ if ('vol_delete_on_instance_delete' in defaults) {
+model.newInstanceSpec.vol_delete_on_instance_delete =
defaults.vol_delete_on_instance_delete;
+ }
}
/**
---
horizon-24.0.0.orig/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/source/source.controller.js
+++
horizon-24.0.0/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/source/source.controller.js
@@ -471,7 +471,7 @@
} else {
$scope.model.newInstanceSpec.vol_create = false;
}
- $scope.model.newInstanceSpec.vol_delete_on_instance_delete = false;
+ //$scope.model.newInstanceSpec.vol_delete_on_instance_delete = false;
changeBootSource(selectedSource, preSelection);
validateBootSourceType();
}
This doesn't alter the existing behaviour by default, but does allow
local_settings.py to optionally contain:
LAUNCH_INSTANCE_DEFAULTS.update({
'vol_delete_on_instance_delete': True,
})
Which then changes the default for "Delete Volume on Instance Delete" to
"Yes" in the web interface.
Change tested against 24.0.0.
** Affects: horizon
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/2081879
Title:
Allow the default for "Delete Volume on Instance Delete" instance
creation option to be configurable
Status in OpenStack Dashboard (Horizon):
New
Bug description:
When creating an instance with the "Create New Volume" option selected
(the default), there's an option to "Delete Volume on Instance Delete"
which defaults to "No". This default is hard-coded, and is a sensible
default, but there are situations when an operator may wish to change
the default to "Yes". I'm in that position where we have a more
controlled use case and don't want users accidentally leaving orphaned
volumes behind.
A simple change to allow this is:
---
horizon-24.0.0.orig/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/launch-instance-model.service.js
+++
horizon-24.0.0/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/launch-instance-model.service.js
@@ -309,6 +309,9 @@
if ('default_availability_zone' in defaults) {
model.default_availability_zone = defaults.default_availability_zone;
}
+ if ('vol_delete_on_instance_delete' in defaults) {
+model.newInstanceSpec.vol_delete_on_instance_delete =
defaults.vol_delete_on_instance_delete;
+ }
}
/**
---
horizon-24.0.0.orig/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/source/source.controller.js
+++
horizon-24.0.0/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/source/source.controller.js
@@ -471,7 +471,7 @@
} else {
$scope.model.newInstanceSpec.vol_create = false;
}
- $scope.model.newInstanceSpec.vol_delete_on_instance_delete = false;
+ //$scope.model.newInstanceSpec.vol_delete_on_instance_delete = false;
changeBootSource(selectedSource, preSelection);
validateBootSourceType();
}
This doesn't alter the existing behaviour by default, but does allow
local_settings.py to optionally contain:
LAUNCH_INSTANCE_DEFAULTS.update({
'vol_delete_on_instance_delete': True,
})
Which then changes the default for "Delete Volume on Instance Delete"
to "Yes" in the web interface.
Change tested against 24.0.0.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/2081879/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2081878] [NEW] Allow the default for "Delete Volume on Instance Delete" instance creation option to be configurable
Public bug reported:
When creating an instance with the "Create New Volume" option selected
(the default), there's an option to "Delete Volume on Instance Delete"
which defaults to "No". This default is hard-coded, and is a sensible
default, but there are situations when an operator may wish to change
the default to "Yes". I'm in that position where we have a more
controlled use case and don't want users accidentally leaving orphaned
volumes behind.
A simple change to allow this is:
---
horizon-24.0.0.orig/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/launch-instance-model.service.js
+++
horizon-24.0.0/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/launch-instance-model.service.js
@@ -309,6 +309,9 @@
if ('default_availability_zone' in defaults) {
model.default_availability_zone = defaults.default_availability_zone;
}
+ if ('vol_delete_on_instance_delete' in defaults) {
+model.newInstanceSpec.vol_delete_on_instance_delete =
defaults.vol_delete_on_instance_delete;
+ }
}
/**
---
horizon-24.0.0.orig/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/source/source.controller.js
+++
horizon-24.0.0/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/source/source.controller.js
@@ -471,7 +471,7 @@
} else {
$scope.model.newInstanceSpec.vol_create = false;
}
- $scope.model.newInstanceSpec.vol_delete_on_instance_delete = false;
+ //$scope.model.newInstanceSpec.vol_delete_on_instance_delete = false;
changeBootSource(selectedSource, preSelection);
validateBootSourceType();
}
This doesn't alter the existing behaviour by default, but does allow
local_settings.py to optionally contain:
LAUNCH_INSTANCE_DEFAULTS.update({
'vol_delete_on_instance_delete': True,
})
Which then changes the default for "Delete Volume on Instance Delete" to
"Yes" in the web interface.
Change tested against 24.0.0.
** Affects: horizon
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/2081878
Title:
Allow the default for "Delete Volume on Instance Delete" instance
creation option to be configurable
Status in OpenStack Dashboard (Horizon):
New
Bug description:
When creating an instance with the "Create New Volume" option selected
(the default), there's an option to "Delete Volume on Instance Delete"
which defaults to "No". This default is hard-coded, and is a sensible
default, but there are situations when an operator may wish to change
the default to "Yes". I'm in that position where we have a more
controlled use case and don't want users accidentally leaving orphaned
volumes behind.
A simple change to allow this is:
---
horizon-24.0.0.orig/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/launch-instance-model.service.js
+++
horizon-24.0.0/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/launch-instance-model.service.js
@@ -309,6 +309,9 @@
if ('default_availability_zone' in defaults) {
model.default_availability_zone = defaults.default_availability_zone;
}
+ if ('vol_delete_on_instance_delete' in defaults) {
+model.newInstanceSpec.vol_delete_on_instance_delete =
defaults.vol_delete_on_instance_delete;
+ }
}
/**
---
horizon-24.0.0.orig/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/source/source.controller.js
+++
horizon-24.0.0/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/source/source.controller.js
@@ -471,7 +471,7 @@
} else {
$scope.model.newInstanceSpec.vol_create = false;
}
- $scope.model.newInstanceSpec.vol_delete_on_instance_delete = false;
+ //$scope.model.newInstanceSpec.vol_delete_on_instance_delete = false;
changeBootSource(selectedSource, preSelection);
validateBootSourceType();
}
This doesn't alter the existing behaviour by default, but does allow
local_settings.py to optionally contain:
LAUNCH_INSTANCE_DEFAULTS.update({
'vol_delete_on_instance_delete': True,
})
Which then changes the default for "Delete Volume on Instance Delete"
to "Yes" in the web interface.
Change tested against 24.0.0.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/2081878/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2079850] Re: Ephemeral with vfat format fails inspection
Reviewed: https://review.opendev.org/c/openstack/oslo.utils/+/928448 Committed: https://opendev.org/openstack/oslo.utils/commit/3c33e37d64e44addc9a818bd556f5919ed2e9002 Submitter: "Zuul (22348)" Branch:master commit 3c33e37d64e44addc9a818bd556f5919ed2e9002 Author: Dan Smith Date: Fri Sep 6 07:51:13 2024 -0700 Avoid detecting FAT VBR as an MBR The 1980s FAT filesystem has a VBR in the first sector, which looks almost exactly like an MBR with zero partitions. To avoid detecting these as MBRs, look for some extra attributes that indicate that the structure is a VBR and avoid matching it as a GPT/MBR in that case. We can add an inspector for this as a separate thing, but at the moment we don't have that immediate need. Closes-Bug: #2079850 Change-Id: Ibad87743b5a3b6469bd708d4caafe7911b045855 ** Changed in: oslo.utils Status: In Progress => 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/2079850 Title: Ephemeral with vfat format fails inspection Status in OpenStack Compute (nova): Fix Released Status in oslo.utils: Fix Released Bug description: When configured to format ephemerals as vfat, we get this failure: Sep 03 17:34:28 compute-2 nova_compute[133243]: 2024-09-03 17:34:28.358 2 DEBUG oslo_utils.imageutils.format_inspector [None req-fcf3a278-3417-4a6d-8b10-66e91ca1677d 60ed4d3e522640b6ad19633b28c5b5bb ae43aec9c3c242a785c8256abdda1747 - - default default] Format inspector failed, aborting: Signature KDMV not found: b'\xebX\x90m' _process_chunk /usr/lib/python3.9/site-packages/oslo_utils/imageutils/format_inspector.py:1302 Sep 03 17:34:28 compute-2 nova_compute[133243]: 2024-09-03 17:34:28.365 2 DEBUG oslo_utils.imageutils.format_inspector [None req-fcf3a278-3417-4a6d-8b10-66e91ca1677d 60ed4d3e522640b6ad19633b28c5b5bb ae43aec9c3c242a785c8256abdda1747 - - default default] Format inspector failed, aborting: Region signature not found at 3 _process_chunk /usr/lib/python3.9/site-packages/oslo_utils/imageutils/format_inspector.py:1302 Sep 03 17:34:28 compute-2 nova_compute[133243]: 2024-09-03 17:34:28.366 2 WARNING oslo_utils.imageutils.format_inspector [None req-fcf3a278-3417-4a6d-8b10-66e91ca1677d 60ed4d3e522640b6ad19633b28c5b5bb ae43aec9c3c242a785c8256abdda1747 - - default default] Safety check mbr on gpt failed because GPT MBR has no partitions defined: oslo_utils.imageutils.format_inspector.SafetyViolation: GPT MBR has no partitions defined Sep 03 17:34:28 compute-2 nova_compute[133243]: 2024-09-03 17:34:28.366 2 WARNING nova.virt.libvirt.imagebackend [None req-fcf3a278-3417-4a6d-8b10-66e91ca1677d 60ed4d3e522640b6ad19633b28c5b5bb ae43aec9c3c242a785c8256abdda1747 - - default default] Base image /var/lib/nova/instances/_base/ephemeral_1_0706d66 failed safety check: Safety checks failed: mbr: oslo_utils.imageutils.format_inspector.SafetyCheckFailed: Safety checks failed: mbr Sep 03 17:34:28 compute-2 nova_compute[133243]: 2024-09-03 17:34:28.367 2 ERROR nova.compute.manager [None req-fcf3a278-3417-4a6d-8b10-66e91ca1677d 60ed4d3e522640b6ad19633b28c5b5bb ae43aec9c3c242a785c8256abdda1747 - - default default] [instance: 263ccd01-10b1-46a6-9f81-a6fc27c7177a] Instance failed to spawn: nova.exception.InvalidDiskInfo: Disk info file is invalid: Base image failed safety check Sep 03 17:34:28 compute-2 nova_compute[133243]: 2024-09-03 17:34:28.367 2 ERROR nova.compute.manager [instance: 263ccd01-10b1-46a6-9f81-a6fc27c7177a] Traceback (most recent call last): Sep 03 17:34:28 compute-2 nova_compute[133243]: 2024-09-03 17:34:28.367 2 ERROR nova.compute.manager [instance: 263ccd01-10b1-46a6-9f81-a6fc27c7177a] File "/usr/lib/python3.9/site-packages/nova/virt/libvirt/imagebackend.py", line 685, in create_image Sep 03 17:34:28 compute-2 nova_compute[133243]: 2024-09-03 17:34:28.367 2 ERROR nova.compute.manager [instance: 263ccd01-10b1-46a6-9f81-a6fc27c7177a] inspector.safety_check() Sep 03 17:34:28 compute-2 nova_compute[133243]: 2024-09-03 17:34:28.367 2 ERROR nova.compute.manager [instance: 263ccd01-10b1-46a6-9f81-a6fc27c7177a] File "/usr/lib/python3.9/site-packages/oslo_utils/imageutils/format_inspector.py", line 430, in safety_check Sep 03 17:34:28 compute-2 nova_compute[133243]: 2024-09-03 17:34:28.367 2 ERROR nova.compute.manager [instance: 263ccd01-10b1-46a6-9f81-a6fc27c7177a] raise SafetyCheckFailed(failures) Sep 03 17:34:28 compute-2 nova_compute[133243]: 2024-09-03 17:34:28.367 2 ERROR nova.compute.manager [instance: 263ccd01-10b1-46a6-9f81-a6fc27c7177a] oslo_utils.imageutils.format_inspector.SafetyCheckFailed: Safety checks failed: mbr Sep 03 17:34:28 compute-2 nova_compute[133243]: 2024-09-03 17:34:28.367 2 ERROR nova.compute.manager [instance: 263ccd01-10b1-46a6-9f81-a6fc27c7177a] Sep 03 17:34:28 compute-2 nova_c
[Yahoo-eng-team] [Bug 2081945] [NEW] [postgresql] AttributeError: 'NoneType' object has no attribute 'id'
Public bug reported: Neutron API failing with the following error: ``` AttributeError: 'NoneType' object has no attribute 'id' ``` Log: https://e22ff80d6617e0aebdbb- fab3512704550cb902a3eea3d4491f2b.ssl.cf1.rackcdn.com/periodic/opendev.org/openstack/neutron/master/neutron- ovn-tempest-postgres-full/6b355b7/controller/logs/screen-q-svc.txt Snippet: https://paste.opendev.org/show/bx6fuJBVC2RvjVHDH7Ug/ This bug is related to https://bugs.launchpad.net/neutron/+bug/2078787. ** Affects: neutron Importance: Undecided Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) Status: New ** Changed in: neutron Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2081945 Title: [postgresql] AttributeError: 'NoneType' object has no attribute 'id' Status in neutron: New Bug description: Neutron API failing with the following error: ``` AttributeError: 'NoneType' object has no attribute 'id' ``` Log: https://e22ff80d6617e0aebdbb- fab3512704550cb902a3eea3d4491f2b.ssl.cf1.rackcdn.com/periodic/opendev.org/openstack/neutron/master/neutron- ovn-tempest-postgres-full/6b355b7/controller/logs/screen-q-svc.txt Snippet: https://paste.opendev.org/show/bx6fuJBVC2RvjVHDH7Ug/ This bug is related to https://bugs.launchpad.net/neutron/+bug/2078787. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2081945/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
