[Yahoo-eng-team] [Bug 1988220] Re: large unused dependency ncclient + paramiko in os-ken
Hello Josh: The "ncclient" library is currently used in the "os-ken" project: https://codesearch.openstack.org/?q=ncclient&i=nope&literal=nope&files=&excludeFiles=&repos=openstack/os- ken. I can't remove this dependency. Regards. ** Changed in: neutron Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1988220 Title: large unused dependency ncclient + paramiko in os-ken Status in neutron: Won't Fix Bug description: Hello, ncclient which adds paramiko as a dependency, was added as a dependency in os-ken 2.5.0, though ncclient doesn't appear to be actually used anywhere (https://github.com/openstack/os- ken/commit/2495ebdff927a3de2f642b3346ed4f438b2c6316). Would it be possible for this dependency to be removed? It is not used - it increases os-ken's footprint substantially, and for non-x86 platforms wheels have to be built, which is very resource intensive. Thanks, To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1988220/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1988281] [NEW] neutron dhcp agent state not consistent with real status
Public bug reported: We are observing that neutron-dhcp-agent's state is deviating from "real state", by saying real state, I mean all hosted dnsmasq are running and configured. For example, agent A is hosting 1,000 networks, if I reboot agent A then all dnsmasq processes are gone, and dhcp agent will try to reboot every dnsmasq, this will introduce a long delay between agent start and agent handles new rabbitmq messages. But weirdly, openstack network agent list will show that the agent is up and running which IMO is inconsistent. I think under this situation, openstack network agent list should report the corresponding agent to be down. ** Affects: neutron Importance: Undecided Status: New ** Description changed: - We are observing that neutron-dhcp-agent's state is deviating from "real state", by saying real state, I mean - all hosted dnsmasq are running and configured. For example, agent A is hosting 1,000 networks, if I reboot agent A then all dnsmasq processes are gone, and dhcp agent will try to reboot every dnsmasq, this will introduce a long delay between agent start and agent handles new rabbitmq messages. But weirdly, openstack network agent list will show that the agent is up and running which IMO is inconsistent. + We are observing that neutron-dhcp-agent's state is deviating from "real + state", by saying real state, I mean all hosted dnsmasq are running and + configured. + + For example, agent A is hosting 1,000 networks, if I reboot agent A then + all dnsmasq processes are gone, and dhcp agent will try to reboot every + dnsmasq, this will introduce a long delay between agent start and agent + handles new rabbitmq messages. But weirdly, openstack network agent list + will show that the agent is up and running which IMO is inconsistent. I + think under this situation, openstack network agent list should report + the corresponding agent to be down. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1988281 Title: neutron dhcp agent state not consistent with real status Status in neutron: New Bug description: We are observing that neutron-dhcp-agent's state is deviating from "real state", by saying real state, I mean all hosted dnsmasq are running and configured. For example, agent A is hosting 1,000 networks, if I reboot agent A then all dnsmasq processes are gone, and dhcp agent will try to reboot every dnsmasq, this will introduce a long delay between agent start and agent handles new rabbitmq messages. But weirdly, openstack network agent list will show that the agent is up and running which IMO is inconsistent. I think under this situation, openstack network agent list should report the corresponding agent to be down. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1988281/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1988297] [NEW] Duplicate index external_id in table access_rule of keystone database
Public bug reported: Currently the primary key and an additional unique index are configured on the same column. This is why sqlalchemy logs a warning on a database migration displaying following information: ``` /usr/lib/python3/dist-packages/pymysql/cursors.py:170: Warning: (1831, 'Duplicate index `uniq_instances0uuid`. This is deprecated and will be disallowed in a future release') result = self._query(query) ``` (This example is actually taken from the nova output, but looks just the same for Keystone. There actually is the same issue within Nova schemas, see bug https://bugs.launchpad.net/nova/+bug/1641185) From my understanding of the documentation of mysql (see [1] [2]) and postgres (see [3] [4]) a unique constraint, which is created in the first place, automatically creates an index for the column(s). So there should be no need to create an additional index for the same column: ``` Table: access_rule (https://opendev.org/openstack/keystone/src/commit/7c2d0f589c8daf5c65a80ed20d1e7fbfcc282312/keystone/common/sql/migrations/versions/27e647c0fad4_initial_version.py#L120) Column: external_id Indexes: Unique Constraint: access_rule_external_id_key Index: external_id ``` [1] https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-unique [2] https://dev.mysql.com/doc/refman/8.0/en/mysql-indexes.html [3] https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS [4] https://www.postgresql.org/docs/current/indexes-types.html ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1988297 Title: Duplicate index external_id in table access_rule of keystone database Status in OpenStack Identity (keystone): New Bug description: Currently the primary key and an additional unique index are configured on the same column. This is why sqlalchemy logs a warning on a database migration displaying following information: ``` /usr/lib/python3/dist-packages/pymysql/cursors.py:170: Warning: (1831, 'Duplicate index `uniq_instances0uuid`. This is deprecated and will be disallowed in a future release') result = self._query(query) ``` (This example is actually taken from the nova output, but looks just the same for Keystone. There actually is the same issue within Nova schemas, see bug https://bugs.launchpad.net/nova/+bug/1641185) From my understanding of the documentation of mysql (see [1] [2]) and postgres (see [3] [4]) a unique constraint, which is created in the first place, automatically creates an index for the column(s). So there should be no need to create an additional index for the same column: ``` Table: access_rule (https://opendev.org/openstack/keystone/src/commit/7c2d0f589c8daf5c65a80ed20d1e7fbfcc282312/keystone/common/sql/migrations/versions/27e647c0fad4_initial_version.py#L120) Column: external_id Indexes: Unique Constraint: access_rule_external_id_key Index: external_id ``` [1] https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-unique [2] https://dev.mysql.com/doc/refman/8.0/en/mysql-indexes.html [3] https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS [4] https://www.postgresql.org/docs/current/indexes-types.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1988297/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1988296] [NEW] neutron-lib pep8 CI failing with pylint==2.15.0
Public bug reported: Error: https://paste.opendev.org/show/bvMNn5rrf87eBwCVKV4W/ pylint 2.15.0 released on August 26th, 2022: https://pypi.org/project/pylint/#history ** Affects: neutron Importance: Undecided Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez) ** Description changed: Error: https://paste.opendev.org/show/bvMNn5rrf87eBwCVKV4W/ + + pylint 2.15.0 released on August 26th, 2022: + https://pypi.org/project/pylint/#history -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1988296 Title: neutron-lib pep8 CI failing with pylint==2.15.0 Status in neutron: In Progress Bug description: Error: https://paste.opendev.org/show/bvMNn5rrf87eBwCVKV4W/ pylint 2.15.0 released on August 26th, 2022: https://pypi.org/project/pylint/#history To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1988296/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1988298] [NEW] [neutron-lib] "registry.has_resource_extenders" is the same as "resource_extend.has_resource_extenders"
Public bug reported: has_resource_extenders: https://github.com/openstack/neutron- lib/blob/f01b2e9025d33aeff3bf22ea2568bda036878819/neutron_lib/db/resource_extend.py#L112-L153 has_registry_receivers: https://github.com/openstack/neutron- lib/blob/f01b2e9025d33aeff3bf22ea2568bda036878819/neutron_lib/callbacks/registry.py#L85-L126 ** 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/1988298 Title: [neutron-lib] "registry.has_resource_extenders" is the same as "resource_extend.has_resource_extenders" Status in neutron: New Bug description: has_resource_extenders: https://github.com/openstack/neutron- lib/blob/f01b2e9025d33aeff3bf22ea2568bda036878819/neutron_lib/db/resource_extend.py#L112-L153 has_registry_receivers: https://github.com/openstack/neutron- lib/blob/f01b2e9025d33aeff3bf22ea2568bda036878819/neutron_lib/callbacks/registry.py#L85-L126 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1988298/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1988311] [NEW] Concurrent evacuation of vms with pinned cpus to the same host fail randomly
Public bug reported:
Reproduction:
Boot two vms (each with one pinned cpu) on devstack0.
Then evacuate them to devtack0a.
devstack0a has two dedicated cpus, so both vms should fit.
However sometimes (for example 6 out of 10 times) the evacuation of one vm
fails with this error message: 'CPU set to pin [0] must be a subset of free CPU
set [1]'.
devstack0 - all-in-one host
devstack0a - compute-only host
# have two dedicated cpus for pinning on the evacuation target host
devstack0a:/etc/nova/nova-cpu.conf:
[compute]
cpu_dedicated_set = 0,1
# the dedicated cpus are properly tracked in placement
$ openstack resource provider list
+--+++--+--+
| uuid | name | generation |
root_provider_uuid | parent_provider_uuid |
+--+++--+--+
| a0574d87-42ee-4e13-b05a-639dc62c1196 | devstack0a | 2 |
a0574d87-42ee-4e13-b05a-639dc62c1196 | None |
| 2e6fac42-d6e3-4366-a864-d5eb2bdc2241 | devstack0 | 2 |
2e6fac42-d6e3-4366-a864-d5eb2bdc2241 | None |
+--+++--+--+
$ openstack resource provider inventory list
a0574d87-42ee-4e13-b05a-639dc62c1196
++--+--+--+--+---+---+--+
| resource_class | allocation_ratio | min_unit | max_unit | reserved |
step_size | total | used |
++--+--+--+--+---+---+--+
| MEMORY_MB | 1.5 |1 | 3923 | 512 |
1 | 3923 |0 |
| DISK_GB| 1.0 |1 | 28 |0 |
1 |28 |0 |
| PCPU | 1.0 |1 |2 |0 |
1 | 2 |0 |
++--+--+--+--+---+---+--+
# use vms with one pinned cpu
openstack flavor create cirros256-pinned --public --ram 256 --disk 1 --vcpus 1
--property hw_rng:allowed=True --property hw:cpu_policy=dedicated
# boot two vms (each with one pinned cpu) on devstack0
n=2 ; for i in $( seq $n ) ; do openstack server create --flavor
cirros256-pinned --image cirros-0.5.2-x86_64-disk --nic net-id=private
--availability-zone :devstack0 --wait vm$i ; done
# kill n-cpu on devstack0
devstack0 $ sudo systemctl stop devstack@n-cpu
# and force it down, so we can start evacuating
openstack compute service set devstack0 nova-compute --down
# evacuate both vms to devstack0a concurrently
for vm in $( openstack server list --host devstack0 -f value -c ID ) ; do
openstack --os-compute-api-version 2.29 server evacuate --host devstack0a $vm &
done
# follow up on how the evacuation is going, check if the bug occured, see
details a bit below
for i in $( seq $n ) ; do openstack server show vm$i -f value -c
OS-EXT-SRV-ATTR:host -c status ; done
# clean up
devstack0 $ sudo systemctl start devstack@n-cpu
openstack compute service set devstack0 nova-compute --up
for i in $( seq $n ) ; do openstack server delete vm$i --wait ; done
This bug is not deterministic. For example out of 10 tries (like above)
I have seen 4 successes - when both vms successfully evacuated to (went
to ACTIVE on) devstack0a.
But in the other 6 cases only one vm evacuated successfully. The other
vm went to ERROR state, with the error message: "CPU set to pin [0] must
be a subset of free CPU set [1]". For example:
$ openstack server show vm2
...
| fault | {'code': 400, 'created':
'2022-08-24T13:50:33Z', 'message': 'CPU set to pin [0] must be a subset of free
CPU set [1]'} |
...
In n-cpu logs we see the following:
aug 24 13:50:33 devstack0a nova-compute[246038]: ERROR nova.compute.manager
[None req-278f5b67-a765-4231-b2b9-db3f8c7fe092 admin admin] [instance:
dc3acde3-f1c6-41a9-9a12-0c278ad4b348] Setting instance vm_state to ERROR:
nova.exception.CPUPinningInvalid: CPU set to pin [0] must be a subset of free
CPU set [1]
aug 24 13:50:33 devstack0a nova-compute[246038]: ERROR nova.compute.manager
[instance: dc3acde3-f1c6-41a9-9a12-0c278ad4b348] Traceback (most recent call
last):
aug 24 13:50:33 devstack0a nova-compute[246038]: ERROR nova.compute.manager
[instance: dc3acde3-f1c6-41a9-9a12-0c278ad4b348] File
"/opt/stack/nova/nova/compute/manager.py", line 10375, in
_error_out_instance_on_exception
aug 24 13:50:33 devstack0a nova-compute[246038]: ERROR nova.compute.manager
[instance: dc3acde3-f1c6-41a9-9a12-0c278ad4b348] yield
aug 24 13:50:33 devstack0a nova-compute[246038]: ERROR nova.compute.manager
[instance: dc3acde3-f1c6-41a9-9a12-0c278ad4b348] File
"/opt/st
[Yahoo-eng-team] [Bug 1988302] Re: novncproxy open redirect
*** This bug is a duplicate of bug 1927677 *** https://bugs.launchpad.net/bugs/1927677 That would be a question for the Ubuntu package maintainers, but we did publish backports to the stable/train branch for that advisory and its errata. Thanks for confirming this is the same issue, I'll switch this report to public and mark it as a duplicate of bug 1927677. ** Information type changed from Private Security to Public Security ** This bug has been marked a duplicate of bug 1927677 [OSSA-2021-002] Open Redirect in noVNC proxy (CVE-2021-3654) ** Description changed: - This issue is being treated as a potential security risk under - embargo. Please do not make any public mention of embargoed - (private) security vulnerabilities before their coordinated - publication by the OpenStack Vulnerability Management Team in the - form of an official OpenStack Security Advisory. This includes - discussion of the bug or associated fixes in public forums such as - mailing lists, code review systems and bug trackers. Please also - avoid private disclosure to other individuals not already approved - for access to this information, and provide this same reminder to - those who are made aware of the issue prior to publication. All - discussion should remain confined to this private bug report, and - any proposed fixes should be added to the bug as attachments. This - embargo shall not extend past 2022-11-29 and will be made - public by or on that date even if no fix is identified. - Security Issue == We have found an open redirect vulnerability in Nova novncproxy Impact == - Attackers can serve malicious websites that steal passwords or download ransomware to their victims' machines due to a redirect and there are a heap of other attack vectors. - Attackers may be able to use this to execute believable phishing attacks, bypass authentication, or (in rare circumstances) violate CSRF mitigations. Steps to Reproduce == Simple curl the below url and it will redirect to google.com http://nova-novncproxy:6080google.com/%2f%2e%2e Example === $ curl "http://nova-novncproxy:6080google.com/%2f.."; -v * Trying 10.X.Y.Z... * TCP_NODELAY set * Connected to nova-novncproxy (10.X.Y.Z) port 6080 (#0) > GET google.com/%2f.. HTTP/1.1 > Host: nova-novncproxy:6080 > User-Agent: curl/7.58.0 > Accept: */* > < HTTP/1.1 301 Moved Permanently < Server: WebSockify Python/3.6.9 < Date: Wed, 31 Aug 2022 11:59:29 GMT < Location: //google.com/%2f../ Reference = https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html -- 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/1988302 Title: novncproxy open redirect Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Incomplete Bug description: Security Issue == We have found an open redirect vulnerability in Nova novncproxy Impact == - Attackers can serve malicious websites that steal passwords or download ransomware to their victims' machines due to a redirect and there are a heap of other attack vectors. - Attackers may be able to use this to execute believable phishing attacks, bypass authentication, or (in rare circumstances) violate CSRF mitigations. Steps to Reproduce == Simple curl the below url and it will redirect to google.com http://nova-novncproxy:6080google.com/%2f%2e%2e Example === $ curl "http://nova-novncproxy:6080google.com/%2f.."; -v * Trying 10.X.Y.Z... * TCP_NODELAY set * Connected to nova-novncproxy (10.X.Y.Z) port 6080 (#0) > GET google.com/%2f.. HTTP/1.1 > Host: nova-novncproxy:6080 > User-Agent: curl/7.58.0 > Accept: */* > < HTTP/1.1 301 Moved Permanently < Server: WebSockify Python/3.6.9 < Date: Wed, 31 Aug 2022 11:59:29 GMT < Location: //google.com/%2f../ Reference = https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1988302/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1988316] [NEW] unshelve to host fails with "Compute host could not be found" even when the compute exists
Public bug reported:
We observed that the recently merged
test_unshelve_to_specific_host[id-b5cc0889-50c2-46a0-b8ff-b5fb4c3a6e20] tempest
test case 100% fails in the nova-multi-cell job with:
Details: {'code': 400, 'message': 'Compute host ubuntu-focal-rax-dfw-0030919238
could not be found.'}[1]
Even thought the requested host do exists, up and enabled.
The problem appears to be that the compute.api.API.unshelve() code,
running the compute-api service tries to queries the Cell DB to check
the provided hostname without targeting the context to the proper Cell
DB [2].
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi Traceback (most
recent call last):
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi File
"/opt/stack/nova/nova/api/openstack/compute/shelve.py", line 124, in _unshelve
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi
self.compute_api.unshelve(
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi File
"/opt/stack/nova/nova/compute/api.py", line 388, in inner
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi return
function(self, context, instance, *args, **kwargs)
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi File
"/opt/stack/nova/nova/compute/api.py", line 241, in inner
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi return
function(self, context, instance, *args, **kwargs)
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi File
"/opt/stack/nova/nova/compute/api.py", line 167, in inner
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi return f(self,
context, instance, *args, **kw)
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi File
"/opt/stack/nova/nova/compute/api.py", line 4577, in unshelve
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi
objects.ComputeNode.get_first_node_by_host_for_old_compat(
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi File
"/usr/local/lib/python3.8/dist-packages/oslo_versionedobjects/base.py", line
184, in wrapper
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi result =
fn(cls, context, *args, **kwargs)
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi File
"/opt/stack/nova/nova/objects/compute_node.py", line 293, in
get_first_node_by_host_for_old_compat
Aug 31 12:35:18.468701 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi computes =
ComputeNodeList.get_all_by_host(context, host, use_slave)
Aug 31 12:35:18.470614 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi File
"/usr/local/lib/python3.8/dist-packages/oslo_versionedobjects/base.py", line
184, in wrapper
Aug 31 12:35:18.470614 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi result =
fn(cls, context, *args, **kwargs)
Aug 31 12:35:18.470614 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi File
"/opt/stack/nova/nova/objects/compute_node.py", line 476, in get_all_by_host
Aug 31 12:35:18.470614 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi db_computes =
cls._db_compute_node_get_all_by_host(context, host,
Aug 31 12:35:18.470614 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi File
"/opt/stack/nova/nova/db/main/api.py", line 179, in wrapper
Aug 31 12:35:18.470614 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi return
f(*args, **kwargs)
Aug 31 12:35:18.470614 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi File
"/opt/stack/nova/nova/objects/compute_node.py", line 472, in
_db_compute_node_get_all_by_host
Aug 31 12:35:18.470614 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi return
db.compute_node_get_all_by_host(context, host)
Aug 31 12:35:18.470614 ubuntu-focal-rax-dfw-0030919238
devstack@n-api.service[98054]: ERROR nova.api.openstack.wsgi File
"/opt/stack/nova/nova/db/main/api.py",
[Yahoo-eng-team] [Bug 1988323] [NEW] "port" resource is not deleted if child "ml2_port_bindings" DB register does not exist
Public bug reported: The "port" database register (and any other related register) are not deleted from the database if the child "ml2_port_bindings" register is not present. When a "port" database register is created, a "ml2_port_bindings" child register is created too. Initially, the "ml2_port_bindings" is set to unbound. The Neutron server deletes the "ml2_port_bindings" register when the "port" register is deleted (for example, when the user executes "openstack port delete "). However, we have seen a user that has manually deleted the "ml2_port_bindings" register. In this case when the port is show, we can see all the binding related attributes filled with "None" [1]. If we manually try to delete this port using the CLI, the OSC does not return any exception, but the port is still in the database. I know this situation is not part of the normal operation, it implies a manual manipulation of the database. However, in this case we should: 1) Raise an exception saying that the Neutron API is not deleting this port. 2) Actually delete the register (I'm in favor of this one). [1]https://paste.opendev.org/show/bp2PPtNVN3ln4PReuByP/ ** Affects: neutron Importance: Low Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) Status: New ** Changed in: neutron Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez) ** Changed in: neutron Importance: Undecided => Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1988323 Title: "port" resource is not deleted if child "ml2_port_bindings" DB register does not exist Status in neutron: New Bug description: The "port" database register (and any other related register) are not deleted from the database if the child "ml2_port_bindings" register is not present. When a "port" database register is created, a "ml2_port_bindings" child register is created too. Initially, the "ml2_port_bindings" is set to unbound. The Neutron server deletes the "ml2_port_bindings" register when the "port" register is deleted (for example, when the user executes "openstack port delete "). However, we have seen a user that has manually deleted the "ml2_port_bindings" register. In this case when the port is show, we can see all the binding related attributes filled with "None" [1]. If we manually try to delete this port using the CLI, the OSC does not return any exception, but the port is still in the database. I know this situation is not part of the normal operation, it implies a manual manipulation of the database. However, in this case we should: 1) Raise an exception saying that the Neutron API is not deleting this port. 2) Actually delete the register (I'm in favor of this one). [1]https://paste.opendev.org/show/bp2PPtNVN3ln4PReuByP/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1988323/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1988325] [NEW] Volume attach failed cause volume turn to available when delete the instance
Public bug reported: Description === Using admin user to sign in. When a volume C is attached to instance A, if i try to attach it to another instance B, nova-api will raise an error "Invalid volume: Volume status must be available or downloading (HTTP 400) (Request-ID: x) (HTTP 400) (Request-ID: x)".At this time there is a deleted bdm record in nova for this failed attach.But then i delete instance B, the volume C (which is still attached to instance A) turned to available...making instance A can not use this volume. Steps to reproduce == * Using admin user to log in * create an volume C * attach volume C to instance A * attach volume C to instance B, it failed and left a deleted bdm record in nova * delete instance B, volume C alse become available and detached from instance A.. Expected result === volume C should not become available and detached from instance A Actual result = volume C become available and detached from instance A Environment === rpm -qa|grep nova openstack-nova-common-18.2.2-1.el7.noarch openstack-nova-api-18.2.2-1.el7.noarch python2-novaclient-11.0.0-1.el7.noarch python-nova-18.2.2-1.el7.noarch ** Affects: nova Importance: Undecided Status: New ** Description changed: Description === - Using admin user to sign in. When a volume C is attached to one instance A, if i try to attach it to another instance B, nova-api will - raise an error "Invalid volume: Volume status must be available or downloading (HTTP 400) (Request-ID: x) (HTTP 400) (Request-ID: x)".At this time there is a deleted bdm record in nova for this failed attach.But then i delete instance B, the volume C (which is still attached to instance A) turned to available...making instance A can not use this volume. + Using admin user to sign in. When a volume C is attached to instance A, if i try to attach it to another instance B, nova-api will + raise an error "Invalid volume: Volume status must be available or downloading (HTTP 400) (Request-ID: x) (HTTP 400) (Request-ID: x)".At this time there is a deleted bdm record in nova for this failed attach.But then i delete instance B, the volume C (which is still attached to instance A) turned to available...making instance A can not use this volume. Steps to reproduce == * Using admin user to log in * create an volume C * attach volume C to instance A * attach volume C to instance B, it failed and left a deleted bdm record in nova * delete instance B, volume C alse become available and detached from instance A.. - Expected result === volume C should not become available and detached from instance A Actual result = volume C become available and detached from instance A Environment === rpm -qa|grep nova openstack-nova-common-18.2.2-1.el7.noarch openstack-nova-api-18.2.2-1.el7.noarch python2-novaclient-11.0.0-1.el7.noarch python-nova-18.2.2-1.el7.noarch -- 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/1988325 Title: Volume attach failed cause volume turn to available when delete the instance Status in OpenStack Compute (nova): New Bug description: Description === Using admin user to sign in. When a volume C is attached to instance A, if i try to attach it to another instance B, nova-api will raise an error "Invalid volume: Volume status must be available or downloading (HTTP 400) (Request-ID: x) (HTTP 400) (Request-ID: x)".At this time there is a deleted bdm record in nova for this failed attach.But then i delete instance B, the volume C (which is still attached to instance A) turned to available...making instance A can not use this volume. Steps to reproduce == * Using admin user to log in * create an volume C * attach volume C to instance A * attach volume C to instance B, it failed and left a deleted bdm record in nova * delete instance B, volume C alse become available and detached from instance A.. Expected result === volume C should not become available and detached from instance A Actual result = volume C become available and detached from instance A Environment === rpm -qa|grep nova openstack-nova-common-18.2.2-1.el7.noarch openstack-nova-api-18.2.2-1.el7.noarch python2-novaclient-11.0.0-1.el7.noarch python-nova-18.2.2-1.el7.noarch To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1988325/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1988281] Re: neutron dhcp agent state not consistent with real status
I would agree with Rodolfo that this is more of an RFE as there isn't any fine-grained status info, in this case UP indicates the agent is running. As an FYI the agent is consuming messages off the queue as it's doing a full-sync, and it should also be receiving other messages as instances are created/destroyed. Also, these "new" messages have a priority value such that they should be processed sooner than some of the full-sync ones, based on the code and comments on the notifier code. neutron/api/rpc/agentnotifiers/dhcp_rpc_agent_api.py # In order to improve port dhcp provisioning when nova concurrently create # multiple vms, I classify the port_create_end message to two levels, the # high-level message only cast to one agent, the low-level message cast to all # other agent. In this way, When there are a large number of ports that need to # be processed, we can dispatch the high priority message of port to different # agent, so that the processed port will not block other port's processing in # other dhcp agents. It can take a long time for any agent to complete a full-sync operation on a restart, but we have tried to speed it up as best we can and there's probably always room for improvement. The other option is go to an OVN backend, which removes these agents completely... ** Changed in: neutron Importance: Undecided => Wishlist ** Changed in: neutron Status: New => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1988281 Title: neutron dhcp agent state not consistent with real status Status in neutron: Opinion Bug description: We are observing that neutron-dhcp-agent's state is deviating from "real state", by saying real state, I mean all hosted dnsmasq are running and configured. For example, agent A is hosting 1,000 networks, if I reboot agent A then all dnsmasq processes are gone, and dhcp agent will try to reboot every dnsmasq, this will introduce a long delay between agent start and agent handles new rabbitmq messages. But weirdly, openstack network agent list will show that the agent is up and running which IMO is inconsistent. I think under this situation, openstack network agent list should report the corresponding agent to be down. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1988281/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
