[Yahoo-eng-team] [Bug 2083760] [NEW] API request is not logged when neutron is run by httpd+mod_wsgi
Public bug reported: When the monolithic neutron-server is used to serve both api and rpc, we could check access from the clients logged like; 2024-10-05 17:00:25.898 52377 INFO neutron.wsgi [None req- de46b401-8c2d-4466-b937-3e40c76ef70e 813a38244a2d425883d89d8609ff0877 37d00479190a45ab8835f8b6abcbadac - - default default] 127.0.0.1 "GET /v2.0/networks HTTP/1.1" status: 200 len: 213 time: 0.8498089 However the same infomation is not longer logged when neutron API is run by httpd + mod_wsgi . This makes it quite difficult to debug problems triggered by API call. NOTE: Similar logs may be found in apache logs but this does not help really especially because the log does not contain request id and it becomes quite hard when similar requests come in concurrently. ** Affects: neutron Importance: Undecided Status: New ** Description changed: When the monolithic neutron-server is used to serve both api and rpc, we could check access from the clients logged like; 2024-10-05 17:00:25.898 52377 INFO neutron.wsgi [None req- de46b401-8c2d-4466-b937-3e40c76ef70e 813a38244a2d425883d89d8609ff0877 37d00479190a45ab8835f8b6abcbadac - - default default] 127.0.0.1 "GET /v2.0/networks HTTP/1.1" status: 200 len: 213 time: 0.8498089 However the same infomation is not longer logged when neutron API is run by httpd + mod_wsgi . This makes it quite difficult to debug problems triggered by API call. + + NOTE: + Similar logs may be found in apache logs but this does not help really especially because the log does not contain request id and it becomes quite hard when similar requests come in concurrently. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2083760 Title: API request is not logged when neutron is run by httpd+mod_wsgi Status in neutron: New Bug description: When the monolithic neutron-server is used to serve both api and rpc, we could check access from the clients logged like; 2024-10-05 17:00:25.898 52377 INFO neutron.wsgi [None req- de46b401-8c2d-4466-b937-3e40c76ef70e 813a38244a2d425883d89d8609ff0877 37d00479190a45ab8835f8b6abcbadac - - default default] 127.0.0.1 "GET /v2.0/networks HTTP/1.1" status: 200 len: 213 time: 0.8498089 However the same infomation is not longer logged when neutron API is run by httpd + mod_wsgi . This makes it quite difficult to debug problems triggered by API call. NOTE: Similar logs may be found in apache logs but this does not help really especially because the log does not contain request id and it becomes quite hard when similar requests come in concurrently. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2083760/+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 2071596] Re: netifaces is archived, please remove from dependecies
** Also affects: ironic-python-agent Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2071596 Title: netifaces is archived, please remove from dependecies Status in ironic-python-agent: New Status in OpenStack Compute (nova): In Progress Status in oslo.utils: In Progress Bug description: The oslo.utils python package is using as a dependency netifaces. This python package is not maintained since 2021 https://github.com/al45tair/netifaces/issues/78 Please remove it as a dependency and find an alternative To manage notifications about this bug go to: https://bugs.launchpad.net/ironic-python-agent/+bug/2071596/+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 2084977] [NEW] Deleting a security group fails with "Cannot find Port_Group with name=pg_" when neutron-api is run by httpd + mod_wsgi
Public bug reported:
In Puppet OpenStack project we've been attempting to switch neutron
deployment from standalone eventlet server to api run by httpd +
mod_wsgi and separate worker processes.
However we've seeing the strange failure consistently and I've not yet
able to identify the cause, so am opening this but in case anyone can
help dig into the issue.
The current problem is that deleting a security group fails because
neutron-api can't find the port group in ovn db.
Example:
build:
https://zuul.opendev.org/t/openstack/build/3f8cb2013ad143589979befc43234c9c
tempest report:
https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_ee4/890924/30/check/puppet-openstack-integration-7-scenario005-tempest-centos-9-stream/ee49397/logs/testr_results.html
The tempest failure we actually see is;
tempest.lib.exceptions.Conflict: Conflict with state of target resource
Details: {'type': 'SecurityGroupInUse', 'message': 'Security Group None cannot
perform precommit_delete due to Callback
neutron.plugins.ml2.drivers.ovn.mech_driver.mech_driver.OVNMechanismDriver._delete_security_group_precommit-623828
failed with "Cannot find Port_Group with
name=pg_8f86d456_755d_42fd_8951_cd21fea8377e".', 'detail': ''}
However from neutron api log I see the pg was created successfully.
https://97af450d4496db857e42-e03b399dba5d60e417a0a61de1589ca2.ssl.cf5.rackcdn.com/890924/30/check/puppet-openstack-integration-7-scenario003-tempest-centos-9-stream/3f8cb20/logs/neutron/app.txt
```
2024-10-18 13:08:40.508 76845 DEBUG ovsdbapp.backend.ovs_idl.transaction [None
req-36a5b37b-170f-471a-a214-dcba3dd0de19 - - - - - -] Running txn n=2
command(idx=0): PgAddCommand(_result=0835e7e8-d620-4986-8cbc-fda0b360b97a,
name=pg_0d20c3b7_d0cd_4339_988c_ac3b2a49bde1, may_exist=False, columns={'acls':
[], 'external_ids': {'neutron:security_group_id':
'0d20c3b7-d0cd-4339-988c-ac3b2a49bde1'}}) do_commit
/usr/lib/python3.9/site-packages/ovsdbapp/backend/ovs_idl/transaction.py:89
2024-10-18 13:08:40.508 76845 DEBUG ovsdbapp.backend.ovs_idl.transaction [None
req-36a5b37b-170f-471a-a214-dcba3dd0de19 - - - - - -] Running txn n=2
command(idx=1): PgAclAddCommand(_result=4986db11-f42e-4f70-8237-41627c92affc,
entity=pg_0d20c3b7_d0cd_4339_988c_ac3b2a49bde1, direction=to-lport,
priority=1002, match=outport == @pg_0d20c3b7_d0cd_4339_988c_ac3b2a49bde1 && ip6
&& ip6.src == $pg_0d20c3b7_d0cd_4339_988c_ac3b2a49bde1_ip6,
action=allow-related, log=False, may_exist=True, severity=[], name=[],
meter=None, external_ids={'neutron:security_group_rule_id':
'87e8cfd3-9ee5-44cd-98b6-36b51077cf0b'}) do_commit
/usr/lib/python3.9/site-packages/ovsdbapp/backend/ovs_idl/transaction.py:89
2024-10-18 13:08:40.509 76845 DEBUG ovsdbapp.backend.ovs_idl.transaction [None
req-36a5b37b-170f-471a-a214-dcba3dd0de19 - - - - - -] Running txn n=2
command(idx=2): PgAclAddCommand(_result=c1470e9f-6062-4a75-8d6a-5d34a05d,
entity=pg_0d20c3b7_d0cd_4339_988c_ac3b2a49bde1, direction=to-lport,
priority=1002, match=outport == @pg_0d20c3b7_d0cd_4339_988c_ac3b2a49bde1 && ip4
&& ip4.src == $pg_0d20c3b7_d0cd_4339_988c_ac3b2a49bde1_ip4,
action=allow-related, log=False, may_exist=True, severity=[], name=[],
meter=None, external_ids={'neutron:security_group_rule_id':
'c08c43af-a7dc-435f-b7d5-d034983f3944'}) do_commit
/usr/lib/python3.9/site-packages/ovsdbapp/backend/ovs_idl/transaction.py:89
2024-10-18 13:08:40.509 76845 DEBUG ovsdbapp.backend.ovs_idl.transaction [None
req-36a5b37b-170f-471a-a214-dcba3dd0de19 - - - - - -] Running txn n=2
command(idx=3): PgAclAddCommand(_result=8fe9ed5f-ef77-4f51-8a17-d9a061dafa49,
entity=pg_0d20c3b7_d0cd_4339_988c_ac3b2a49bde1, direction=from-lport,
priority=1002, match=inport == @pg_0d20c3b7_d0cd_4339_988c_ac3b2a49bde1 && ip4,
action=allow-related, log=False, may_exist=True, severity=[], name=[],
meter=None, external_ids={'neutron:security_group_rule_id':
'c4349c63-0dce-4791-998f-290247a9d368'}) do_commit
/usr/lib/python3.9/site-packages/ovsdbapp/backend/ovs_idl/transaction.py:89
2024-10-18 13:08:40.510 76845 DEBUG ovsdbapp.backend.ovs_idl.transaction [None
req-36a5b37b-170f-471a-a214-dcba3dd0de19 - - - - - -] Running txn n=2
command(idx=4): PgAclAddCommand(_result=c491b5de-f1bf-4ab9-ad26-cb7f39969300,
entity=pg_0d20c3b7_d0cd_4339_988c_ac3b2a49bde1, direction=from-lport,
priority=1002, match=inport == @pg_0d20c3b7_d0cd_4339_988c_ac3b2a49bde1 && ip6,
action=allow-related, log=False, may_exist=True, severity=[], name=[],
meter=None, external_ids={'neutron:security_group_rule_id':
'eaea975a-9ac8-416b-9375-574a642b5d61'}) do_commit
/usr/lib/python3.9/site-packages/ovsdbapp/backend/ovs_idl/transaction.py:89
...
2024-10-18 13:08:40.574 76845 DEBUG neutron_lib.db.resource_extend [None
req-4089cacb-ccc8-41ab-be87-6dacc03f09c6 - - - - - -] It took 0.44 seconds to
run function 'neutron_lib.db.resource_extend.apply_funcs' wrapper
/usr/lib/python3.9/site-packages/oslo_utils/timeutils.py:336
2024-
[Yahoo-eng-team] [Bug 2071596] Re: netifaces is archived, please remove from dependecies
** Also affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2071596 Title: netifaces is archived, please remove from dependecies Status in OpenStack Compute (nova): New Status in oslo.utils: New Bug description: The oslo.utils python package is using as a dependency netifaces. This python package is not maintained since 2021 https://github.com/al45tair/netifaces/issues/78 Please remove it as a dependency and find an alternative To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2071596/+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 2071596] Re: netifaces is archived, please remove from dependecies
** Also affects: openstacksdk Importance: Undecided Status: New ** Changed in: ironic-python-agent Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Changed in: openstacksdk Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- 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/2071596 Title: netifaces is archived, please remove from dependecies Status in ironic-python-agent: In Progress Status in OpenStack Compute (nova): In Progress Status in openstacksdk: In Progress Status in oslo.utils: In Progress Bug description: The oslo.utils python package is using as a dependency netifaces. This python package is not maintained since 2021 https://github.com/al45tair/netifaces/issues/78 Please remove it as a dependency and find an alternative To manage notifications about this bug go to: https://bugs.launchpad.net/ironic-python-agent/+bug/2071596/+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 2086477] Re: Rabbitmq related log spam in nova-compute-ironic
The log is generated not by nova but by oslo.messaging. We lowered down the log level by https://review.opendev.org/c/openstack/oslo.messaging/+/930672 . We haven't yet created a new release for 2024.1 but once that's done then the issue will be fixed. As the fix is already released for 2024.2 , I'll mark this as resolved but I'll propose a new release soon ** Project changed: nova => oslo.messaging ** Changed in: oslo.messaging Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2086477 Title: Rabbitmq related log spam in nova-compute-ironic Status in oslo.messaging: Fix Released Bug description: I've just upgraded to 2024.1 and am seeing a lot of these types of messages in the logs: 2024-10-30 18:02:29.377 7 INFO oslo_messaging._drivers.amqpdriver [None req-2a3a4253-4914-439e-845f-b52f204b6fec - - - - - -] Expecting reply to msg 15bf6ec0a951479a871bef7518153067 in queue reply_5d2e3a7d4d594feb9f8034e9a6afeae3 2024-10-30 18:02:29.385 7 INFO oslo_messaging._drivers.amqpdriver [-] Received RPC response for msg 15bf6ec0a951479a871bef7518153067 Should this a DEBUG log? To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.messaging/+bug/2086477/+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 2082883] [NEW] neutron-tempest-plugin: KeyError caused by missing 'previous' ref
Public bug reported:
Neutron returns reference to next and previous in list APIs "Only when any item
is returned".
However the client implementation in neutron-tempest-plugin always assumes
these refs are present.
This results in uexpected failures in some api call.
For example in
https://zuul.opendev.org/t/openstack/build/0208cd2fa5ac45199ee047f796ab1eb6
the following error is found.
```
ft1.6:
neutron_tempest_plugin.api.test_subnets.SubnetsSearchCriteriaTest.test_list_pagination_with_href_links[id-351183ef-6ed9-4d71-a9f2-a5ac049bd7ea]testtools.testresult.real._StringException:
pythonlogging:'': {{{
...
Response - Headers: {'date': 'Thu, 26 Sep 2024 15:43:49 GMT', 'server':
'Apache/2.4.52 (Ubuntu)', 'content-type': 'application/json', 'content-length':
'1024', 'x-openstack-request-id': 'req-da904a1e-52ed-4b19-81d9-fbe5c35fb52b',
'connection': 'close', 'status': '200', 'content-location':
'https://213.32.78.164/networking/v2.0/subnets?limit=1&sort_dir=asc&sort_key=name&shared=False&marker=b76f1872-968a-4acd-b114-6a4eb446c6e7&page_reverse=True'}
Body:
b'{"subnets":[{"id":"5bfc6a9e-bca1-4d0b-9cff-a6daabb16d69","name":"123test","tenant_id":"37f53ece30b6499b8a2175032589df05","network_id":"fbf42c58-0463-4c09-b3f3-970adb269a1b","ip_version":4,"subnetpool_id":null,"enable_dhcp":true,"ipv6_ra_mode":null,"ipv6_address_mode":null,"gateway_ip":"10.1.0.49","cidr":"10.1.0.48/28","allocation_pools":[{"start":"10.1.0.50","end":"10.1.0.62"}],"host_routes":[],"dns_nameservers":[],"description":"","router:external":false,"service_types":[],"dns_publish_fixed_ip":false,"tags":[],"created_at":"2024-09-26T15:43:45Z","updated_at":"2024-09-26T15:43:45Z","revision_number":0,"project_id":"37f53ece30b6499b8a2175032589df05"}],"subnets_links":[{"rel":"next","href":"https://213.32.78.164/networking/v2.0/subnets?limit=1&sort_dir=asc&sort_key=name&shared=False&marker=5bfc6a9e-bca1-4d0b-9cff-a6daabb16d69"},{"rel":"previous","href":"https://213.32.78.164/networking/v2.0/subnets?limit=1&sort_dir=asc&sort_key=name&shared=False&marker=5bfc6a9e-bca1-4d
0b-9cff-a6daabb16d69&page_reverse=True"}]}'
2024-09-26 15:43:50,279 88505 INFO [tempest.lib.common.rest_client] Request
(SubnetsSearchCriteriaTest:test_list_pagination_with_href_links): 200 GET
https://213.32.78.164/networking/v2.0/subnets?limit=1&sort_dir=asc&sort_key=name&shared=False&marker=5bfc6a9e-bca1-4d0b-9cff-a6daabb16d69&page_reverse=True
0.050s
2024-09-26 15:43:50,280 88505 DEBUG[tempest.lib.common.rest_client] Request
- Headers: {'Content-Type': 'application/json', 'Accept': 'application/json',
'X-Auth-Token': ''}
Body: None
Response - Headers: {'date': 'Thu, 26 Sep 2024 15:43:50 GMT', 'server':
'Apache/2.4.52 (Ubuntu)', 'content-type': 'application/json', 'content-length':
'150', 'x-openstack-request-id': 'req-3961b469-3fd6-459d-a2cb-566688c9c17c',
'connection': 'close', 'status': '200', 'content-location':
'https://213.32.78.164/networking/v2.0/subnets?limit=1&sort_dir=asc&sort_key=name&shared=False&marker=5bfc6a9e-bca1-4d0b-9cff-a6daabb16d69&page_reverse=True'}
Body:
b'{"subnets":[],"subnets_links":[{"rel":"next","href":"https://213.32.78.164/networking/v2.0/subnets?limit=1&sort_dir=asc&sort_key=name&shared=False"}]}'
}}}
Traceback (most recent call last):
File
"/opt/stack/tempest/.tox/tempest/lib/python3.10/site-packages/neutron_tempest_plugin/api/test_subnets.py",
line 50, in test_list_pagination_with_href_links
self._test_list_pagination_with_href_links()
File
"/opt/stack/tempest/.tox/tempest/lib/python3.10/site-packages/neutron_tempest_plugin/api/base.py",
line 1413, in inner
return f(self, *args, **kwargs)
File
"/opt/stack/tempest/.tox/tempest/lib/python3.10/site-packages/neutron_tempest_plugin/api/base.py",
line 1404, in inner
return f(self, *args, **kwargs)
File
"/opt/stack/tempest/.tox/tempest/lib/python3.10/site-packages/neutron_tempest_plugin/api/base.py",
line 1606, in _test_list_pagination_with_href_links
self._test_list_pagination_iteratively(self._list_all_with_hrefs)
File
"/opt/stack/tempest/.tox/tempest/lib/python3.10/site-packages/neutron_tempest_plugin/api/base.py",
line 1528, in _test_list_pagination_iteratively
resources = lister(
File
"/opt/stack/tempest/.tox/tempest/lib/python3.10/site-packages/neutron_tempest_plugin/api/base.py",
line 1589, in _list_all_with_hrefs
uri = self.get_bare_url(prev_links['previous'])
KeyError: 'previous'
```
** 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/2082883
Title:
neutron-tempest-plugin: KeyError caused by missing 'previous' ref
Status in neutron:
New
Bug description:
Neutron returns reference to next and previous in list APIs "Only when any
item is returned".
However the client implementation in neutron-tempest-plugin always
[Yahoo-eng-team] [Bug 2083092] [NEW] sqlalchemy.exc.InvalidRequestError im image update
Public bug reported:
A strange failure was caught in glance-multistore-cinder-import job.
According to the tempest test case failure, image deleted failed because
of 500 error.
https://zuul.opendev.org/t/openstack/build/bcb2045e696c473e9ab8a1f376bcc714
And the following traceback is logged in g-api.log. I'm reporting this
here in case this could be related to recent migration to SQLAlchemy 2.0
.
```
Sep 27 15:44:58.566377 np0038636614 devstack@g-api.service[88666]: DEBUG
glance.api.middleware.version_negotiation [None
req-cb60319b-481e-4127-96ff-8e6dfdfafeca tempest-ImagesFormatTest-522606120
tempest-ImagesFormatTest-522606120-project-member] Determining version of
request: POST /v2/images Accept: application/json {{(pid=88666) process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:44}}
Sep 27 15:44:58.566594 np0038636614 devstack@g-api.service[88666]: DEBUG
glance.api.middleware.version_negotiation [None
req-cb60319b-481e-4127-96ff-8e6dfdfafeca tempest-ImagesFormatTest-522606120
tempest-ImagesFormatTest-522606120-project-member] Using url versioning
{{(pid=88666) process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:57}}
Sep 27 15:44:58.566806 np0038636614 devstack@g-api.service[88666]: DEBUG
glance.api.middleware.version_negotiation [None
req-cb60319b-481e-4127-96ff-8e6dfdfafeca tempest-ImagesFormatTest-522606120
tempest-ImagesFormatTest-522606120-project-member] Matched version: v2
{{(pid=88666) process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:69}}
Sep 27 15:44:58.567040 np0038636614 devstack@g-api.service[88666]: DEBUG
glance.api.middleware.version_negotiation [None
req-cb60319b-481e-4127-96ff-8e6dfdfafeca tempest-ImagesFormatTest-522606120
tempest-ImagesFormatTest-522606120-project-member] new path /v2/images
{{(pid=88666) process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:70}}
...
'cinder://lvmdriver-1/09bc6160-d566-45c9-9cde-4e35497dd7a9', 'metadata':
{'store': 'lvmdriver-1'}, 'status': 'active'}, {'id': 38, 'url':
'cinder://lvmdriver-2/3cd47cd3-ad7f-437e-bfa4-10101e019d15', 'metadata':
{'store': 'lvmdriver-2'}, 'status': 'active'}] {{(pid=88666)
sort_image_locations /opt/stack/glance/glance/common/utils.py:735}}
Sep 27 15:44:58.033280 np0038636614 devstack@g-api.service[88666]: DEBUG
glance_store._drivers.cinder.store [None
req-cb60319b-481e-4127-96ff-8e6dfdfafeca tempest-ImagesFormatTest-522606120
tempest-ImagesFormatTest-522606120-project-member] Cinderclient connection
created for user glance using URL: https://158.69.74.140/identity/v3.
{{(pid=88666) get_cinderclient
/opt/stack/data/venv/lib/python3.10/site-packages/glance_store/_drivers/cinder/store.py:648}}
Sep 27 15:44:58.041288 np0038636614 devstack@g-api.service[88665]: DEBUG
glance.common.utils [-] Sorted locations: [{'id': 37, 'url':
'cinder://lvmdriver-1/09bc6160-d566-45c9-9cde-4e35497dd7a9', 'metadata':
{'store': 'lvmdriver-1'}, 'status': 'active'}, {'id': 38, 'url':
'cinder://lvmdriver-2/3cd47cd3-ad7f-437e-bfa4-10101e019d15', 'metadata':
{'store': 'lvmdriver-2'}, 'status': 'active'}] {{(pid=88665)
sort_image_locations /opt/stack/glance/glance/common/utils.py:735}}
Sep 27 15:44:58.062043 np0038636614 devstack@g-api.service[88665]: DEBUG
glance.common.utils [-] Sorted locations: [{'id': 37, 'url':
'cinder://lvmdriver-1/09bc6160-d566-45c9-9cde-4e35497dd7a9', 'metadata':
{'store': 'lvmdriver-1'}, 'status': 'active'}, {'id': 38, 'url':
'cinder://lvmdriver-2/3cd47cd3-ad7f-437e-bfa4-10101e019d15', 'metadata':
{'store': 'lvmdriver-2'}, 'status': 'active'}] {{(pid=88665)
sort_image_locations /opt/stack/glance/glance/common/utils.py:735}}
Sep 27 15:44:58.139389 np0038636614 devstack@g-api.service[88666]: DEBUG
glance_store._drivers.cinder.store [None
req-cb60319b-481e-4127-96ff-8e6dfdfafeca tempest-ImagesFormatTest-522606120
tempest-ImagesFormatTest-522606120-project-member] Cinderclient connection
created for user glance using URL: https://158.69.74.140/identity/v3.
{{(pid=88666) get_cinderclient
/opt/stack/data/venv/lib/python3.10/site-packages/glance_store/_drivers/cinder/store.py:648}}
...
Sep 27 15:44:58.507784 np0038636614 devstack@g-api.service[88666]: DEBUG
glance.db.sqlalchemy.api [None req-cb60319b-481e-4127-96ff-8e6dfdfafeca
tempest-ImagesFormatTest-522606120
tempest-ImagesFormatTest-522606120-project-member] StaleDataError while
deleting property 'os_glance_import_task' from image
'f16c174b-46fd-4241-aeb6-ae85583564d1' likely means we raced during delete:
UPDATE statement on table 'image_properties' expected to update 1 row(s); 0
were matched. {{(pid=88666) _image_property_delete
/opt/stack/glance/glance/db/sqlalchemy/api.py:1328}}
Sep 27 15:44:58.532097 np0038636614 devstack@g-api.service[88666]: ERROR
glance.common.wsgi [None req-cb60319b-481e-4127-96ff-8e6dfdfafeca
tempest-ImagesFormatTest-522606120
tempest-ImagesFormatTest-522606120-project-member] Caught error:
[Yahoo-eng-team] [Bug 2081732] Re: oslo_utils.secretutils.constant_time_compare is redundant
** Also affects: ceilometer Importance: Undecided Status: New ** Also affects: keystonemiddleware Importance: Undecided Status: New ** Also affects: octavia Importance: Undecided Status: New ** Also affects: osprofiler Importance: Undecided Status: New ** Also affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2081732 Title: oslo_utils.secretutils.constant_time_compare is redundant Status in Ceilometer: New Status in keystonemiddleware: New Status in OpenStack Compute (nova): In Progress Status in octavia: New Status in oslo.utils: Fix Released Status in osprofiler: New Bug description: The constant_time_compare function is equivalent to hmac.compare_digest in Python 3, because the constant_time_compare function has been available since Python 3.3 . [1] https://docs.python.org/3/library/hmac.html#hmac.compare_digest We can get rid of the redundant wrapper and use the built-in implementation instead. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/2081732/+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 2083524] [NEW] distutils was removed in Python 3.12
Public bug reported: Description === The built-in distutils module was deprecated in 3.10 and was removed in Python 3.12 . https://docs.python.org/3.11/library/distutils.html We should remove the remaining usage of it. ** 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/2083524 Title: distutils was removed in Python 3.12 Status in OpenStack Dashboard (Horizon): New Bug description: Description === The built-in distutils module was deprecated in 3.10 and was removed in Python 3.12 . https://docs.python.org/3.11/library/distutils.html We should remove the remaining usage of it. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/2083524/+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 2083518] [NEW] distutils was removed in Python 3.12
Public bug reported: Description === The built-in distutils module was deprecated in 3.10 and was removed in Python 3.12 . https://docs.python.org/3.11/library/distutils.html We should remove the remaining usage of it. ``` $ git log -n 1 commit 1ecab6dbc573fb0a60e35382269374193158b7f0 (HEAD -> master, origin/master, origin/HEAD) Merge: d88d968e96 1c20647a14 Author: Zuul Date: Thu Sep 5 16:04:22 2024 + Merge "doc: Fix markup syntax and typo" [tkajinam@fedora nova]$ grep -r -n distutils nova/ nova/scheduler/filters/image_props_filter.py:17:from distutils import versionpredicate nova/version.py:31:# these modules are accessible when distutils uses ``` ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2083518 Title: distutils was removed in Python 3.12 Status in OpenStack Compute (nova): New Bug description: Description === The built-in distutils module was deprecated in 3.10 and was removed in Python 3.12 . https://docs.python.org/3.11/library/distutils.html We should remove the remaining usage of it. ``` $ git log -n 1 commit 1ecab6dbc573fb0a60e35382269374193158b7f0 (HEAD -> master, origin/master, origin/HEAD) Merge: d88d968e96 1c20647a14 Author: Zuul Date: Thu Sep 5 16:04:22 2024 + Merge "doc: Fix markup syntax and typo" [tkajinam@fedora nova]$ grep -r -n distutils nova/ nova/scheduler/filters/image_props_filter.py:17:from distutils import versionpredicate nova/version.py:31:# these modules are accessible when distutils uses ``` To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2083518/+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 2083518] Re: distutils was removed in Python 3.12
** Also affects: oslo.versionedobjects Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2083518 Title: distutils was removed in Python 3.12 Status in OpenStack Compute (nova): New Status in oslo.versionedobjects: New Bug description: Description === The built-in distutils module was deprecated in 3.10 and was removed in Python 3.12 . https://docs.python.org/3.11/library/distutils.html We should remove the remaining usage of it. ``` $ git log -n 1 commit 1ecab6dbc573fb0a60e35382269374193158b7f0 (HEAD -> master, origin/master, origin/HEAD) Merge: d88d968e96 1c20647a14 Author: Zuul Date: Thu Sep 5 16:04:22 2024 + Merge "doc: Fix markup syntax and typo" [tkajinam@fedora nova]$ grep -r -n distutils nova/ nova/scheduler/filters/image_props_filter.py:17:from distutils import versionpredicate nova/version.py:31:# these modules are accessible when distutils uses ``` To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2083518/+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 2083620] [NEW] pkg_resources is deprecated
Public bug reported: Description === The pkg_resources module was deprecated. It was removed from the core Python and has been moved to setuptools in Python 3.12. We should replace the usage to adopt to that change. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2083620 Title: pkg_resources is deprecated Status in OpenStack Compute (nova): New Bug description: Description === The pkg_resources module was deprecated. It was removed from the core Python and has been moved to setuptools in Python 3.12. We should replace the usage to adopt to that change. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2083620/+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 2081009] [NEW] oslo_config.cfg.NotInitializedError when switching default policy_file in oslo.policy
Public bug reported: While we attempted to update the default policy file in https://review.opendev.org/c/openstack/oslo.policy/+/929714 , we observed the glance-api can't start and complains the error below. ``` Traceback (most recent call last): File "/opt/stack/data/venv/bin/glance-wsgi-api", line 6, in from glance.common.wsgi_app import init_app File "/opt/stack/glance/glance/common/wsgi_app.py", line 24, in from glance.common import config File "/opt/stack/glance/glance/common/config.py", line 643, in policy.Enforcer(CONF) File "/opt/stack/oslo.policy/oslo_policy/policy.py", line 543, in __init__ self.policy_file = policy_file or pick_default_policy_file( File "/opt/stack/oslo.policy/oslo_policy/policy.py", line 378, in pick_default_policy_file if conf.find_file(conf.oslo_policy.policy_file): File "/opt/stack/data/venv/lib/python3.10/site-packages/oslo_config/cfg.py", line 2782, in find_file Traceback (most recent call last): File "/opt/stack/data/venv/bin/glance-wsgi-api", line 6, in from glance.common.wsgi_app import init_app File "/opt/stack/glance/glance/common/wsgi_app.py", line 24, in from glance.common import config File "/opt/stack/glance/glance/common/config.py", line 643, in policy.Enforcer(CONF) File "/opt/stack/oslo.policy/oslo_policy/policy.py", line 543, in __init__ self.policy_file = policy_file or pick_default_policy_file( File "/opt/stack/oslo.policy/oslo_policy/policy.py", line 378, in pick_default_policy_file raise NotInitializedError() oslo_config.cfg.NotInitializedError: call expression on parser has not been invoked ``` The problem here is that Enforcer() is called directly at the module level in glance.common.config and we can't guarantee the module is imported after CONF instance is initialized. ** Affects: glance Importance: Undecided Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/2081009 Title: oslo_config.cfg.NotInitializedError when switching default policy_file in oslo.policy Status in Glance: In Progress Bug description: While we attempted to update the default policy file in https://review.opendev.org/c/openstack/oslo.policy/+/929714 , we observed the glance-api can't start and complains the error below. ``` Traceback (most recent call last): File "/opt/stack/data/venv/bin/glance-wsgi-api", line 6, in from glance.common.wsgi_app import init_app File "/opt/stack/glance/glance/common/wsgi_app.py", line 24, in from glance.common import config File "/opt/stack/glance/glance/common/config.py", line 643, in policy.Enforcer(CONF) File "/opt/stack/oslo.policy/oslo_policy/policy.py", line 543, in __init__ self.policy_file = policy_file or pick_default_policy_file( File "/opt/stack/oslo.policy/oslo_policy/policy.py", line 378, in pick_default_policy_file if conf.find_file(conf.oslo_policy.policy_file): File "/opt/stack/data/venv/lib/python3.10/site-packages/oslo_config/cfg.py", line 2782, in find_file Traceback (most recent call last): File "/opt/stack/data/venv/bin/glance-wsgi-api", line 6, in from glance.common.wsgi_app import init_app File "/opt/stack/glance/glance/common/wsgi_app.py", line 24, in from glance.common import config File "/opt/stack/glance/glance/common/config.py", line 643, in policy.Enforcer(CONF) File "/opt/stack/oslo.policy/oslo_policy/policy.py", line 543, in __init__ self.policy_file = policy_file or pick_default_policy_file( File "/opt/stack/oslo.policy/oslo_policy/policy.py", line 378, in pick_default_policy_file raise NotInitializedError() oslo_config.cfg.NotInitializedError: call expression on parser has not been invoked ``` The problem here is that Enforcer() is called directly at the module level in glance.common.config and we can't guarantee the module is imported after CONF instance is initialized. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/2081009/+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 2081732] Re: oslo_utils.secretutils.constant_time_compare is redundant
This was fixed in ceilometer by https://review.opendev.org/c/openstack/ceilometer/+/931149 ** Changed in: ceilometer Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2081732 Title: oslo_utils.secretutils.constant_time_compare is redundant Status in Ceilometer: Fix Released Status in keystonemiddleware: Fix Released Status in OpenStack Compute (nova): In Progress Status in octavia: Fix Released Status in oslo.utils: Fix Released Status in osprofiler: In Progress Bug description: The constant_time_compare function is equivalent to hmac.compare_digest in Python 3, because the constant_time_compare function has been available since Python 3.3 . [1] https://docs.python.org/3/library/hmac.html#hmac.compare_digest We can get rid of the redundant wrapper and use the built-in implementation instead. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/2081732/+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 2089051] Re: jsonschema: FormatChecker.cls_checks was deprecated
** Also 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/2089051 Title: jsonschema: FormatChecker.cls_checks was deprecated Status in Cinder: In Progress Status in OpenStack Identity (keystone): In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in OpenStack Compute (nova): New Status in placement: New Status in tacker: New Status in tempest: New Bug description: The method was deprecated in jsonschema 4.14.0[1] and now triggers the following warning. --- DeprecationWarning: FormatChecker.cls_checks is deprecated. Call FormatChecker.checks on a specific FormatChecker instance instead. --- We should update the usage accordingly. [1] https://github.com/python- jsonschema/jsonschema/commit/cd8f0592b93947a9deb8b3e6502cc5a69cb6d722 To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/2089051/+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 2089051] Re: jsonschema: FormatChecker.cls_checks was deprecated
** Also affects: nova Importance: Undecided Status: New ** Also affects: placement Importance: Undecided Status: New ** Also affects: tacker Importance: Undecided Status: New ** Also affects: tempest Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2089051 Title: jsonschema: FormatChecker.cls_checks was deprecated Status in Cinder: In Progress Status in OpenStack Identity (keystone): In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in OpenStack Compute (nova): New Status in placement: New Status in tacker: New Status in tempest: New Bug description: The method was deprecated in jsonschema 4.14.0[1] and now triggers the following warning. --- DeprecationWarning: FormatChecker.cls_checks is deprecated. Call FormatChecker.checks on a specific FormatChecker instance instead. --- We should update the usage accordingly. [1] https://github.com/python- jsonschema/jsonschema/commit/cd8f0592b93947a9deb8b3e6502cc5a69cb6d722 To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/2089051/+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 2089051] Re: jsonschema: FormatChecker.cls_checks was deprecated
** Also affects: manila 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/2089051 Title: jsonschema: FormatChecker.cls_checks was deprecated Status in Cinder: In Progress Status in OpenStack Identity (keystone): In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in OpenStack Compute (nova): New Status in placement: New Status in tacker: New Status in tempest: New Bug description: The method was deprecated in jsonschema 4.14.0[1] and now triggers the following warning. --- DeprecationWarning: FormatChecker.cls_checks is deprecated. Call FormatChecker.checks on a specific FormatChecker instance instead. --- We should update the usage accordingly. [1] https://github.com/python- jsonschema/jsonschema/commit/cd8f0592b93947a9deb8b3e6502cc5a69cb6d722 To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/2089051/+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 2088279] [NEW] neutron-tempest-plugin: dynamic rouring tests are broken by new os-ken
Public bug reported: It seems dynamic routing tests in neutron-tempest-plugin consistently fails with the following traceback. ``` --- import errors --- Failed to import test module: neutron_tempest_plugin.neutron_dynamic_routing.scenario.basic.test_4byte_asn Traceback (most recent call last): File "/usr/lib/python3.10/unittest/loader.py", line 436, in _find_test_path module = self._get_module_from_name(name) File "/usr/lib/python3.10/unittest/loader.py", line 377, in _get_module_from_name __import__(name) File "/opt/stack/tempest/.tox/tempest/lib/python3.10/site-packages/neutron_tempest_plugin/neutron_dynamic_routing/scenario/basic/test_4byte_asn.py", line 22, in from os_ken.tests.integrated.common import quagga ImportError: cannot import name 'quagga' from 'os_ken.tests.integrated.common' (/opt/stack/tempest/.tox/tempest/lib/python3.10/site-packages/os_ken/tests/integrated/common/__init__.py) ``` https://zuul.opendev.org/t/openstack/build/5942d2aa0e5849a3b0fec527487103e4 The issue was triggered by the recent switch to frr. https://review.opendev.org/c/openstack/os-ken/+/891677 ** 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/2088279 Title: neutron-tempest-plugin: dynamic rouring tests are broken by new os-ken Status in neutron: New Bug description: It seems dynamic routing tests in neutron-tempest-plugin consistently fails with the following traceback. ``` --- import errors --- Failed to import test module: neutron_tempest_plugin.neutron_dynamic_routing.scenario.basic.test_4byte_asn Traceback (most recent call last): File "/usr/lib/python3.10/unittest/loader.py", line 436, in _find_test_path module = self._get_module_from_name(name) File "/usr/lib/python3.10/unittest/loader.py", line 377, in _get_module_from_name __import__(name) File "/opt/stack/tempest/.tox/tempest/lib/python3.10/site-packages/neutron_tempest_plugin/neutron_dynamic_routing/scenario/basic/test_4byte_asn.py", line 22, in from os_ken.tests.integrated.common import quagga ImportError: cannot import name 'quagga' from 'os_ken.tests.integrated.common' (/opt/stack/tempest/.tox/tempest/lib/python3.10/site-packages/os_ken/tests/integrated/common/__init__.py) ``` https://zuul.opendev.org/t/openstack/build/5942d2aa0e5849a3b0fec527487103e4 The issue was triggered by the recent switch to frr. https://review.opendev.org/c/openstack/os-ken/+/891677 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2088279/+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 1926693] [NEW] Logic to obtain hypervisor hostname is not completely compatible with libvirt
Public bug reported: Currently we use socket.getshostname() to determine the heyervisor hostname assuming that is what is used in libvirt. However libvirt actually ues the following steps to generate hypervisor hostname and socket.gethostname() doesn't match in some cases. /* Who knew getting a hostname could be so delicate. In Linux (and Unices * in general), many things depend on "hostname" returning a value that will * resolve one way or another. In the modern world where networks frequently * come and go this is often being hard-coded to resolve to "localhost". If * it *doesn't* resolve to localhost, then we would prefer to have the FQDN. * That leads us to 3 possibilities: * * 1) gethostname() returns an FQDN (not localhost) - we return the string * as-is, it's all of the information we want * 2) gethostname() returns "localhost" - we return localhost; doing further * work to try to resolve it is pointless * 3) gethostname() returns a shortened hostname - in this case, we want to * try to resolve this to a fully-qualified name. Therefore we pass it * to getaddrinfo(). There are two possible responses: * a) getaddrinfo() resolves to a FQDN - return the FQDN * b) getaddrinfo() fails or resolves to localhost - in this case, the * data we got from gethostname() is actually more useful than what * we got from getaddrinfo(). Return the value from gethostname() * and hope for the best. */ https://github.com/libvirt/libvirt/blob/ec2e3336b8c8df572600043976e1ab5feead656e/src/util/virutil.c#L454-L531 Acutally we do see that in TripleO deployment socket.gethostname() and virsh hostname doesn't agree, and this causes an issue when we set up resource_provider_bandwidths ~~~ [heat-admin@compute-0 ~]$ python Python 3.6.8 (default, Dec 5 2019, 15:45:45) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> socket.gethostname() 'compute-0' >>> exit() [heat-admin@compute-0 ~]$ sudo podman exec -it nova_libvirt virsh hostname compute-0.redhat.local ~~~ ** 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/1926693 Title: Logic to obtain hypervisor hostname is not completely compatible with libvirt Status in neutron: New Bug description: Currently we use socket.getshostname() to determine the heyervisor hostname assuming that is what is used in libvirt. However libvirt actually ues the following steps to generate hypervisor hostname and socket.gethostname() doesn't match in some cases. /* Who knew getting a hostname could be so delicate. In Linux (and Unices * in general), many things depend on "hostname" returning a value that will * resolve one way or another. In the modern world where networks frequently * come and go this is often being hard-coded to resolve to "localhost". If * it *doesn't* resolve to localhost, then we would prefer to have the FQDN. * That leads us to 3 possibilities: * * 1) gethostname() returns an FQDN (not localhost) - we return the string * as-is, it's all of the information we want * 2) gethostname() returns "localhost" - we return localhost; doing further * work to try to resolve it is pointless * 3) gethostname() returns a shortened hostname - in this case, we want to * try to resolve this to a fully-qualified name. Therefore we pass it * to getaddrinfo(). There are two possible responses: * a) getaddrinfo() resolves to a FQDN - return the FQDN * b) getaddrinfo() fails or resolves to localhost - in this case, the * data we got from gethostname() is actually more useful than what * we got from getaddrinfo(). Return the value from gethostname() * and hope for the best. */ https://github.com/libvirt/libvirt/blob/ec2e3336b8c8df572600043976e1ab5feead656e/src/util/virutil.c#L454-L531 Acutally we do see that in TripleO deployment socket.gethostname() and virsh hostname doesn't agree, and this causes an issue when we set up resource_provider_bandwidths ~~~ [heat-admin@compute-0 ~]$ python Python 3.6.8 (default, Dec 5 2019, 15:45:45) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> socket.gethostname() 'compute-0' >>> exit() [heat-admin@compute-0 ~]$ sudo podman exec -it nova_libvirt virsh hostname compute-0.redhat.local ~~~ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1926693/+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 :
[Yahoo-eng-team] [Bug 1905276] Re: Overriding hypervisor name for resource provider always requires a complete list of interfaces/bridges
Closing this because our expectation here is that neutron and libvirt should detect the same hostname. I've reported another bug to fix current incompatibility. https://bugs.launchpad.net/neutron/+bug/1926693 ** Changed in: neutron Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1905276 Title: Overriding hypervisor name for resource provider always requires a complete list of interfaces/bridges Status in neutron: Invalid Bug description: In some deployments, hostnames can be different between hosts and resource provider records. For example in deployment managed by TripleO we use short host name (without domain name) in host, while we use FQDN for resource provider records (this comes from the FQDN set to the host option in nova.conf). This causes an issue with the way how currently neutron looks up the root resource provider because placment API requires the exact hostname and doesn't automatically translate short name and FQDN. To fix the issue we need to set the resource_provider_hypervisors option[1] now but it is very redundant to list up all devices or bridges in this option to override hostnames for the devices/bridges by the same value. [1] https://review.opendev.org/#/c/696600/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1905276/+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 1927494] [NEW] [designate] admin_* options are based on v2 identity instead of v3
Public bug reported: Currently neutron accepts the following parameters to set up identity for connecting to designate in admin context, but the list doesn't include domain parameters and it seems these parameters are based on keystone v2 indentity instead of keystone v3 identity. - admin_username - admin_password - admin_tenant_id - admin_tenant_name - admin_auth_url' ** 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/1927494 Title: [designate] admin_* options are based on v2 identity instead of v3 Status in neutron: New Bug description: Currently neutron accepts the following parameters to set up identity for connecting to designate in admin context, but the list doesn't include domain parameters and it seems these parameters are based on keystone v2 indentity instead of keystone v3 identity. - admin_username - admin_password - admin_tenant_id - admin_tenant_name - admin_auth_url' To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1927494/+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 1930499] [NEW] Can't add a subnet without gateway ip to a router
Public bug reported: Currently when adding an interface to a router, Horizon shows subnets with gateway ip. On the other hand, Horizon supports attaching a subnet to a router with fixed interface ip. In this case gateway ip is not required but a new port is created with a given ip in the subnet and the port is attached to the router. This is useful especially when users want to connect an instance to multiple subnets with a single default gateway (only one subnet has gateway ip while the other subnet don't). However because of the current logic to filter out subnets without gateway ip, we can't add a subnet without gateway ip to a router using fixed ip now. ** Affects: horizon Importance: Undecided Status: In Progress ** Description changed: Currently when adding an interface to a router, Horizon shows subnets with gateway ip. On the other hand, Horizon supports attaching a subnet to a router with fixed interface ip. - In this case gateway ip is not required but a new port is created with a given ip in the subnet - and the port is attached to the router. + In this case gateway ip is not required but a new port is created with a given ip in the subnet and the port is attached to the router. This is useful especially when users want to connect an instance to multiple subnets with a single default gateway (only one subnet has gateway ip while the other subnet don't). - However because of the current logic to filter out subnets without gateway ip, we can't add - a subnet without gateway ip to a router using fixed ip now. + However because of the current logic to filter out subnets without + gateway ip, we can't add a subnet without gateway ip to a router using + fixed ip now. -- 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/1930499 Title: Can't add a subnet without gateway ip to a router Status in OpenStack Dashboard (Horizon): In Progress Bug description: Currently when adding an interface to a router, Horizon shows subnets with gateway ip. On the other hand, Horizon supports attaching a subnet to a router with fixed interface ip. In this case gateway ip is not required but a new port is created with a given ip in the subnet and the port is attached to the router. This is useful especially when users want to connect an instance to multiple subnets with a single default gateway (only one subnet has gateway ip while the other subnet don't). However because of the current logic to filter out subnets without gateway ip, we can't add a subnet without gateway ip to a router using fixed ip now. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1930499/+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 1936278] [NEW] nova-manage placement audit command always fails with --resource_provider option
Public bug reported: Description === nova-mange placement audit command always fails because the target resource provider is not found ~~~ # nova-manage placement audit --resource_provider dbba1bf7-6e97-4dcb-8d4c-37fe36633358 --verbose Resource provider with UUID dbba1bf7-6e97-4dcb-8d4c-37fe36633358 does not exist. Error: non zero exit code: 127: OCI runtime error ~~~ However the resource provider record actually exists in Placement. ~~~ (overcloud) [stack@undercloud-0 ~]$ openstack resource provider list --uuid dbba1bf7-6e97-4dcb-8d4c-37fe36633358 --os-placement-api-version 1.14 +--+++--+--+ | uuid | name | generation | root_provider_uuid | parent_provider_uuid | +--+++--+--+ | dbba1bf7-6e97-4dcb-8d4c-37fe36633358 | compute-0.redhat.local | 28 | dbba1bf7-6e97-4dcb-8d4c-37fe36633358 | None | +--+++--+--+ ~~~ Looking at placement access log, the command is sending request with &uuid= instead of ?uuid= ~~~ 2021-07-15 02:02:28.101 24 INFO placement.requestlog [req-a9d4942e-411a-4901-b05e-98ec1239ef70 31e1d736a759444f92346daf932243ff 91063c94413548b695edc6a0ef1f1252 - default default] 172.17.1.24 "GET /placement/resource_providers&uuid=dbba1bf7-6e97-4dcb-8d4c-37fe36633358" status: 404 len: 162 microversion: 1.14 ~~~ Steps to reproduce == - Look up existing resource provider uuid $ openstack resource provider list - Run audit command with one of the ids specified $ nova-manage placement audit --resource_provider Expected result === The command succeeds without error Actual result = The command fails with the following error Resource provider with UUID does not exist. Environment === This issue was initially found in the following downstream bug. https://bugzilla.redhat.com/show_bug.cgi?id=1982485 Logs & Configs == N/A ** 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/1936278 Title: nova-manage placement audit command always fails with --resource_provider option Status in OpenStack Compute (nova): In Progress Bug description: Description === nova-mange placement audit command always fails because the target resource provider is not found ~~~ # nova-manage placement audit --resource_provider dbba1bf7-6e97-4dcb-8d4c-37fe36633358 --verbose Resource provider with UUID dbba1bf7-6e97-4dcb-8d4c-37fe36633358 does not exist. Error: non zero exit code: 127: OCI runtime error ~~~ However the resource provider record actually exists in Placement. ~~~ (overcloud) [stack@undercloud-0 ~]$ openstack resource provider list --uuid dbba1bf7-6e97-4dcb-8d4c-37fe36633358 --os-placement-api-version 1.14 +--+++--+--+ | uuid | name | generation | root_provider_uuid | parent_provider_uuid | +--+++--+--+ | dbba1bf7-6e97-4dcb-8d4c-37fe36633358 | compute-0.redhat.local | 28 | dbba1bf7-6e97-4dcb-8d4c-37fe36633358 | None | +--+++--+--+ ~~~ Looking at placement access log, the command is sending request with &uuid= instead of ?uuid= ~~~ 2021-07-15 02:02:28.101 24 INFO placement.requestlog [req-a9d4942e-411a-4901-b05e-98ec1239ef70 31e1d736a759444f92346daf932243ff 91063c94413548b695edc6a0ef1f1252 - default default] 172.17.1.24 "GET /placement/resource_providers&uuid=dbba1bf7-6e97-4dcb-8d4c-37fe36633358" status: 404 len: 162 microversion: 1.14 ~~~ Steps to reproduce == - Look up existing resource provider uuid $ openstack resource provider list - Run audit command with one of the ids specified $ nova-manage placement audit --resource_provider Expected result === The command succeeds without error Actual result = The command fails with the following error Resource provider with UUID does not exist. Environment === This issue was initially found in the following dow
[Yahoo-eng-team] [Bug 1936667] Re: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3
** Also affects: mistral Importance: Undecided Status: New ** Also affects: manila Importance: Undecided Status: New ** Also affects: zaqar 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/1936667 Title: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3 Status in OpenStack Shared File Systems Service (Manila): New Status in Mistral: New Status in neutron: In Progress Status in zaqar: New Bug description: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3. For example: >>> import collections >>> collections.Iterable :1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop working >>> from collections import abc >>> abc.Iterable To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1936667/+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 1936667] Re: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3
** Also affects: taskflow Importance: Undecided Status: New ** Changed in: taskflow Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1936667 Title: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3 Status in OpenStack Identity (keystone): New Status in OpenStack Shared File Systems Service (Manila): In Progress Status in Mistral: In Progress Status in neutron: In Progress Status in taskflow: In Progress Status in tempest: In Progress Status in zaqar: In Progress Bug description: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3. For example: >>> import collections >>> collections.Iterable :1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop working >>> from collections import abc >>> abc.Iterable To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1936667/+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 1936667] Re: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3
** Also 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/1936667 Title: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3 Status in OpenStack Identity (keystone): In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in Mistral: In Progress Status in neutron: In Progress Status in taskflow: In Progress Status in tempest: In Progress Status in zaqar: In Progress Bug description: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3. For example: >>> import collections >>> collections.Iterable :1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop working >>> from collections import abc >>> abc.Iterable To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1936667/+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 1936667] Re: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3
** Also affects: tempest Importance: Undecided Status: New ** Changed in: tempest Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1936667 Title: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3 Status in OpenStack Identity (keystone): In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in Mistral: In Progress Status in neutron: In Progress Status in taskflow: In Progress Status in tempest: In Progress Status in zaqar: In Progress Bug description: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3. For example: >>> import collections >>> collections.Iterable :1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop working >>> from collections import abc >>> abc.Iterable To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1936667/+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 1936667] Re: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3
The following command would detect what we should replace... egrep -r -e 'collections\.(Awaitable|Coroutine|AsyncIterable|AsyncIterator|AsyncGenerator|Hashable|Iterable|Iterator|Generator|Reversible|Sized|Container|Callable|Collection|Set|MutableSet|Mapping|MutableMapping|MappingView|KeysView|ItemsView|ValuesView|Sequence|MutableSequence|ByteString)' --exclude-dir .tox --exclude-dir doc . ** Also affects: cinder Importance: Undecided Status: New ** No longer affects: cinder -- 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/1936667 Title: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3 Status in OpenStack Identity (keystone): In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in Mistral: In Progress Status in neutron: In Progress Status in taskflow: In Progress Status in tempest: In Progress Status in zaqar: In Progress Bug description: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3. For example: >>> import collections >>> collections.Iterable :1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop working >>> from collections import abc >>> abc.Iterable To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1936667/+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 1936667] Re: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3
** Also affects: swift 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/1936667 Title: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3 Status in OpenStack Identity (keystone): In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in Mistral: In Progress Status in neutron: In Progress Status in OpenStack Object Storage (swift): In Progress Status in taskflow: In Progress Status in tempest: In Progress Status in zaqar: In Progress Bug description: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3. For example: >>> import collections >>> collections.Iterable :1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop working >>> from collections import abc >>> abc.Iterable To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1936667/+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 1936667] Re: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3
** Also affects: cinder Importance: Undecided Status: New ** No longer affects: cinder ** Also affects: tacker 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/1936667 Title: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3 Status in OpenStack Identity (keystone): In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in Mistral: In Progress Status in neutron: Fix Released Status in OpenStack Object Storage (swift): Fix Released Status in tacker: In Progress Status in taskflow: Fix Released Status in tempest: In Progress Status in zaqar: In Progress Bug description: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3. For example: >>> import collections >>> collections.Iterable :1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop working >>> from collections import abc >>> abc.Iterable To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1936667/+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 1937901] [NEW] healthcheck middleware should be deployed as app instead of filter
Public bug reported: Since oslo.middleware 3.22.0[1], deploying healtcheck middleware as a filter is deprecated and it should be deployed as an app. [1] https://review.opendev.org/c/openstack/oslo.middleware/+/403734 ** Affects: glance Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Changed in: glance Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1937901 Title: healthcheck middleware should be deployed as app instead of filter Status in Glance: In Progress Bug description: Since oslo.middleware 3.22.0[1], deploying healtcheck middleware as a filter is deprecated and it should be deployed as an app. [1] https://review.opendev.org/c/openstack/oslo.middleware/+/403734 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1937901/+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 1938045] [NEW] OsloDBDeprecationWarning: EngineFacade is deprecated; please use oslo_db.sqlalchemy.enginefacade
Public bug reported: The following deprecation warning in continuously observed in unit test jobs. /home/zuul/src/opendev.org/openstack/glance/.tox/py39/lib/python3.9/site- packages/oslo_db/sqlalchemy/enginefacade.py:1366: OsloDBDeprecationWarning: EngineFacade is deprecated; please use oslo_db.sqlalchemy.enginefacade Example can be found here. https://zuul.opendev.org/t/openstack/build/744e2be61f5f459b9b2bcf7f046cd31e Usage of EngineFacade is deprecated since oslo.db 1.12.0 https://github.com/openstack/oslo.db/commit/fdbd928b1fdf0334e1740e565ab8206fff54eaa6 However there is one usage left in glance code. https://github.com/openstack/glance/blob/fa558885503121813bd7d9bacb63754ad5b61676/glance/db/sqlalchemy/api.py#L88 ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1938045 Title: OsloDBDeprecationWarning: EngineFacade is deprecated; please use oslo_db.sqlalchemy.enginefacade Status in Glance: New Bug description: The following deprecation warning in continuously observed in unit test jobs. /home/zuul/src/opendev.org/openstack/glance/.tox/py39/lib/python3.9/site- packages/oslo_db/sqlalchemy/enginefacade.py:1366: OsloDBDeprecationWarning: EngineFacade is deprecated; please use oslo_db.sqlalchemy.enginefacade Example can be found here. https://zuul.opendev.org/t/openstack/build/744e2be61f5f459b9b2bcf7f046cd31e Usage of EngineFacade is deprecated since oslo.db 1.12.0 https://github.com/openstack/oslo.db/commit/fdbd928b1fdf0334e1740e565ab8206fff54eaa6 However there is one usage left in glance code. https://github.com/openstack/glance/blob/fa558885503121813bd7d9bacb63754ad5b61676/glance/db/sqlalchemy/api.py#L88 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1938045/+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 1938103] [NEW] assertDictContainsSubset is deprecated since Python3.2
Public bug reported:
unittest.TestCase.assertDictContainsSubset is deprecated since Python
3.2[1] and shows the following warning.
~~~
/usr/lib/python3.9/unittest/case.py:1134: DeprecationWarning:
assertDictContainsSubset is deprecated
warnings.warn('assertDictContainsSubset is deprecated',
~~~
[1] https://docs.python.org/3/whatsnew/3.2.html#unittest
** Affects: glance
Importance: Undecided
Status: In Progress
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1938103
Title:
assertDictContainsSubset is deprecated since Python3.2
Status in Glance:
In Progress
Status in OpenStack Identity (keystone):
New
Bug description:
unittest.TestCase.assertDictContainsSubset is deprecated since Python
3.2[1] and shows the following warning.
~~~
/usr/lib/python3.9/unittest/case.py:1134: DeprecationWarning:
assertDictContainsSubset is deprecated
warnings.warn('assertDictContainsSubset is deprecated',
~~~
[1] https://docs.python.org/3/whatsnew/3.2.html#unittest
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1938103/+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 1938103] Re: assertDictContainsSubset is deprecated since Python3.2
** Also 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/1938103
Title:
assertDictContainsSubset is deprecated since Python3.2
Status in Glance:
In Progress
Status in OpenStack Identity (keystone):
New
Bug description:
unittest.TestCase.assertDictContainsSubset is deprecated since Python
3.2[1] and shows the following warning.
~~~
/usr/lib/python3.9/unittest/case.py:1134: DeprecationWarning:
assertDictContainsSubset is deprecated
warnings.warn('assertDictContainsSubset is deprecated',
~~~
[1] https://docs.python.org/3/whatsnew/3.2.html#unittest
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1938103/+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 1938103] Re: assertDictContainsSubset is deprecated since Python3.2
** Changed in: glance
Assignee: (unassigned) => Takashi Kajinami (kajinamit)
** Changed in: keystone
Assignee: (unassigned) => Takashi Kajinami (kajinamit)
** Also affects: designate
Importance: Undecided
Status: New
** No longer affects: designate
--
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/1938103
Title:
assertDictContainsSubset is deprecated since Python3.2
Status in Glance:
In Progress
Status in OpenStack Identity (keystone):
In Progress
Bug description:
unittest.TestCase.assertDictContainsSubset is deprecated since Python
3.2[1] and shows the following warning.
~~~
/usr/lib/python3.9/unittest/case.py:1134: DeprecationWarning:
assertDictContainsSubset is deprecated
warnings.warn('assertDictContainsSubset is deprecated',
~~~
[1] https://docs.python.org/3/whatsnew/3.2.html#unittest
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1938103/+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 1938120] [NEW] keystone-protection-functional is failing because of missing demo project
Public bug reported: The keystone-protection-functional job is repeatedly failing because the demo project is not found. ``` + ./stack.sh:main:1294 : echo_summary 'Creating initial neutron network elements' + ./stack.sh:echo_summary:422 : [[ -t 3 ]] + ./stack.sh:echo_summary:428 : echo -e Creating initial neutron network elements + ./stack.sh:main:1297 : type -p neutron_plugin_create_initial_networks + ./stack.sh:main:1300 : create_neutron_initial_network + lib/neutron_plugins/services/l3:create_neutron_initial_network:164 : local project_id ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : grep ' demo ' ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : oscwrap project list ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : get_field 1 ++ functions-common:get_field:726 : local data field ++ functions-common:get_field:727 : read data ++ functions-common:oscwrap:2349: return 0 + lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : project_id= + lib/neutron_plugins/services/l3:create_neutron_initial_network:166 : die_if_not_set 166 project_id 'Failure retrieving project_id for demo' + functions-common:die_if_not_set:216 : local exitcode=0 [Call Trace] ./stack.sh:1300:create_neutron_initial_network /opt/stack/devstack/lib/neutron_plugins/services/l3:166:die_if_not_set /opt/stack/devstack/functions-common:223:die [ERROR] /opt/stack/devstack/functions-common:166 Failure retrieving project_id for demo exit_trap: cleaning up child processes Error on exit *** FINISHED *** ``` Example can be found here; https://zuul.opendev.org/t/openstack/build/90628c08f0f84927a0e547e5c9fc409e ** 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/1938120 Title: keystone-protection-functional is failing because of missing demo project Status in OpenStack Identity (keystone): New Bug description: The keystone-protection-functional job is repeatedly failing because the demo project is not found. ``` + ./stack.sh:main:1294 : echo_summary 'Creating initial neutron network elements' + ./stack.sh:echo_summary:422 : [[ -t 3 ]] + ./stack.sh:echo_summary:428 : echo -e Creating initial neutron network elements + ./stack.sh:main:1297 : type -p neutron_plugin_create_initial_networks + ./stack.sh:main:1300 : create_neutron_initial_network + lib/neutron_plugins/services/l3:create_neutron_initial_network:164 : local project_id ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : grep ' demo ' ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : oscwrap project list ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : get_field 1 ++ functions-common:get_field:726 : local data field ++ functions-common:get_field:727 : read data ++ functions-common:oscwrap:2349: return 0 + lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : project_id= + lib/neutron_plugins/services/l3:create_neutron_initial_network:166 : die_if_not_set 166 project_id 'Failure retrieving project_id for demo' + functions-common:die_if_not_set:216 : local exitcode=0 [Call Trace] ./stack.sh:1300:create_neutron_initial_network /opt/stack/devstack/lib/neutron_plugins/services/l3:166:die_if_not_set /opt/stack/devstack/functions-common:223:die [ERROR] /opt/stack/devstack/functions-common:166 Failure retrieving project_id for demo exit_trap: cleaning up child processes Error on exit *** FINISHED *** ``` Example can be found here; https://zuul.opendev.org/t/openstack/build/90628c08f0f84927a0e547e5c9fc409e To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1938120/+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 1938120] Re: keystone-protection-functional is failing because of missing demo project
After looking into this in detail now I have a feeling that this issue was introduced by a change[1] in devstack and we should fix devstack. [1] https://opendev.org/openstack/devstack/commit/9dc2b88eb42a5f98f43bc8ad3dfa3962a4d44d74 ** Also affects: devstack 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/1938120 Title: keystone-protection-functional is failing because of missing demo project Status in devstack: New Status in OpenStack Identity (keystone): New Bug description: The keystone-protection-functional job is repeatedly failing because the demo project is not found. ``` + ./stack.sh:main:1294 : echo_summary 'Creating initial neutron network elements' + ./stack.sh:echo_summary:422 : [[ -t 3 ]] + ./stack.sh:echo_summary:428 : echo -e Creating initial neutron network elements + ./stack.sh:main:1297 : type -p neutron_plugin_create_initial_networks + ./stack.sh:main:1300 : create_neutron_initial_network + lib/neutron_plugins/services/l3:create_neutron_initial_network:164 : local project_id ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : grep ' demo ' ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : oscwrap project list ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : get_field 1 ++ functions-common:get_field:726 : local data field ++ functions-common:get_field:727 : read data ++ functions-common:oscwrap:2349: return 0 + lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : project_id= + lib/neutron_plugins/services/l3:create_neutron_initial_network:166 : die_if_not_set 166 project_id 'Failure retrieving project_id for demo' + functions-common:die_if_not_set:216 : local exitcode=0 [Call Trace] ./stack.sh:1300:create_neutron_initial_network /opt/stack/devstack/lib/neutron_plugins/services/l3:166:die_if_not_set /opt/stack/devstack/functions-common:223:die [ERROR] /opt/stack/devstack/functions-common:166 Failure retrieving project_id for demo exit_trap: cleaning up child processes Error on exit *** FINISHED *** ``` Example can be found here; https://zuul.opendev.org/t/openstack/build/90628c08f0f84927a0e547e5c9fc409e To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1938120/+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 1938120] Re: keystone-protection-functional is failing because of missing demo project
** No longer affects: keystone -- 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/1938120 Title: keystone-protection-functional is failing because of missing demo project Status in devstack: New Bug description: The keystone-protection-functional job is repeatedly failing because the demo project is not found. ``` + ./stack.sh:main:1294 : echo_summary 'Creating initial neutron network elements' + ./stack.sh:echo_summary:422 : [[ -t 3 ]] + ./stack.sh:echo_summary:428 : echo -e Creating initial neutron network elements + ./stack.sh:main:1297 : type -p neutron_plugin_create_initial_networks + ./stack.sh:main:1300 : create_neutron_initial_network + lib/neutron_plugins/services/l3:create_neutron_initial_network:164 : local project_id ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : grep ' demo ' ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : oscwrap project list ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : get_field 1 ++ functions-common:get_field:726 : local data field ++ functions-common:get_field:727 : read data ++ functions-common:oscwrap:2349: return 0 + lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : project_id= + lib/neutron_plugins/services/l3:create_neutron_initial_network:166 : die_if_not_set 166 project_id 'Failure retrieving project_id for demo' + functions-common:die_if_not_set:216 : local exitcode=0 [Call Trace] ./stack.sh:1300:create_neutron_initial_network /opt/stack/devstack/lib/neutron_plugins/services/l3:166:die_if_not_set /opt/stack/devstack/functions-common:223:die [ERROR] /opt/stack/devstack/functions-common:166 Failure retrieving project_id for demo exit_trap: cleaning up child processes Error on exit *** FINISHED *** ``` Example can be found here; https://zuul.opendev.org/t/openstack/build/90628c08f0f84927a0e547e5c9fc409e To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1938120/+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 1939944] [NEW] The parameters of the healthcheck middlewares are missing from glance-api.conf
Public bug reported: Since https://review.opendev.org/c/openstack/glance/+/148595 was merged, the healthcheck middleware has been enabled in the default api pipelines. However the parameters of the middleware are missing from the example glance-api.conf file, and are not rendered if we regenerate the file using oslo-config-generator. ** Affects: glance Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Changed in: glance Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1939944 Title: The parameters of the healthcheck middlewares are missing from glance- api.conf Status in Glance: In Progress Bug description: Since https://review.opendev.org/c/openstack/glance/+/148595 was merged, the healthcheck middleware has been enabled in the default api pipelines. However the parameters of the middleware are missing from the example glance-api.conf file, and are not rendered if we regenerate the file using oslo-config-generator. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1939944/+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 1940009] [NEW] The healthcheck middleware options are not included in neutron.conf generated by "tox -e genconfig"
Public bug reported: The healthcheck middleware was added to api pipeline during Victoria cycle. Â https://review.opendev.org/c/openstack/neutron/+/724676 However the options of the middleware is not included in neutron.conf generated by "tox e genconfig" which executes internally oslo-config-generator. This is because the oslo.middleware.healthcheck endpoint is not added to the configuration file used by the generator command. ** Affects: neutron Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Description changed: - The healthcheck middleware was added during Victoria cycle. - https://review.opendev.org/c/openstack/neutron/+/724676 + The healthcheck middleware was added to api pipeline during Victoria cycle. + Â https://review.opendev.org/c/openstack/neutron/+/724676 However the options of the middleware is not included in neutron.conf generated by "tox e genconfig" which executes internally oslo-config-generator. This is because the oslo.middleware.healthcheck endpoint is not added to the configuration file used by the generator command. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1940009 Title: The healthcheck middleware options are not included in neutron.conf generated by "tox -e genconfig" Status in neutron: In Progress Bug description: The healthcheck middleware was added to api pipeline during Victoria cycle. Â https://review.opendev.org/c/openstack/neutron/+/724676 However the options of the middleware is not included in neutron.conf generated by "tox e genconfig" which executes internally oslo-config-generator. This is because the oslo.middleware.healthcheck endpoint is not added to the configuration file used by the generator command. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1940009/+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 1937904] Re: imp module is deprecated
** 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/1937904 Title: imp module is deprecated Status in neutron: In Progress Status in os-win: Fix Released Bug description: The imp module is deprecated since Python 3.4 and should be replaced by the importlib module. Now usage of the imp module shows the following deprecation warning. ~~~ DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses ~~~ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1937904/+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 1937904] Re: imp module is deprecated
** Changed in: os-win Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Changed in: neutron Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Also affects: python-novaclient 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/1937904 Title: imp module is deprecated Status in neutron: In Progress Status in os-win: Fix Released Status in python-novaclient: New Bug description: The imp module is deprecated since Python 3.4 and should be replaced by the importlib module. Now usage of the imp module shows the following deprecation warning. ~~~ DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses ~~~ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1937904/+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 1937904] Re: imp module is deprecated
** Also affects: tripleo 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/1937904 Title: imp module is deprecated Status in neutron: In Progress Status in os-win: Fix Released Status in python-novaclient: In Progress Status in tripleo: New Bug description: The imp module is deprecated since Python 3.4 and should be replaced by the importlib module. Now usage of the imp module shows the following deprecation warning. ~~~ DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses ~~~ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1937904/+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 1940090] [NEW] options of the castellan library are missing from glance-api.conf
Public bug reported: Glance loads the castellan library for encryption but options for that library(like ones under [key_manager], [barbican] and etc) are missing from example glance-api.conf. I've regenerated the conf file using `tox -e genconfig` which interaly calls oslo-confing-generator, but even in the generated config file the options are still missing. ** Affects: glance Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1940090 Title: options of the castellan library are missing from glance-api.conf Status in Glance: In Progress Bug description: Glance loads the castellan library for encryption but options for that library(like ones under [key_manager], [barbican] and etc) are missing from example glance-api.conf. I've regenerated the conf file using `tox -e genconfig` which interaly calls oslo-confing-generator, but even in the generated config file the options are still missing. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1940090/+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 1940733] [NEW] [oslo_reports] options are missing from the config file generated by oslo-confi-generator
Public bug reported: Description === The oslo.reports library[1] introduced ability to generate an error report which is usually called "guru meditation report". This library provides several config options but currently none of them are rendered into .conf file generated by oslo-confing-generator. [1] https://github.com/openstack/oslo.reports Steps to reproduce == * Generate .conf file by `tox -e genconfig` * Review options described in the generated .conf file Expected result === The [oslo_reports] section is included Actual result = The [oslo_reports] section is missing Environment === N/A Logs & Configs == N/A ** Affects: ceilometer Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Affects: designate Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Affects: glance Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Affects: manila Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Affects: nova Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Also affects: manila Importance: Undecided Status: New ** Changed in: manila Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- 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/1940733 Title: [oslo_reports] options are missing from the config file generated by oslo-confi-generator Status in Ceilometer: In Progress Status in Designate: In Progress Status in Glance: In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in OpenStack Compute (nova): In Progress Bug description: Description === The oslo.reports library[1] introduced ability to generate an error report which is usually called "guru meditation report". This library provides several config options but currently none of them are rendered into .conf file generated by oslo-confing-generator. [1] https://github.com/openstack/oslo.reports Steps to reproduce == * Generate .conf file by `tox -e genconfig` * Review options described in the generated .conf file Expected result === The [oslo_reports] section is included Actual result = The [oslo_reports] section is missing Environment === N/A Logs & Configs == N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1940733/+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 1940733] Re: [oslo_reports] options are missing from the config file generated by oslo-confi-generator
** Also affects: ceilometer Importance: Undecided Status: New ** Changed in: ceilometer Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Also affects: glance Importance: Undecided Status: New ** Changed in: glance Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- 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/1940733 Title: [oslo_reports] options are missing from the config file generated by oslo-confi-generator Status in Ceilometer: In Progress Status in Designate: In Progress Status in Glance: In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in OpenStack Compute (nova): In Progress Bug description: Description === The oslo.reports library[1] introduced ability to generate an error report which is usually called "guru meditation report". This library provides several config options but currently none of them are rendered into .conf file generated by oslo-confing-generator. [1] https://github.com/openstack/oslo.reports Steps to reproduce == * Generate .conf file by `tox -e genconfig` * Review options described in the generated .conf file Expected result === The [oslo_reports] section is included Actual result = The [oslo_reports] section is missing Environment === N/A Logs & Configs == N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1940733/+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 1940733] Re: [oslo_reports] options are missing from the config file generated by oslo-confi-generator
** Also affects: designate Importance: Undecided Status: New ** Changed in: designate Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Changed in: ceilometer Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1940733 Title: [oslo_reports] options are missing from the config file generated by oslo-confi-generator Status in Ceilometer: In Progress Status in Designate: In Progress Status in Glance: In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in OpenStack Compute (nova): In Progress Bug description: Description === The oslo.reports library[1] introduced ability to generate an error report which is usually called "guru meditation report". This library provides several config options but currently none of them are rendered into .conf file generated by oslo-confing-generator. [1] https://github.com/openstack/oslo.reports Steps to reproduce == * Generate .conf file by `tox -e genconfig` * Review options described in the generated .conf file Expected result === The [oslo_reports] section is included Actual result = The [oslo_reports] section is missing Environment === N/A Logs & Configs == N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1940733/+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 1940790] [NEW] oslo.cache options are missing from neutron.conf generated by "tox -e genconfig"
Public bug reported: # We could include this in bug 1940009 but the fix for the bug was already merged. # So I'll crate a separate bug to avoid two Closes-Bug commits which I believe is confusing. Neutron uses oslo.cache library for caching and registers its options. However these options are missing from neutron.conf generated by "tox -e genconfig". [1] https://github.com/openstack/neutron/blob/84d9bb1e0e5cde34acd9f4ee7f54baf9c89c7d81/neutron/common/cache_utils.py#L28-L30 ** Affects: neutron Importance: Undecided Status: In Progress ** Description changed: # We could include this in bug 1940009 but the fix for the bug was already merged. - # So I'll crate a separate bug to avoid two Closes-Bug commit which is confusing. + # So I'll crate a separate bug to avoid two Closes-Bug commits which I believe is confusing. Neutron uses oslo.cache library for caching and registers its options. However these options are missing from neutron.conf generated by "tox -e genconfig". [1] https://github.com/openstack/neutron/blob/84d9bb1e0e5cde34acd9f4ee7f54baf9c89c7d81/neutron/common/cache_utils.py#L28-L30 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1940790 Title: oslo.cache options are missing from neutron.conf generated by "tox -e genconfig" Status in neutron: In Progress Bug description: # We could include this in bug 1940009 but the fix for the bug was already merged. # So I'll crate a separate bug to avoid two Closes-Bug commits which I believe is confusing. Neutron uses oslo.cache library for caching and registers its options. However these options are missing from neutron.conf generated by "tox -e genconfig". [1] https://github.com/openstack/neutron/blob/84d9bb1e0e5cde34acd9f4ee7f54baf9c89c7d81/neutron/common/cache_utils.py#L28-L30 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1940790/+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 1941020] [NEW] [memcache] options are no longer used
Public bug reported: Keystone provides some options under the [memcache] section but these parameters are not used in any place. Looking at history, it seems these parameters were used in memcache_pool backend to persist tokens but that backend was removed during Pike. https://opendev.org/openstack/keystone/src/tag/newton- eol/keystone/token/persistence/backends/memcache_pool.py ** Affects: keystone Importance: Undecided Status: In Progress -- 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/1941020 Title: [memcache] options are no longer used Status in OpenStack Identity (keystone): In Progress Bug description: Keystone provides some options under the [memcache] section but these parameters are not used in any place. Looking at history, it seems these parameters were used in memcache_pool backend to persist tokens but that backend was removed during Pike. https://opendev.org/openstack/keystone/src/tag/newton- eol/keystone/token/persistence/backends/memcache_pool.py To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1941020/+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 1938103] Re: assertDictContainsSubset is deprecated since Python3.2
** Also affects: python-neutronclient
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/1938103
Title:
assertDictContainsSubset is deprecated since Python3.2
Status in Glance:
In Progress
Status in OpenStack Identity (keystone):
In Progress
Status in neutron:
New
Status in python-neutronclient:
In Progress
Bug description:
unittest.TestCase.assertDictContainsSubset is deprecated since Python
3.2[1] and shows the following warning.
~~~
/usr/lib/python3.9/unittest/case.py:1134: DeprecationWarning:
assertDictContainsSubset is deprecated
warnings.warn('assertDictContainsSubset is deprecated',
~~~
[1] https://docs.python.org/3/whatsnew/3.2.html#unittest
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1938103/+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 1938103] Re: assertDictContainsSubset is deprecated since Python3.2
** 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 OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1938103
Title:
assertDictContainsSubset is deprecated since Python3.2
Status in Glance:
In Progress
Status in OpenStack Identity (keystone):
In Progress
Status in neutron:
In Progress
Status in python-neutronclient:
In Progress
Bug description:
unittest.TestCase.assertDictContainsSubset is deprecated since Python
3.2[1] and shows the following warning.
~~~
/usr/lib/python3.9/unittest/case.py:1134: DeprecationWarning:
assertDictContainsSubset is deprecated
warnings.warn('assertDictContainsSubset is deprecated',
~~~
[1] https://docs.python.org/3/whatsnew/3.2.html#unittest
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1938103/+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 1938103] Re: assertDictContainsSubset is deprecated since Python3.2
** Also affects: mistral
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/1938103
Title:
assertDictContainsSubset is deprecated since Python3.2
Status in Designate:
In Progress
Status in Glance:
In Progress
Status in OpenStack Identity (keystone):
In Progress
Status in Mistral:
In Progress
Status in neutron:
In Progress
Status in python-neutronclient:
In Progress
Bug description:
unittest.TestCase.assertDictContainsSubset is deprecated since Python
3.2[1] and shows the following warning.
~~~
/usr/lib/python3.9/unittest/case.py:1134: DeprecationWarning:
assertDictContainsSubset is deprecated
warnings.warn('assertDictContainsSubset is deprecated',
~~~
[1] https://docs.python.org/3/whatsnew/3.2.html#unittest
To manage notifications about this bug go to:
https://bugs.launchpad.net/designate/+bug/1938103/+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 1938103] Re: assertDictContainsSubset is deprecated since Python3.2
** Changed in: mistral
Assignee: (unassigned) => Takashi Kajinami (kajinamit)
** Also affects: designate
Importance: Undecided
Status: New
** Changed in: designate
Assignee: (unassigned) => Takashi Kajinami (kajinamit)
--
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/1938103
Title:
assertDictContainsSubset is deprecated since Python3.2
Status in Designate:
In Progress
Status in Glance:
In Progress
Status in OpenStack Identity (keystone):
In Progress
Status in Mistral:
In Progress
Status in neutron:
In Progress
Status in python-neutronclient:
In Progress
Bug description:
unittest.TestCase.assertDictContainsSubset is deprecated since Python
3.2[1] and shows the following warning.
~~~
/usr/lib/python3.9/unittest/case.py:1134: DeprecationWarning:
assertDictContainsSubset is deprecated
warnings.warn('assertDictContainsSubset is deprecated',
~~~
[1] https://docs.python.org/3/whatsnew/3.2.html#unittest
To manage notifications about this bug go to:
https://bugs.launchpad.net/designate/+bug/1938103/+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 1944043] [NEW] Wrong exception type is expected to retry volume detachment API calls
Public bug reported: Description === The following change introduced the logic to retry cinder API calls to detach volumes. https://review.opendev.org/c/openstack/nova/+/669674 The logic detects the InternalServerError class from cindreclient.apiclient.exceptions. However this is wrong and these API calls raises the ClientException class from cinderclient.exceptions instead. Steps to reproduce == N/A Actual result = N/A Environment === N/A Logs & Configs == N/A ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1944043 Title: Wrong exception type is expected to retry volume detachment API calls Status in OpenStack Compute (nova): New Bug description: Description === The following change introduced the logic to retry cinder API calls to detach volumes. https://review.opendev.org/c/openstack/nova/+/669674 The logic detects the InternalServerError class from cindreclient.apiclient.exceptions. However this is wrong and these API calls raises the ClientException class from cinderclient.exceptions instead. Steps to reproduce == N/A Actual result = N/A Environment === N/A Logs & Configs == N/A To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1944043/+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 1946100] [NEW] [oslo_limit] parameters are missing from glance-api.conf
Public bug reported: The following change[1] introduced dependency on the oslo.limit library to implement the unified quota but the parameter of the library are still missing from the example glance-api.conf as well as the conf file generated by oslo-config-generator. We should add the missing oslo.config.opts entrypoint so that the library parameters are rendered into the conf file by oslo-config- generator. [1] https://review.opendev.org/c/openstack/glance/+/788054 ** Affects: glance Importance: Undecided Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1946100 Title: [oslo_limit] parameters are missing from glance-api.conf Status in Glance: In Progress Bug description: The following change[1] introduced dependency on the oslo.limit library to implement the unified quota but the parameter of the library are still missing from the example glance-api.conf as well as the conf file generated by oslo-config-generator. We should add the missing oslo.config.opts entrypoint so that the library parameters are rendered into the conf file by oslo-config- generator. [1] https://review.opendev.org/c/openstack/glance/+/788054 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1946100/+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 1938103] Re: assertDictContainsSubset is deprecated since Python3.2
** Also affects: tempest
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/1938103
Title:
assertDictContainsSubset is deprecated since Python3.2
Status in Designate:
In Progress
Status in Glance:
Fix Released
Status in OpenStack Identity (keystone):
Fix Released
Status in Mistral:
In Progress
Status in neutron:
Fix Released
Status in python-neutronclient:
Fix Released
Status in tempest:
In Progress
Bug description:
unittest.TestCase.assertDictContainsSubset is deprecated since Python
3.2[1] and shows the following warning.
~~~
/usr/lib/python3.9/unittest/case.py:1134: DeprecationWarning:
assertDictContainsSubset is deprecated
warnings.warn('assertDictContainsSubset is deprecated',
~~~
[1] https://docs.python.org/3/whatsnew/3.2.html#unittest
To manage notifications about this bug go to:
https://bugs.launchpad.net/designate/+bug/1938103/+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 1957180] [NEW] The [AGENT] veth_mtu parameter is no longer used
Public bug reported: Since the [ovs] use_veth_interconnection parameter was removed by [1], the [AGENT] veth_mtu parameter is no longer used. [1] https://review.opendev.org/c/openstack/neutron/+/759947 We should deprecate and remove the parameter since it has no effect now. ** Affects: neutron Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Description changed: Since the [ovs] use_veth_interconnection parameter was removed by [1], the [AGENT] veth_mtu parameter is no longer used. [1] https://review.opendev.org/c/openstack/neutron/+/759947 + + We should deprecate and remove the parameter since it has no effect now. ** Changed in: neutron Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1957180 Title: The [AGENT] veth_mtu parameter is no longer used Status in neutron: In Progress Bug description: Since the [ovs] use_veth_interconnection parameter was removed by [1], the [AGENT] veth_mtu parameter is no longer used. [1] https://review.opendev.org/c/openstack/neutron/+/759947 We should deprecate and remove the parameter since it has no effect now. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1957180/+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 1958075] [NEW] The fixtures library is missing from requirements.txt
Public bug reported:
Description
===
The following change[1] made the nova.utils module depend on the fixtures
library.
[1] https://review.opendev.org/c/openstack/nova/+/824280
However the fixtures library is listed only in test-requirements.txt and is not
yet listed in requirements.txt .
Because of this the library is not installed in normal deployment and the
`nova-manage api_db sync` command fails with the following error.
Traceback (most recent call last):
File "/usr/bin/nova-manage", line 6, in
from nova.cmd.manage import main
File "/usr/lib/python3.6/site-packages/nova/cmd/manage.py", line 49, in
from nova.cmd import common as cmd_common
File "/usr/lib/python3.6/site-packages/nova/cmd/common.py", line 26, in
import nova.db.main.api
File "/usr/lib/python3.6/site-packages/nova/db/main/api.py", line 45, in
from nova import block_device
File "/usr/lib/python3.6/site-packages/nova/block_device.py", line 26, in
from nova import utils
File "/usr/lib/python3.6/site-packages/nova/utils.py", line 32, in
import fixtures
ModuleNotFoundError: No module named 'fixtures'
This issue was initially detected in litmus jobs in puppet repos[2].
These jobs uses rdo packages which define dependencies based on requirements.txt
[2] example:
https://zuul.opendev.org/t/openstack/build/e086ca3375714860ae463b7a1d9b1bab
Steps to reproduce
==
Expected result
===
Actual result
=
Environment
===
Logs & Configs
======
** Affects: nova
Importance: Undecided
Assignee: Takashi Kajinami (kajinamit)
Status: In Progress
** Changed in: nova
Assignee: (unassigned) => Takashi Kajinami (kajinamit)
--
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/1958075
Title:
The fixtures library is missing from requirements.txt
Status in OpenStack Compute (nova):
In Progress
Bug description:
Description
===
The following change[1] made the nova.utils module depend on the fixtures
library.
[1] https://review.opendev.org/c/openstack/nova/+/824280
However the fixtures library is listed only in test-requirements.txt and is
not yet listed in requirements.txt .
Because of this the library is not installed in normal deployment and the
`nova-manage api_db sync` command fails with the following error.
Traceback (most recent call last):
File "/usr/bin/nova-manage", line 6, in
from nova.cmd.manage import main
File "/usr/lib/python3.6/site-packages/nova/cmd/manage.py", line 49, in
from nova.cmd import common as cmd_common
File "/usr/lib/python3.6/site-packages/nova/cmd/common.py", line 26, in
import nova.db.main.api
File "/usr/lib/python3.6/site-packages/nova/db/main/api.py", line 45, in
from nova import block_device
File "/usr/lib/python3.6/site-packages/nova/block_device.py", line 26, in
from nova import utils
File "/usr/lib/python3.6/site-packages/nova/utils.py", line 32, in
import fixtures
ModuleNotFoundError: No module named 'fixtures'
This issue was initially detected in litmus jobs in puppet repos[2].
These jobs uses rdo packages which define dependencies based on
requirements.txt
[2] example:
https://zuul.opendev.org/t/openstack/build/e086ca3375714860ae463b7a1d9b1bab
Steps to reproduce
==
Expected result
===
Actual result
=
Environment
===
Logs & Configs
==
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1958075/+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 1960247] [NEW] server suspend action allows authorization by user_id while server resume action does not
Public bug reported: Description === Since the following change was merged, nova allows authorization by user_id for server suspend action. https://review.opendev.org/c/openstack/nova/+/353344 However the same is not yet implemented in resume action and this results in inconsistent policy rule for corresponding two operations. Steps to reproduce == * Define policy rules like the following example   "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"   "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s" * Create a server by a non-admin user * Suspend the server by the user * Resume the server by the user Expected result === Both suspend and resume are accepted Actual result = Only suspend is accepted and resume fails with ERROR (Forbidden): Policy doesn't allow os_compute_api:os-suspend- server:suspend to be performed. (HTTP 403) (Request-ID: req-...) Environment === This issue was initially reported as one found in stable/xena deployment. http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027078.html Logs & Configs == N/A ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1960247 Title: server suspend action allows authorization by user_id while server resume action does not Status in OpenStack Compute (nova): New Bug description: Description === Since the following change was merged, nova allows authorization by user_id for server suspend action. https://review.opendev.org/c/openstack/nova/+/353344 However the same is not yet implemented in resume action and this results in inconsistent policy rule for corresponding two operations. Steps to reproduce == * Define policy rules like the following example   "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"   "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s" * Create a server by a non-admin user * Suspend the server by the user * Resume the server by the user Expected result === Both suspend and resume are accepted Actual result = Only suspend is accepted and resume fails with ERROR (Forbidden): Policy doesn't allow os_compute_api:os-suspend- server:suspend to be performed. (HTTP 403) (Request-ID: req-...) Environment === This issue was initially reported as one found in stable/xena deployment. http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027078.html Logs & Configs == N/A To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1960247/+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 1962726] [NEW] ssh-rsa key is no longer allowed by recent openssh
Public bug reported: Description === Currently create Key-pair API without actual key content returns the key generated at server side which is formatted in ssh-rsa. However ssh-rsa is no longer supported by default since openssh 8.8 https://www.openssh.com/txt/release-8.8 ``` This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for https://www.openssh.com/txt/release-8.8 + + ``` + + This release disables RSA signatures using the SHA-1 hash algorithm + by default. This change has been made as the SHA-1 hash algorithm is + cryptographically broken, and it is possible to create chosen-prefix + hash collisions for https://www.openssh.com/txt/release-8.8 ``` - This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for https://bugs.launchpad.net/bugs/1962726 Title: ssh-rsa key is no longer allowed by recent openssh Status in OpenStack Compute (nova): New Bug description: Description === Currently create Key-pair API without actual key content returns the key generated at server side which is formatted in ssh-rsa. However ssh-rsa is no longer supported by default since openssh 8.8 https://www.openssh.com/txt/release-8.8 ``` This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for https://bugs.launchpad.net/nova/+bug/1962726/+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 1525439] Re: Glance V2 API is not backwards compatible and breaks Cinder solidfire driver
** Changed in: puppet-cinder Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1525439 Title: Glance V2 API is not backwards compatible and breaks Cinder solidfire driver Status in Cinder: Won't Fix Status in Glance: Won't Fix Status in puppet-cinder: Won't Fix Bug description: In stable/kilo Glance API V2 change of image-metadata is_public flag to visibility = Public breaks the SolidFire (and maybe other, NetApp?) drivers that depend on is_public flag. Specifically this breaks the ability efficiently handle images by caching images in the SolidFire cluster. Changing the API back to V1 through the cinder.conf file then breaks Ceph which depends on V2 and the image-metadata direct_url and locations to determine if it can clone a image to a volume. So this breaks Ceph's ability to efficiently handle images This version mismatch does not allow for SolidFire and Ceph to both be used efficiently in the same OpenStack cloud. NOTE: openstack/puppet-cinder defaults to glance-api-version = 2 which allows Ceph efficientcy to work and not SolidFire (and others). Mainly Opening this Bug to document this problem since no changes are allowed to Kilo there is probably no way to fix this. Code locations: cinder/cinder/image/glance.py line 250-256 cinder/cinder/volume/drivers/rbd.py line 827 cinder/cinder/volume/drivers/solidfire.py line 647 puppet-cinder/manifests/glance.pp line 59 To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1525439/+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 1967683] [NEW] Wrong property to look up remote address
Public bug reported: Currently, remote_address attribute of the Reqeust object is used to look up client address in multiple places. eg. https://github.com/openstack/cinder/blob/7086157de07b77e8b67bbb767bc2ce25e86c2f51/cinder/api/middleware/auth.py#L64 ~~~ def _set_request_context(req, **kwargs): """Sets request context based on parameters and request.""" remote_address = getattr(req, 'remote_address', '127.0.0.1') ~~~ However, webob.Request has no remote_address attribute but only remote_addr attribute. https://docs.pylonsproject.org/projects/webob/en/stable/api/request.html#webob.request.BaseRequest.remote_addr ** Affects: cinder Importance: Undecided Status: In Progress ** Affects: nova Importance: Undecided Status: New ** Also affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1967683 Title: Wrong property to look up remote address Status in Cinder: In Progress Status in OpenStack Compute (nova): New Bug description: Currently, remote_address attribute of the Reqeust object is used to look up client address in multiple places. eg. https://github.com/openstack/cinder/blob/7086157de07b77e8b67bbb767bc2ce25e86c2f51/cinder/api/middleware/auth.py#L64 ~~~ def _set_request_context(req, **kwargs): """Sets request context based on parameters and request.""" remote_address = getattr(req, 'remote_address', '127.0.0.1') ~~~ However, webob.Request has no remote_address attribute but only remote_addr attribute. https://docs.pylonsproject.org/projects/webob/en/stable/api/request.html#webob.request.BaseRequest.remote_addr To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1967683/+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 1967683] Re: Wrong property to look up remote address
** Also affects: manila Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1967683 Title: Wrong property to look up remote address Status in Cinder: In Progress Status in ec2-api: In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in OpenStack Compute (nova): In Progress Bug description: Currently, remote_address attribute of the Reqeust object is used to look up client address in multiple places. eg. https://github.com/openstack/cinder/blob/7086157de07b77e8b67bbb767bc2ce25e86c2f51/cinder/api/middleware/auth.py#L64 ~~~ def _set_request_context(req, **kwargs): """Sets request context based on parameters and request.""" remote_address = getattr(req, 'remote_address', '127.0.0.1') ~~~ However, webob.Request has no remote_address attribute but only remote_addr attribute. https://docs.pylonsproject.org/projects/webob/en/stable/api/request.html#webob.request.BaseRequest.remote_addr To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1967683/+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 1967683] Re: Wrong property to look up remote address
** Also affects: ec2-api Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1967683 Title: Wrong property to look up remote address Status in Cinder: In Progress Status in ec2-api: In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in OpenStack Compute (nova): In Progress Bug description: Currently, remote_address attribute of the Reqeust object is used to look up client address in multiple places. eg. https://github.com/openstack/cinder/blob/7086157de07b77e8b67bbb767bc2ce25e86c2f51/cinder/api/middleware/auth.py#L64 ~~~ def _set_request_context(req, **kwargs): """Sets request context based on parameters and request.""" remote_address = getattr(req, 'remote_address', '127.0.0.1') ~~~ However, webob.Request has no remote_address attribute but only remote_addr attribute. https://docs.pylonsproject.org/projects/webob/en/stable/api/request.html#webob.request.BaseRequest.remote_addr To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1967683/+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 1967683] Re: Wrong property to look up remote address
** Also affects: masakari Importance: Undecided Status: New ** No longer affects: masakari ** Changed in: cinder Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Changed in: nova Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Changed in: manila Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Changed in: ec2-api Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- 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/1967683 Title: Wrong property to look up remote address Status in Cinder: In Progress Status in ec2-api: In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in OpenStack Compute (nova): In Progress Bug description: Currently, remote_address attribute of the Reqeust object is used to look up client address in multiple places. eg. https://github.com/openstack/cinder/blob/7086157de07b77e8b67bbb767bc2ce25e86c2f51/cinder/api/middleware/auth.py#L64 ~~~ def _set_request_context(req, **kwargs): """Sets request context based on parameters and request.""" remote_address = getattr(req, 'remote_address', '127.0.0.1') ~~~ However, webob.Request has no remote_address attribute but only remote_addr attribute. https://docs.pylonsproject.org/projects/webob/en/stable/api/request.html#webob.request.BaseRequest.remote_addr To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1967683/+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 1967686] [NEW] [DEFAULT] use_forwarded_for is duplicate of the HTTPProxyToWSGI middleware
Public bug reported: The [DEFAULT] use_forwarded_for parameter enables detection of remote address by the X-Forwarded-For request header. However this functionality is duplicate of the HTTPProxyToWSGI middleware in the oslo.middleware library. Now the HTTPProxyToWSGI middleware is enabled in api pipeline by default, and also is globally used by multiple components, the own use_forwarded_for parameter can be removed. ** Affects: cinder Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Affects: manila Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Affects: nova Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Also affects: nova Importance: Undecided Status: New ** Also affects: manila Importance: Undecided Status: New ** Changed in: cinder Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Changed in: nova Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Changed in: manila Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Description changed: The [DEFAULT] use_forwarded_for parameter enables detection of remote address by the X-Forwarded-For request header. - However this functionality is duplicate of the HTTPProxyToWSGI middleware. + However this functionality is duplicate of the HTTPProxyToWSGI middleware in the oslo.middleware library. Now the HTTPProxyToWSGI middleware is enabled in api pipeline by default, and also is globally used by multiple components, the own use_forwarded_for parameter can be removed. -- 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/1967686 Title: [DEFAULT] use_forwarded_for is duplicate of the HTTPProxyToWSGI middleware Status in Cinder: In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in OpenStack Compute (nova): In Progress Bug description: The [DEFAULT] use_forwarded_for parameter enables detection of remote address by the X-Forwarded-For request header. However this functionality is duplicate of the HTTPProxyToWSGI middleware in the oslo.middleware library. Now the HTTPProxyToWSGI middleware is enabled in api pipeline by default, and also is globally used by multiple components, the own use_forwarded_for parameter can be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1967686/+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 1967686] Re: [DEFAULT] use_forwarded_for is duplicate of the HTTPProxyToWSGI middleware
** Also affects: ec2-api Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1967686 Title: [DEFAULT] use_forwarded_for is duplicate of the HTTPProxyToWSGI middleware Status in Cinder: In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in OpenStack Compute (nova): In Progress Bug description: The [DEFAULT] use_forwarded_for parameter enables detection of remote address by the X-Forwarded-For request header. However this functionality is duplicate of the HTTPProxyToWSGI middleware in the oslo.middleware library. Now the HTTPProxyToWSGI middleware is enabled in api pipeline by default, and also is globally used by multiple components, the own use_forwarded_for parameter can be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1967686/+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 1967686] Re: [DEFAULT] use_forwarded_for is duplicate of the HTTPProxyToWSGI middleware
** Changed in: ec2-api Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** No longer affects: ec2-api -- 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/1967686 Title: [DEFAULT] use_forwarded_for is duplicate of the HTTPProxyToWSGI middleware Status in Cinder: In Progress Status in OpenStack Shared File Systems Service (Manila): In Progress Status in OpenStack Compute (nova): In Progress Bug description: The [DEFAULT] use_forwarded_for parameter enables detection of remote address by the X-Forwarded-For request header. However this functionality is duplicate of the HTTPProxyToWSGI middleware in the oslo.middleware library. Now the HTTPProxyToWSGI middleware is enabled in api pipeline by default, and also is globally used by multiple components, the own use_forwarded_for parameter can be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1967686/+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 1968468] [NEW] metering-agent: Duplicate report_interval parameters
Public bug reported: The neutron-metering-agent service has the following two report_interval parameters, and these two looks duplicate. (1) [DEFAULT] report_interval=300 (2) [AGENT] report_interval=30 Looking at the implementation, (1) is used to determine the configuration.report_interval in agent status while (2) is used to determine the actual interval in agent side. Considering consistency with the other agents, we should use (2) only and deprecate (1). ** 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/1968468 Title: metering-agent: Duplicate report_interval parameters Status in neutron: New Bug description: The neutron-metering-agent service has the following two report_interval parameters, and these two looks duplicate. (1) [DEFAULT] report_interval=300 (2) [AGENT] report_interval=30 Looking at the implementation, (1) is used to determine the configuration.report_interval in agent status while (2) is used to determine the actual interval in agent side. Considering consistency with the other agents, we should use (2) only and deprecate (1). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1968468/+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 1968468] Re: metering-agent: Duplicate report_interval parameters
After digging into the implementation again, I noticed [DEFAULT] report_interval is actually used to determine interval between metering report, instead of agent status report. ** Changed in: neutron Assignee: Takashi Kajinami (kajinamit) => (unassigned) ** Changed in: neutron Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1968468 Title: metering-agent: Duplicate report_interval parameters Status in neutron: Invalid Bug description: The neutron-metering-agent service has the following two report_interval parameters, and these two looks duplicate. (1) [DEFAULT] report_interval=300 (2) [AGENT] report_interval=30 Looking at the implementation, (1) is used in configuration.report_interval in agent status while (2) determines the actual interval in agent side. Considering consistency with the other agents, we should use (2) only and deprecate (1). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1968468/+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 1843883] [NEW] Can't configure extra parameters for live migration uri in libvirt
Public bug reported: In libvirt we can add some extra parameters into migration target uri in query parameter format.[1] [1] https://libvirt.org/remote.html This is still vlaid for some usecases. For example in TripleO we define a path for key file to authenticate to the remote node by keyfile parameter. However, since live_migration_uri was deprecated and replaced by live_migration_scheme, there are no available methods to configure this without using the deprecated parameter live_migration_uri. We need some additional option like live_migration_extraparams which can be used to these define parameters, Otherwise it can break existing deployment which requires extra parameters configured. ** Affects: nova Importance: Undecided Assignee: Takashi Kajinami (kajinamit) 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/1843883 Title: Can't configure extra parameters for live migration uri in libvirt Status in OpenStack Compute (nova): In Progress Bug description: In libvirt we can add some extra parameters into migration target uri in query parameter format.[1] [1] https://libvirt.org/remote.html This is still vlaid for some usecases. For example in TripleO we define a path for key file to authenticate to the remote node by keyfile parameter. However, since live_migration_uri was deprecated and replaced by live_migration_scheme, there are no available methods to configure this without using the deprecated parameter live_migration_uri. We need some additional option like live_migration_extraparams which can be used to these define parameters, Otherwise it can break existing deployment which requires extra parameters configured. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1843883/+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 1898553] Re: nova-compute doesn't start due to libvirtd --listen restriction
I think this is not an issue with nova but the one with puppet-nova. Actually we fixed the configration related to libvirt on CentOS while we fixed that mentioned bug, but we still need the same fix for Ubuntu which has libvirt 6.0 recently. We already have a proposed fix for the issue https://review.opendev.org/#/c/749603 so I think we can move this forward to address the issue. ** Also affects: puppet-nova Importance: Undecided Status: New ** Changed in: puppet-nova Importance: Undecided => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1898553 Title: nova-compute doesn't start due to libvirtd --listen restriction Status in OpenStack Compute (nova): New Status in puppet-nova: In Progress Bug description: hello, after upgrading from Openstack Train to Ussuri, running on Ubuntu 18.04, the nova-compute service doesn't start due to the libvirtd service not starting because of the --listen option being enabled in the /etc/default/libvirtd file and so, the nova-compute service fail to reach the socket that doesn't exist. i have found other bug report and patch that claim to have fixed this issue but it's not, at least not on the package installed version of openstack on ubuntu 18.04 (https://bugs.launchpad.net/puppet- nova/+bug/1880619) is nova-compute able to use another mechanism to connect to libvirtd ? and thus not needing the --listen option ? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1898553/+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 1905276] [NEW] Overriding hypervisor name for resource provider always requires a complete list of interfaces/bridges
Public bug reported: In some deployments, hostnames can be different between hosts and resource provider records. For example in deployment managed by TripleO we use short host name (without domain name) in host, while we use FQDN for resource provider records (this comes from the FQDN set to the host option in nova.conf). This causes an issue with the way how currently neutron looks up the root resource provider because placment API requires the exact hostname and doesn't automatically translate short name and FQDN. To fix the issue we need to set the resource_provider_hypervisors option[1] now but it is very redundant to list up all devices or bridges in this option to override hostnames for the devices/bridges by the same value. [1] https://review.opendev.org/#/c/696600/ ** Affects: neutron Importance: Undecided Status: New ** Summary changed: - Overriding defualt hypervisor name always requires a complete list of interfaces/bridges + Overriding hypervisor name for resource provider management always requires a complete list of interfaces/bridges ** Summary changed: - Overriding hypervisor name for resource provider management always requires a complete list of interfaces/bridges + Overriding hypervisor name for resource provider always requires a complete list of interfaces/bridges -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1905276 Title: Overriding hypervisor name for resource provider always requires a complete list of interfaces/bridges Status in neutron: New Bug description: In some deployments, hostnames can be different between hosts and resource provider records. For example in deployment managed by TripleO we use short host name (without domain name) in host, while we use FQDN for resource provider records (this comes from the FQDN set to the host option in nova.conf). This causes an issue with the way how currently neutron looks up the root resource provider because placment API requires the exact hostname and doesn't automatically translate short name and FQDN. To fix the issue we need to set the resource_provider_hypervisors option[1] now but it is very redundant to list up all devices or bridges in this option to override hostnames for the devices/bridges by the same value. [1] https://review.opendev.org/#/c/696600/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1905276/+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 1917483] [NEW] Horizon loads policy files partially when one of policy files are written in a wrong format
Public bug reported: Currently horizon stops loading policy rules when it detects any file in a wrong format. This results in a situation where horizon works with very incomplete policy rules because of only one invalid policy file. For example when horizon susceeds to load the keystone policy firstly and then fails to load the nova policy secondly, it recognizes policy rules for only keystone and doesn't recognize policy rules for not only nova but the remaining services like neutron, cinder and so on. ** 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/1917483 Title: Horizon loads policy files partially when one of policy files are written in a wrong format Status in OpenStack Dashboard (Horizon): New Bug description: Currently horizon stops loading policy rules when it detects any file in a wrong format. This results in a situation where horizon works with very incomplete policy rules because of only one invalid policy file. For example when horizon susceeds to load the keystone policy firstly and then fails to load the nova policy secondly, it recognizes policy rules for only keystone and doesn't recognize policy rules for not only nova but the remaining services like neutron, cinder and so on. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1917483/+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 1920842] [NEW] "rpc_response_max_timeout" configuration variable not present in metadata-agent
Public bug reported: We have observed that the following Traceback is logged in metadata- agent.log when metadata-agent encounters MessagingTimeout. ~~~ Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 397, in get return self._queues[msg_id].get(block=True, timeout=timeout) File "/usr/lib/python3.6/site-packages/eventlet/queue.py", line 322, in get return waiter.wait() File "/usr/lib/python3.6/site-packages/eventlet/queue.py", line 141, in wait return get_hub().switch() File "/usr/lib/python3.6/site-packages/eventlet/hubs/hub.py", line 298, in switch return self.greenlet.switch() queue.Empty During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/neutron_lib/rpc.py", line 157, in call return self._original_context.call(ctxt, method, **kwargs) File "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/client.py", line 181, in call transport_options=self.transport_options) File "/usr/lib/python3.6/site-packages/oslo_messaging/transport.py", line 129, in _send transport_options=transport_options) File "/usr/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 646, in send transport_options=transport_options) File "/usr/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 634, in _send call_monitor_timeout) File "/usr/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 523, in wait message = self.waiters.get(msg_id, timeout=timeout) File "/usr/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 401, in get 'to message ID %s' % msg_id) oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/oslo_config/cfg.py", line 2197, in __getattr__ return self._get(name) File "/usr/lib/python3.6/site-packages/oslo_config/cfg.py", line 2631, in _get value, loc = self._do_get(name, group, namespace) File "/usr/lib/python3.6/site-packages/oslo_config/cfg.py", line 2649, in _do_get info = self._get_opt_info(name, group) File "/usr/lib/python3.6/site-packages/oslo_config/cfg.py", line 2849, in _get_opt_info raise NoSuchOptError(opt_name, group) oslo_config.cfg.NoSuchOptError: no such option rpc_response_max_timeout in group [DEFAULT] During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/neutron/agent/metadata/agent.py", line 88, in __call__ instance_id, tenant_id = self._get_instance_and_tenant_id(req) File "/usr/lib/python3.6/site-packages/neutron/agent/metadata/agent.py", line 184, in _get_instance_and_tenant_id skip_cache=skip_cache) File "/usr/lib/python3.6/site-packages/neutron/agent/metadata/agent.py", line 169, in _get_ports skip_cache=skip_cache) File "/usr/lib/python3.6/site-packages/neutron/common/cache_utils.py", line 122, in __call__ return self.func(target_self, *args, **kwargs) File "/usr/lib/python3.6/site-packages/neutron/agent/metadata/agent.py", line 146, in _get_ports_for_remote_address ip_address=remote_address) File "/usr/lib/python3.6/site-packages/neutron/agent/metadata/agent.py", line 113, in _get_ports_from_server return self.plugin_rpc.get_ports(self.context, filters) File "/usr/lib/python3.6/site-packages/neutron/agent/metadata/agent.py", line 71, in get_ports return cctxt.call(context, 'get_ports', filters=filters) File "/usr/lib/python3.6/site-packages/neutron_lib/rpc.py", line 173, in call self._original_context.timeout * 2, self.get_max_timeout()) File "/usr/lib/python3.6/site-packages/neutron_lib/rpc.py", line 133, in get_max_timeout return cls._max_timeout or _get_rpc_response_max_timeout() File "/usr/lib/python3.6/site-packages/neutron_lib/rpc.py", line 95, in _get_rpc_response_max_timeout return TRANSPORT.conf.rpc_response_max_timeout File "/usr/lib/python3.6/site-packages/oslo_messaging/_drivers/common.py", line 508, in __getattr__ value = getattr(self._conf, name) File "/usr/lib/python3.6/site-packages/oslo_config/cfg.py", line 2201, in __getattr__ raise NoSuchOptError(name) oslo_config.cfg.NoSuchOptError: no such option rpc_response_max_timeout in group [DEFAULT] ~~~ A similar issue has been reported in https://bugs.launchpad.net/neutron/+bug/1880934 and fixed already. We need the same fix for metadata-agent. Note: This issue was found in stable/train deployment ** 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/1920842 Title: "rpc_r
[Yahoo-eng-team] [Bug 2033683] Re: openvswitch.agent.ovs_neutron_agent fails to Cmd: ['iptables-restore', '-n']
We are facing this issue in Puppet OpenStack CI which uses RDO stable/yoga and c8s, so this looks like a legit bug in iptables. I don't think this is also related to TripleO so I'll close this as invalid. ** Changed in: tripleo Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2033683 Title: openvswitch.agent.ovs_neutron_agent fails to Cmd: ['iptables-restore', '-n'] Status in neutron: Invalid Status in tripleo: Invalid Bug description: Description === Wallaby deployment via undercloud/overcloud started to fail recently on overcloud node provision Neutron constantly reports inability to update iptables that in turn makes baremetal to fail to boot from PXE From the review it seems that /usr/bin/update-alternatives set to legacy fails since neutron user doesn't have sudo to run it In the info I can see that neutron user has the following subset of commands it's able to run: ... (root) NOPASSWD: /usr/bin/update-alternatives --set iptables /usr/sbin/iptables-legacy (root) NOPASSWD: /usr/bin/update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy (root) NOPASSWD: /usr/bin/update-alternatives --auto iptables (root) NOPASSWD: /usr/bin/update-alternatives --auto ip6tables But the issue is the fact that command isn't found as it was moved to /usr/sbin/update-alternatives Steps to reproduce == 1. Deploy undercloud 2. Deploy networks and VIP 3. Add and introspect a node 4. Execute overcloud node provision ... that will timeout Expected result === Successful overcloud node baremetal provisioning Logs & Configs == 2023-08-31 18:21:28.613 4413 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-18d52177-9c93-401c-b97d-0334e488a257 - - - - -] Error while processing VIF ports: neutron_lib.exceptions.ProcessExecutionError: Exit code: 1; Cmd: ['iptables-restore', '-n']; Stdin: # Generated by iptables_manager 2023-08-31 18:21:28.613 4413 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent COMMIT 2023-08-31 18:21:28.613 4413 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent # Completed by iptables_manager 2023-08-31 18:21:28.613 4413 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent ; Stdout: ; Stderr: iptables-restore: line 23 failed Environment === Centos 9 Stream and undercloud deployment tool To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2033683/+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 2035168] [NEW] Remaining db migrations for unmaintained Nuage plugin
Public bug reported: (This is not a functional bug but is a potential cleanup opportunity) The latest master still contains database migration code for tables used by Nuage plugin. https://github.com/openstack/neutron/tree/8cba9a2ee86cb3b65645674ef315c14cfb261143/neutron/db/migration/alembic_migrations -> nuage_init_opts.py However I noticed the nuage plugin is no longer maintained. https://github.com/nuagenetworks/nuage-openstack-neutron/tree/master AFAIU we can't remove these tables because plugins split out from the neutron repo early rely in tables/databases created by neutron, but it's no longer useful to maintain these in case the plugin is already unmaintained. ** Affects: neutron Importance: Undecided Status: New ** Summary changed: - Remaining db migrations for Nuage plugin + Remaining db migrations for unmaintained Nuage plugin -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2035168 Title: Remaining db migrations for unmaintained Nuage plugin Status in neutron: New Bug description: (This is not a functional bug but is a potential cleanup opportunity) The latest master still contains database migration code for tables used by Nuage plugin. https://github.com/openstack/neutron/tree/8cba9a2ee86cb3b65645674ef315c14cfb261143/neutron/db/migration/alembic_migrations -> nuage_init_opts.py However I noticed the nuage plugin is no longer maintained. https://github.com/nuagenetworks/nuage-openstack-neutron/tree/master AFAIU we can't remove these tables because plugins split out from the neutron repo early rely in tables/databases created by neutron, but it's no longer useful to maintain these in case the plugin is already unmaintained. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2035168/+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 1566622] Re: live migration fails with xenapi virt driver and SRs with old-style naming convention
I don't understand what can be a reason to change the affected project. Please describe it in case the change was appropriate and intentional. ** Project changed: ilh-facebook => nova -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1566622 Title: live migration fails with xenapi virt driver and SRs with old-style naming convention Status in OpenStack Compute (nova): Confirmed Bug description: version: commit ce5a2fb419f999bec0fb2c67413387c8b67a691a 1. create a boot-from-volume instance prior to deploying commit 5bd222e8d854ca7f03ee6936454ee57e0d6e1a78 2. upgrade nova to commit 5bd222e8d854ca7f03ee6936454ee57e0d6e1a78 3. live-migrate instance 4. observe live-migrate action fail based on my analysis of logs and code: 1. destination uses new-style SR naming convention in sr_uuid_map. 2. source tries to use new-style SR naming convention in talking to XenAPI (in nova.virt.xenapi.vmops.py:VMOps.live_migrate() -> _call_live_migrate_command()) 3. xenapi throws XenAPI.Failure exception because it "Got exception UUID_INVALID" because it only knows the SR by the old-style naming convention example destination nova-compute, source nova-compute, and xenapi logs from a live-migrate request to follow. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1566622/+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 2040449] [NEW] Instance with memory encryption enabled can't be launched when [libvirt] cpu_mode is custom
Public bug reported: Description === When a user tries to launch an instance with memory encryption enabled, the instance always becomes error state if the nova-compute has [libvirt] cpu_mode = custom. Steps to reproduce == 1. Set the following options in nova.conf and restart nova-compute [libvirt] cpu_mode = custom cpu_models = EPYC 2. Prepare a flavor with memory encryption enabled $ openstack flavor show m1.small-enc -f yaml OS-FLV-DISABLED:disabled: false OS-FLV-EXT-DATA:ephemeral: 0 access_project_ids: null description: null disk: 20 id: ee97652f-8948-4cdd-a5cd-71411cf9c8e4 name: m1.small-enc os-flavor-access:is_public: true properties:   hw:mem_encryption: 'true' ram: 2048 rxtx_factor: 1.0 swap: 0 vcpus: 1 3. Create an image with hw_firmware_type property set to 'uefi' $ openstack image show cirros-uefi -f yaml checksum: c8fc807773e5354afe61636071771906 container_format: bare created_at: '2023-10-25T02:46:57Z' disk_format: qcow2 file: /v2/images/d6353363-f580-464c-9909-93212298a58a/file id: d6353363-f580-464c-9909-93212298a58a min_disk: 0 min_ram: 0 name: cirros-uefi owner: 5a2803c4cdb1412fa1e83738d7821904 properties:   hw_disk_bus: scsi   hw_firmware_type: uefi   hw_scsi_model: virtio-scsi   os_hash_algo: sha512   os_hash_value: 1103b92ce8ad966e41235a4de260deb791ff571670c0342666c8582fbb9caefe6af07ebb11d34f44f8414b609b29c1bdf1d72ffa6faa39c88e8721d09847952b   os_hidden: false   owner_specified.openstack.md5: ''   owner_specified.openstack.object: images/cirros-uefi   owner_specified.openstack.sha256: ''   stores: fs protected: false schema: /v2/schemas/image size: 21430272 status: active tags: [] updated_at: '2023-10-25T06:00:15Z' virtual_size: 117440512 visibility: public 4. launch an instance using the flavr and the image $ openstack server create --image cirros-uefi --flavor m1.small-enc --network private cirros-enc Expected result === The instance becomes active state Actual result = Instance becomes error state. The following traceback is found in nova-compute.log ``` 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [None req-104288bc-7bf5-4bcd-a728-cd85ac72416f 69d6ccfef7e240398970c80f0be8ccf7 5a2803c4cdb1412fa1e83738d7821904 - - default default] [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] Failed to build and run instance: nova.exception.FlavorImageConflict: Memory encryption requested by hw:mem_encryption extra spec in m1.small-enc flavor but image None doesn't have 'hw_firmware_type' property set to 'uefi' or volume-backed instance was requested 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] Traceback (most recent call last): 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 2615, in _build_and_run_instance 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] self.driver.spawn(context, instance, image_meta, 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 4413, in spawn 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] xml = self._get_guest_xml(context, instance, network_info, 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 7565, in _get_guest_xml 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] conf = self._get_guest_config(instance, network_info, image_meta, 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 7045, in _get_guest_config 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] guest.cpu = self._get_guest_cpu_config( 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 5451, in _get_guest_cpu_config 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] cpu = self._get_guest_cpu_model_config(flavor, arch) 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 5398, in _get_guest_cpu_model_config 2023-10-25 06:33:20.674 38337 ERROR nova.compute.manager [instance: 000b22bc-6b28-4adb-a3af-44b1f090c542] flags = libvirt_utils.get_flags_by_flavor_specs(flavor) 2023-10-25 06
[Yahoo-eng-team] [Bug 2041511] [NEW] nova api returns 500 when creating a volume booted instance with memory enryption enabled
Public bug reported: Description === When creating an instance with an volume created from an image with hw_mem_encryption: true, nova-api returns 500 and the creation request is not accepted. Steps to reproduce == * Create an image with hw_mem_encryption=True  $ openstack image create encrypted ...  $ openstack image set encrypted --property hw_mem_encryption=True * Create a volume from the image  $ openstack volume create bootvolume --image encrypted ... * Create an instance  $ openstack server create --volume bootvolume ... Expected result === Instance creation is accepted and processed by nova, without errors Actual result = Nova api returns 500 error and does not accept the request Environment === 1. Exact version of OpenStack you are running. See the following   list for all releases: http://docs.openstack.org/releases/ Ubuntu 22.04 and UCA bobcat. # dpkg -l | grep nova ii nova-api3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - API frontend ii nova-common 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - common files ii nova-compute3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - compute node base ii nova-compute-kvm3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - compute node (KVM) ii nova-compute-libvirt3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - compute node libvirt support ii nova-conductor 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - conductor service ii nova-novncproxy 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - NoVNC proxy ii nova-scheduler 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - virtual machine scheduler ii python3-nova3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute Python 3 libraries ii python3-novaclient 2:18.4.0-0ubuntu1~cloud0 all client library for OpenStack Compute API - 3.x 2. Which hypervisor did you use? Libvirt + KVM 3. Which storage type did you use? LVM 4. Which networking type did you use? ml2 + ovs Logs & Configs == The following traceback is found in nova-api.log ``` 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi [None req-f55255c7-5829-4f89-bee9-ab34a6c02faf 69d6ccfef7e240398970c80f0be8ccf7 5a2803c4cdb1412fa1e83738d7821904 - - default default] Unexpected exception in API method: NotImplementedError: Cannot load 'id' in the base class 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi Traceback (most recent call last): 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/api/openstack/wsgi.py", line 658, in wrapped 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi return f(*args, **kwargs) 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/api/validation/__init__.py", line 110, in wrapper 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/api/validation/__init__.py", line 110, in wrapper 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/api/validation/__init__.py", line 110, in wrapper 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi [Previous line repeated 11 more times] 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/api/openstack/compute/servers.py", line 786, in create 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi instances, resv_id = self.compute_api.create( 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/compute/api.py", line 2207, in create 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi return self._create_instance( 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/compute/api.py", line 1725, in _create_instance 2023-10-27 07:46:56.878 381436 ERROR nova.api.openstack.wsgi self._checks_for_create_and_rebuild(context, image_id
[Yahoo-eng-team] [Bug 2042647] [NEW] doc: Options described in "DHCP High-availability" are outdated
Public bug reported: The "DHCP High-availability" chapter in admin guide[1] contains multiple outdated options. - linux bridge core_plugin is used instead of ml2 + linuxbridge - [database] option should be added to neutron.conf - [DEFAULT] rabbit_host option and [DEFAULT] rabbit_password option no longer exit - [DEFAULT] use_neutron and [DEFAULT] firewall_driver were removed from nova - [neutron] admin_* options were removed from nova [1] https://docs.openstack.org/neutron/latest/admin/config-dhcp-ha.html Although we can fix these, it probably makes better sense to refer to installation guide for most of options and then describe only specific options ( dhcp_agents_per_network ), so that we don't have to maintain basic options in multiple chapters. ** Affects: neutron Importance: Undecided Status: New ** Tags: doc ** Tags added: doc -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2042647 Title: doc: Options described in "DHCP High-availability" are outdated Status in neutron: New Bug description: The "DHCP High-availability" chapter in admin guide[1] contains multiple outdated options. - linux bridge core_plugin is used instead of ml2 + linuxbridge - [database] option should be added to neutron.conf - [DEFAULT] rabbit_host option and [DEFAULT] rabbit_password option no longer exit - [DEFAULT] use_neutron and [DEFAULT] firewall_driver were removed from nova - [neutron] admin_* options were removed from nova [1] https://docs.openstack.org/neutron/latest/admin/config-dhcp- ha.html Although we can fix these, it probably makes better sense to refer to installation guide for most of options and then describe only specific options ( dhcp_agents_per_network ), so that we don't have to maintain basic options in multiple chapters. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2042647/+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 2043116] [NEW] Unit test fails with oslo.utils 6.3.0
Public bug reported: Description === We recently created oslo.utils 6.3.0 release which includes the fix for the bug[1] affecting sqlalchemy-master jobs. However when we attempt to bump the version in u-c file[2], unit tests of ironic and nova fail with the following errors. ``` nova.tests.unit.objects.test_objects.TestRegistry.test_hook_keeps_newer_properly Captured traceback: ~~~ Traceback (most recent call last): Â Â File "/usr/lib/python3.10/unittest/mock.py", line 1379, in patched return func(*newargs, **newkeywargs) Â Â File "/home/zuul/src/opendev.org/openstack/nova/nova/tests/unit/objects/test_objects.py", line 1060, in test_hook_keeps_newer_properly reg.registration_hook(MyObj, 0) Â Â File "/home/zuul/src/opendev.org/openstack/nova/nova/objects/base.py", line 72, in registration_hook cur_version = versionutils.convert_version_to_tuple( Â Â File "/home/zuul/src/opendev.org/openstack/nova/.tox/py310/lib/python3.10/site-packages/oslo_utils/versionutils.py", line 91, in convert_version_to_tuple version_str = re.sub(r'(\d+)(a|alpha|b|beta|rc)\d+$', '\\1', version_str) Â Â File "/usr/lib/python3.10/re.py", line 209, in sub return _compile(pattern, flags).sub(repl, string, count) TypeError: expected string or bytes-like object ``` [1] https://bugs.launchpad.net/oslo.utils/+bug/2042886 [2] https://review.opendev.org/c/openstack/requirements/+/900517 ** Affects: ironic Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: New ** Affects: nova Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- 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/2043116 Title: Unit test fails with oslo.utils 6.3.0 Status in Ironic: New Status in OpenStack Compute (nova): In Progress Bug description: Description === We recently created oslo.utils 6.3.0 release which includes the fix for the bug[1] affecting sqlalchemy-master jobs. However when we attempt to bump the version in u-c file[2], unit tests of ironic and nova fail with the following errors. ``` nova.tests.unit.objects.test_objects.TestRegistry.test_hook_keeps_newer_properly Captured traceback: ~~~ Traceback (most recent call last): Â Â File "/usr/lib/python3.10/unittest/mock.py", line 1379, in patched return func(*newargs, **newkeywargs) Â Â File "/home/zuul/src/opendev.org/openstack/nova/nova/tests/unit/objects/test_objects.py", line 1060, in test_hook_keeps_newer_properly reg.registration_hook(MyObj, 0) Â Â File "/home/zuul/src/opendev.org/openstack/nova/nova/objects/base.py", line 72, in registration_hook cur_version = versionutils.convert_version_to_tuple( Â Â File "/home/zuul/src/opendev.org/openstack/nova/.tox/py310/lib/python3.10/site-packages/oslo_utils/versionutils.py", line 91, in convert_version_to_tuple version_str = re.sub(r'(\d+)(a|alpha|b|beta|rc)\d+$', '\\1', version_str) Â Â File "/usr/lib/python3.10/re.py", line 209, in sub return _compile(pattern, flags).sub(repl, string, count) TypeError: expected string or bytes-like object ``` [1] https://bugs.launchpad.net/oslo.utils/+bug/2042886 [2] https://review.opendev.org/c/openstack/requirements/+/900517 To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/2043116/+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 2043116] Re: Unit test fails with oslo.utils 6.3.0
** Also affects: ironic Importance: Undecided Status: New ** Description changed: Description === - We recently created oslo.utils 6.3.0 release. - However when we attempt to bump the version in u-c file[1], unit tests of ironic and nova fail with the following errors. + We recently created oslo.utils 6.3.0 release which includes the fix for + the bug[1] affecting sqlalchemy-master jobs. + + However when we attempt to bump the version in u-c file[2], unit tests + of ironic and nova fail with the following errors. ``` nova.tests.unit.objects.test_objects.TestRegistry.test_hook_keeps_newer_properly Captured traceback: ~~~ - Traceback (most recent call last): + Traceback (most recent call last): - File "/usr/lib/python3.10/unittest/mock.py", line 1379, in patched - return func(*newargs, **newkeywargs) + Â Â File "/usr/lib/python3.10/unittest/mock.py", line 1379, in patched + return func(*newargs, **newkeywargs) - File "/home/zuul/src/opendev.org/openstack/nova/nova/tests/unit/objects/test_objects.py", line 1060, in test_hook_keeps_newer_properly - reg.registration_hook(MyObj, 0) + Â Â File "/home/zuul/src/opendev.org/openstack/nova/nova/tests/unit/objects/test_objects.py", line 1060, in test_hook_keeps_newer_properly + reg.registration_hook(MyObj, 0) - File "/home/zuul/src/opendev.org/openstack/nova/nova/objects/base.py", line 72, in registration_hook - cur_version = versionutils.convert_version_to_tuple( + Â Â File "/home/zuul/src/opendev.org/openstack/nova/nova/objects/base.py", line 72, in registration_hook + cur_version = versionutils.convert_version_to_tuple( - File "/home/zuul/src/opendev.org/openstack/nova/.tox/py310/lib/python3.10/site-packages/oslo_utils/versionutils.py", line 91, in convert_version_to_tuple - version_str = re.sub(r'(\d+)(a|alpha|b|beta|rc)\d+$', '\\1', version_str) + Â Â File "/home/zuul/src/opendev.org/openstack/nova/.tox/py310/lib/python3.10/site-packages/oslo_utils/versionutils.py", line 91, in convert_version_to_tuple + version_str = re.sub(r'(\d+)(a|alpha|b|beta|rc)\d+$', '\\1', version_str) - File "/usr/lib/python3.10/re.py", line 209, in sub - return _compile(pattern, flags).sub(repl, string, count) + Â Â File "/usr/lib/python3.10/re.py", line 209, in sub + return _compile(pattern, flags).sub(repl, string, count) - TypeError: expected string or bytes-like object + TypeError: expected string or bytes-like object ``` - - [1] https://review.opendev.org/c/openstack/requirements/+/900517 + [1] https://bugs.launchpad.net/oslo.utils/+bug/2042886 + [2] https://review.opendev.org/c/openstack/requirements/+/900517 ** Changed in: ironic Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- 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/2043116 Title: Unit test fails with oslo.utils 6.3.0 Status in Ironic: In Progress Status in OpenStack Compute (nova): In Progress Bug description: Description === We recently created oslo.utils 6.3.0 release which includes the fix for the bug[1] affecting sqlalchemy-master jobs. However when we attempt to bump the version in u-c file[2], unit tests of ironic and nova fail with the following errors. ``` nova.tests.unit.objects.test_objects.TestRegistry.test_hook_keeps_newer_properly Captured traceback: ~~~ Traceback (most recent call last): Â Â File "/usr/lib/python3.10/unittest/mock.py", line 1379, in patched return func(*newargs, **newkeywargs) Â Â File "/home/zuul/src/opendev.org/openstack/nova/nova/tests/unit/objects/test_objects.py", line 1060, in test_hook_keeps_newer_properly reg.registration_hook(MyObj, 0) Â Â File "/home/zuul/src/opendev.org/openstack/nova/nova/objects/base.py", line 72, in registration_hook cur_version = versionutils.convert_version_to_tuple( Â Â File "/home/zuul/src/opendev.org/openstack/nova/.tox/py310/lib/python3.10/site-packages/oslo_utils/versionutils.py", line 91, in convert_version_to_tuple version_str = re.sub(r'(\d+)(a|alpha|b|beta|rc)\d+$', '\\1', version_str) Â Â File "/usr/lib/python3.10/re.py", line 209, in sub return _compile(pattern, flags).sub(repl, string, count) TypeError: expected string or bytes-like object ``` [1] https://bugs.launchpad.net/oslo.utils/+bug/2042886 [2] https://r
[Yahoo-eng-team] [Bug 2035168] Re: Remaining db migrations for unmaintained Nuage plugin
*** This bug is a duplicate of bug 2038555 *** https://bugs.launchpad.net/bugs/2038555 ** This bug has been marked a duplicate of bug 2038555 Remove unused tables -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2035168 Title: Remaining db migrations for unmaintained Nuage plugin Status in neutron: New Bug description: (This is not a functional bug but is a potential cleanup opportunity) The latest master still contains database migration code for tables used by Nuage plugin. https://github.com/openstack/neutron/tree/8cba9a2ee86cb3b65645674ef315c14cfb261143/neutron/db/migration/alembic_migrations  -> nuage_init_opts.py However I noticed the nuage plugin is no longer maintained. https://github.com/nuagenetworks/nuage-openstack-neutron/tree/master AFAIU we could not remove these tables because plugins split out from the neutron repo early rely in tables/databases created by neutron, but it's no longer useful to maintain these in case the plugin is already unmaintained. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2035168/+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 2044896] [NEW] [metadata_rate_limiting] options are absent from sample config files
Public bug reported: The metadata_rate_limiting options were added as part of the metadata ratelimiting feature, which was added a few cycles ago[1]. However the change did not add these options for config entry points thus these options are not added to the sample config files generated by oslo-config-generator. https://review.opendev.org/c/openstack/neutron/+/858879 ** Affects: neutron Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2044896 Title: [metadata_rate_limiting] options are absent from sample config files Status in neutron: In Progress Bug description: The metadata_rate_limiting options were added as part of the metadata ratelimiting feature, which was added a few cycles ago[1]. However the change did not add these options for config entry points thus these options are not added to the sample config files generated by oslo-config-generator. https://review.opendev.org/c/openstack/neutron/+/858879 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2044896/+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 2045287] Re: Error in charm when bootstrapping OpenStack with Sunbeam
This does not really apear as a neutron problem now, and should be investigated from Sunbeam's perspective until the problem is narrowed down to something wrong with Neutron. ** Project changed: neutron => charm-neutron-api ** Project changed: charm-neutron-api => charm-ops-sunbeam -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2045287 Title: Error in charm when bootstrapping OpenStack with Sunbeam Status in Ops Sunbeam: New Bug description: When trying to bootstrap OpenStack using Sunbeam, there is an error in the charm of neutron, which looks like the following: * In app view: neutronwaiting 1 neutron-k8s2023.1/stable 53 10.152.183.36 no installing agent * In unit view: neutron/0* blocked idle 10.1.163.29 (workload) Error in charm (see logs): timed out waiting for change 2 (301 seconds) * Looking at the logs for the error, they look like this: 2023-11-30T09:27:16.903Z [container-agent] 2023-11-30 09:27:16 INFO juju-log identity-service:85: Syncing database... 2023-11-30T09:32:18.000Z [container-agent] 2023-11-30 09:32:18 ERROR juju-log identity-service:85: Exception raised in section 'Bootstrapping': timed out waiting for change 2 (301 seconds) 2023-11-30T09:32:18.008Z [container-agent] 2023-11-30 09:32:18 ERROR juju-log identity-service:85: Traceback (most recent call last): 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/ops_sunbeam/guard.py", line 91, in guard 2023-11-30T09:32:18.008Z [container-agent] yield 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/ops_sunbeam/charm.py", line 265, in configure_charm 2023-11-30T09:32:18.008Z [container-agent] self.configure_unit(event) 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/ops_sunbeam/charm.py", line 479, in configure_unit 2023-11-30T09:32:18.008Z [container-agent] self.run_db_sync() 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/ops_sunbeam/job_ctrl.py", line 74, in wrapped_f 2023-11-30T09:32:18.008Z [container-agent] f(charm, *args, **kwargs) 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/./src/charm.py", line 302, in run_db_sync 2023-11-30T09:32:18.008Z [container-agent] super().run_db_sync() 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/ops_sunbeam/job_ctrl.py", line 74, in wrapped_f 2023-11-30T09:32:18.008Z [container-agent] f(charm, *args, **kwargs) 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/ops_sunbeam/charm.py", line 549, in run_db_sync 2023-11-30T09:32:18.008Z [container-agent] self._retry_db_sync(cmd) 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/tenacity/__init__.py", line 289, in wrapped_f 2023-11-30T09:32:18.008Z [container-agent] return self(f, *args, **kw) 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/tenacity/__init__.py", line 379, in __call__ 2023-11-30T09:32:18.008Z [container-agent] do = self.iter(retry_state=retry_state) 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/tenacity/__init__.py", line 314, in iter 2023-11-30T09:32:18.008Z [container-agent] return fut.result() 2023-11-30T09:32:18.008Z [container-agent] File "/usr/lib/python3.10/concurrent/futures/_base.py", line 451, in result 2023-11-30T09:32:18.008Z [container-agent] return self.__get_result() 2023-11-30T09:32:18.008Z [container-agent] File "/usr/lib/python3.10/concurrent/futures/_base.py", line 403, in __get_result 2023-11-30T09:32:18.008Z [container-agent] raise self._exception 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/tenacity/__init__.py", line 382, in __call__ 2023-11-30T09:32:18.008Z [container-agent] result = fn(*args, **kwargs) 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/ops_sunbeam/charm.py", line 529, in _retry_db_sync 2023-11-30T09:32:18.008Z [container-agent] out, warnings = process.wait_output() 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/ops/pebble.py", line 1354, in wait_output 2023-11-30T09:32:18.008Z [container-agent] exit_code: int = self._wait() 2023-11-30T09:32:18.008Z [container-agent] File "/var/lib/juju/agents/unit-neutron-0/charm/venv/ops/pebble.py", line 1294, in _wait 2023-11-30T09:
[Yahoo-eng-team] [Bug 1508442] Re: LOG.warn is deprecated
This was fixed in python-watcherclient by https://review.opendev.org/c/openstack/python-watcherclient/+/280026 . ** Changed in: python-watcherclient Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1508442 Title: LOG.warn is deprecated Status in anvil: New Status in Aodh: Fix Released Status in Astara: Fix Released Status in Barbican: Fix Released Status in bilean: Fix Released Status in Ceilometer: Fix Released Status in cloud-init: Fix Released Status in cloudkitty: Fix Released Status in congress: Fix Released Status in Designate: Fix Released Status in django-openstack-auth: Fix Released Status in DragonFlow: Fix Released Status in ec2-api: Fix Released Status in Evoque: In Progress Status in gce-api: Fix Released Status in Gnocchi: Fix Released Status in OpenStack Heat: Fix Released Status in heat-cfntools: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in KloudBuster: Fix Released Status in kolla: Fix Released Status in Magnum: Fix Released Status in OpenStack Shared File Systems Service (Manila): Fix Released Status in masakari: Fix Released Status in Mistral: Invalid Status in Monasca: New Status in networking-arista: Fix Released Status in networking-calico: Fix Released Status in networking-cisco: In Progress Status in networking-fujitsu: Fix Released Status in networking-odl: Fix Committed Status in networking-ofagent: Fix Committed Status in networking-plumgrid: In Progress Status in networking-powervm: Fix Released Status in networking-vsphere: Fix Released Status in OpenStack Compute (nova): Fix Released Status in nova-powervm: Fix Released Status in nova-solver-scheduler: In Progress Status in octavia: Fix Released Status in openstack-ansible: Fix Released Status in oslo.cache: Fix Released Status in oslo.middleware: Fix Released Status in Packstack: Fix Released Status in python-dracclient: Fix Released Status in python-magnumclient: Fix Released Status in RACK: In Progress Status in python-watcherclient: Fix Released Status in Rally: Fix Released Status in OpenStack Searchlight: Fix Released Status in senlin: Fix Committed Status in shaker: Fix Released Status in Solum: Fix Released Status in tacker: Fix Released Status in tempest: Fix Released Status in tripleo: Fix Released Status in trove-dashboard: Fix Released Status in Vitrage: Fix Committed Status in watcher: Fix Released Status in zaqar: Fix Released Bug description: LOG.warn is deprecated in Python 3 [1] . But it still used in a few places, non-deprecated LOG.warning should be used instead. Note: If we are using logger from oslo.log, warn is still valid [2], but I agree we can switch to LOG.warning. [1]https://docs.python.org/3/library/logging.html#logging.warning [2]https://github.com/openstack/oslo.log/blob/master/oslo_log/log.py#L85 To manage notifications about this bug go to: https://bugs.launchpad.net/anvil/+bug/1508442/+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 1508442] Re: LOG.warn is deprecated
** Changed in: senlin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1508442 Title: LOG.warn is deprecated Status in anvil: New Status in Aodh: Fix Released Status in Astara: Fix Released Status in Barbican: Fix Released Status in bilean: Fix Released Status in Ceilometer: Fix Released Status in cloud-init: Fix Released Status in cloudkitty: Fix Released Status in congress: Fix Released Status in Designate: Fix Released Status in django-openstack-auth: Fix Released Status in DragonFlow: Fix Released Status in ec2-api: Fix Released Status in Evoque: In Progress Status in gce-api: Fix Released Status in Gnocchi: Fix Released Status in OpenStack Heat: Fix Released Status in heat-cfntools: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in KloudBuster: Fix Released Status in kolla: Fix Released Status in Magnum: Fix Released Status in OpenStack Shared File Systems Service (Manila): Fix Released Status in masakari: Fix Released Status in Mistral: Invalid Status in Monasca: New Status in networking-arista: Fix Released Status in networking-calico: Fix Released Status in networking-cisco: In Progress Status in networking-fujitsu: Fix Released Status in networking-odl: Fix Committed Status in networking-ofagent: Fix Committed Status in networking-plumgrid: In Progress Status in networking-powervm: Fix Released Status in networking-vsphere: Fix Released Status in OpenStack Compute (nova): Fix Released Status in nova-powervm: Fix Released Status in nova-solver-scheduler: In Progress Status in octavia: Fix Released Status in openstack-ansible: Fix Released Status in oslo.cache: Fix Released Status in oslo.middleware: Fix Released Status in Packstack: Fix Released Status in python-dracclient: Fix Released Status in python-magnumclient: Fix Released Status in RACK: In Progress Status in python-watcherclient: Fix Released Status in Rally: Fix Released Status in OpenStack Searchlight: Fix Released Status in senlin: Fix Released Status in shaker: Fix Released Status in Solum: Fix Released Status in tacker: Fix Released Status in tempest: Fix Released Status in tripleo: Fix Released Status in trove-dashboard: Fix Released Status in Vitrage: Fix Committed Status in watcher: Fix Released Status in zaqar: Fix Released Bug description: LOG.warn is deprecated in Python 3 [1] . But it still used in a few places, non-deprecated LOG.warning should be used instead. Note: If we are using logger from oslo.log, warn is still valid [2], but I agree we can switch to LOG.warning. [1]https://docs.python.org/3/library/logging.html#logging.warning [2]https://github.com/openstack/oslo.log/blob/master/oslo_log/log.py#L85 To manage notifications about this bug go to: https://bugs.launchpad.net/anvil/+bug/1508442/+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 2047399] [NEW] nova api returns 500 when resizing an instance with memory encryption enabled
Public bug reported: Description === When a user attempts to resize an instance with memory encryption enabled, API returns 500 error consistently. Looking into nova-api.log, it seems the issue is caused by a mechanism similar to https://bugs.launchpad.net/nova/+bug/2041511 . Steps to reproduce == * Create an image with hw_mem_encryption=True $ openstack image create encrypted ... $ openstack image set encrypted --property hw_mem_encryption=True * Create an instance $ openstack server create testinstance --image encrypted --flavor flavor1 ... * Resize the instance $ openstack server resize testinstance --flavor flavor2 Expected result === Instance resize is accepted and processed by nova, without errors Actual result = Nova api returns 500 error and does not accept the request Environment === 1. Exact version of OpenStack you are running. See the following list for all releases: http://docs.openstack.org/releases/ Ubuntu 22.04 and UCA bobcat. # dpkg -l | grep nova ii nova-api 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - API frontend ii nova-common 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - common files ii nova-compute 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - compute node base ii nova-compute-kvm 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - compute node (KVM) ii nova-compute-libvirt 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - compute node libvirt support ii nova-conductor 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - conductor service ii nova-novncproxy 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - NoVNC proxy ii nova-scheduler 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute - virtual machine scheduler ii python3-nova 3:28.0.0-0ubuntu1~cloud0 all OpenStack Compute Python 3 libraries ii python3-novaclient 2:18.4.0-0ubuntu1~cloud0 all client library for OpenStack Compute API - 3.x 2. Which hypervisor did you use? Libvirt + KVM 3. Which storage type did you use? LVM 4. Which networking type did you use? ml2 + ovs Logs & Configs == The following traceback is found in nova-api.log ``` 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi [None req-20b9b69c-a792-45cd-8520-7e9cd3387c0d 838cd42e04884ddfa8ec4ac11e2f8818 baf003aa0202430a92edd003f98794a3 - - default default] Unexpected exception in API method: NotImplementedError: Cannot load 'id' in the base class 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi Traceback (most recent call last): 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/api/openstack/wsgi.py", line 658, in wrapped 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi return f(*args, **kwargs) 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/api/validation/__init__.py", line 110, in wrapper 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/api/openstack/compute/servers.py", line 1146, in _action_resize 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi self._resize(req, id, flavor_ref, **kwargs) 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/api/openstack/compute/servers.py", line 1060, in _resize 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi self.compute_api.resize(context, instance, flavor_id, 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/compute/api.py", line 389, in inner 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi return function(self, context, instance, *args, **kwargs) 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/compute/api.py", line 374, in wrapper 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi return func(self, context, instance, *args, **kwargs) 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/compute/api.py", line 357, in wrapper 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi return func(self, context, instance, *args, **kwargs) 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/compute/api.py", line 242, in inner 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi return function(self, context, instance, *args, **kwargs) 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/compute/api.py", line 168, in inner 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi return f(self, context, instance, *args, **kw) 2023-12-26 08:02:19.371 30791 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/nova/comput
[Yahoo-eng-team] [Bug 2049064] [NEW] Unit/functional test failures with oslo.limit 2.3.0
Public bug reported: Description === The new oslo.limit 2.3.0 release introduced the validation to ensure the [oslo_limit] endpoint_id option is set. However this change broke some unit/functional test cases which enable unified quota implementation without setting this option. Steps to reproduce == - Download global upper constraints - Bump oslo.limit version to 2.3.0 - Run unit tests with the modified upper constraints $ TOX_CONSTRAINTS_FILE= tox -e py310 Expected result === - No test case fails Actual result = - Some of the test cases fail because of the following error Environment === N/A Logs & Configs == cross-nova-py310: https://zuul.opendev.org/t/openstack/build/79d2c815f0e04d4b8f6838b1d1ec026f cross-nova-functional: https://zuul.opendev.org/t/openstack/build/159f06a88d7948209a111a9f45306e0a cross-glance-py310: https://zuul.opendev.org/t/openstack/build/7634390991ab4442b4230b09563ef26b ** Affects: glance Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: New ** Affects: nova Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Also affects: glance Importance: Undecided Status: New ** Description changed: Description === The new oslo.limit 2.3.0 release introduced the validation to ensure the [oslo_limit] endpoint_id option is set. However this change broke some unit/functional test cases which enable unified quota implementation without setting this option. Steps to reproduce == - Download global upper constraints - Bump oslo.limit version to 2.3.0 - Run unit tests with the modified upper constraints - + $ TOX_CONSTRAINTS_FILE= tox -e py310 Expected result === - No test case fails Actual result = - Some of the test cases fail because of the following error Environment === N/A Logs & Configs == cross-nova-py310: https://zuul.opendev.org/t/openstack/build/79d2c815f0e04d4b8f6838b1d1ec026f cross-nova-functional: https://zuul.opendev.org/t/openstack/build/159f06a88d7948209a111a9f45306e0a cross-glance-py310: https://zuul.opendev.org/t/openstack/build/7634390991ab4442b4230b09563ef26b ** Summary changed: - Unit test fails with oslo.limit 2.3.0 + Unit/functional test failures with oslo.limit 2.3.0 ** Changed in: nova Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Changed in: glance Assignee: (unassigned) => Takashi Kajinami (kajinamit) -- 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/2049064 Title: Unit/functional test failures with oslo.limit 2.3.0 Status in Glance: New Status in OpenStack Compute (nova): In Progress Bug description: Description === The new oslo.limit 2.3.0 release introduced the validation to ensure the [oslo_limit] endpoint_id option is set. However this change broke some unit/functional test cases which enable unified quota implementation without setting this option. Steps to reproduce == - Download global upper constraints - Bump oslo.limit version to 2.3.0 - Run unit tests with the modified upper constraints $ TOX_CONSTRAINTS_FILE= tox -e py310 Expected result === - No test case fails Actual result = - Some of the test cases fail because of the following error Environment === N/A Logs & Configs == cross-nova-py310: https://zuul.opendev.org/t/openstack/build/79d2c815f0e04d4b8f6838b1d1ec026f cross-nova-functional: https://zuul.opendev.org/t/openstack/build/159f06a88d7948209a111a9f45306e0a cross-glance-py310: https://zuul.opendev.org/t/openstack/build/7634390991ab4442b4230b09563ef26b To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/2049064/+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 2050090] [NEW] doc build is broken with pillow>=10.0.0
Public bug reported:
Description
===
Since pillow in upper-constraints was bumped to >=10.0.0, doc build (tox -e
docs) consistently fails with the following error.
```
$ tox -e docs
...
done
WARNING: dot code 'seqdiag {\nAPI; Conductor; Scheduler; Source;
Destination;\nedge_length = 300;\nspan_height = 15;\nactivation =
none;\ndefault_note_color = white;\n\nAPI ->> Conductor [label =
"cast", note = "resize_instance/migrate_server"];\nConductor => Scheduler
[label = "MigrationTask", note = "select_destinations"];\nConductor ->
Conductor [label = "TargetDBSetupTask"];\nConductor => Destination [label =
"PrepResizeAtDestTask", note = "prep_snapshot_based_resize_at_dest"];\n
Conductor => Source [label = "PrepResizeAtSourceTask", note =
"prep_snapshot_based_resize_at_source"];\nConductor => Destination [label =
"FinishResizeAtDestTask", note = "finish_snapshot_based_resize_at_dest"];\n
Conductor -> Conductor [label = "FinishResizeAtDestTask", note = "update
instance mapping"];\n}': 'ImageDraw' object has no attribute 'textsize'
WARNING: dot code 'seqdiag {\nAPI; Conductor; Source;\nedge_length =
300;\nspan_height = 15;\nactivation = none;\ndefault_note_color =
white;\n\nAPI ->> Conductor [label = "cast (or call if deleting)", note =
"confirm_snapshot_based_resize"];\n\n// separator to indicate everything
after this is driven by ConfirmResizeTask\n=== ConfirmResizeTask ===\n\n
Conductor => Source [label = "call", note =
"confirm_snapshot_based_resize_at_source"];\nConductor -> Conductor [note =
"hard delete source cell instance"];\nConductor -> Conductor [note =
"update target cell instance status"];\n\n}': 'ImageDraw' object has no
attribute 'textsize'
WARNING: dot code 'seqdiag {\nAPI; Conductor; Source; Destination;\n
edge_length = 300;\nspan_height = 15;\nactivation = none;\n
default_note_color = white;\n\nAPI ->> Conductor [label = "cast", note =
"revert_snapshot_based_resize"];\n\n// separator to indicate everything
after this is driven by RevertResizeTask\n=== RevertResizeTask ===\n\n
Conductor -> Conductor [note = "update records from target to source cell"];\n
Conductor -> Conductor [note = "update instance mapping"];\nConductor =>
Destination [label = "call", note = "revert_snapshot_based_resize_at_dest"];\n
Conductor -> Conductor [note = "hard delete target cell instance"];\n
Conductor => Source [label = "call", note =
"finish_revert_snapshot_based_resize_at_source"];\n\n}': 'ImageDraw' object has
no attribute 'textsize'
WARNING: dot code 'seqdiag {\nAPI; Conductor; Scheduler; Source;
Destination;\nedge_length = 300;\nspan_height = 15;\nactivation =
none;\ndefault_note_color = white;\n\nAPI -> Conductor [label = "cast",
note = "resize_instance/migrate_server"];\n Conductor => Scheduler
[label = "call", note = "select_destinations"];\n Conductor ->
Destination [label = "cast", note = "prep_resize"];\n Source <-
Destination [label = "cast", leftnote = "resize_instance"];\n
Source -> Destination [label = "cast", note = "finish_resize"];\n}':
'ImageDraw' object has no attribute 'textsize'
WARNING: dot code 'seqdiag {\nAPI; Source;\nedge_length = 300;\n
span_height = 15;\nactivation = none;\ndefault_note_color = white;\n\n
API -> Source [label = "cast (or call if deleting)", note =
"confirm_resize"];\n}': 'ImageDraw' object has no attribute 'textsize'
WARNING: dot code 'seqdiag {\nAPI; Source; Destination;\nedge_length =
300;\nspan_height = 15;\nactivation = none;\ndefault_note_color =
white;\n\nAPI -> Destination [label = "cast", note = "revert_resize"];\n
Source <- Destination [label = "cast", leftnote =
"finish_revert_resize"];\n}': 'ImageDraw' object has no attribute 'textsize'
WARNING: dot code 'actdiag {\nbuild-spec -> send-spec -> send-reqs -> query
-> return-rps ->\ncreate -> filter -> claim -> return-hosts ->
send-hosts;\n\nlane conductor {\nlabel = "Conductor";\n
build-spec [label = "Build request spec object", height = 38];\n
send-spec [label = "Submit request spec to scheduler", height = 38];\n
send-hosts [label = "Submit list of suitable hosts to target cell", height =
51];\n}\n\nlane scheduler {\nlabel = "Scheduler";\n
send-reqs [label = "Submit resource requirements to placement", height = 64];\n
create [label = "Create a HostState object for each RP returned from
Placement", height = 64];\nfilter [label = "Filter and weigh results",
height = 38];\nreturn-hosts [label = "Return a list of selected host &
alternates, along with their allocations, to the conductor", height = 89];\n
}\n\nlane placement {\nlabel = "Placement";\nquery [labe
l = "Query to dete
[Yahoo-eng-team] [Bug 2050090] Re: doc build is broken with pillow>=10.0.0
*** This bug is a duplicate of bug 2026345 ***
https://bugs.launchpad.net/bugs/2026345
** This bug has been marked a duplicate of bug 2026345
Sphinx raises 'ImageDraw' object has no attribute 'textsize' error
--
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/2050090
Title:
doc build is broken with pillow>=10.0.0
Status in OpenStack Compute (nova):
New
Bug description:
Description
===
Since pillow in upper-constraints was bumped to >=10.0.0, doc build (tox -e
docs) consistently fails with the following error.
```
$ tox -e docs
...
done
WARNING: dot code 'seqdiag {\nAPI; Conductor; Scheduler; Source;
Destination;\nedge_length = 300;\nspan_height = 15;\nactivation =
none;\ndefault_note_color = white;\n\nAPI ->> Conductor [label =
"cast", note = "resize_instance/migrate_server"];\nConductor => Scheduler
[label = "MigrationTask", note = "select_destinations"];\nConductor ->
Conductor [label = "TargetDBSetupTask"];\nConductor => Destination [label =
"PrepResizeAtDestTask", note = "prep_snapshot_based_resize_at_dest"];\n
Conductor => Source [label = "PrepResizeAtSourceTask", note =
"prep_snapshot_based_resize_at_source"];\nConductor => Destination [label =
"FinishResizeAtDestTask", note = "finish_snapshot_based_resize_at_dest"];\n
Conductor -> Conductor [label = "FinishResizeAtDestTask", note = "update
instance mapping"];\n}': 'ImageDraw' object has no attribute 'textsize'
WARNING: dot code 'seqdiag {\nAPI; Conductor; Source;\nedge_length =
300;\nspan_height = 15;\nactivation = none;\ndefault_note_color =
white;\n\nAPI ->> Conductor [label = "cast (or call if deleting)", note =
"confirm_snapshot_based_resize"];\n\n// separator to indicate everything
after this is driven by ConfirmResizeTask\n=== ConfirmResizeTask ===\n\n
Conductor => Source [label = "call", note =
"confirm_snapshot_based_resize_at_source"];\nConductor -> Conductor [note =
"hard delete source cell instance"];\nConductor -> Conductor [note =
"update target cell instance status"];\n\n}': 'ImageDraw' object has no
attribute 'textsize'
WARNING: dot code 'seqdiag {\nAPI; Conductor; Source; Destination;\n
edge_length = 300;\nspan_height = 15;\nactivation = none;\n
default_note_color = white;\n\nAPI ->> Conductor [label = "cast", note =
"revert_snapshot_based_resize"];\n\n// separator to indicate everything
after this is driven by RevertResizeTask\n=== RevertResizeTask ===\n\n
Conductor -> Conductor [note = "update records from target to source cell"];\n
Conductor -> Conductor [note = "update instance mapping"];\nConductor =>
Destination [label = "call", note = "revert_snapshot_based_resize_at_dest"];\n
Conductor -> Conductor [note = "hard delete target cell instance"];\n
Conductor => Source [label = "call", note =
"finish_revert_snapshot_based_resize_at_source"];\n\n}': 'ImageDraw' object has
no attribute 'textsize'
WARNING: dot code 'seqdiag {\nAPI; Conductor; Scheduler; Source;
Destination;\nedge_length = 300;\nspan_height = 15;\nactivation =
none;\ndefault_note_color = white;\n\nAPI -> Conductor [label = "cast",
note = "resize_instance/migrate_server"];\n Conductor => Scheduler
[label = "call", note = "select_destinations"];\n Conductor ->
Destination [label = "cast", note = "prep_resize"];\n Source <-
Destination [label = "cast", leftnote = "resize_instance"];\n
Source -> Destination [label = "cast", note = "finish_resize"];\n}':
'ImageDraw' object has no attribute 'textsize'
WARNING: dot code 'seqdiag {\nAPI; Source;\nedge_length = 300;\n
span_height = 15;\nactivation = none;\ndefault_note_color = white;\n\n
API -> Source [label = "cast (or call if deleting)", note =
"confirm_resize"];\n}': 'ImageDraw' object has no attribute 'textsize'
WARNING: dot code 'seqdiag {\nAPI; Source; Destination;\nedge_length
= 300;\nspan_height = 15;\nactivation = none;\ndefault_note_color =
white;\n\nAPI -> Destination [label = "cast", note = "revert_resize"];\n
Source <- Destination [label = "cast", leftnote =
"finish_revert_resize"];\n}': 'ImageDraw' object has no attribute 'textsize'
WARNING: dot code 'actdiag {\nbuild-spec -> send-spec -> send-reqs ->
query -> return-rps ->\ncreate -> filter -> claim -> return-hosts ->
send-hosts;\n\nlane conductor {\nlabel = "Conductor";\n
build-spec [label = "Build request spec object", height = 38];\n
send-spec [label = "Submit request spec to scheduler", height = 38];\n
send-hosts [label = "Submit list of suitable hosts to target cell", height =
51];\n}\n\nlane scheduler {\nlabel = "S
[Yahoo-eng-team] [Bug 2051066] [NEW] Traceback is dumped when nova-api is run by apache + mod_wsgi
Public bug reported:
Description
===
We noticed that the following traceback is dumped to error log in httpd when
nova-api is run by httpd + mod_wsgi.
This is because nova-api WSGI application attempts to register signal handers
for GMR but this is blocked y httpd.
This does not cause any functional problem, but is annoying for operators, and
we should consider the way to surpress these warnings.
[Mon Jan 22 06:29:49.889120 2024] [wsgi:warn] [pid 82455:tid 82557] mod_wsgi
(pid=82455): Callback registration for signal 12 ignored.
[Mon Jan 22 06:29:49.889918 2024] [wsgi:warn] [pid 82455:tid 82557] File
"/var/www/cgi-bin/nova/nova-api", line 52, in
[Mon Jan 22 06:29:49.889937 2024] [wsgi:warn] [pid 82455:tid 82557]
application = init_application()
[Mon Jan 22 06:29:49.889955 2024] [wsgi:warn] [pid 82455:tid 82557] File
"/usr/lib/python3.9/site-packages/nova/api/openstack/compute/wsgi.py", line 20,
in init_application
[Mon Jan 22 06:29:49.889967 2024] [wsgi:warn] [pid 82455:tid 82557] return
wsgi_app.init_application(NAME)
[Mon Jan 22 06:29:49.889983 2024] [wsgi:warn] [pid 82455:tid 82557] File
"/usr/lib/python3.9/site-packages/nova/api/openstack/wsgi_app.py", line 128, in
init_application
[Mon Jan 22 06:29:49.889994 2024] [wsgi:warn] [pid 82455:tid 82557]
init_global_data(conf_files, name)
[Mon Jan 22 06:29:49.890027 2024] [wsgi:warn] [pid 82455:tid 82557] File
"/usr/lib/python3.9/site-packages/nova/utils.py", line 1133, in wrapper
[Mon Jan 22 06:29:49.890039 2024] [wsgi:warn] [pid 82455:tid 82557] return
func(*args, **kwargs)
[Mon Jan 22 06:29:49.890054 2024] [wsgi:warn] [pid 82455:tid 82557] File
"/usr/lib/python3.9/site-packages/nova/api/openstack/wsgi_app.py", line 105, in
init_global_data
[Mon Jan 22 06:29:49.890065 2024] [wsgi:warn] [pid 82455:tid 82557]
gmr.TextGuruMeditation.setup_autorun(
[Mon Jan 22 06:29:49.890080 2024] [wsgi:warn] [pid 82455:tid 82557] File
"/usr/lib/python3.9/site-packages/oslo_reports/guru_meditation_report.py", line
155, in setup_autorun
[Mon Jan 22 06:29:49.890091 2024] [wsgi:warn] [pid 82455:tid 82557]
cls._setup_signal(signal.SIGUSR2,
[Mon Jan 22 06:29:49.890106 2024] [wsgi:warn] [pid 82455:tid 82557] File
"/usr/lib/python3.9/site-packages/oslo_reports/guru_meditation_report.py", line
188, in _setup_signal
[Mon Jan 22 06:29:49.890117 2024] [wsgi:warn] [pid 82455:tid 82557]
signal.signal(signum,
Steps to reproduce
==
* Install httpd
* Add vhost to run nova-api
* Start httpd
Expected result
===
No traceback appears in error.log
Actual result
=
Traceback appears in error.log
Environment
===
This issue wsa initially found in CentOS Stream 9 + RDO master.
httpd-2.4.57-6.el9.x86_64
openstack-nova-api-28.1.0-0.20240111050756.fed1230.el9.noarch
openstack-nova-common-28.1.0-0.20240111050756.fed1230.el9.noarch
openstack-nova-compute-28.1.0-0.20240111050756.fed1230.el9.noarch
openstack-nova-conductor-28.1.0-0.20240111050756.fed1230.el9.noarch
openstack-nova-novncproxy-28.1.0-0.20240111050756.fed1230.el9.noarch
openstack-nova-scheduler-28.1.0-0.20240111050756.fed1230.el9.noarch
Logs & Configs
==
Example log:
https://cab2ad659632c7fadcca-8cee698db2ecce5ea7fdb78c34542529.ssl.cf1.rackcdn.com/906237/1/check/puppet-openstack-integration-7-scenario001-tempest-centos-9-stream/29e7836/logs/apache/nova_api_wsgi_error_ssl.txt
** Affects: nova
Importance: Undecided
Assignee: Takashi Kajinami (kajinamit)
Status: In Progress
** Changed in: nova
Assignee: (unassigned) => Takashi Kajinami (kajinamit)
--
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/2051066
Title:
Traceback is dumped when nova-api is run by apache + mod_wsgi
Status in OpenStack Compute (nova):
In Progress
Bug description:
Description
===
We noticed that the following traceback is dumped to error log in httpd when
nova-api is run by httpd + mod_wsgi.
This is because nova-api WSGI application attempts to register signal handers
for GMR but this is blocked y httpd.
This does not cause any functional problem, but is annoying for operators,
and we should consider the way to surpress these warnings.
[Mon Jan 22 06:29:49.889120 2024] [wsgi:warn] [pid 82455:tid 82557] mod_wsgi
(pid=82455): Callback registration for signal 12 ignored.
[Mon Jan 22 06:29:49.889918 2024] [wsgi:warn] [pid 82455:tid 82557] File
"/var/www/cgi-bin/nova/nova-api", line 52, in
[Mon Jan 22 06:29:49.889937 2024] [wsgi:warn] [pid 82455:tid 82557]
application = init_application()
[Mon Jan 22 06:29:49.889955 2024] [wsgi:warn] [pid 82455:tid 82557] File
"/usr/lib/python3.9/site-packages/nova/api/openstack/compute/wsgi.py", l
[Yahoo-eng-team] [Bug 1259760] Re: Spice console isn't working when ssl_only=True is set
** Changed in: nova Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1259760 Title: Spice console isn't working when ssl_only=True is set Status in OpenStack Nova Cloud Controller Charm: Invalid Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive queens series: Fix Released Status in OpenStack Compute (nova): Invalid Status in spice-html5 package in Ubuntu: Fix Released Bug description: OpenStack instalation: 2013.2 OS: Ubuntu 13.10 Repo: standart Ubuntu repozitory When using ssl_only in nova.conf, browser gets error: [Exception... "The operation is insecure." code: "18" nsresult: "0x80530012 (SecurityError)" location: "https://api.region.domain.tld:6082/spiceconn.js Line: 34"] Problem: trying to reach using ws:// schema, not wss://. Temporary fixed changing /usr/share/spice-html5/spice_auto.html scheme = "wss://" at 82th line. To manage notifications about this bug go to: https://bugs.launchpad.net/charm-nova-cloud-controller/+bug/1259760/+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 1607395] Re: Traceback in dynamic metadata driver: unexpected keyword argument 'extra_md'
The vendordata_driver option was already removed. So we may not "fix" this problem really. ** Changed in: nova Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1607395 Title: Traceback in dynamic metadata driver: unexpected keyword argument 'extra_md' Status in OpenStack Compute (nova): Invalid Bug description: Using new dynamic metadata driver fails with a traceback: ERROR nova.api.metadata.handler [req-d4df1623-dc4a-4e9c-b129-1e5dd76c59ac None None] Failed to get metadata for IP 10.0.0.3 TRACE nova.api.metadata.handler Traceback (most recent call last): TRACE nova.api.metadata.handler File "/home/stack/openstack/nova/nova/api/metadata/handler.py", line 134, in _handle_remote_ip_request TRACE nova.api.metadata.handler meta_data = self.get_metadata_by_remote_address(remote_address) TRACE nova.api.metadata.handler File "/home/stack/openstack/nova/nova/api/metadata/handler.py", line 61, in get_metadata_by_remote_address TRACE nova.api.metadata.handler data = base.get_metadata_by_address(address) TRACE nova.api.metadata.handler File "/home/stack/openstack/nova/nova/api/metadata/base.py", line 660, in get_metadata_by_address TRACE nova.api.metadata.handler ctxt) TRACE nova.api.metadata.handler File "/home/stack/openstack/nova/nova/api/metadata/base.py", line 670, in get_metadata_by_instance_id TRACE nova.api.metadata.handler return InstanceMetadata(instance, address) TRACE nova.api.metadata.handler File "/home/stack/openstack/nova/nova/api/metadata/base.py", line 195, in __init__ TRACE nova.api.metadata.handler extra_md=extra_md, network_info=network_info) TRACE nova.api.metadata.handler TypeError: __init__() got an unexpected keyword argument 'extra_md' This is the configuration: vendordata_providers = StaticJSON, DynamicJSON vendordata_dynamic_targets = 'join@http://127.0.0.1:/v1/' vendordata_driver = nova.api.metadata.vendordata_dynamic.DynamicVendorData vendordata_dynamic_connect_timeout = 5 vendordata_dynamic_read_timeout = 30 vendordata_jsonfile_path = /etc/nova/cloud-config.json To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1607395/+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 1944043] Re: Wrong exception is expected to retry volume detachment API calls
** Changed in: nova/yoga Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1944043 Title: Wrong exception is expected to retry volume detachment API calls Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: New Status in OpenStack Compute (nova) rocky series: New Status in OpenStack Compute (nova) stein series: New Status in OpenStack Compute (nova) train series: In Progress Status in OpenStack Compute (nova) ussuri series: In Progress Status in OpenStack Compute (nova) victoria series: Fix Committed Status in OpenStack Compute (nova) wallaby series: Fix Committed Status in OpenStack Compute (nova) xena series: Fix Released Status in OpenStack Compute (nova) yoga series: Fix Released Bug description: Description === The following change introduced the logic to retry cinder API calls to detach volumes. https://review.opendev.org/c/openstack/nova/+/669674 The logic detects the InternalServerError class from cindreclient.apiclient.exceptions. However this is wrong and these API calls raises the ClientException class from cinderclient.exceptions instead. Steps to reproduce == N/A Actual result = N/A Environment === N/A Logs & Configs == N/A To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1944043/+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 2052484] [NEW] [DEFAULT] rpc_worker=0 leaves one rpc worker
Public bug reported: Since https://review.opendev.org/c/openstack/neutron/+/823637 was merged, neutron-server allows disabling rpc worker by setting:: [DEFAULT] rpc_worker=0 However, I observe one rpc worker is still kept even with this setting. >From neutron-server log, rpc_workers and rpc_state_report_workers are set to 0. 2024-02-05 13:05:33.159 70458 DEBUG neutron.common.config [-] rpc_state_report_workers = 0 log_opt_values /usr/lib/python3.9/site-packages/oslo_config/cfg.py:2602 2024-02-05 13:05:33.159 70458 DEBUG neutron.common.config [-] rpc_workers = 0 log_opt_values /usr/lib/python3.9/site-packages/oslo_config/cfg.py:2602 ps shows there is one rpc worker running. neutron70458 1 70458 0.3 1.8 133664 144496 /usr/bin/python3 -s /usr/bin/neutron-server ... neutron70499 70458 70499 11.4 3.1 246792 248240 neutron-server: api worker (...) neutron70500 70458 70500 11.0 3.1 243640 249488 neutron-server: api worker (...) neutron70502 70458 70502 0.3 1.7 141196 142132 neutron-server: rpc worker (...) neutron70503 70458 70503 0.3 1.8 145256 146356 neutron-server: MaintenanceWorker (...) neutron70504 70458 70504 0.0 1.7 135472 135604 neutron-server: periodic worker (...) I've noticed this in Puppet OpenStack jobs which uses RDO master packages. The package versions currently used are:: openstack-neutron-24.0.0-0.20240131211457.b85b19e.el9.noarch openstack-neutron-common-24.0.0-0.20240131211457.b85b19e.el9.noarch openstack-neutron-ml2-24.0.0-0.20240131211457.b85b19e.el9.noarch openstack-neutron-ovn-agent-24.0.0-0.20240131211457.b85b19e.el9.noarch openstack-neutron-ovn-metadata-agent-24.0.0-0.20240131211457.b85b19e.el9.noarch openstack-neutron-rpc-server-24.0.0-0.20240131211457.b85b19e.el9.noarch ** Affects: neutron Importance: Undecided Assignee: Takashi Kajinami (kajinamit) 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/2052484 Title: [DEFAULT] rpc_worker=0 leaves one rpc worker Status in neutron: New Bug description: Since https://review.opendev.org/c/openstack/neutron/+/823637 was merged, neutron-server allows disabling rpc worker by setting:: [DEFAULT] rpc_worker=0 However, I observe one rpc worker is still kept even with this setting. From neutron-server log, rpc_workers and rpc_state_report_workers are set to 0. 2024-02-05 13:05:33.159 70458 DEBUG neutron.common.config [-] rpc_state_report_workers = 0 log_opt_values /usr/lib/python3.9/site-packages/oslo_config/cfg.py:2602 2024-02-05 13:05:33.159 70458 DEBUG neutron.common.config [-] rpc_workers = 0 log_opt_values /usr/lib/python3.9/site-packages/oslo_config/cfg.py:2602 ps shows there is one rpc worker running. neutron70458 1 70458 0.3 1.8 133664 144496 /usr/bin/python3 -s /usr/bin/neutron-server ... neutron70499 70458 70499 11.4 3.1 246792 248240 neutron-server: api worker (...) neutron70500 70458 70500 11.0 3.1 243640 249488 neutron-server: api worker (...) neutron70502 70458 70502 0.3 1.7 141196 142132 neutron-server: rpc worker (...) neutron70503 70458 70503 0.3 1.8 145256 146356 neutron-server: MaintenanceWorker (...) neutron70504 70458 70504 0.0 1.7 135472 135604 neutron-server: periodic worker (...) I've noticed this in Puppet OpenStack jobs which uses RDO master packages. The package versions currently used are:: openstack-neutron-24.0.0-0.20240131211457.b85b19e.el9.noarch openstack-neutron-common-24.0.0-0.20240131211457.b85b19e.el9.noarch openstack-neutron-ml2-24.0.0-0.20240131211457.b85b19e.el9.noarch openstack-neutron-ovn-agent-24.0.0-0.20240131211457.b85b19e.el9.noarch openstack-neutron-ovn-metadata-agent-24.0.0-0.20240131211457.b85b19e.el9.noarch openstack-neutron-rpc-server-24.0.0-0.20240131211457.b85b19e.el9.noarch To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2052484/+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 2052760] [NEW] libvirt: swtpm_setup and swtpm are BOTH required for vtpm support
Public bug reported: Description === Currently libvirt driver ensures any of swtpm_setup and swtpm is present for vTPM support. However libvirt requires BOTH of these to setup and run swtpm. Steps to reproduce == * Deploy nova-compute with swtpm support * Remove swtpm_setup from PATH * Restart nova-compute * Check capabilities reported by nova-compute Expected result === The report shows no swtpm support Actual result = The report shows swtpm support Environment === This issue was initially found in master, but would be present in stable branches. Logs & Configs == N/A ** Affects: nova Importance: Undecided Assignee: Takashi Kajinami (kajinamit) 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/2052760 Title: libvirt: swtpm_setup and swtpm are BOTH required for vtpm support Status in OpenStack Compute (nova): New Bug description: Description === Currently libvirt driver ensures any of swtpm_setup and swtpm is present for vTPM support. However libvirt requires BOTH of these to setup and run swtpm. Steps to reproduce == * Deploy nova-compute with swtpm support * Remove swtpm_setup from PATH * Restart nova-compute * Check capabilities reported by nova-compute Expected result === The report shows no swtpm support Actual result = The report shows swtpm support Environment === This issue was initially found in master, but would be present in stable branches. Logs & Configs == N/A To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2052760/+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 2052761] [NEW] libvirt: swtpm_ioctl is required for vTPM support
Public bug reported: Description === Libvirt uses swtpm_ioctl to shutdown the swtpm process at VM termination, because QEMU does not send shutdown command. However the binary is not included in the required binaries (swtpm and swtpm_setup, at the time of writing) checked by libvirt driver. So users can use vTPM support without binaries, which leaves swtpm processes kept running. Steps to reproduce == * Deploy nova-compute with vTPM support * Move swtpm_ioctl from PATH * Restart nova-compute * Check capabilities reported by nova-compute Expected result === The report shows no swtpm support Actual result = The report shows swtpm support Environment === This issue was initially found in master, but would be present in stable branches. Logs & Configs == N/A ** Affects: nova Importance: Undecided Assignee: Takashi Kajinami (kajinamit) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Takashi Kajinami (kajinamit) ** Description changed: Description === - Libvirt uses swtpm_ioctl to shutdown the swtpm process at VM termination, because QEMU does not send shutdown command. However the binary is not included in the required binaries (swtpm and swtpm_setup, at the time of writing) checked by libvirt driver. So users can use vTPM support without binaries, which leaves swtpm processes kept running. Steps to reproduce == * Deploy nova-compute with vTPM support * Move swtpm_ioctl from PATH * Restart nova-compute * Check capabilities reported by nova-compute Expected result === The report shows no swtpm support Actual result = The report shows swtpm support Environment === This issue was initially found in master, but would be present in stable branches. Logs & Configs == N/A -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2052761 Title: libvirt: swtpm_ioctl is required for vTPM support Status in OpenStack Compute (nova): In Progress Bug description: Description === Libvirt uses swtpm_ioctl to shutdown the swtpm process at VM termination, because QEMU does not send shutdown command. However the binary is not included in the required binaries (swtpm and swtpm_setup, at the time of writing) checked by libvirt driver. So users can use vTPM support without binaries, which leaves swtpm processes kept running. Steps to reproduce == * Deploy nova-compute with vTPM support * Move swtpm_ioctl from PATH * Restart nova-compute * Check capabilities reported by nova-compute Expected result === The report shows no swtpm support Actual result = The report shows swtpm support Environment === This issue was initially found in master, but would be present in stable branches. Logs & Configs == N/A To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2052761/+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
